Skip to content

Managed Instance Group sizing

ルール ID: gcp.compute.mig.sizingカテゴリ: sizing ・ 必要な読み取り: インベントリ + 利用メトリクス 計画中

Managed Instance Group(MIG)全体で見たときに、1 台 1 台のマシンタイプが大きすぎるケースを見つけます。台数はオートスケーラが調整してくれても、1 台あたりのサイズは誰も見直していない — そこに残る無駄が対象です。

このページは判定規範に従う予定仕様です。閾値・観測窓の根拠(出典)は実装時に付記します。

何を無駄とみなすか

グループ全体の集約 CPU 利用率が低いまま維持されている MIG。個々の VM ではなくグループ単位で判定し、インスタンステンプレートのマシンタイプ縮小を提案します(MIG 配下の VM は個別ルールの対象から除外され、こちらへ集約されます)。

判定条件

  • グループ全体の集約 CPU 利用率が低利用である場合に、テンプレートのマシンタイプ縮小を提案します

具体的な閾値と観測窓は実装時に確定し、出典とともにこのページへ付記します。

必須 facts

  • グループのインスタンス数と現在のインスタンステンプレートのマシンタイプ
  • グループ全体の集約 CPU 利用率の実測
  • オートスケーラの有無と設定(CPU ターゲット等 — 縮小がスケール動作に与える影響の確認)

取得できない facts がある場合は「観測不能」と表示し、候補にしません(候補を捏造しない)。

誤検知・危険になり得る条件

  • スパイクに数秒で応答するため、意図的に余裕を持たせているグループ(スケールアウトが間に合わない種類の負荷)
  • メモリやネットワークが律速で、CPU だけが低く見えるワークロード
  • ローリング更新やカナリア配信の途中で、一時的に台数・利用率が通常と異なるグループ

実行前の確認

  • オートスケーラの指標(CPU ターゲット等)を確認する — マシンタイプを縮小すると同じ負荷でも利用率が上がり、台数が増えて相殺される場合があります
  • CPU 以外(メモリ・ネットワーク)の律速がないか所有チームに確認する
  • インスタンステンプレートが IaC(Terraform 等)で管理されている場合はコード側で変更する

非破壊テストとロールバック

Safety Tier: medium(テンプレート更新 + ローリング置換による可逆な設定変更)

  1. 現行のインスタンステンプレートを記録する(テンプレート自体は残るため、戻り先が消えることはありません)
  2. 縮小したテンプレートで一部のインスタンスだけ置き換え(カナリア)、負荷・応答時間・台数の変化を観察する
  3. 問題がなければグループ全体へローリング展開する

ロールバック: 旧テンプレートを指定してローリング更新を実行し、元の構成へ戻します。

効果検証

削減の確定は、変更前ベースラインと変更後請求の比較で行います(Verify)。縮小後に台数が増えていないかも合わせて確認します。他のルールはルールカタログを参照してください。