Compute Engine — 仮想マシンとインスタンスグループ

第 3 章でネットワークという土台を作りました。この章ではその上に載せる計算資源、Compute Engine を扱います。単体の VM を「正しく選んで正しく作る」ところから始め、後半では VM を 1 台ずつ世話するのをやめて群れ（マネージドインスタンスグループ、MIG）として運用する発想へ切り替えます。PCA 試験でも実務でも、Compute Engine の設問はほぼこの「選定」と「群れの自動運用」の 2 テーマに集約されます。

計算資源を選ぶ — マシンファミリー・Spot VM・割引

Compute Engine の VM はマシンタイプ（vCPU とメモリの組）を指定して作ります。マシンタイプ名は e2-standard-4 のように「シリーズ - メモリ構成 - vCPU 数」を表し、シリーズは用途別のマシンファミリーに分類されています。

事前定義マシンタイプのメモリ構成は 3 系統で覚えられます: highcpu（約 2 GB/vCPU）、standard（約 4 GB/vCPU）、highmem（約 8 GB/vCPU）。この比率に合わない場合は、汎用ファミリーの N 系・E2 系で vCPU とメモリを個別指定するカスタムマシンタイプが使えます（2026-08 時点で事前定義より約 5% 割高）。さらに小さい負荷には、物理コアを共有する共有コアマシンタイプ（e2-micro / e2-small / e2-medium）があり、一時的な CPU バーストで軽い処理を安価にさばけます。本書のハンズオンの主役もこの e2-micro です。

Spot VM — 中断と引き換えに最大 91% 引き

Spot VM は、Google Cloud の余剰キャパシティを割安に使う実行モデルです。標準 VM と同じマシンタイプ・同じディスクを使えますが、Google 側がキャパシティを必要とするといつでもプリエンプト（強制停止）されうるのが根本的な違いです。その代わり多くのマシンタイプ・GPU・Local SSD で最大 91%（2026-08 時点）の割引が適用されます。押さえるべき特性は次のとおりです。

• プリエンプト時は ACPI シャットダウン信号が送られ、猶予はベストエフォートで約 30 秒。この間にチェックポイント保存などの後始末を行います
• 旧称のプリエンプティブル VM にあった最大 24 時間の実行時間制限は、Spot VM にはありません
• ライブマイグレーションされず、Compute Engine の SLA 対象外。無料枠（Free Tier）の対象にもなりません
• プリエンプト後に単体では自動再起動しません。復帰させたい場合は後述の MIG に入れます（MIG がプリエンプトされた VM を再作成します）

# Spot VM の作成: --provisioning-model=SPOT を付けるだけ
gcloud compute instances create batch-vm \
  --zone=asia-northeast1-b \
  --machine-type=e2-medium \
  --provisioning-model=SPOT \
  --instance-termination-action=DELETE

--instance-termination-action はプリエンプト時の動作で、STOP（既定。停止状態で残る）か DELETE（VM ごと削除）を選べます。向くのはバッチ処理・レンダリング・CI のような中断されても再実行でリカバリできるワークロードです。

料金の基本 — 3 つの割引を使い分ける

Compute Engine のコスト設計は「オンデマンド価格から、どの割引をどう重ねるか」の設計です。割引は大きく 3 系統あります。

SUD が CUD 適用済みの使用分には重ねて効かない点、SUD の対象が旧世代シリーズに限られる点は誤解が多いので注意してください。割引戦略の全体像（ライトサイジングや請求データの分析を含む）は第 17 章で扱います。

ディスクとイメージ — Hyperdisk・スナップショット・イメージファミリー

VM のデータを支えるブロックストレージは 3 系統です。現行世代の第一候補は Hyperdisk で、容量と性能（IOPS / スループット）を独立に設定できるのが最大の特徴です。前世代の Persistent Disk は性能がプロビジョニング容量に比例するため、性能を上げるには容量も増やす必要がありました。また C4 や N4 などの最新マシンシリーズでは Persistent Disk は利用できず、Hyperdisk が前提になります。

