Google Cloud BatchとCloud Run Jobsの徹底比較

Cloud Batch採用のメリット

1. HPC・並列処理の最適化

• 配列ジョブ（Array Jobs）のネイティブサポート: 数千の類似タスクを効率的に並列実行
• MPIサポート: マルチノード間の密結合通信が必要な科学計算に対応
• ジョブ間の依存関係管理: DAG（有向非巡回グラフ）による複雑なワークフロー制御

2. コンピューティングリソースの柔軟性

• GPUの高度な制御: 特定のGPUタイプ（A100、T4等）の選択が容易
• プリエンプティブルVM/Spot VM: 最大91%のコスト削減が可能
• カスタムマシンタイプ: CPU・メモリ比を細かく調整可能
• ローカルSSDの活用: 高速なスクラッチストレージ

3. 長時間実行ジョブへの対応

• 実行時間制限がより緩和的: 数日〜数週間の実行も想定
• 自動リトライとチェックポイント機能: 長時間ジョブの信頼性向上

4. ストレージ統合

• 並列ファイルシステム: Lustre、NFSなどの統合が容易
• 大容量データの効率的な処理: Persistent Diskの柔軟なマウント

5. 既存HPC資産の移行

• 従来のバッチスクリプト互換性: SLURM等からの移行がスムーズ
• Docker以外のコンテナランタイム: Singularityなどにも対応

6. きめ細かいリソース管理

• ノードごとのタスク配置制御: アフィニティ・アンチアフィニティの設定
• リソースプールの予約: 確実なリソース確保

Cloud Batch採用のデメリット

1. サーバーレスではない複雑さ

• インフラ管理の増加: VM起動時間、ネットワーク設定などの考慮が必要
• コールドスタートの遅延: VMプロビジョニングに数分かかることも

2. コスト面での注意点

• 最小課金単位: VMベースのため、短時間ジョブでは割高
• アイドル時間への課金: リソースが確保されている間は課金継続
• ネットワーク帯域幅コスト: 大容量データ転送で高額化の可能性

3. 運用の複雑性

• 設定の学習曲線: Cloud Run Jobsより設定項目が多い
• デバッグの難しさ: 分散環境でのトラブルシューティングが複雑
• モニタリング: より詳細な監視設定が必要

4. スケーラビリティの制約

• クォータ制限: リージョンあたりのCPU/GPU数に上限
• スケールアウトの速度: VMベースのため、Cloud Run Jobsより遅い
• リソース競合: 他の利用者とのリソース競合の可能性

5. 開発・デプロイの煩雑さ

• CI/CDパイプラインの複雑化: デプロイプロセスがより手動的
• バージョン管理: コンテナイメージとジョブ定義の両方を管理
• テスト環境の構築: ローカルでの動作確認が困難

6. ベンダーロックイン

• GCP固有の機能依存: 他クラウドへの移行が困難
• APIの複雑さ: Cloud Run Jobsよりプラットフォーム依存度が高い

選択の判断基準

Cloud Batchが適している場合

• 数千以上の並列タスク実行
• GPU/TPUを使った機械学習トレーニング
• MPI等を使う科学計算・シミュレーション
• 数時間〜数日かかる長時間処理
• 既存のHPCワークロードの移行
• コスト最適化のためSpot VMを活用したい

Cloud Run Jobsが適している場合

• 数分〜数十分の短時間処理
• イベント駆動の単純なバッチ処理
• 完全なサーバーレスを求める
• 迅速なスケールアウトが必要
• シンプルな運用を優先
• 頻繁なデプロイが発生する

DAGとは何か？

DAG = Directed Acyclic Graph（有向非巡回グラフ）

簡単に言うと「タスクの実行順序を矢印で表した図で、ループがないもの」です。

• 有向（Directed）: 矢印に方向がある（A→B）
• 非巡環（Acyclic）: ぐるぐる回らない（A→B→C→Aのような循環がない）

具体例で理解する

