imu-note
いむたろ
いむたろ
@imutaroh
新卒エンジニア / データ基盤 × AI

What — 設定値と決め手の一覧

覚え方の一行:

CPU は処理の性質(I/O 待ちか計算か)、memory はデータ容量×膨張率、timeout は正常時間の数倍、retry は冪等性とセット。

設定決め手
cpu"1"処理の性質(I/O 待ち支配なら 1)
memory"512Mi"データ容量 × パース膨張率
timeout"900s"正常時間(数分)の数倍
max_retries1冪等だが、失敗原因は再試行で直らない系
schedule早朝の日次下流(dbt)の開始より前+日次で提供遅延に追従
Scheduler retry3回 / 30〜300sdispatch 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。最初から盛らない文化。

関連