Hyperdisk と Persistent Disk はネットワーク接続型なので VM と独立に存続し、保存時・転送時とも既定で暗号化されます。単一ゾーン障害に備えたい場合は、2 つのゾーンへ同期複製するリージョンディスクを選べます。Local SSD はあくまでスクラッチ・キャッシュ用の使い捨て領域と割り切ってください。

スナップショット — 増分バックアップの仕組み

ディスクのバックアップはスナップショットで取ります。仕組みを理解しておくとコストと復元時間の両方を読めるようになります。初回のスナップショットはディスク全データを含むフルバックアップで、2 回目以降は前回からの変更ブロックだけを保存し、未変更分は過去のスナップショットへの参照で済ませます。どのスナップショットから復元しても完全なディスクが得られるのに、保存コストは変更分しか増えない、という設計です。

スナップショットには用途別に 3 種類があります。

• 標準スナップショット — 地理的に冗長なバックアップ。ゾーン・リージョン障害からの復旧（DR）の基本手段
• アーカイブスナップショット — 機能は標準と同じで、数か月〜数年保持するコンプライアンス・長期保存向けに最適化
• インスタントスナップショット — ソースディスクと同じゾーン / リージョンに置かれ、復元が最速。ただしソースディスクを削除すると消えるため、DR ではなく直前状態への巻き戻し用

保存先はマルチリージョン（asia など。可用性重視）かリージョン（コストと所在地の統制重視）を選べます。手動で取り続けるのは現実的でないため、スナップショットスケジュールをディスクに紐付けて自動化するのが実務の既定です。

イメージ — VM の雛形を配る

ブートディスクの元になるのがイメージです。Google や OS ベンダーが提供する公開イメージと、自分のプロジェクトだけで使えるカスタムイメージ（既存 VM のブートディスクやスナップショットから作成）があります。ここで重要な仕組みがイメージファミリーで、ファミリー名は常に「非推奨（deprecated）になっていない最新イメージ」を指します。インスタンステンプレートにイメージ名ではなくファミリー名（例: debian-12）を書いておけば、テンプレートを書き換えずに常に最新版で VM が立ち上がり、問題が出たら新しい版を deprecated にするだけでロールバックできます。「ディスク → スナップショット → カスタムイメージ → テンプレート」という流れが、次節の MIG 運用の土台になります。

VM の初期化と SSH — メタデータ・起動スクリプト・OS Login

VM の初期構成をコンソールで手作業すると再現性がありません。Compute Engine ではメタデータ（key-value ペア。プロジェクト共通またはインスタンス個別に設定）に構成情報を持たせ、VM 内のゲストエージェントがそれを読んで動く、という仕組みで初期化を自動化します。代表的なキーが起動スクリプト用の startup-script と、SSH 管理用の enable-oslogin です。

起動スクリプト

• startup-script キーにスクリプト本体を入れる（上限 256 KB）。それを超える場合は Cloud Storage に置いて startup-script-url で参照する（VM のサービスアカウントにオブジェクトの読み取り権限、storage.objectViewer が必要）
• スクリプトはブートのたびに root ユーザーとして実行される。初回だけ実行したい処理は、スクリプト側で完了マーカーを確認するなど冪等に書く
• ネットワークが利用可能になってから実行されるため、パッケージ取得などの外部通信を前提にできる

OS Login — SSH アクセスを IAM に載せる

既定の SSH はメタデータに公開鍵を配って回る方式で、人数とインスタンスが増えると鍵の棚卸しが破綻します。OS Login は Linux アカウントを Google アカウントに紐付け、SSH 可否を IAM ロールで制御する仕組みです。メタデータ enable-oslogin=TRUE（プロジェクトまたはインスタンス単位）で有効化すると、ゲストエージェントはメタデータ上の SSH 鍵を無視するようになり、以後のアクセス制御は次の 2 つのロールで行います。

