覚え方の一行:
CPU は処理の性質(I/O 待ちか計算か)、memory はデータ容量×膨張率、timeout は正常時間の数倍、retry は冪等性とセット。
| 設定 | 値 | 決め手 |
|---|---|---|
| cpu | "1" | 処理の性質(I/O 待ち支配なら 1) |
| memory | "512Mi" | データ容量 × パース膨張率 |
| timeout | "900s" | 正常時間(数分)の数倍 |
| max_retries | 1 | 冪等だが、失敗原因は再試行で直らない系 |
| schedule | 早朝の日次 | 下流(dbt)の開始より前+日次で提供遅延に追従 |
| Scheduler retry | 3回 / 30〜300s | dispatch HTTP 失敗時のみ。リポジトリ多数派パターン |
行ごとの根拠は2本に分けた。cpu・memory は Cloud Run Jobのcpuとmemoryの決め方、schedule・retry は Jobのスケジュールとリトライは下流から逆算する。
実測データから逆算して最小で始め、破綻したら実測で上げる。
この方針の例外が timeout だ。"900s" は正常時間(数分)の数倍に置いてある。モジュール既定の 3600s をあえて短縮した値で、timeout は性能チューニングではなく、ハング時の課金ストッパーとして使う。「正常なら届かない、ハングしたら無限課金しない」上限、と考えると迷わない。
そして数字より効くのが、根拠を言葉にしておくこと。実際の PR レビューでは「この時刻にしてる理由は?」と時刻の根拠を指摘された。値そのものより、なぜその値かを1行で言えるかが見られている。
リポジトリの前例:別の大容量変換 Job は 4Gi で OOM した実績があって 8Gi に増強、また別の Job は「OOM が出たら上げる」コメント付きの 4Gi。最初から盛らない文化。