## What — 設定値と決め手の一覧 覚え方の一行： > **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のスケジュールとリトライは下流から逆算する]]。 ## How — 最小で始めて、実測で上げる 実測データから逆算して最小で始め、破綻したら実測で上げる。 この方針の例外が timeout だ。`"900s"` は正常時間（数分）の数倍に置いてある。モジュール既定の 3600s をあえて短縮した値で、**timeout は性能チューニングではなく、ハング時の課金ストッパー**として使う。「正常なら届かない、ハングしたら無限課金しない」上限、と考えると迷わない。 そして数字より効くのが、根拠を言葉にしておくこと。実際の PR レビューでは「この時刻にしてる理由は？」と時刻の根拠を指摘された。値そのものより、**なぜその値かを1行で言えるか**が見られている。 リポジトリの前例：別の大容量変換 Job は 4Gi で OOM した実績があって 8Gi に増強、また別の Job は「OOM が出たら上げる」コメント付きの 4Gi。最初から盛らない文化。 ## 関連 - [[Google Cloud]] - [[Cloud Run Jobのcpuとmemoryの決め方]] — リソース側の根拠 - [[Jobのスケジュールとリトライは下流から逆算する]] — 実行タイミングと失敗時の設計 - [[APIとJobの違い]] - [[Cloud StorageとBigQuery]]