Spanner oversized

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

Spanner のノード数は初期見積りのまま見直されないことがよくあります。このルールは、実測 CPU 使用率に対してノード数が過大なインスタンスを見つけ、実測に基づく縮小先を提案します。

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

何を無駄とみなすか

実測の CPU 使用率が低いまま、余裕を持ちすぎたノード数で稼働しているインスタンス。使い方を変えずに、ノード数だけを実測に見合う水準へ縮小できます。

判定条件

• 30 日間の CPU 使用率が 30% 未満である
• 縮小先は「利用率 65% を目標としたノード数」を実測から逆算して提案する(縮小にならない場合は候補にしない)
• オートスケーリング有効・マルチリージョン構成のインスタンスは対象外

必須 facts

• インスタンスの構成・現在のノード数
• オートスケーリング設定の有無
• 観測窓(30 日)内の CPU 使用率
• 作成からの経過日数(観測窓の完全性の確認)

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

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

• ストレージ容量がノード数を規定しているインスタンス — CPU が低くても、縮小後のノード数でストレージ要件を満たせない場合がある
• 繁忙期・イベントに備えて意図的に余裕を持たせている構成(観測窓にピークが含まれない)
• レイテンシ要件が厳しく、低い利用率を意図して維持しているワークロード

実行前の確認

• ストレージ使用量を確認し、縮小後のノード数で容量要件を満たすかを確認する
• 直近 30 日に含まれない繁忙期・スパイクの有無を所有チームに確認する
• IaC(Terraform 等)でノード数を管理している場合は IaC 側を変更する

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

Safety Tier: medium — ノード数の変更は稼働中に実施でき、元の値に戻せる可逆な操作です。

1. 変更前にレイテンシ・CPU 使用率のベースラインを記録する
2. 提案されたノード数へ段階的に縮小する
3. CPU 使用率とレイテンシを観察し、目標水準を超えて逼迫する場合は戻す

ロールバック: ノード数を元の値へ戻す。

効果検証

削減の確定は、変更前ベースラインと変更後請求の比較で行います(Verify)。

その他のルールはルールカタログを参照してください。