GCP Spot VMは、クラウドインフラのコスト削減において最も効果的な手段のひとつです。本来なら使われずに終わるCompute Engineの余剰キャパシティを活用することで、標準のオンデマンド料金から最大91%の割引が受けられます。
トレードオフは周知のとおりです。Compute EngineはSpot VMをいつでも回収できます。プリエンプションが発生すると、GCPは終了シグナルを送信し、VMが正常に停止できるようベストエフォートで30秒間のシャットダウン猶予を設けたうえで終了処理を行います。ドレインにより長い時間を要するworkloads向けには、120秒のプリエンプション通知期間もプレビュー提供されています。
これまで見えづらかったのは、特定ゾーンの特定マシンタイプが、必要なタイミングで実際に確保できるかどうかという点でした。
課題:見えないままのプロビジョニング
Spot VMを大規模に運用する際にストレスの原因となっていたのが、事前にゾーンのキャパシティを確認する信頼できる手段がなかったことです。Managed Instance Groupを起動して作成やスケーリングを要求しても、そのゾーンに十分なリソースがあったかどうかは実行後にしか分かりません。可用性の問題はすべてプロビジョニング失敗という形で表面化し、チームは待機・再試行・代替策の検討を迫られていました。
ゾーン選定にも同じ問題がありました。可用性はリージョンだけでなく、そのリージョン内の個々のゾーンにも左右されます。判断材料がないため、チームは空きキャパシティが最も多いゾーンではなく、使い慣れたゾーンを選びがちでした。
結果として、後手に回るフィードバックサイクルに陥っていました。
- プロビジョニング要求が失敗して初めて可用性の問題が判明する。
- ゾーン選定が情報に基づく意思決定ではなく、当てずっぽうになる。
- プリエンプションの頻度が不透明で、特定ロケーションでのマシンタイプの安定性を示すシグナルがない。
- プリエンプションリスクと価格動向が可視化されず、コスト計画が立てづらい。
何が変わったか:リアルタイム可用性シグナル
GCPはadvice.capacity APIを通じて、Spot VM向けのリアルタイム可用性シグナルを導入し、現在パブリックプレビューで提供しています。プロビジョニングを実行する前に、特定のマシンタイプとゾーンについて2つの主要指標を照会できます。
1. 取得可能性スコア(Obtainability Score)
現在のリソース可用性と直近の作成成功率をもとに、Spot VM作成要求が成功する確率を示す数値です。
| スコア | シグナル |
|---|---|
0.7 – 1.0 |
High — 成功する可能性が非常に高い |
0.4 – 0.6 |
Medium — ある程度の可能性あり。一括作成では一部のみ充足される場合あり |
0.0 – 0.3 |
Low — 成功しにくい。別のゾーン、リージョン、マシンタイプを検討 |
取得可能性スコアは保証ではありません。照会時点とプロビジョニング時点の間でキャパシティが変動することがあります。
2. 推定稼働時間(Estimated Uptime)
過去および現在の使用パターンから算出される、大半のSpot VMがプリエンプションされるまで稼働すると見込まれる最小期間です。
| 推定稼働時間 | 意味 |
|---|---|
| 60分(3,600秒) | 中断をある程度許容できる長時間バッチworkloadsに適する |
| 10分(600秒) | 短時間のタスクや、頻繁にチェックポイントを取るworkloads向け |
| 1分(60秒) | テストや非重要作業のみ。別のゾーンやマシンタイプを検討 |
推定稼働時間は保証ではありません。実際の稼働時間は前後する可能性があります。
使い方
コンソールのCapacity Advisor(Spot向け)を使えば、リアルタイムの取得可能性と過去のプリエンプション率を単一の画面で並べて確認でき、最も手軽です。gcloudではこれらをスクリプトや自動化向けに個別のコマンドとして提供しています。
コンソール経由(Capacity Advisor for Spot)
GCPコンソールでCompute Engine → Capacity Advisorを開き、リージョン、マシンファミリー、シリーズ、マシンタイプを選択してSearchをクリックします。
マップビューとリストビューでは、リージョン単位・ゾーン単位の可用性シグナルが、過去のプリエンプション率および現行のSpot価格とともに表示されます。複数のマシンシリーズ、タイプ、リージョンを同時に比較したい場合は、CLIではなくこのコンソールビューが便利です。
以下のスクリーンショットは、e2-medium Spot VMについてus-central1を照会した例です。4つのゾーン(us-central1-a、-b、-c、-f)いずれもHigh availability、過去のプリエンプション率0〜5%、現行Spot価格は$0.027664/hrとなっています。
gcloud経由
リアルタイムの可用性と推定稼働時間:
gcloud beta compute advice capacity \ --provisioning-model=SPOT \ --instance-selection-machine-types=MACHINE_TYPES \ --target-distribution-shape=TARGET_DISTRIBUTION_SHAPE \ --size=SIZE \ --region=REGIONレスポンスには、指定した構成に対するobtainabilityスコアとestimatedUptimeが含まれます。
出力例:
recommendations:- scores: estimatedUptime: 3600s obtainability: 0.9 shards: - instanceCount: 10 machineType: e2-medium provisioningModel: SPOT zone: https://www.googleapis.com/compute/beta/projects/chimbuc-playground/zones/us-central1-f過去のプリエンプション率と価格:
capacity-historyコマンドは、指定したマシンタイプとゾーンの日次プリエンプション率および価格履歴を返します。
gcloud beta compute advice capacity-history \ --provisioning-model=SPOT \ --machine-type=e2-medium \ --types=PREEMPTION,PRICE \ --region=us-central1出力例:
location: https://www.googleapis.com/compute/beta/projects/chimbuc-playground/regions/us-central1machineType: e2-mediumpreemptionHistory:- interval: endTime: '2026-06-23T07:00:00Z' startTime: '2026-03-25T07:00:00Z' preemptionRate: 0.0priceHistory:- interval: endTime: '2026-04-12T07:00:00Z' startTime: '2026-04-08T07:00:00Z' listPrice: currencyCode: USD nanos: 26752000- interval: endTime: '2026-06-16T07:00:00Z' startTime: '2026-04-12T07:00:00Z' listPrice: currencyCode: USD nanos: 27664000プロビジョニング前のゾーンおよびマシンタイプ選定にはcapacityを、workloadアーキテクチャ設計やFinOps予算策定における長期的な安定性・価格変動の把握にはcapacity-historyを活用してください。
制限事項
- TPUの可用性は
advice.capacityAPIでは照会できません。 - レコメンデーションにはAIゾーンがデフォルトで含まれます。推奨結果を利用する前に、プロジェクトでAIゾーンが有効化されていることを確認してください。
- N1 GPU VMや、マシンタイプにデフォルトで接続されていないLocal SSDディスクの可用性を照会するには、REST APIを直接呼び出してください。
- スコアや稼働時間の推定値は保証ではなく、照会時点と作成時点の間でキャパシティが変動する可能性があります。
ベストプラクティス
マシンタイプを横断して比較する。 workloadに柔軟性があるなら、構成間で結果を比較しましょう。たとえば
100 × n1-standard-2と50 × n1-standard-4など。要件に応じて取得可能性と推定稼働時間のバランスが取れる構成を選びます。ロケーションを横断して比較する。 複数のリージョンやゾーンで実行可能なworkloadなら、それぞれの可用性を確認しましょう。推定稼働時間が同程度の2つのリージョンでは、取得可能性スコアが高い方を優先します。
ゾーンに分散する。 リージョナルMIGで
ANYまたはBALANCEDの分散シェイプを使う場合、APIは作成成功率を最大化するためにゾーン間で分散する構成を推奨することがあります。たとえば100台すべてを1ゾーンに配置するのではなく、90台を1ゾーン、10台を別ゾーンといった具合です。定期的に見直す。 Spotの可用性はGCP全体の需要に応じて変動します。MIG管理やGKEノードプールのレビューサイクルに、定期的な可用性チェックを組み込みましょう。
まとめ
可用性を確認せずにSpot VMをプロビジョニングするのは、地図を持たずに運転するようなものです。advice.capacity APIは、その地図を手元に届けてくれます。照会を省略する理由はもうありません。
インスタンステンプレートを書く前、terraform applyを実行する前、MIGをスケールする前に——まずチェックしてください。そのゾーンでVMを確保できるのか、そしてどれくらい稼働し続けそうかを教えてくれます。このシグナルこそが、ゾーン選定、マシンタイプの選択、チェックポイント間隔の設計を導く指針になります。
Spot VMは、依然としてGCPで最も強力なコスト削減手段のひとつです。91%の割引は本物です。プリエンプションのリスクも本物ですが——今やそれは、見えないリスクではなく、照会可能な既知のリスクとなりました。
まず照会する。シグナルで選ぶ。稼働時間に合わせて設計する。需要の変化に応じて見直す。