Google Cloudのバッチ基盤 — Cloud Functions / Cloud Run Jobs / Cloud Batchの選び方
定期処理は「何を動かすか」より、実行時間・並列制御・実行環境で決める。Cloud Scheduler は起点、実行基盤は処理の重さに合わせて選ぶ。
TL;DR
- 軽い運用自動化は Cloud Functions、通常のプロダクトバッチは Cloud Run Jobs が第一候補。
- GPU・HPC・巨大な並列計算だけ Cloud Batch を検討する。
- Scheduler は時刻に起動する役であり、ジョブの実行基盤そのものではない。
01全体像 — 時刻で起こし、処理の重さで実行先を変える
Cloud Scheduler は決めた時刻に HTTP / API 呼び出しを行うトリガー。実際の処理は、関数・コンテナジョブ・VM系バッチのいずれかに委ねる。
Schedulerは実行器ではない
- トリガー：Cloud Scheduler — 実行基盤を時刻で起動
- 実行基盤：Cloud Functions / Run Jobs / Batch — ワークロードの重さで選ぶ
- 実行履歴：実行基盤側で確認 — Schedulerの成功だけで完了としない
023つの選定軸
コンテナで run-to-completion するため、Web API と同じイメージ・CI/CD の考え方を流用できる。execution と task の単位で状態や再試行を追える。
標準解は Cloud Run Jobs
- Cloud Functions：軽い補助処理 — 関数として短く実装する
- Cloud Run Jobs：通常の業務バッチ — コンテナで完了まで実行する
- Cloud Batch：GPU・HPC — VM級の大量計算を扱う
03失敗しない決め方
GPU・巨大メモリ・HPC が必須でない限り、まず Cloud Run Jobs の実行時間、CPU/メモリ、タスク並列数で要件を満たせるか確認する。
先に「最大負荷」を確認する
- 実行時間：短い — Functionsを候補にする
- 並列と再試行：タスク単位で必要 — Run Jobsを候補にする
- GPU・特殊VM：必要 — Batchを候補にする
結論
- Cloud Scheduler は「いつ」、実行基盤は「どう処理するか」を担う。
- プロダクトの定期バッチは、まず Cloud Run Jobs を比較の基準に置く。
- 巨大計算以外で最初から Cloud Batch を選ぶ必要は通常ない。