例1: 動画処理パイプライン

[動画アップロード]
      ↓
[動画分割] ← ここから並列実行
      ↓
   ┌──┴──┬──────┬──────┐
   ↓     ↓      ↓      ↓
[HD変換][4K変換][音声抽出][サムネイル生成]
   ↓     ↓      ↓      ↓
   └──┬──┴──────┴──────┘
      ↓
[メタデータ統合]
      ↓
[データベース登録]
      ↓
[通知送信]

DAGでできること:

• 「動画分割が終わってから」HD変換・4K変換・音声抽出を同時並列実行
• 全ての変換が終わってから、メタデータ統合を実行
• 依存関係を自動管理（親タスクが失敗したら子タスクは実行しない）

例2: 機械学習パイプライン

[データ取得A] [データ取得B] [データ取得C]
      ↓           ↓           ↓
      └───────┬───┴───────────┘
              ↓
        [データ統合]
              ↓
        [前処理・クレンジング]
              ↓
      ┌───────┴───────┐
      ↓               ↓
[モデルA訓練]    [モデルB訓練]
      ↓               ↓
      └───────┬───────┘
              ↓
        [モデル評価]
              ↓
        [最良モデル選択]
              ↓
        [デプロイ]

DAGでできること:

• 複数のデータソースから並列取得
• データが揃ってから次のステップへ
• 複数モデルを並列訓練してコスト・時間削減
• 1つのタスクが失敗したら、そこから先は実行しない

DAGがない場合の問題

❌ 単純な順次実行だと...

# シェルスクリプトの例
./task1.sh
./task2.sh
./task3.sh
./task4.sh

問題点:

1. 並列化できない → 時間がかかる
2. 依存関係が不明確 → task3が実際にはtask1だけに依存していても、task2の完了を待つ
3. 失敗時の制御が難しい → どのタスクが失敗しても、次が実行されてしまう
4. 再実行が非効率 → 全体をやり直す必要がある

Cloud BatchでのDAG実装例

{
  "taskGroups": [
    {
      "taskSpec": {
        "runnables": [{"container": {"imageUri": "データ取得"}}]
      },
      "taskCount": 3,
      "parallelism": 3
    },
    {
      "taskSpec": {
        "runnables": [{"container": {"imageUri": "前処理"}}]
      },
      "taskCount": 1,
      "dependencies": [0]  // ← タスクグループ0に依存
    },
    {
      "taskSpec": {
        "runnables": [{"container": {"imageUri": "訓練"}}]
      },
      "taskCount": 2,
      "parallelism": 2,
      "dependencies": [1]  // ← タスクグループ1に依存
    }
  ]
}

実務でのメリット

1. コスト削減

• 並列実行可能なタスクを同時実行 → 全体の処理時間を短縮
• 例: 10個のタスクを順次実行（100分）→ 並列実行（20分）

2. 信頼性向上

• 失敗したタスクだけ再実行
• 例: 10ステップ中8ステップ目で失敗 → 8ステップ目から再開

3. 可視化とデバッグ

✓ データ取得A（完了）
✓ データ取得B（完了）
✗ データ取得C（失敗） ← ここで止まる
⏸ データ統合（待機中） ← 依存関係により未実行
⏸ 前処理（待機中）

4. リソース効率

• 必要なタスクだけ実行
• 不要な計算リソースの無駄遣いを防止

Cloud Run Jobsとの違い

まとめ

DAGは「料理のレシピ」のようなもの

野菜を切る → 肉を切る → 同時に炒める → 調味料を加える → 盛り付け
     ↓            ↓            ↓
  (並列可能)   (並列可能)   (前の工程が必要)

• 同時にできる作業は並列実行
• 順番が必要な作業は待機
• 失敗したら、そこから作り直せる

DAGがないと: すべて順番にやるしかなく、非効率で融通が利かない

このような複雑なワークフローが必要ならCloud Batch、シンプルな処理ならCloud Run Jobsという選択になります。