## 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 — 破綻したときの戻し方まで決めておく > [!warning] 週1提供のファイルを数ヶ月放置すると未取込が溜まって危険ライン > OOM したら terraform で一時増強 → 手動実行で消化 → 戻す。ローカル実行での消化は環境差分・個人認証のリスクがあるので非推奨。 最小で始める前提が成立するのは、この「上げ方」が先に決まっているからだ。上げっぱなしにしないために、増強はコミットに理由を残して、消化後に戻すところまでを1セットにする。 ## 関連 - [[Google Cloud]] - [[Cloud Run Jobの設定値の決め方]] — 設定値全体の一覧と方針 - [[Jobのスケジュールとリトライは下流から逆算する]] — 実行タイミング側の根拠 - [[APIとJobの違い]]