Compute Engine インスタンス sizing

ルール ID: gcp.compute.instance.sizing ・ カテゴリ: sizing ・ 必要な読み取り: インベントリ + 利用メトリクス(権限が付くまで locked) 計画中

実測の利用率に対して大きすぎるマシンタイプで動いているインスタンスを見つけます。ピークを含む実測(p99)で判定するので、「たまたま暇な瞬間」を根拠にした乱暴な縮小提案はしません。

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

何を無駄とみなすか

CPU・メモリの実測ピークに対して明らかに過大なマシンタイプ。使われない vCPU とメモリの分だけ、毎時間の課金が上乗せされ続けます。

判定条件

次のすべてを満たすインスタンスを候補にします。

• 30 日間の p99 CPU 利用率が 10% 以下
• 30 日間の p99 メモリ利用率が 30% 以下(メモリ実測には Ops Agent が必要 — 導入されていない場合は非該当に倒し、推測でメモリを判定しません)
• CPU・メモリの全次元を満たす、より安価なマシンタイプが実在する(縮小先が実在しない場合は候補にしません)

必須 facts

• 現在のマシンタイプ(vCPU 数・メモリ容量)
• 30 日間の p99 CPU 利用率
• 30 日間の p99 メモリ利用率と、Ops Agent の導入有無
• 全次元を満たす縮小先マシンタイプの実在と構成

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

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

• 月末締めや繁忙期など、30 日の観測窓の外にピークが来るワークロード
• 起動時・デプロイ時にだけ高負荷になり、定常時は低利用に見えるアプリケーション
• 特定の CPU プラットフォームや命令セットを前提にしたソフトウェア(縮小先ファミリで同じ性能特性が保証されない場合があります)

実行前の確認

• ワークロードの繁忙周期(月次・季節性)を所有チームに確認する
• メモリ実測が Ops Agent 由来の実データであることを確認する
• IaC(Terraform 等)でマシンタイプが管理されている場合は、コード側の変更として実施する
• 縮小先でネットワーク帯域やローカルディスク構成が変わらないか確認する

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

Safety Tier: medium(停止 → マシンタイプ変更 → 起動の可逆な設定変更)

1. 変更前のマシンタイプを記録する
2. 一度に最小サイズまで落とさず、1 段階ずつ縮小して負荷と応答時間を観察する
3. 冗長構成であれば 1 台だけ先に縮小し、問題がなければ残りへ展開する

ロールバック: 同じ手順で元のマシンタイプへ戻します。

効果検証

削減の確定は、変更前ベースラインと変更後請求の比較で行います(Verify)。他のルールはルールカタログを参照してください。