From 3175373e477ce7215f63713efe31087569ef1205 Mon Sep 17 00:00:00 2001 From: suecharo Date: Thu, 18 Apr 2024 12:50:15 +0900 Subject: [PATCH] Update README --- README.md | 299 ++++++++++++++++-------------------- README.prev-cli.md | 40 ----- README.prev-gui.md | 15 -- backup_policy.md | 153 ++++++++++++++++++ src/components/IntroSec.tsx | 4 +- 5 files changed, 284 insertions(+), 227 deletions(-) delete mode 100644 README.prev-cli.md delete mode 100644 README.prev-gui.md create mode 100644 backup_policy.md diff --git a/README.md b/README.md index 6d6d0b1..3f6d6d2 100644 --- a/README.md +++ b/README.md @@ -1,176 +1,135 @@ # DBCLS Backup System: Zuke -## 概要 +A backup system for DBCLS internal physical servers. + +Application is available at [https://dbcls.github.io/backup-system/](https://dbcls.github.io/backup-system/). + +## Abstract - DBCLS 内の物理サーバ上のデータのバックアップを行うためのシステム - 天災や人災によるデータの損失に備える - 単に `rsync` を設定するだけだと、コストが掛かりすぎる -- そのため、データごとにコスト感などを確認しつつ、バックアップポリシー (e.g., バックアップ頻度、バックアップ先) を管理しなければならない - - -> GUI として、バックアップポリシー管理 app を実装する -- 更に、設定されたポリシー (実体としては Json) を元に、実際の backup 処理を行う script を実装する - - この script を cron などで定期的に実行する - -## Components - -- `zuke-gui` - - バックアップポリシー管理 app - - script でさらってきた、file ストを展開して、User がそれぞれの file に対してバックアップポリシーを設定する - - この際、コスト感などを意識しつつ、設定できるようにする - - SPA として実装する - - github.io などに deploy する - - 状態の永続化は行わず、状態の import/export button を実装する -- `zuke-cli` - - `zuke-gui` で設定されたポリシーを元に、実際の backup 処理を行う cli - - cron などで定期的に実行する - - cron の設定や、cli の command などは、`gui` の方で生成できるようにしておく - -## Backup Policy - -データに紐づくポリシーの設定項目として、以下が考えられる - -- バックアップ頻度 - - e.g., daily, weekly, monthly -- バックアップ先 - - file storage (e.g., linux storage) or object storage (e.g., s3) - - バックアップ方式により、決定される - - incremental backup -> file storage - - full backup -> object storage - - object storage の中でも、更に tape storage なども選択に上がる -- バックアップ方式 - - full backup か incremental backup (差分 backup) か -- バックアップの世代管理 (保持期間) - - incremental backup が 1 世代の場合、実質的に full backup と同じ - - full backup を複数世代保持するということは、一旦考慮しない -- バックアップの暗号化 - - する or しない - - -> 今回は storage 側の機能で暗号化する -- バックアップの圧縮 - - する or しない - - -> 今回は、可能な限り圧縮を行う - -それぞれのデータの特性に応じて、これらのポリシーを設定するべきであるが、同時に、コストも考慮しなければならない。 -そのため、下記のようなバックアップポリシーとバックアップ方式 (コストを含む) の対応表を作成した。 -ユーザは、ポリシーを細かく設定するのではなく (可能だがユーザの負担増、要 PoC)、ある程度整理されたバックアップ方式をコストを考慮しつつ選択する。 - -| 頻度 | 方式 | 世代管理 | バックアップ方式 | -| --- | --- | --- | --- | -| daily | full/inc. | 1 gen. | object storage に backup。更新頻度が高く、size が小さいデータを想定 | -| daily | full | 7 gen. | 考慮しない ("object storage に full" と "file storage に inc." のコスト感を後述する) | -| daily | inc. | 7 gen. | file storage に rsync。更新頻度が高く、size が小さいデータを想定 | -| weekly | full/inc. | 1 gen. | object storage に backup。更新頻度が比較的低いデータを想定 | -| weekly | inc. | 4 gen. | file storage に rsync。更新頻度が比較的低いデータを想定 | -| monthly | full/inc. | 1 gen. | object storage (tape) に backup。データ量が大きく重要性の高いデータを想定 | - -- 上の表は網羅性としては、不十分である - - 例えば、`monthly - inc. - 6 gen.` なども考えられるが、データ量が大きいものを file storage に差分 backup するのはコストが掛かりすぎて現実的でない部分もある - - 保持し続けるだけでコストが掛かるため、可用性のための backup としては適切ではない - - そのため、バックアップ方式を選ぶ UI からは、このような選択肢を削除する - - ポリシーを細かく設定する UI も考えられる - - 両方、検証してみて pros./cons. を検討する - -## データの保存先の調査・検討 - -要件として、可用性や耐障害性が求められるため、機関インフラ内で NAS などを運用し、そこをデータの保存先とすることは考慮しない - -### まとめ - -下の内容をコストを考慮し先にまとめたもの - -#### file storage (for rsync) - -t3.medium 相当のインスタンス + 10 TB storage を利用すると想定 (data upload 料金はどこも基本的に無料) - -- `さくらインターネット` - - 114,620 yen/month -- `AWS EC2 + EBS (gp2, SSD)` - - 274,514 yen/month -- `AWS EC2 + EBS (st1, HDD, アトランタ)` - - 105,764 yen/month -- `AWS EC2 + EBS (sc1, コールド HDD, アトランタ)` - - 38,264 yen/month -- `AWS EC2 + EFS (standard)` - - 244,514 yen/month -- `AWS EC2 + EFS (low freq. access)` - - 24,514 yen/month - -#### object storage (for full backup) - -1 GB あたりの料金を比較 - -- `さくらインターネット` - - 4.95 yen/month (ただし、転送量 8.8 yen/GB) -- `S3 標準` - - 3.75 yen/month -- `S3 標準 - 低頻度アクセス` (ミリ秒単位のアクセスが必要な、長期保管だがアクセス頻度の低いデータ) - - 2.07 yen/month -- `S3 Glacier Instant Retrieval` (ミリ秒単位で瞬時に取り出し、四半期に 1 回アクセスするような長期保存のアーカイブデータ) - - 0.75 yen/month - -### 機関 object storage - -- "オブジェクトストレージ@柏Ⅱ" - - ActiveScale (S3 互換) - - 300TB - - S3 互換 API が提供されているが、そちらを利用せず、rsync 先の file storage として利用することも可能だと思われる - -### さくらインターネット - -- 大口としての契約は問い合わせが必要 -- いわゆるインスタンス貸しは "さくらクラウド" - - - - データの転送量は無料 - - 石狩リージョンと東京リージョンが選択可能 - - 石狩リージョンの方が安価かつ、可用性を考慮すると石狩の方が better - - 12 TB で 132,000 yen/month - - 11.0 yen/month - - 2core + 4GB (t3.medium 相当) の使用料は 4,620 yen/month -- オブジェクトストレージ - - - - データの転送量は無料 - - だが、10 GB / month を超えると 1GB あたり 8.8円 - - upload or download かの記述はなし - - S3 互換 API を提供 - - 1GB あたり 4.95円 - -### AWS - -- わかりやすい資料として - -- Block Storage (File Storage) - - Amazon Elastic Block Store (EBS) - - EC2 にアタッチして利用するブロックストレージ - - rsync 的に世代 backup したいならこちら - - - - 東京・大阪リージョンの場合、`汎用 SSD (gp2) ボリューム` (SSD) しか利用できない - - HDD だと `スループット最適化 HDD (st1)` や `コールド HDD (sc1)` がある (アトランタリージョン) - - st1: 1 GB あたり 10.125 yen/month - - sc1: 1 GB あたり 3.375 yen/month - - 1 GB あたり 27 yen/month - - -> さくらインターネットの方が安価 - - インターネット -> EC2 への転送量は無料 - - ref: - - EC2 instance t3.medium (2core, 4gb) の料金は 4514.4 yen/month - - Amazon EC2 Instance Store - - - - "インスタンスストアを一時的なストレージとして使用します。インスタンスストアボリュームに保存されたデータは、インスタンスの停止、終了、またはハードウェア障害が発生しても保持されません。" - - -> EBS を使うべき -- File Storage - - Amazon Elastic File System (EFS) - - EC2 に NFS mount する storage - - size はデータ量に応じて自動拡張される - - EC2 からのデータ転送は無料 - - - - 大阪リージョンを想定 - - スタンダード: 1 GB あたり 24 yen/month - - 低頻度アクセス (四半期に数回しかアクセスされないデータに対してコスト最適化): 1 GB あたり 2 yen/month -- Object Storage - - Amazon Simple Storage Service (S3) - - upload は無料 - - download は deep なほど高価 (e.g., S3 Glacier: 3.3 yen/GB) - - - - 大阪リージョンを想定 - - S3 標準: 1 GB あたり 3.75 yen/month - - S3 標準 - 低頻度アクセス (ミリ秒単位のアクセスが必要な、長期保管だがアクセス頻度の低いデータ): 1 GB あたり 2.07 yen/month - - S3 Glacier Instant Retrieval (ミリ秒単位で瞬時に取り出し、四半期に 1 回アクセスするような長期保存のアーカイブデータ): 1 GB あたり 0.75 yen/month - - S3 Glacier Deep Archive (1 年に 1〜2 回アクセスされ、12 時間以内に復元できる長期のデータアーカイブ): 1 GB あたり 0.3 yen/month - - -> 最短保存期間が 180 日なので、今回の要件には合わないと思われる +- そのため、データごとにコスト感などを確認しつつ、バックアップポリシー (e.g., バックアップ頻度、バックアップ先, etc.) を設定・管理しなければならない + - GUI として、バックアップポリシー管理 app (Zuke) +- 更に、設定されたポリシー (実体としては JSON) を元に、実際の backup 処理を行う script も出力する + - この script を cron などで定期的に実行することで、バックアップを実現する + +## Zuke + +- バックアップポリシー設定・管理 app +- 実体としては、React で書かれた Single Page Application (SPA) + - 外部通信/情報の永続化などは行わない + - -> 代わりに State の Import/Export 機能を実装する + - GitHub Pages に deploy されている + - -> [https://dbcls.github.io/backup-system/](https://dbcls.github.io/backup-system/) +- App 内の手順として、 + - 1. `"File List の読み込み"`: Server 上で、script (`du` や `find`) を実行し、App に読み込ませる + - 2. `"Backup Policy の設定"`: File ごとに、Policy (頻度や Backup 先) を設定する + - 3. `"3. Server での設定"`: 生成された Backup script を Server 上に設定する +- 汎用的なものとして実装する + - 一度、日本語で PoC を作成し、その結果をもって完全英語化するかを検討する + +### ポリシーの事前設定 + +- バックアップポリシーについての考察は、別 docs [./backup_policy.md](./backup_policy.md) を参照 +- Admin は、ポリシー (e.g., バックアップ頻度、バックアップ先, etc.) を事前に設定する + - [`./src/policyConfig.json`](./src/policyConfig.json) に記述する + - [`./src/policyDocs.md`](./src/policyDocs.md) には、レンダリングしたいドキュメントを記述する +- この File の中身の例として、 + +```json +[ + { + "id": "daily", + "label": "Daily", + "generation": 7, + "interval": 1, + "diffRatio": 1, + "costPerMonth": 0.025, + "constCost": 0 + }, + { + "id": "weekly", + "label": "Weekly", + "generation": 4, + "interval": 7, + "diffRatio": 0.1, + "costPerMonth": 0.02, + "constCost": 29.95 + }, +] +``` + +それぞれの項目の説明として、 + +```typescript +/* +* - id: ポリシーの ID +* - label: ポリシーの Label (Button に表示される文字列) +* - generation: 何世代分保持するか +* - interval: 何日ごとに full backup するか (e.g., daily なら 1, weekly なら 7) +* - diffRatio: incremental backup の差分データ量の割合 (0.01 なら 1%) +* - 1 の場合、Full Backup となる +* - costPerMonth: GB あたりの 1 ヶ月分のコスト (USD、0.01 USD/GB/month なら 0.01) +* - constCost: 固定コスト (e.g., AWS EC2 インスタンス, 月額 USD) +*/ +export interface PolicyConfig { + id: string + label: string + generation: number + interval: number + diffRatio: number + costPerMonth: number + constCost: number +} +``` + +必要に応じて、これらの File を変更することで、ポリシーの設定を変更できる。 + +### Backup Script 生成 + +- Under development (TODO) +- Server Location や S3 Bucket の情報も渡さなければならない +- Discussion として、 + - GUI の画面上に、生成された script を表示する + - `rsync`, `s3`, `rclone`, etc. などを実行する script になると思われる + - 考慮するべき点として、 + - Disk IO + - `ionice -c2 -n7 rsync` などで制限する？ + - CPU/Memory Usage + - `nice` などで制限する？ + - Network IO + - `tc tbf | netem` などで制限する？ + - 死活監視 + - Slack notification などを設定できるようにする？ +- 複雑なことをしたくなると、CLI command を用意して、それに JSON を渡したくなるが、CLI command のメンテナンス性や寿命とのトレードオフになる (例えば、Python の Version の変更など) + - -> なるべく、メンテナンスフリーで長期間稼働してほしい + +### 復旧方法 + +- Under development (TODO) +- 環境に強く依存する部分だから汎用化が難しい + - 復旧する際は、そのまま戻すのではなく、環境自体 (e.g., サーバのハードウェア, etc.) が刷新されるはず + +### Development + +開発環境: + +```bash +docker compose -f compose.dev.yml up -d --build +docker compose -f compose.dev.yml exec npm run dev +``` + +Release: + +```bash +bash release.sh +# 1. 設定ファイルの version を更新 +# 2. git commit & tag & push +# (3. GitHub Actions で自動的に image/release/pages が生成・公開される) +``` + +## License + +This project is licensed under [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0). +See the [LICENSE](./LICENSE) file for details. diff --git a/README.prev-cli.md b/README.prev-cli.md deleted file mode 100644 index a0584c3..0000000 --- a/README.prev-cli.md +++ /dev/null @@ -1,40 +0,0 @@ -# Zuke-cli - -- Server 上で実行される script 群 -- `../zuke-gui/src/assets` 以下にも同じ script 群 - - gui 側で配信するか、github の raw content を参照するか未定 - -## `get_file_list.sh` - -- server 上の file list を取得してくる script -- zuke-gui で読み込む - -Usage: - -```bash -./get_file_list.sh -d -``` - -## Backup script - -- 実装案として、 - - 1. Backup policy を元に zuke-gui 側で自動生成する - - 2. 前もって script を書いておき、policy を入力とする -- 内部で叩くコマンドとして、`rsync`, `s3`, `rclone`, etc. - - macOS の TimeMachine も `rsync` の機構で実装されている - - ref.: linux 版の TimeMachine - - -- その他考慮するべき点として、 - - Disk io - - `ionice -c2 -n7 rsync` などで、disk IO を制限するべき - - CPU/Memory - - `nice` command で制限する - - Network IO - - `tc tbf|netem` で上限を決める - - 死活監視 - - Slack notification など - -## 復旧方法 - -- 未定 -- Upload 先の Data location を管理するのはやっておかなければならない diff --git a/README.prev-gui.md b/README.prev-gui.md deleted file mode 100644 index b90fcf2..0000000 --- a/README.prev-gui.md +++ /dev/null @@ -1,15 +0,0 @@ -# Zuke-gui - -- Backup policy を設定するための GUI app -- 汎用的なものとして実装する - - policy の選択肢を、外部変数化し、動的に描画する - - 一度、日本語で PoC を作成し、その結果をもって完全英語化するかを検討する - ---- - -開発環境の起動方法として、 - -```bash -docker compose up -d --build -docker compose exec npm run dev -``` diff --git a/backup_policy.md b/backup_policy.md new file mode 100644 index 0000000..b7cc7a4 --- /dev/null +++ b/backup_policy.md @@ -0,0 +1,153 @@ +# バックアップポリシーについての考察 + +データに紐づくポリシーの設定項目として、以下が考えられる + +- バックアップ頻度 + - e.g., daily, weekly, monthly +- バックアップ方式 + - incremental backup (差分 backup) か full backup か +- バックアップ先 + - file storage (e.g., linux storage) or object storage (e.g., s3) + - バックアップ方式により、決定される + - incremental backup -> file storage + - full backup -> object storage + - object storage の中でも、更に tape storage なども選択に上がる +- バックアップの世代管理 (保持期間) + - incremental backup が 1 世代の場合、実質的に full backup と同じ +- バックアップの暗号化 + - する or しない + - -> 今回は考慮しない +- バックアップの圧縮 + - する or しない + - -> 今回は考慮しない + +それぞれのデータの性質に応じて、これらのポリシーを設定するべきであるが、同時に、コストも考慮しなければならない。 +そのため、まず、下記のようなバックアップポリシーとバックアップ方式の対応表を作成した。 + +| 頻度 | 方式 | 世代管理 | バックアップ方式 | +| --- | --- | --- | --- | +| daily | full/inc. | 1 gen. | object storage に backup。更新頻度が高く、size が小さいデータを想定 | +| daily | full | 7 gen. | スコープ外 | +| daily | inc. | 7 gen. | file storage に rsync。更新頻度が高く、size が小さいデータを想定 | +| weekly | full/inc. | 1 gen. | object storage に backup。更新頻度が比較的低いデータを想定 | +| weekly | inc. | 4 gen. | file storage に rsync。更新頻度が比較的低いデータを想定 | +| monthly | full/inc. | 1 gen. | object storage (低頻度アクセス) に backup。データ量が大きく重要性の高いデータを想定 | + +- 上の表は網羅性としては、不十分である + - 例えば、`monthly - inc. - 6 gen.` なども考えられるが、データ量が大きいものを file storage に差分 backup するのはコストが掛かりすぎて現実的でない部分もある + - 保持し続けるだけでコストが掛かるため、可用性のための backup としては適切ではない + - そのため、バックアップ方式を選ぶ UI からは、このような選択肢を削除する + - ポリシーを細かく設定する UI (もしくはポリシーを自由に追加できる UI) も考えられる + - 両方、検証してみて pros./cons. を検討する + +## データの保存先の調査・検討 + +- 要件として、可用性や耐障害性が求められる + - そのため、機関インフラ内で NAS などを運用し、そこをデータの保存先とすることは考慮しない + +### まとめ + +下の保存先案を、コストを軸に先にまとめる + +#### File storage (for incremental backup) + +t3.medium 相当のインスタンス + 10 TB storage を利用すると想定 (data upload 料金はどこも基本的に無料) + +- `さくらインターネット` + - 114,620 yen/month +- `AWS EC2 + EBS (gp2, SSD)` + - 274,514 yen/month +- `AWS EC2 + EBS (st1, HDD, アトランタ)` + - 105,764 yen/month +- `AWS EC2 + EBS (sc1, コールド HDD, アトランタ)` + - 38,264 yen/month +- `AWS EC2 + EFS (standard)` + - 244,514 yen/month +- `AWS EC2 + EFS (low freq. access)` + - 24,514 yen/month + +#### Object storage (for full backup) + +1 GB あたりの料金を比較 + +- `さくらインターネット` + - 4.95 yen/month (ただし、転送量 8.8 yen/GB) +- `S3 標準` + - 3.75 yen/month +- `S3 標準 - 低頻度アクセス` (ミリ秒単位のアクセスが必要な、長期保管だがアクセス頻度の低いデータ、最低ストレージ期間 30 日) + - 2.07 yen/month +- `S3 Glacier Instant Retrieval` (ミリ秒単位で瞬時に取り出し、四半期に 1 回アクセスするような長期保存のアーカイブデータ) + - 0.75 yen/month + +### 保存先案: 機関 object storage + +- "オブジェクトストレージ@柏Ⅱ" + - ActiveScale (S3 互換) + - 300TB + - S3 互換 API が提供されているが、そちらを利用せず、rsync 先の file storage として利用することも可能だと思われる + +### 保存先案: さくらインターネット + +- 大口としての契約は問い合わせが必要 +- いわゆるインスタンス貸しは "さくらクラウド" + - + - データの転送量は無料 + - 石狩リージョンと東京リージョンが選択可能 + - 石狩リージョンの方が安価かつ、可用性を考慮すると石狩の方が better + - 12 TB で 132,000 yen/month + - 11.0 yen/month + - 2core + 4GB (t3.medium 相当) の使用料は 4,620 yen/month +- オブジェクトストレージ + - + - データの転送量は無料 + - だが、10 GB / month を超えると 1GB あたり 8.8円 + - upload or download かの記述はなし + - S3 互換 API を提供 + - 1GB あたり 4.95円 + +### 保存先案: AWS + +- わかりやすい資料として + +- Block Storage (File Storage) + - Amazon Elastic Block Store (EBS) + - EC2 にアタッチして利用するブロックストレージ + - rsync 的に世代 backup したいならこちら + - + - 東京・大阪リージョンの場合、`汎用 SSD (gp2) ボリューム` (SSD) しか利用できない + - HDD だと `スループット最適化 HDD (st1)` や `コールド HDD (sc1)` がある (アトランタリージョン) + - `st1`: 1 GB あたり 10.125 yen/month + - `sc1`: 1 GB あたり 3.375 yen/month + - `gp2`: 1 GB あたり 27 yen/month + - -> さくらインターネットの方が安価 + - インターネット -> EC2 への転送量は無料 + - ref: + - EC2 instance t3.medium (2core, 4gb) の料金は 4514.4 yen/month + - Amazon EC2 Instance Store + - + - "インスタンスストアを一時的なストレージとして使用します。インスタンスストアボリュームに保存されたデータは、インスタンスの停止、終了、またはハードウェア障害が発生しても保持されません。" + - -> EBS を使うべき +- File Storage + - Amazon Elastic File System (EFS) + - EC2 に NFS mount する storage + - size はデータ量に応じて自動拡張される + - EC2 からのデータ転送は無料 + - + - 大阪リージョンを想定 + - `スタンダード`: 1 GB あたり 24 yen/month + - `低頻度アクセス (四半期に数回しかアクセスされないデータに対してコスト最適化)`: 1 GB あたり 2 yen/month +- Object Storage + - Amazon Simple Storage Service (S3) + - upload は無料 + - download は deep な storage なほど高価 (e.g., S3 Glacier: 3.3 yen/GB) + - + - 大阪リージョンを想定 + - `S3 標準`: + 1 GB あたり 3.75 yen/month + - `S3 標準 - 低頻度アクセス` (ミリ秒単位のアクセスが必要な、長期保管だがアクセス頻度の低いデータ、最低ストレージ期間 30 日): + - 1 GB あたり 2.07 yen/month + - `S3 Glacier Instant Retrieval` (ミリ秒単位で瞬時に取り出し、四半期に 1 回アクセスするような長期保存のアーカイブデータ): + - 1 GB あたり 0.75 yen/month + - `S3 Glacier Deep Archive` (1 年に 1-2 回アクセスされ、12 時間以内に復元できる長期のデータアーカイブ): + - 1 GB あたり 0.3 yen/month + - -> 最短保存期間が 180 日なので、今回の要件には合わないと思われる diff --git a/src/components/IntroSec.tsx b/src/components/IntroSec.tsx index 7be5ffd..d282aa0 100644 --- a/src/components/IntroSec.tsx +++ b/src/components/IntroSec.tsx @@ -10,8 +10,8 @@ interface IntroSecProps { const descContent = ` - Server 上の Data の Backup 設定を生成するための GUI App です。下の項目を順に行ってください - - \`"1. File List の読み込み"\`: Server 上で、script (\`du\` や \`find\`) を実行し、この App に読み込ませる - - \`"2. Backup Policy の設定"\`: file ごとなどに、Policy (頻度や Backup 先) を設定する + - \`"1. File List の読み込み"\`: Server 上で、script (\`du\` や \`find\`) を実行し、この App に読み込ませる + - \`"2. Backup Policy の設定"\`: File ごとに、Policy (頻度や Backup 先) を設定する - \`"3. Server での設定"\`: 生成された Backup script を Server 上に設定する - この App は、SPA (Single Page Application) で、全ての処理は Browser 上で行います - どこかの Server に情報を送信することはありません