どんな場面で検討するか
EC2 上の既存アプリや DB が通常のディスクを必要とし、容量とランダム I/O 性能を分けて調整したい場合。ファイル保存だけでなく OS が扱う永続ブロックデバイスが必要な用途。
組織で使う条件
容量逼迫、I/O 待ち、ボリューム型と性能の設定、暗号化鍵への権限を監視する。EC2 側の帯域制約も合わせて確認する。 バックアップ間隔と保存期間、業務を静止または整合させる方法、復旧用インスタンスと手順を管理する。スナップショットの一覧があることと復元できることを区別する。
採用前に試すこと
- 検証 EC2 と同 AZ に暗号化 gp3 ボリュームを作り、ファイルを保存して I/O の測定条件を記録する。
- アプリ書込みを整合させてスナップショットを作り、別の検証用ボリュームへ復元して別インスタンスで開く。
- 容量・IOPS・スループットの設定変更を試し、不要なボリュームとバックアップを洗い出す。
合格と判断する条件
- 全ファイルの読み戻しハッシュが一致し、必要容量と I/O 要件に対して設定不足がない。
- 復元後の全ハッシュとアプリの整合性検査が一致し、復元時間が事前に定めた要件内に収まる。
- 変更前後の性能差を同条件で説明でき、必要な復旧点を保持しながら不要な課金リソースを一覧化できる。
見落としたくない点
- 複数拠点からオブジェクトを直接共有するだけなら S3、一般的な共有ファイルシステムなら EFS 等と比較する。通常ボリュームを複数サーバーの共有ディスクとみなさない。 EBS の存在だけで AZ 障害時の DB 復旧やデータ整合性が解決するとは判断しない。Multi-Attach には対象型やファイルシステム側の条件があり、汎用の共有用途として採用しない。
- 複数拠点からオブジェクトを直接共有するだけなら S3、一般的な共有ファイルシステムなら EFS 等と比較する。通常ボリュームを複数サーバーの共有ディスクとみなさない。
- EBS の存在だけで AZ 障害時の DB 復旧やデータ整合性が解決するとは判断しない。Multi-Attach には対象型やファイルシステム側の条件があり、汎用の共有用途として採用しない。