Cloud Run Jobのcpuとmemoryの決め方
What — cpu は処理の性質、memory はデータ容量×膨張率
cpu の決め手はデータ容量ではなく処理の性質。判定質問はひとつで済む。
「CPU を倍にしたら、この Job は速く終わるか？」
この Job は Cloud Storage ダウンロード待ち＋ BigQuery ロード完了待ち（I/O 待ち）が支配的で、CPU が働く仕事（数MBの CSV パース）は一瞬。だから答えは No で、"1" でいい。課金は vCPU 数 × 実行秒数なので、増やしても料金だけ倍になる。
同じリポジトリでも 2 CPU の Job があるのは、大容量 CSV の変換処理＝CPU が実際に働く仕事があるからで、容量が大きいからではない。
memory は逆に、扱うデータの実測から積み上げる。
- 実測：CSV 約 3.4MB/ファイル
map[string]anyへのパース展開で 10〜20 倍に膨らむ（OOM 実績のある Job と同じ形式）→ 数十MB/ファイル- 実装は未取込ファイルを全件メモリに積んで一括ロードするため、512Mi の目安は未取込 5 ファイル程度まで
How — 破綻したときの戻し方まで決めておく
週1提供のファイルを数ヶ月放置すると未取込が溜まって危険ライン
OOM したら terraform で一時増強 → 手動実行で消化 → 戻す。ローカル実行での消化は環境差分・個人認証のリスクがあるので非推奨。
最小で始める前提が成立するのは、この「上げ方」が先に決まっているからだ。上げっぱなしにしないために、増強はコミットに理由を残して、消化後に戻すところまでを1セットにする。
関連
- Google Cloud
- Cloud Run Jobの設定値の決め方 — 設定値全体の一覧と方針
- Jobのスケジュールとリトライは下流から逆算する — 実行タイミング側の根拠
- APIとJobの違い
Table of contents