• roles/compute.osLogin — ログイン可（sudo なし）
• roles/compute.osAdminLogin — ログイン可（sudo あり）

IAM を外せば即座に SSH できなくなり、接続の監査ログも残ります。2 段階認証プロセスの強制にも対応しており、多数のユーザー・インスタンス・プロジェクトを抱える組織では OS Login が推奨手段です。第 2 章で学んだ「アクセス制御は IAM に一元化する」原則の、SSH への適用と捉えてください。

インスタンステンプレートと MIG — VM を群れとして運用する

ここからが本章の主戦場です。VM を 1 台ずつ作って世話をする運用は、台数が増えた瞬間に破綻します。Compute Engine の答えは「VM の設計図（インスタンステンプレート）を作り、その設計図からマネージドインスタンスグループ（MIG）に VM の群れを維持させる」ことです。

インスタンステンプレート — 不変の設計図

インスタンステンプレートは、マシンタイプ・ブートディスクイメージ・ラベル・起動スクリプトなど VM 構成一式を保存するリソースです。重要な性質は作成後に変更できない（イミュータブル）こと。構成を変えたければ新しいテンプレートを作ります。この不変性があるからこそ「どのテンプレートで作った VM か」が常に一意に決まり、後述のローリング更新やカナリアが成立します。テンプレートにはグローバルとリージョナルがあり、リージョン障害の影響を分離するため、リージョンをまたいで使い回す必要がなければリージョナルテンプレートが推奨です。テンプレート自体は無料で、作られたリソースにだけ課金されます。

MIG の自動運用 — 修復・オートヒーリング・スケーリング

インスタンスグループには、同一構成の VM を単一の実体として運用する MIG と、既存の異種 VM をロードバランサ配下にまとめるだけの非マネージドインスタンスグループがあります。非マネージド側にはオートスケーリングも自動修復もローリング更新もないため、以降は MIG だけを考えます。MIG の自動運用は 3 層で理解します。

• 自動修復（repair） — MIG 配下の VM が停止・クラッシュ・プリエンプトされたり、MIG 以外の操作で削除されたりすると、MIG がテンプレートから自動再作成して目標台数を維持する。既定で有効
• オートヒーリング — ヘルスチェックでアプリケーションの応答まで検査し、プロセスは生きているが応答しない VM を検知して再作成する。VM は無事でもアプリが死んでいる障害はこれでしか拾えない
• オートスケーリング — 負荷に応じて台数そのものを増減する

オートヒーリングで実務上いちばん重要なパラメータが初期遅延（initial delay）です。VM 起動からアプリが応答可能になるまでの時間より短く設定すると、「起動中なのに unhealthy と判定 → 再作成 → また起動中に判定」という再作成ループに陥ります。またロードバランサ用のヘルスチェックを使い回さず、オートヒーリング専用に、より保守的な（失敗と判定しにくい）ヘルスチェックを別に用意するのがドキュメント推奨のベストプラクティスです。LB は「一時的に外す」判断、オートヒーリングは「作り直す」判断なので、後者は慎重であるべきだからです。

配置の観点では、単一ゾーンに置くゾーン MIG（既定上限 1,000 台。2026-08 時点）と、複数ゾーンへ分散するリージョン MIG（既定上限 2,000 台。ゾーン間の配分は分散シェイプで制御）を選べます。ゾーン障害に耐えたければリージョン MIG が答えです。またディスクや VM 名を維持したいワークロード向けにステートフル MIG もありますが、まずは「MIG はステートレスな群れの道具」と押さえるのが先です。

オートスケーリングのシグナルは 4 種類 — CPU 使用率・ロードバランサの処理能力・Cloud Monitoring 指標・スケジュール（1 グループ最大 128 本。2026-08 時点）。挙動を制御する主なパラメータは次のとおりです。

