Skip to content

Pub/Sub subscription idle

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

コンシューマが居なくなった購読(subscription)には、未 ack のメッセージが溜まり続け、滞留分のストレージ課金が発生します。このルールは、配信が完全に途絶えたまま滞留だけが残る購読を見つけます。

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

何を無駄とみなすか

長期間 1 通も配信されていない(= コンシューマ不在)のに、未 ack メッセージの滞留が続いている購読。読み手のいないメッセージの保管に課金だけが続きます。

判定条件

  • 30 日間の配信(サブスクライバへの送出)が 0 である
  • かつ、未 ack メッセージの滞留が観測されている

必須 facts

  • 観測窓(30 日)内の配信数
  • 未 ack メッセージ数と最古の未 ack メッセージの経過時間
  • 購読の状態と接続先トピック

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

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

  • 障害対応・再処理の保険として意図的にメッセージを溜めている購読
  • デッドレター(処理失敗メッセージの退避先)として使っている購読 — 滞留が仕様であることがある
  • BigQuery / Cloud Storage への直接エクスポート型の購読は、通常のサブスクライバ配信メトリクスに活動が現れない場合がある

実行前の確認

  • 命名・ラベルから購読の役割(通常処理 / デッドレター / エクスポート)を確認する
  • コンシューマとなるはずのアプリケーションが現存するかを確認する
  • 滞留しているメッセージの要否を所有チームに確認する
  • IaC(Terraform 等)での参照有無を確認する

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

Safety Tier: high — 購読の削除で未 ack の滞留メッセージは失われ、購読自体も復元できません(トピックと発行側は影響を受けません)。バックアップ取得と観察期間を必須にします。

  1. 滞留メッセージが必要な場合は、削除前に pull して退避する
  2. 観察期間を置き、コンシューマ再開の予定がないことを確認してから削除する

ロールバック: 同じ設定で購読を再作成する(削除前に設定を控えておく)。削除時点の滞留メッセージは戻せないため、退避したデータが復旧手段です。

効果検証

削減の確定は、変更前ベースラインと変更後請求の比較で行います(Verify)。滞留分のストレージ課金はメッセージのバイト数が観測できず金額に換算できないため、金額の推定表示は行いません(推定不能を明示します)。

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