Amazon EBS のボリューム設計と運用 - gp3・io2 の選定基準とスナップショット戦略

EBS ボリュームタイプの選定基準

この記事は約 4 分で読めます。 EBS には汎用 SSD (gp3/gp2)、プロビジョンド IOPS SSD (io2/io2 Block Express)、スループット最適化 HDD (st1)、コールド HDD (sc1) の 4 カテゴリがあります。選定の出発点は gp3 です。gp3 はベースラインとして 3,000 IOPS と 125 MiB/s を追加料金なしで提供し、必要に応じて最大 16,000 IOPS・1,000 MiB/s まで独立してスケールできます。gp2 では IOPS がボリュームサイズに比例するため、IOPS を増やすにはボリュームを大きくする必要がありましたが、gp3 ではこの制約がなくなりました。io2 Block Express はデータベースワークロード向けで、1 ボリュームあたり最大 256,000 IOPS を実現します。99.999% の年間耐久性 SLA を提供する唯一のボリュームタイプであり、Oracle や SAP HANA のようなミッションクリティカルなワークロードに適しています。st1 はビッグデータやログ処理など、シーケンシャルリードが中心のワークロードに向いており、最大 500 MiB/s のスループットを低コストで提供します。

この分野について体系的に学びたい方は、関連書籍 (Amazon) も参考になります。

IOPS とスループットの設計

IOPS の要件を見積もるには、アプリケーションの I/O パターンを把握する必要があります。データベースのようなランダム I/O が多いワークロードでは IOPS が律速になり、ETL やログ分析のようなシーケンシャル I/O ではスループットが律速になります。CloudWatch の VolumeReadOps、VolumeWriteOps メトリクスで実際の IOPS を計測し、VolumeQueueLength が常に 1 を超えている場合はボリュームが I/O ボトルネックになっています。gp3 で IOPS を追加する場合、1 IOPS あたり約 0.006 USD/月 (東京リージョン) のコストが発生します。16,000 IOPS を超える要件がある場合にのみ io2 への移行を検討すべきです。io2 は 1 IOPS あたり約 0.074 USD/月と gp3 の約 12 倍のコストになるため、本当に必要な IOPS を正確に見積もることがコスト最適化の鍵です。

スナップショット戦略とバックアップ設計

EBS スナップショットは増分方式で、前回のスナップショット以降に変更されたブロックのみを S3 に保存します。初回は全データをコピーしますが、2 回目以降は差分のみのため、ストレージコストと作成時間が大幅に削減されます。スナップショットの自動化には Amazon Data Lifecycle Manager (DLM) を使用します。DLM ポリシーでタグベースのスケジュールを定義し、日次・週次のスナップショット作成と世代管理を自動化できます。本番環境では、DLM で日次スナップショットを 7 世代保持し、週次スナップショットを 4 世代保持する構成が一般的です。クロスリージョンコピーを有効にすれば、リージョン障害時の DR にも対応できます。Fast Snapshot Restore (FSR) は、スナップショットから復元したボリュームの初回アクセス時に発生するレイテンシペナルティを排除する機能です。データベースのように初回アクセスのレイテンシが許容できないワークロードでは FSR の有効化を推奨します。

さらに詳しく知りたい方は、関連書籍 (Amazon) で理解を深められます。

まとめ - EBS 設計のベストプラクティス

EBS ボリューム設計の基本方針は、gp3 から始めて CloudWatch メトリクスで実測し、必要に応じてスケールアップすることです。IOPS とスループットを独立して調整できる gp3 の柔軟性を活かし、過剰プロビジョニングを避けます。スナップショットは DLM で自動化し、クロスリージョンコピーで DR に備えます。ボリュームタイプの変更はオンラインで実行可能なため、最初から最適解を狙う必要はなく、実測データに基づいて段階的に最適化するアプローチが有効です。