gp3 vs io2 — EBS ボリュームの選択基準

インフラ AWS コスト
読了 6分

EBS ボリュームタイプの選択は、二つの問いに絞られました。「gp3 で足りるか?」と「io2 が必要な条件は何か?」です。この記事はその二つの問いに答える実務基準を整理します。結論を先に書くと、大半のワークロードは gp3 が正解で、io2 は必要条件が明確なときだけ選びます。 スペックと実測の差(fsync、キュー深度)は サーバーが遅い理由 #3 で扱ったので、ここでは AWS 側の選択基準に集中します。価格は us-east-1 基準です。

gp2 の遺産 — なぜまだ gp2 が多いのか #

gp2 は性能がサイズに縛られたモデルでした。GB あたり 3 IOPS が基本なので性能が必要なら容量を膨らませる必要があり、小さいボリュームはバーストクレジットでしのぎ、クレジットが尽きると性能が階段状に落ちました。「数日は問題なかったのに急に遅くなった」という EBS のトラブル事例の大半がこのクレジット枯渇です。

gp3 はこの結び付きを断ち切りました。ところが gp2 時代に作ったボリュームと、その時代のテンプレートや AMI が今も gp2 を作り続けていて、多くのアカウントに gp2 が残っています。gp3 が GB あたり約 20% 安く、変換が無停止なので、残った gp2 は事実上整理の対象です(点検リスト参照)。

gp3 — 独立プロビジョニングと引き上げられた上限 #

gp3 の構造は 3 行に要約できます。

  • 保存容量(約 $0.08/GB・月)と性能を別々に買います。
  • ボリュームサイズと無関係に 3,000 IOPS と 125MiB/s が基本で含まれます。バーストクレジットの概念がありません。
  • さらに必要なら追加 IOPS(3,000 超過分、IOPS あたり約 $0.005/月)と追加スループット(125MiB/s 超過分、MB/s あたり約 $0.04/月)を載せます。

上限も引き上げられました。ボリュームあたり最大 80,000 IOPS、2,000MB/s までプロビジョニングできます(長い間 16,000 IOPS・1,000MB/s で、古い資料には旧上限が残っています)。この引き上げで「gp3 の上限のせいで io2 に行く」という判断の基準線が大きく上がりました。たいていのデータベース級ワークロードも gp3 の範囲に収まります。

一つ注意すべきなのは、ボリュームの上限とは別にインスタンス側の EBS 帯域・IOPS 上限があることです。小さいインスタンスに 80,000 IOPS をプロビジョニングしてもインスタンスの限度で切られます。ボリュームを増強する前に、インスタンスタイプの EBS 最適化スペックを先に確認します。

io2 Block Express — 必要条件が明確なプレミアム #

現行の io2 は Block Express アーキテクチャで、次の条件で選びます。

  • 非常に高い IOPS: ボリュームあたり最大 256,000 IOPS、4,000MB/s。gp3 の上限(80,000)を実測で超えるワークロードの領域です。
  • 一貫したサブミリ秒レイテンシ: Nitro インスタンスとの組み合わせで、ミリ秒未満の安定した I/O レイテンシを提供します。レイテンシのスパイクに敏感なトランザクションデータベースが対象です。
  • 高い耐久性の要求: io2 は 99.999% の耐久性で、gp3(99.8〜99.9%)より桁が上です。ボリューム損失が即インシデントになる単一ボリューム構成なら意味のある差です。
  • IOPS 密度: GB あたり 1,000 IOPS まで設定できるので、小さい容量に高い IOPS が必要な場合は gp3 より有利な領域があります。

価格構造は保存(約 $0.125/GB・月)にプロビジョニングした IOPS の料金が加わる方式で、IOPS 料金は段階制(32,000 まで IOPS あたり約 $0.065、超過分は単価引き下げ)です。同じ性能をプロビジョニングしたとき gp3 より数倍高いので、「念のため io2」は無駄です。

選択基準 — まず実測です #

タイプ選択の順序はスペック比較ではなく実測です。

  1. 現在の消費量を測る — CloudWatch のボリューム指標(VolumeReadOps+VolumeWriteOps を秒あたりに換算、VolumeThroughputPercentage、gp2 なら BurstBalance)でピークの IOPS・スループットを確認します。OS 側では iostat -x の IOPS と aqu-sz、await で実際にボトルネックかを見ます。読み方は サーバーが遅い理由 #3 で扱いました。
  2. ピークが 3,000 IOPS・125MiB/s 以内なら gp3 の基本形で終わりです。大半のウェブ・API サーバー、小規模 DB がここに該当します。
  3. ピークがその上なら gp3 に必要な分だけ IOPS・スループットを載せます。80,000 IOPS・2,000MB/s までは gp3 が io2 よりほぼ常に安いのです。
  4. io2 へ移る条件は、実測の要求が gp3 の上限を超えるか、ミリ秒未満のレイテンシの一貫性・99.999% の耐久性・GB あたり IOPS 密度という明示的な要求があるときです。
  5. スループット中心(シーケンシャル大容量)なら st1 のような HDD 系も残っていますが、gp3 のスループット単価が下がって以降は、gp3 に統一するほうが運用上シンプルな場合が多いのです。

変換の実務 — Elastic Volumes で無停止 #

ボリュームのタイプ・サイズ・性能の変更は、Elastic Volumes でインスタンスを止めずに適用されます。aws ec2 modify-volume で gp2 → gp3 の変換も IOPS の引き上げもオンラインででき、変更後は最適化状態(optimizing)が終わるまで性能が漸進的に適用されます。注意点は二つです。同じボリュームの変更は 6 時間に 1 回だけ可能で、サイズは大きくすることしかできません(縮小は新しいボリュームへ移す必要があります)。

gp2 → gp3 の一括変換では、gp2 のサイズ比例で得ていた IOPS より gp3 の基本(3,000)が低くなる大きいボリューム(1TB 超)がないかだけ確認します。あるなら、そのボリュームだけ IOPS を載せて既存の性能に合わせます。

まとめ #

  • デフォルトは gp3 です。サイズと性能を別々に買い、バーストクレジットがなく、3,000 IOPS・125MiB/s が基本で含まれます。
  • gp3 の上限は 80,000 IOPS・2,000MB/s に引き上げられました。旧上限(16,000)を基準に io2 を選ぶ資料は古いのです。
  • io2 Block Express は超高 IOPS(最大 256,000)、ミリ秒未満のレイテンシの一貫性、99.999% の耐久性、GB あたり IOPS 密度が必要なときの選択です。
  • タイプ選択はスペック表ではなく実測(CloudWatch のボリューム指標、iostat)から始めます。ボリュームの上限に劣らず、インスタンス側の EBS 限度も確認します。
  • gp2 の残存ボリュームは Elastic Volumes で無停止変換できるので、約 20% の削減を先送りする理由がありません。
X