Bigtable idle

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

Bigtable はプロビジョンしたノードに対して、使われていてもいなくても課金が続きます。このルールは、負荷がほぼゼロのまま放置されたインスタンスを見つけます。

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

何を無駄とみなすか

プロビジョン済みノードを持ちながら、長期間 CPU 負荷がほぼゼロのインスタンス。検証・移行の後に消し忘れられたクラスタが典型です。

判定条件

• プロビジョン済みノードを持つインスタンスで、30 日間の cpu_load が 5% 以下である
• 作成から 30 日以上経過している(観測窓の完全性の確認)

必須 facts

• インスタンスの状態と種別
• クラスタごとのノード数
• 観測窓(30 日)内の cpu_load
• 作成からの経過日数

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

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

• ストレージ保管が主目的のインスタンス — CPU 負荷が低くてもデータには価値があり、削除すれば失われる
• 可用性のために複数クラスタでレプリケーションしている構成(待機側クラスタの負荷は低くて正常)
• 30 日を超える周期のバッチからのみ参照されるテーブル

実行前の確認

• 保持しているテーブルとデータの要否を確認する
• 命名・ラベルから用途(本番 / 検証)とレプリケーション構成の意図を確認する
• IaC(Terraform 等)・アプリケーションの接続設定からの参照有無を確認する
• 所有チームに利用予定を確認する

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

Safety Tier: high — インスタンスの削除はデータごと失われる、復元に手順が要る操作です。バックアップ取得と観察期間を必須にします。

1. 削除前に、全テーブルをインスタンスの外に残る形で退避する — Cloud Storage へのエクスポート、または削除しない別インスタンスのクラスタへのバックアップコピー。通常のバックアップは対象インスタンス内のクラスタに保存されるため、インスタンスを削除すると一緒に失われ、退避になりません
2. 退避データからの復元が成立することを確認する
3. 観察期間を置き、利用の問い合わせがないことを確認してから削除する

ロールバック: インスタンスを再作成し、Cloud Storage のエクスポートまたは別インスタンスへ退避したバックアップから復元する。

効果検証

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

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