Skip to content

Dataflow 長時間 batch

ルール ID: gcp.dataflow.batch.stuckカテゴリ: zombie ・ 必要な読み取り: インベントリのみ(ジョブ一覧・初回スキャンで検出) 計画中

バッチジョブは終わることが本来の姿です。何日も RUNNING のまま残っているバッチジョブは、ハングやデータ滞留の疑いがあり、ワーカーの課金だけが続いている可能性があります。

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

何を無駄とみなすか

7 日を超えて RUNNING 状態が続いているバッチジョブ。ストリーミングジョブは長期実行が正常な形態のため、対象から除外します。

判定条件

  • ジョブ種別がバッチである(ストリーミングは除外)
  • RUNNING 状態への遷移から 7 日を超えて経過している

必須 facts

  • ジョブ種別(バッチ / ストリーミング)と現在の状態
  • RUNNING 遷移からの経過日数
  • リージョナルエンドポイント

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

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

  • 正当な超長時間バッチ(大規模なバックフィル・全量再処理など)
  • 完了間際のジョブ — キャンセルすると処理途中の結果が失われ、再実行のコストが大きい
  • 上流のデータ到着待ちで意図的に待機させているジョブ

実行前の確認

  • ジョブの進捗(処理済みデータ量・ステージの進行)が止まっているか、進んでいるかを確認する
  • ジョブ名・起動元(スケジューラ・テンプレート)から、想定実行時間と再実行の可否を確認する
  • 所有チームに、長期実行が意図したものかを確認する

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

Safety Tier: medium — ジョブのキャンセルは、そのジョブの処理途中の結果を確定させずに止める操作です。パイプライン定義は失われず、再実行できます。

  1. 進捗が止まっていることを確認してからジョブをキャンセルする
  2. 必要であれば同じパイプラインを再実行し、正常に完了することを確認する

ロールバック: 同一パイプラインの再実行(キャンセルしたジョブ自体は再開できないため、再実行が復旧手段です)。

効果検証

削減の確定は、変更前ベースラインと変更後請求の比較で行います(Verify)。本来終わっているはずのジョブの異常な延命が対象であり、ジョブのワーカー構成も一覧からは観測できないため、金額の推定表示は行いません(推定不能を明示します)。

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