• 初期化期間（旧称クールダウン。既定 60 秒） — 起動直後の VM の指標をスケールアウト判断から除外する猶予
• 安定化期間（既定 10 分） — スケールインは直近ピークを基準に判断し、急な縮小での取りこぼしを防ぐ
• スケールイン制御 — 一定時間内に減らせる台数を制限する
• 予測オートスケーリング — 日次・週次の周期性がある負荷を学習し、初期化に時間がかかる（目安 2 分超）アプリでも需要の先回りでスケールアウトする

ローリング更新とカナリア — テンプレートの入れ替え

テンプレートは不変なので、アプリの新バージョンは「新テンプレートを作り、MIG の VM を順次入れ替える」ことで配ります。これが自動ローリング更新です。更新には、グループ全体へ即座に展開する proactive と、再作成やスケールアウトのタイミングでだけ新テンプレートを使う opportunistic の 2 方式があります。展開速度と可用性は 2 つのパラメータで制御します。

• max-surge — 更新中に目標台数を何台超過してよいか（既定はゾーン MIG で 1、リージョン MIG で 3）。大きいほど速いが一時コスト増
• max-unavailable — 更新中に何台まで同時停止を許すか。max-unavailable=0 かつ max-surge 1 以上で無停止デプロイになる

カナリアは --canary-version で「新テンプレートを適用する台数（または割合）」を指定するだけで実現できます。名前を維持したまま入れ替えたい場合は --replacement-method=recreate を指定します。ロールバックに専用機能はなく、旧テンプレートを指定してもう一度ローリング更新するだけです。この対称性が Infrastructure as Code と相性がよく、第 16 章のデプロイ戦略（Blue-Green・カナリア）につながります。

gcloud compute firewall-rules create allow-http-handson \
  --allow=tcp:80 --target-tags=http-server

gcloud compute instances create web-vm \
  --zone=asia-northeast1-b \
  --machine-type=e2-micro \
  --image-family=debian-12 \
  --image-project=debian-cloud \
  --tags=http-server \
  --metadata=startup-script='#! /bin/bash
apt-get update
apt-get install -y nginx'

gcloud compute instances list
# EXTERNAL_IP 列の値を控える。起動スクリプト完了まで 1〜2 分待つ

curl http://EXTERNAL_IP
# 期待される出力: <title>Welcome to nginx!</title> を含む HTML

gcloud compute instances add-metadata web-vm \
  --zone=asia-northeast1-b \
  --metadata=enable-oslogin=TRUE

gcloud compute ssh web-vm --zone=asia-northeast1-b
# ログイン後、exit で抜ける

gcloud compute instances delete web-vm --zone=asia-northeast1-b --quiet
gcloud compute firewall-rules delete allow-http-handson --quiet

gcloud compute health-checks create http mig-health-check \
  --port=80 --check-interval=10 --timeout=5 \
  --healthy-threshold=1 --unhealthy-threshold=3

gcloud compute firewall-rules create allow-health-check \
  --allow=tcp:80 \
  --source-ranges=130.211.0.0/22,35.191.0.0/16 \
  --target-tags=allow-health-check

gcloud compute instance-templates create web-template-v1 \
  --machine-type=e2-micro \
  --image-family=debian-12 --image-project=debian-cloud \
  --tags=allow-health-check \
  --metadata=startup-script='#! /bin/bash
apt-get update
apt-get install -y nginx
echo "v1 - $(hostname)" > /var/www/html/index.html'

gcloud compute instance-groups managed create web-mig \
  --zone=asia-northeast1-b \
  --template=web-template-v1 \
  --size=3 \
  --health-check=mig-health-check \
  --initial-delay=300

gcloud compute instance-groups managed list-instances web-mig \
  --zone=asia-northeast1-b
# 期待される出力: web-mig-xxxx が 3 行。STATUS が RUNNING になるまで待つ

gcloud compute instance-groups managed set-autoscaling web-mig \
  --zone=asia-northeast1-b \
  --max-num-replicas=5 \
  --target-cpu-utilization=0.7 \
  --cool-down-period=90

