Spot VMs

解決する課題

• 中断を許容できる処理を、オンデマンド価格より大幅に安く回したい
• バッチ、レンダリング、CI、データ処理など、止まっても再実行できるワークロードのコストを下げたい
• マネージドインスタンスグループ（MIG）や Google Cloud Batch、GKE と組み合わせ、安いキャパシティを自動で確保したい
• 余剰キャパシティが取れないときにオンデマンドへフォールバックして可用性を保ちたい

これらをコスト面で解決するのが Spot VM です。VM の実体は通常の Compute Engine インスタンスで、違いはプロビジョニングモデルと価格・中断の有無だけです。

主要概念と用語

• Spot VM: Google Cloud の余剰キャパシティを割引価格で使う Compute Engine インスタンス。容量が逼迫すると中断される
• プロビジョニングモデル: VM の確保方針。STANDARD（オンデマンド）か SPOT を選ぶ。Spot を選ぶとそのインスタンスが Spot VM になる
• プリエンプション（中断）: Google 側がキャパシティを回収するために Spot VM を停止・削除する動作。利用者起因ではなくシステム起因で起こる
• プリエンプション通知: 中断の直前に VM へ送られる通知。メタデータサーバー経由のシグナルやシャットダウンスクリプトで受け取り、後始末を行える
• シャットダウンスクリプト: 中断時に走らせる片付け処理。チェックポイント保存や処理中ジョブの解放などに使う
• 旧プリエンプティブル VM: Spot VM の前身。最大稼働時間の上限があったが、Spot VM ではその上限がなくなった（容量がある限り動き続ける）

仕様・制限・クォータ

• 価格を除けば通常の Compute Engine と同じ。マシンタイプ、ディスク、ネットワーク、イメージなどは同様に使える
• いつでも中断され得る。中断時はインスタンスが停止または削除され、その前にプリエンプション通知が送られる
• 旧プリエンプティブル VM と異なり、Spot VM には最大稼働時間の上限がない。容量がある限り動き続ける
• 確保はベストエフォート。余剰キャパシティが無ければ起動・再起動に失敗することがある
• GPU、Local SSD など一部リソースも Spot で使えるが、構成やリージョンにより可用性が変わる
• 利用は vCPU など Compute Engine 側のクォータを消費する。具体的なクォータ値や割引率は時期・リージョン・マシンタイプで変動するため、本番設計時は公式ドキュメントと自プロジェクトの割り当てを確認する

内部の仕組み

Spot VM は、Google Cloud のデータセンターにある未使用の余剰キャパシティを割引価格で貸し出す仕組みです。そのキャパシティが他の用途（オンデマンドや確約利用割引の需要など）で必要になると、Google 側が Spot VM を回収します。これがプリエンプション（中断）です。

中断が起きる直前、VM にはプリエンプション通知が送られます。インスタンス内からはメタデータサーバー経由でこのシグナルを検知でき、シャットダウンスクリプトを仕込んでおけば、猶予時間内にチェックポイントの保存や処理中ジョブの解放といった後始末を実行できます。猶予時間は限られるため、長い後処理を前提にせず、短時間で完了する片付けに絞るのが定石です。

中断時の挙動は、インスタンスの中断時アクションとして「停止（STOP）」か「削除（DELETE）」を選べます。停止を選べばディスクを保持して後で再開を狙え、削除を選べば MIG などが新しい VM を立て直す前提の使い捨て運用に向きます。再起動や再作成のたびに容量確保はベストエフォートで行われるため、取れないことがある点を設計に織り込みます。

設計パターン / ベストプラクティス

• 冪等・ステートレスに作る: いつ中断されても、再実行で結果が壊れないようにする。これが Spot 活用の大前提
• 状態を外部に逃がす: 入出力やチェックポイントを Cloud Storage、状態を Firestore や Memorystore に置き、VM が消えても復旧できるようにする
• MIG で Spot とオンデマンドを混在: 一部をオンデマンドにして基礎可用性を確保し、残りを Spot で安く増やす。容量が取れないときのフォールバックも設計する
• Google Cloud Batch / GKE と組み合わせる: バッチはアロケーションポリシーで Spot を指定、GKE は Spot VM のノードプールで安価なワーカーをまかなう
• マシンタイプやゾーンを分散: 単一のマシンタイプ・ゾーンに依存すると確保失敗の影響が大きい。複数の選択肢を許容して可用性を上げる
• シャットダウンスクリプトで猶予時間を活かす: プリエンプション通知を受けたら、短時間で終わる後始末（進捗保存、キューへの返却など）だけを行う

運用・監視

• プリエンプション通知のハンドリングを実装・検証しておく。中断は本番でも普通に起こる前提で、後始末コードが実際に走るかをテストする
• 中断やシステムイベントは Cloud Logging に記録される。プリエンプション頻度を可視化し、ゾーンやマシンタイプの選択を見直す材料にする
• VM のリソース利用は Cloud Monitoring のメトリクスで把握し、過剰スペックや並列度を調整する
• MIG 運用では、自動修復と組み合わせて中断後の再作成を自動化しつつ、容量確保の失敗率も監視する
• 障害切り分けでは、**容量確保の失敗（中断・在庫不足）**か、アプリ起因の失敗かをまず分ける

コスト

Spot VM の最大の価値はコストです。オンデマンドと比べて大きく割り引かれますが、割引率はマシンタイプ・リージョン・時期で変動し、需給に応じて変わります。固定値として暗記せず、最新の料金で見積もるのが安全です。

セキュリティ

• Spot VM のセキュリティ特性は通常の Compute Engine と同じ。価格と中断以外で扱いを変える必要はない
• 専用のサービスアカウントを割り当て、必要な API・バケットだけに権限を絞る（鍵のハードコードを避ける）
• VPC・ファイアウォールルールで通信を最小化し、不要なら外部 IP を付けない
• 機密情報は環境変数に直書きせず Secret Manager から取得する。ディスクは既定で暗号化され、CMEK で自前鍵も使える

関連サービス・比較

最も近い関連サービスは、土台となる Compute Engine です。Spot VM はその上のプロビジョニングモデルの一種で、価格と中断の有無だけが異なります。

棲み分けとしては、止まっても再実行できる処理は Spot、常時稼働が必要な基礎部分はオンデマンドや確約利用割引、という整理になります。バッチ処理を丸ごとマネージドに回すなら Google Cloud Batch、Kubernetes 前提なら GKE の Spot ノードプールを使うと、Spot の確保とフォールバックを枠組みに任せられます。

ハンズオン / CLI例

# Spot VM を1台作成（--provisioning-model=SPOT を指定）
# 中断時はインスタンスを削除する設定
gcloud compute instances create demo-spot-vm \
  --zone=asia-northeast1-a \
  --machine-type=e2-medium \
  --provisioning-model=SPOT \
  --instance-termination-action=DELETE \
  --image-family=debian-12 \
  --image-project=debian-cloud

# 稼働中の Spot VM を一覧（プロビジョニングモデルを併せて表示）
gcloud compute instances list \
  --filter="status=RUNNING" \
  --format="table(name, machineType.basename(), scheduling.provisioningModel)"