EBS gp2 vs gp3 実測ベンチマーククイズ

1. 持続的な 4k ランダムリード（qd32）において、100 GiB の gp2 ボリュームで実測された IOPS はどのような挙動を示しましたか？
   • A) 開始時から 300 IOPS 前後で緩やかに推移した
   • B) 約 33 分間（1,999 秒）は gp3 と同じ 3,001 IOPS だった後、1 秒以内に 300 IOPS まで低下した
   • C) 3,000 IOPS で始まり、45 分かけて徐々に 300 IOPS まで低下した
   • D) 45 分間ずっと 3,000 IOPS を維持した

回答を表示

回答: B) 約 33 分間（1,999 秒）は gp3 と同じ 3,001 IOPS だった後、1 秒以内に 300 IOPS まで低下した

解説: fio の秒単位の IOPS ログでは、1,998 秒で 3,001、1,999 秒で 2,659、2,000 秒で 300 が記録されました。クレジットが残っている間、gp2 は gp3 と区別できません。クレジットが尽きた瞬間、スイッチが切り替わったかのように性能の 90% が失われます。正確な表現は「gp2 は遅い」ではなく、「gp2 は突然遅くなる」です。

2. 100 GiB の gp2 ボリュームのバースト継続時間が約 2,000 秒と計算されるのはなぜですか？
   • A) 5,400,000 クレジット ÷ (3,000 − 300) IOPS = 2,000 秒
   • B) 100 GiB × 20 秒/GiB = 2,000 秒
   • C) 3,000 IOPS ÷ 1.5 = 2,000 秒
   • D) AWS がボリュームサイズにかかわらず 2,000 秒に固定している

回答を表示

回答: A) 5,400,000 クレジット ÷ (3,000 − 300) IOPS = 2,000 秒

解説: gp2 のベースラインは 3 IOPS/GiB（100 GiB → 300 IOPS）で、クレジットバケットは 540 万クレジットです。3,000 IOPS でバーストすると、ベースラインが補充する 300 を差し引いて、毎秒 2,700 クレジットを消費します。そのため、5,400,000 ÷ 2,700 = 2,000 秒です。ボリュームが大きいほどベースラインは高く、クレジットの消費は遅くなります。1 TiB 以上ではベースラインがすでに 3,000 であるため、急落は起こりません。

3. クレジット枯渇後、gp2 の qd32 平均レイテンシーは約 106 ms でした。正しい解釈はどれですか？
   • A) EBS デバイスの応答時間が 100 ms より遅くなった
   • B) Little の法則により、32 個の未完了 I/O ÷ 300 IOPS ≈ 106.7 ms となる。これはキューでの待機時間である
   • C) ネットワークレイテンシーが急増した
   • D) fio の測定エラーである

回答を表示

回答: B) Little の法則により、32 個の未完了 I/O ÷ 300 IOPS ≈ 106.7 ms となる。これはキューでの待機時間である

解説: 平均レイテンシー = 未完了 I/O 数 ÷ スループットです。毎秒 300 件しか完了しない状況で 32 個の I/O を実行中に保つと、各 I/O は平均 106.7 ms 待機します。3,000 IOPS 時の 10.4 ms も同じ計算です（32 ÷ 3,000 = 10.7 ms）。qd32 ベンチマークにおけるレイテンシーはキューイング時間です。デバイスレイテンシーは qd1 の測定値が示すものです（gp3: 0.56 ms）。

4. クレジット枯渇直後に gp2 で実行した 120 秒間のランダムライトテストが、300 ではなく 601 IOPS を測定したのはなぜですか？
   • A) ライトはクレジットを消費しない
   • B) 先行する 120 秒間のアイドル中に、gp2 は 300 クレジット/秒 × 120 秒 = 36,000 クレジットを蓄積し、120 秒のテストにおいて 300 IOPS が加わった
   • C) fio はライト IOPS を 2 回カウントする
   • D) gp2 のライトベースラインはリードベースラインの 2 倍である

回答を表示

回答: B) 先行する 120 秒間のアイドル中に、gp2 は 300 クレジット/秒 × 120 秒 = 36,000 クレジットを蓄積し、120 秒のテストにおいて 300 IOPS が加わった

解説: gp2 のクレジットバケットは、一度使い切っても永遠に空のままではありません。ボリュームがアイドル状態のときに 3 クレジット/GiB/秒（100 GiB → 300/秒）で再び貯まる銀行口座のようなものです。120 秒で 36,000 クレジットを消費すると、300 のベースラインに 300 IOPS がちょうど加わり、600 IOPS になります（実測: 601）。qd1 テストの 603 IOPS も、60 秒間のアイドル中に 18,000 クレジットが蓄積されたことによる、同じ計算結果です。これが、断続的なトラフィック下の gp2 が「速い日もあれば遅い日もある」理由です。

5. qd1 の 4k ランダムリードテストで、スロットリングされた gp2 は p50 0.602 ms、p95 3.391 ms を示しました。この分布は何を意味しますか？
   • A) gp2 デバイスは本質的に gp3 より遅い
   • B) デバイスは gp3 と同じである（p50 は gp3 の 0.569 ms とほぼ等しい）。ただし、毎秒の許容量を超えた I/O はスロットルキューで待機し、二峰性の分布を生じさせた
   • C) テスト中に別の Pod がボリュームを共有していた
   • D) ランダムリードは常に二峰性の分布を示す

