パブリッククラウドEC2のオーバーコミットとSteal Time測定方法
mpstatでEC2のSteal Timeを実測し、オーバーコミットとノイジーネイバーを特定
Steal Timeが高いからといってオーバーコミットとは限らず、Nitroとクレジットメカニズムを組み合わせて総合的に判断することが重要です。
mpstatによるオーバーコミットの実測
パブリッククラウドEC2でSteal Timeを測定する最も直接的な方法は、mpstat -P ALL 1 で数回 %steal を確認することです。しかし、数値が高いからといってすぐにオーバーコミットと叫んではいけません。私も経験があります：T3インスタンスでCPUクレジットが枯渇すると、%steal も30%以上に跳ね上がりますが、それは決して隣人による占有ではなく、クレジットプールが空になったためです。Nitro仮想化における通常のスケジューリングオーバーヘッド、Burstableクレジット枯渇、悪質な隣人による占有を本当に区別するには、/proc/schedstat とCloudWatchの CPUCreditBalance メトリクスを併せて確認する必要があります。
実務では、まず sudo apt install sysstat && mpstat 1 5 を実行し、%steal が継続的に10%を超えるかどうかに注目します。単発の揺らぎであれば、Host側の通常のCPUリソース競合であることが多いです。長時間高い状態が続き、cpustat の steal 時間の割合が安定している場合にのみ、オーバーコミットを疑います。注意：Steal Timeが高いことはオーバーコミットを意味しません。あなた自身がインスタンスを小さく買いすぎた可能性もあります。T3インスタンスでUnlimitedを有効にすると、継続的な高負荷によって将来のクレジットを先取り消費し、結果としてstealが上昇することがあります。
これで終わりではありません。私はついでに mpstat の出力をCSVにエクスポートし、CloudWatchのスクリーンショットと一緒にPDFにまとめます。もし権利主張のチケットを開くことになれば、これは有力な証拠です。AWSの共有インスタンスのコストパフォーマンスは魅力的に見えますが、FinOpsで計算する際には潜在的なstealリスクをプレミアム率に換算する必要があります。同じ4 vCPUでも、運試しで隣人と競うよりも、Dedicated Hostと共有インスタンスの長期コスト差をきちんと計算したほうが良いでしょう。
完全な監査の考え方はEC2 StealTime巡回ガイドを参照するか、直接運用監査台で自動実行してください。
NitroのオーバーコミットとT3クレジット
AWS EC2のNitroアーキテクチャは通常のKVMオーバーコミットとは異なります。NitroのCPUスケジューリングはよりハードに分離されていますが、共有ホストでは依然として隣接テナントによるリソース競合が発生します。本当に混同しやすいのは、T3/T3a/T4gのようなバースト可能インスタンスです。CPUクレジットが枯渇し、Unlimitedが有効になっていない場合、パフォーマンスは強制的にベースラインまで引き下げられます。このとき、mpstatの%stealは必ずしも急上昇せず、むしろ自分自身が「もたつく」ように感じられます。Unlimitedを有効にすると、クレジットをオーバードラフトできますが、追加費用が発生します。
したがって、調査時にはまずmpstat 1で連続サンプリングし、CloudWatchのCPUCreditBalanceメトリクスと照合します。stealが高くてもクレジットが十分な場合は、オーバーコミットの証拠です。それ以外の場合は、Nitro仮想化の通常のオーバーヘッドである可能性があります。実際の測定で、継続的に高いstealが見られる場合は、/proc/statのタイムスタンプ証拠を収集し、サポートチケットの提出やスペックダウンの根拠として使用することをお勧めします。結局のところ、FinOpsの観点から見ると、オーバーコミットに対して支払うことは、プレミアム率が割に合わないことを意味します。
証跡チケットとFinOpsプレミアム
EC2で持続的に高いsteal timeを観測したとき、まずAWSに「オーバーコミット」のレッテルを貼るのは待ったほうがいい。私の習慣は、まずmpstat -P ALL 1で15分間連続サンプリングし、CloudWatchのCPUCreditBalanceとCPUCreditUsageを照合する。T3/T4gのクレジット残高がゼロになっているなら、steal timeの高さはCPUクレジットの枯渇によるもので、隣接インスタンスのCPUを奪い合っているわけではないことが多い。本当に「悪質な隣人」を確定させるには、Nitro仮想化の下でstealが5%を超え、かつirqの上昇を伴うことを確認する必要がある。ただし、Nitro自体にもわずかなスケジューリングオーバーヘッドがあるため、VPSの0.5%という閾値をそのまま当てはめてはいけない。
調査段階では、CloudWatchのCPUUtilizationとStealTimeメトリクス（EC2のStealTimeはカスタム名前空間にあるため、GetMetricDataで取得する）を同時にエクスポートし、/procスナップショットでcpu行を記録する。この3つをタイムスタンプに沿ってPDFにまとめ、チケットに直接添付する。AWSサポートは、タイムラインとスクリーンショットを含むデータを見れば、通常は基盤となるホストの調査に応じてくれる。彼らがオーバーコミットを認めることはほとんどないが、インスタンスの変更やプレースメントグループの調整を提案してくれる。
最後にFinOpsプレミアムについて：同じ仕様のc7i.largeを共有ホスト上でバッチ処理に使う場合、steal time 3%と8%のインスタンスでは、実際のスループットに12%以上の差が出る。クレジット枯渇後の追加課金（Tシリーズのunlimited）を考慮すると、総合コストが専用ホストよりも高くなる可能性がある。steal timeを毎月のコストレポートに組み込み、5%を超える場合は「パフォーマンス損失プレミアム」として換算し、Dedicated Hostの年間契約価格と比較することを推奨する。実際、多くの場合、重要なワークロードを専用ホストにアップグレードする方がコスト効率が良い。
FAQ
EC2のSteal Timeを測定するにはどうすればよいですか？
topまたはvmstatコマンドを使用し、CPUのsteal割合（例：topの%stフィールド）を確認します。
Steal Timeが高いと必ずオーバーコミットですか？
必ずしもそうではありません。Nitroアーキテクチャとクレジットメカニズムを考慮する必要があり、Steal Timeが高いのは一時的なリソース競合の可能性があります。
Nitroアーキテクチャではどうやってオーバーコミットを判断しますか？
AWS APIを使用してインスタンスの基盤となる物理CPUとvCPUの比率を照会し、実際の割り当て状況を比較します。
クレジットメカニズムはSteal Timeにどのような影響を与えますか？
Tシリーズのバースト可能インスタンスでクレジットが枯渇するとCPUが抑制され、Steal Timeが上昇する可能性があるため、クレジット残高を確認する必要があります。
オーバーコミットを総合判断する手順は？
まずSteal Timeを測定し、次にNitroインスタンスの物理リソースを確認し、最後にクレジット使用状況を分析して総合的に結論を出します。