Skip to content

App Engine 旧バージョン常駐

ルール ID: gcp.appengine.version.staleカテゴリ: zombie ・ 必要な読み取り: インベントリのみ(初回スキャンで検出) 計画中

デプロイを重ねると、トラフィックを受けなくなった旧バージョンが残ります。手動スケーリングの旧バージョンは、トラフィック配分が 0 でも常駐インスタンスの課金が続きます。

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

何を無駄とみなすか

トラフィック配分が 0 のまま、常駐インスタンスを持ち続けてサービング状態にある旧バージョン。リクエストを受けないのにインスタンス課金だけが継続します。

判定条件

  • サービング状態で、トラフィック配分が 0 である
  • 常駐インスタンス(手動スケーリング)が 1 以上残っている
  • その状態が 30 日の時間ゲートを通過している

リクエスト時にのみインスタンスが起動するスケーリング形態は、トラフィック 0 なら課金もほぼ 0 のため対象にしません。

必須 facts

  • サービング状態とトラフィック配分
  • スケーリング形態と常駐インスタンス数
  • バージョンの経過日数

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

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

  • トラフィック配分は 0 でも、バージョン URL への直接アクセスで使われているバージョン(配分外のトラフィックは配分値に現れない)
  • ロールバック先として意図的に温存している直前バージョン
  • 検証・カナリア用に一時的に配分を 0 にしているバージョン

実行前の確認

  • バージョン URL への直接アクセスがないかをリクエストログで確認する
  • 命名・デプロイ履歴から、ロールバック先として残す意図がないかを確認する
  • IaC・デプロイパイプラインがそのバージョンを参照していないかを確認する
  • 所有チームに温存の意図を確認する

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

Safety Tier: medium — 削除ではなく、バージョンの停止(サービング状態の変更)を提案します。

  1. バージョンを停止し、常駐インスタンスを解放する(バージョンとコードは残る)
  2. 影響がないことを確認してから、削除は別途判断する

ロールバック: バージョンのサービング状態を戻して再開する。

効果検証

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

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