回答を表示

回答: B) デバイスは gp3 と同じである（p50 は gp3 の 0.569 ms とほぼ等しい）。ただし、毎秒の許容量を超えた I/O はスロットルキューで待機し、二峰性の分布を生じさせた

解説: gp2 の I/O の半分は、gp3 とまったく同じく 0.6 ms で完了しました。残り半分は、毎秒の許容量（約 603 IOPS）を超えた I/O がスロットルキューに保持されたため、3.4～3.6 ms になりました。平均値だけを見ると 1.65 ms、つまり「少し遅い」程度ですが、p95 は 6 倍に上昇しました。このため、ストレージダッシュボードには p95/p99 とともに p50 が必要です。

6. 1 MiB のシーケンシャルリード/ライトテストで、gp2 と gp3 の両方が 125～130 MiB/s で頭打ちになったのはなぜですか？
   • A) gp3 は 125 MiB/s のベースラインに達し、gp2（≤170 GiB）は 128 MiB/s の上限に達したため。両方の値がたまたま近い
   • B) m5.xlarge インスタンスのネットワーク帯域幅制限
   • C) fio の iodepth=8 がボトルネックだった
   • D) gp2 のクレジットが尽きて両方のボリュームが遅くなった

回答を表示

回答: A) gp3 は 125 MiB/s のベースラインに達し、gp2（≤170 GiB）は 128 MiB/s の上限に達したため。両方の値がたまたま近い

解説: gp3 のデフォルトスループットは 125 MiB/s です。gp2 は 170 GiB 以下のボリュームでは 128 MiB/s に制限されます。EBS は 1 MiB の I/O を 4 個の 256 KiB 操作として数えるため、130 MiB/s は約 520 IOPS に過ぎず、先行するアイドル中に蓄積された 36,000 クレジットの範囲内です。そのため、gp2 の空のクレジットバケットはシーケンシャルテストを遅くしませんでした。IOPS の上限より先にスループットの上限が作動しました。m5.xlarge インスタンスの EBS 帯域幅（≈137 MiB/s）はこれより少し高く、この場合のボトルネックではなかったことに注意してください。ただし、このインスタンスでは gp3 を 250 MiB/s に上げても、約 137 MiB/s で頭打ちになります。

7. 持続的に 3,000 IOPS が必要な 100 GiB のデータセットについて、正しいコスト比較（ソウルリージョン）はどれですか？
   • A) gp2 100 GiB（$11.40）で十分である
   • B) gp3 100 GiB（$9.12）は制限なく 3,000 IOPS を提供する一方、gp2 で同じベースラインを得るには 1 TiB（$114.00）が必要であり、約 12 倍の差がある
   • C) gp3 には追加の有料 IOPS が必要なため、gp2 より高価である
   • D) 両方のボリュームの月額料金は同じである

回答を表示

回答: B) gp3 100 GiB（$9.12）は制限なく 3,000 IOPS を提供する一方、gp2 で同じベースラインを得るには 1 TiB（$114.00）が必要であり、約 12 倍の差がある

解説: $11.40 の gp2 100 GiB が保証する持続 IOPS は 300 のみです（3,000 IOPS のバーストは最長 33 分間）。gp2 の時代には、IOPS を得るためにボリュームを 1 TiB、$114.00 まで増やすのが一般的な方法でした。gp3 は IOPS を容量から分離し、100 GiB で $9.12、同じ 3,000 IOPS を提供します。必要に応じて、6,000 IOPS（+$17.10）または 250 MiB/s（+$5.70）を個別に購入できます。

8. データを保持する既存の gp2 PVC を、Pod を再起動せずに gp3 へ変換する Kubernetes ネイティブな方法は何ですか？
   • A) StorageClass の type パラメータを gp3 に編集すると、既存の PV が自動的に変更される
   • B) VolumeAttributesClass（storage.k8s.io/v1、Kubernetes 1.34 で GA）を作成し、PVC の volumeAttributesClassName を設定する。EBS CSI driver が ModifyVolume を呼び出す
   • C) PVC を削除し、gp3 StorageClass で再作成する
   • D) ノード上で aws ec2 modify-volume を実行することが唯一の選択肢である

回答を表示

回答: B) VolumeAttributesClass（storage.k8s.io/v1、Kubernetes 1.34 で GA）を作成し、PVC の volumeAttributesClassName を設定する。EBS CSI driver が ModifyVolume を呼び出す

解説: StorageClass パラメータは新しいボリュームの作成時にのみ適用され、既存の PV には影響しません。VolumeAttributesClass により、EBS Elastic Volumes を基盤として、Pod の実行中に type、iops、throughput を変更できます。注意点: 同じボリュームで次の変更を行う前に、各変更が completed 状態に到達する必要があります（1 TiB のボリュームでは最大 6 時間）。また、EBS では 24 時間のローリング期間にボリュームあたり最大 4 回の変更しかできないため、type、IOPS、スループットの変更は 1 つのリクエストにまとめてください。さらに、Kubernetes 1.31～1.33 では v1beta1 API と feature gate が必要です。aws ec2 modify-volume を直接実行しても機能しますが、PV オブジェクトには StorageClass 名として gp2 が残るため、後で混乱を招きます。