# VM 名は list-instances の出力に合わせて置き換える
gcloud compute ssh web-mig-xxxx --zone=asia-northeast1-b \
  --command='sudo systemctl stop nginx'

# 1〜2 分おきに繰り返し実行して観察する
gcloud compute instance-groups managed list-instances web-mig \
  --zone=asia-northeast1-b
# 期待される変化: 該当 VM の currentAction が再作成中の表示になり、
# しばらくすると新しい VM として RUNNING に戻る

gcloud compute instance-groups managed delete web-mig \
  --zone=asia-northeast1-b --quiet
gcloud compute instance-templates delete web-template-v1 --quiet
gcloud compute health-checks delete mig-health-check --quiet
gcloud compute firewall-rules delete allow-health-check --quiet

gcloud compute instance-templates create web-template-v2 \
  --machine-type=e2-micro \
  --image-family=debian-12 --image-project=debian-cloud \
  --tags=allow-health-check \
  --metadata=startup-script='#! /bin/bash
apt-get update
apt-get install -y nginx
echo "v2 - $(hostname)" > /var/www/html/index.html'

gcloud compute instance-groups managed rolling-action start-update web-mig \
  --zone=asia-northeast1-b \
  --version=template=web-template-v1 \
  --canary-version=template=web-template-v2,target-size=1 \
  --max-surge=1 --max-unavailable=0

gcloud compute instance-groups managed describe web-mig \
  --zone=asia-northeast1-b
# 期待される出力: versions に web-template-v1 と web-template-v2 が並ぶ

gcloud compute instance-groups managed rolling-action start-update web-mig \
  --zone=asia-northeast1-b \
  --version=template=web-template-v2 \
  --max-surge=1 --max-unavailable=0

gcloud compute instance-groups managed list-instances web-mig \
  --zone=asia-northeast1-b
# 1 台ずつ順に置き換わり、最終的に全台が web-template-v2 になる

gcloud compute instance-groups managed delete web-mig \
  --zone=asia-northeast1-b --quiet
gcloud compute instance-templates delete web-template-v1 --quiet
gcloud compute instance-templates delete web-template-v2 --quiet
gcloud compute health-checks delete mig-health-check --quiet
gcloud compute firewall-rules delete allow-health-check --quiet

gcloud compute instances list
# 期待される出力: Listed 0 items.（何も残っていないことを確認）

つまずきポイント

理解度チェック

まとめと次章へ

• マシンタイプ選定は「特化要件（巨大メモリ / GPU / HPC）→ 特化ファミリー、なければ汎用」の 2 段構え。小さく始めるなら共有コアの e2-micro
• Spot VM は最大 91% 引き（2026-08 時点）だがプリエンプト前提。SLA 対象外で、単体では自動復帰しない
• ブロックストレージの現行第一候補は Hyperdisk。バックアップは増分スナップショット + スケジュール、雛形はイメージファミリーで配る
• 起動スクリプトはメタデータ経由で root として毎ブート実行。SSH は OS Login で IAM 管理に載せるのが推奨
• MIG は自動修復・オートヒーリング・オートスケーリング・ローリング更新で「群れ」を維持する。ゾーン障害に耐えるならリージョン MIG
• コストは CUD（安定分）・Spot（中断可）・オートスケーリング（変動分）の組み合わせで設計する

MIG は単体では外部にサービスを公開できません。第 5 章では Cloud Load Balancing を前段に置き、この章で作った MIG をバックエンドとして世界中からのトラフィックを受ける構成を組み立てます。ヘルスチェックとオートスケーリングが LB とどう連携するかにも注目してください。

参考リンク（公式ドキュメント）:

• マシンファミリーのリソースと比較ガイド
• Spot VM
• ストレージオプションについて
• スナップショットについて
• オペレーティング システム イメージ
• OS Login について
• インスタンス グループ
• インスタンスのグループの自動スケーリング
• 確約利用割引の概要