Managed Instance Groups (MIG)

解決する課題

• 1 台ずつ手作業で VM を作る運用では、障害時の復旧やスケールが属人化し遅くなる
• 同一構成の VM を宣言的に維持したい（あるべき台数とあるべき構成を定義し、その状態に収束させる）
• 障害インスタンスを自動で作り直したい（自動修復によりダウンタイムを最小化）
• 負荷の増減に台数を自動で追従させ、ピークに耐えつつアイドル時のコストを抑えたい
• アプリの新バージョンを無停止で段階的に入れ替えたい（ローリングアップデート / カナリア）

MIG はこれらをテンプレートとポリシーで宣言的に解決します。AWS で言えば EC2 Auto Scaling グループに相当する仕組みです。

主要概念と用語

• インスタンステンプレート: VM のマシンタイプ、イメージ、ディスク、ネットワーク、メタデータなどを定義する不変のひな形。MIG はこのテンプレートを元に VM を作成する（AWS の起動テンプレートに相当）
• マネージドインスタンスグループ（MIG）: テンプレートから同一構成の VM 群を作成・維持する単位。目標台数と各種ポリシーを持つ
• ゾーン MIG / リージョン MIG: 単一ゾーンに VM を置くか、リージョン内の複数ゾーンに分散配置するか。可用性重視ならリージョン MIG
• 自動修復（オートヒーリング）: アプリケーション向けヘルスチェックが失敗した VM を MIG が自動で再作成する
• オートスケーラー: CPU 使用率やロードバランサーの負荷、Cloud Monitoring メトリクスなどに基づいて目標台数を増減させるポリシー
• ローリングアップデート: テンプレートを差し替え、VM を少しずつ入れ替える更新方式。一度に止める割合などを制御できる
• ステートフル MIG / ステートレス MIG: ディスクやインスタンス名などの状態を維持するか否か。多くのワークロードはステートレスで運用する
• 目標分散シェイプ: リージョン MIG が複数ゾーンへ VM をどう配分するか（均等配置など）を決める設定

仕様・制限・クォータ

• ゾーン MIG はそのゾーン、リージョン MIG はリージョン内の複数ゾーンに VM を配置する
• VM 自体は通常の Compute Engine インスタンスであり、vCPU クォータやマシンタイプのクォータは素の Compute Engine と同様に適用される
• 1 つの MIG が抱えられる VM 台数には上限があり、リージョン MIG とゾーン MIG で扱いが異なる。大規模構成では事前に上限とクォータの確認・引き上げ申請が必要
• ステートフル設定や負荷分散との連携には、ヘルスチェックや名前付きポートなどの付随設定が必要
• 具体的な上限値やクォータ数値は変動しうるため、設計時には公式ドキュメントで最新値を確認すること

内部の仕組み

MIG は「あるべき状態（目標台数と構成）に実際の状態を収束させ続ける」コントローラーとして動作します。目標台数より少なければ VM を作成し、多ければ削除し、テンプレートと異なれば作り直します。

• 自動修復は、アプリケーション層のヘルスチェック（HTTP/TCP など）が失敗した VM を「異常」とみなして再作成する。単なる VM のプロセス死活ではなく、アプリが応答するかを見る点が重要
• リージョン MIGは複数ゾーンに VM を分散させるため、1 ゾーンの障害が全滅につながりにくい。これは Compute Engine のゾーンが独立した障害ドメインであることを前提とした設計
• オートスケーラーはメトリクスを継続的に観測し、スケールアウトは速く、スケールインは保守的（安定化のための待機）に動く傾向がある

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

• ステートレス設計を基本にする: 状態は Cloud Storage / Cloud SQL / Memorystore / Firestore など外部に逃がし、VM はいつ作り直しても良い状態にする
• リージョン MIG + Cloud Load Balancing: 複数ゾーンに分散した MIG をロードバランサーの背後に置き、可用性と負荷分散を両立する
• イミュータブルなテンプレート運用: 設定変更は稼働中 VM を直接いじらず、新テンプレートを作りローリングアップデートで入れ替える
• カナリアリリース: ローリングアップデートで一部の VM だけ新バージョンにし、問題なければ全体へ展開する
• MIG を分けすぎない / 分けるべきところは分ける: 役割が異なるワークロードは別 MIG にし、スケールポリシーを独立させる

運用・監視

• Cloud Monitoring / Cloud Logging で MIG の VM 数、自動修復イベント、オートスケールの動きを監視する
• オートスケーラーの判断材料となるメトリクス（CPU 使用率、ロードバランサーの使用率、カスタムメトリクス）を把握しておく
• 自動修復が頻発する場合は、アプリの不具合かヘルスチェック設定の問題を疑う
• ローリングアップデートの進行状況と、更新中に維持される最小稼働台数を確認しながら展開する

コスト

• MIG 自体に追加料金はなく、課金されるのは起動している Compute Engine の VM・ディスク・ネットワークなどの通常リソース
• オートスケールにより、ピーク時のみ台数を増やしアイドル時に減らすことで過剰プロビジョニングのコストを削減できる
• 定常的に稼働する最小台数には確約利用割引（CUD）、中断を許容できるワークロードには Spot VM を組み合わせるとコスト効率が上がる
• スケールインの安定化期間を長く取りすぎると、減らせるはずの VM を抱え続けてコストが増える点に注意

セキュリティ

• VM に割り当てるサービスアカウントは最小権限にし、テンプレート側で固定する（鍵のハードコードを避ける）
• テンプレートのイメージは信頼できる管理元のイメージを使い、必要に応じて Shielded VM を有効化する
• ファイアウォールルールで通信を最小化し、ロードバランサーやヘルスチェックの送信元のみを許可する
• テンプレートを更新する操作は IAM で制御し、誰がどのバージョンを展開できるかを管理する

Well-Architected の観点

• 信頼性: 自動修復とリージョン MIG による複数ゾーン分散で、インスタンス障害・ゾーン障害に強い構成を作れる
• コスト: オートスケールで需要に追従し、過剰プロビジョニングを避ける。最小台数は CUD、バースト分は Spot で最適化できる
• パフォーマンス効率: 負荷に応じて自動的に台数を増減し、ロードバランサーと組み合わせて要求をさばく

試験で問われるポイント

関連サービス・比較

リージョン MIG とゾーン MIG の使い分け、および AWS の相当サービスとの対応を整理します。

ハンズオン / CLI例

# 1. インスタンステンプレートを作成
gcloud compute instance-templates create web-tmpl \
  --machine-type=e2-medium \
  --image-family=debian-12 \
  --image-project=debian-cloud

# 2. テンプレートからリージョン MIG を作成（初期 3 台）
gcloud compute instance-groups managed create web-mig \
  --region=asia-northeast1 \
  --template=web-tmpl \
  --size=3

# 3. ヘルスチェックを使った自動修復を設定
gcloud compute instance-groups managed update web-mig \
  --region=asia-northeast1 \
  --health-check=web-hc \
  --initial-delay=120

# 4. CPU 使用率 60% を目標に自動スケール（最小 3 / 最大 10 台）
gcloud compute instance-groups managed set-autoscaling web-mig \
  --region=asia-northeast1 \
  --min-num-replicas=3 \
  --max-num-replicas=10 \
  --target-cpu-utilization=0.6