バースト可能な EC2 VPN: CPU クレジットは Standard か Unlimited か

一方のモードはベースラインで制限し、もう一方は動き続けて請求される可能性がある。小さなインスタンスをゲートウェイにする前に、クレジットの計算を済ませよう。

小さな VPN ゲートウェイは速度テストに合格し、問題ないように感じられ、そして昼食後に劣化する。インスタンスはテスト中に嘘をついていたわけではない。アイドル中に稼いだクレジットを使っていたのだ。バースト可能なインスタンスはまさにそのために設計されているので、短いベンチマークは午後いっぱいの転送の予測にはならない。二つのクレジットモードは失敗の仕方も異なり、どちらを選ぶかが本当の判断である。

速度テストはどこから借りたのか

CPU クレジット一つは、一つの vCPU が一分間フル稼働することに相当する。バースト可能なインスタンスはベースラインの割合でクレジットを稼ぎ、ベースラインを超えたときにそれを消費する。アイドルの夜は残高を積み上げ、忙しい朝はそれを引き出す。

だから最初のテストは良く見える。インスタンスには貯まった予算があり、それを暗号化処理に使い、健全な速度を報告した。その結果のどこにも、残高がゼロになったときに何が起きるかは書かれていない。ベンチマークが測ったのはバーストであり、バーストこそがインスタンスの提供するものだ。これから頼る定常状態は一度も測られていない。

自分でやるべき計算

入力は vCPU あたりのベースライン率、vCPU の数、蓄積された残高、そして想定する負荷である。あくまで例示として、二つの vCPU を持つ仮想的なインスタンスで、vCPU あたり十パーセントのベースライン、24 の蓄積クレジット、一方の vCPU が完全に稼働し他方がアイドルという状況を考えよう。これらの数値は宣言された入力であり、特定のインスタンスサイズの仕様ではない。

Earn rate:       2 x 10% x 60 = 12 credits/hour
Workload usage:  1 x 100% x 60 = 60 credits/hour
Net draw:        60 - 12 = 48 credits/hour
Accrued budget:  24 / 48 = 0.5 hours

この前提では、予算はおよそ三十分で尽きる。バックグラウンド処理、変化する負荷、インスタンス自身の計上によって結果は動き、これらのどれも VPN のスループットを予測しない。予測するのは、持続的な制約がいつ効き始めるかである。

二番目の読み方にも注意しよう。この例では、稼働している一つの vCPU は CPU 全体容量のおよそ半分である。中程度の全体率は飽和したコアを隠すことがあるので、クレジットの数値と並べてコアごとの挙動を見るべきだ。

Standard と Unlimited: 同じゼロ、異なる意味

Standard モードでは、残高が尽きると持続的な CPU はベースラインへ向けて制約される。インスタンスは動き続けるが、遅くなるだけであり、上限は予測できる。Unlimited モードでは、残高がゼロになった後も余剰クレジットを引き続き使うことができ、ベースラインを超える持続的な使用はサービス会計規則に基づく請求を生み得る。

つまり CPUCreditBalance がゼロであることは、一方のモードではスロットリング、もう一方では請求の可能性を意味する。それが比較のすべてであり、モードを読まずに指標を読むのが誤解を招く理由である。

余剰も一クレジットごとの単純な請求ではない。後からベースラインを下回って運用すると余剰使用を返済でき、さらに他の課金条件も適用される。古いブログ記事の無料枠の主張に頼らず、設定されたモードと現在のサービス規則を確認しよう。

実際の作業中に何を見るか

転送の所要時間と速度の隣に CPUCreditUsage と CPUCreditBalance を記録する。Unlimited では CPUSurplusCreditBalance と CPUSurplusCreditsCharged を追加する。AWS の CPU クレジット監視ガイド が、それぞれが何を報告し、どのくらいの頻度かを説明している。

代表的な同時実行数と傾向が見えるだけの時間で再テストし、開始時の残高を記録する。アイドルの朝と忙しい午後は、同じコマンドでも同じ実験ではない。

CPU ではない制限

ネットワーク帯域には独自のベースラインとバースト挙動があり、パケットレートや接続数の許容範囲が CPU より先に制約になることがある。VPN 実装が接続ごとの状態を保持する場合、メモリが重要になり、小さなインスタンスはクレジットよりずっと早くメモリを使い果たし得る。

したがって健全なクレジット残高が証明するのは一つだけだ。CPU 予算は現在の制約ではない。ネットワーク経路については何も語らず、同時実行数が二倍になったときに何が起きるかも語らない。クレジット指標と同じ時間枠でネットワーク指標を見ておけば、スループット低下には理論ではなく候補となる原因ができる。

意図してベースラインを選ぶ

測定した持続的負荷からベースラインを選ぶか、バーストを明示的に受け入れて予算化する。どちらの答えも、書き留めてあれば擁護できる。他人の成功した動画ストリーミングから推測したものは、どちらも擁護できない。

ゲートウェイが基幹なら、クレジットモードを一度も開かなかった既定値ではなく、容量計画の一部として扱う。選んだモードが、予測できる障害になる。

関連記事