EBSボリュームタイプのシナリオ判断

この単元で学ぶこと

• アクセス特性からEBSタイプを比較する
• 性能制約と容量制約を切り分ける
• 変更・共有・復旧の手順を判断する

本文解説

1. DBが遅いという症状 保存容量が半分空いていても、細かいランダム読取りが多くI/O待ちが発生することがあります。容量不足と性能不足は別です。IOPS、I/Oサイズ、待ち時間、CPUやDBのロック状況を調べます。ストレージが原因と分からないまま高性能タイプへ変更しても、費用だけが増える場合があります。

2. 容量を増やさない改善 200GiBで足りる汎用DBに追加IOPSが必要な場合、gp3なら容量と別に性能を設定できます。既存gp2のバーストに依存していたなら、ピークだけでなく持続負荷を計測して移行設定を決めます。現在の性能上限と価格を確認し、必要な水準だけを割り当てます。

3. 厳しい遅延要求 事業上重要なDBに高い持続IOPSと厳しい遅延目標がある場合、io2 Block Expressを候補にします。接続EC2の対応条件やEBS帯域も評価します。「io2へ変更済み」ではなく、業務ピーク時の実測が目標を満たしたかで合否を判断します。

4. ログ走査の判断 毎日大量ログを順番に読むデータ領域では、ランダムI/O回数より連続転送量が重要です。st1を候補にし、頻度が低く性能要求も緩いならsc1と費用を比較します。OSの起動ディスクには使わず、起動領域と分析用データ領域を分けて考えます。

5. EC2側が限界の場合 複数EBSを増強したのに合計転送量が変わらないとき、EC2のEBS帯域上限が原因かもしれません。単体ボリュームの値を足しただけでは実現性能になりません。EC2の種類、同時I/O、I/Oサイズを確認し、ボリューム追加とEC2変更の効果を分けて試験します。

6. 容量変更後の作業 Elastic Volumesでディスク容量を増やしても、ファイルシステムが元のサイズのままならアプリから使える容量は増えません。事前バックアップを取り、ボリューム変更の状態を確認した後、OS方式に応じた拡張を行います。容量縮小が必要なケースでは別ボリュームへの移行等を検討します。

7. 要件そのものが違う場合 複数AZのWebサーバーで同じアップロードファイルを共有する要件を、単一EBSの性能増強だけでは解決できません。ファイル共有ならEFS等、キーによる保存・取得へ変更できるならS3を比較します。アプリが求めるアクセス方式を先に確認し、似た保存サービスを性能値だけで選ばないことが重要です。

8. 復旧の実験 あるAZのEC2が使えない訓練では、利用可能なスナップショットから別AZにボリュームを作り、アプリを復元します。最新書込みが含まれるか、DBが整合しているか、復元直後の読取り性能が足りるかを測ります。ディスクが作れたことと業務が再開したことを分けて記録します。

図解

重要ポイント

• 空き容量があってもI/O性能不足は起こる
• gp3の性能独立設定とEC2側制限を合わせて見る
• 復元はディスク作成だけでなくアプリ利用まで検証する

間違えやすい点

• EBS帯域の合計がEC2上限を越えて使えると思わない
• HDDの連続転送適性を小さなランダムDBへそのまま当てはめない
• EBSの性能変更を共有ファイル要件の解決策にしない

用語解説

持続負荷

一時的なピークでなく継続して発生する処理量。

I/O待ち

読み書きの完了を待つため処理が進まない時間。

ファイルシステム拡張

増えたブロック容量をOSのファイル保存領域として使えるようにする操作。

関連教材

• EBSボリュームタイプを理解する