Google Cloud Batch

解決する課題

• 大量の計算・データ処理をバッチ（まとめて実行して完了する処理）として流したいが、VM の確保・起動・後始末を自分で管理したくない
• 数百〜数千の独立タスクを並列実行してスループットを上げたい（レンダリング、ゲノム解析、シミュレーション、ETL など）
• 中断を許容できるワークロードを Spot VM で安く回し、足りなければオンデマンドに切り替えたい
• ジョブのスケジュール実行やタスク間の依存関係を宣言的に表現したい
• ピーク時だけリソースを使い、処理が終わったら自動でゼロまで縮退してコストを抑えたい

これらをマネージドに引き受けるのが Google Cloud Batch です。AWS でいう AWS Batch に相当し、ジョブのキューイングとコンピューティング基盤の自動プロビジョニングを肩代わりします。

主要概念と用語

• ジョブ（Job）: バッチ処理の最上位単位。1つ以上のタスクグループと、必要なリソースや実行環境の定義を含む
• タスクグループ（Task Group）: 同一の処理内容を持つタスクの集合。並列実行する数（タスク数）や同時実行数をここで指定する
• タスク（Task）: 実際に実行される最小の処理単位。コンテナまたはスクリプトとして定義する。配列ジョブでは各タスクにインデックスが割り当てられる
• ランナブル（Runnable）: タスク内で実行される個々のステップ。コンテナイメージの実行やシェルスクリプトの実行を順番に並べられる
• アロケーションポリシー（Allocation Policy）: 使用するマシンタイプ、プロビジョニングモデル（オンデマンド／Spot）、リージョンやゾーンなどコンピューティング資源の確保方針
• インスタンステンプレート: 確保する Compute Engine VM の構成（マシンタイプ、ディスク、ネットワークなど）
• 配列ジョブ（Array Job）: 同じタスク定義をインデックス違いで多数並列に走らせる形態。各タスクは環境変数でインデックスを受け取り、処理対象を切り替える

仕様・制限・クォータ

• 実行基盤は Compute Engine VM。VM 上で直接スクリプトを動かすか、コンテナとして実行するかを選べる
• ワークロードに合わせ、Spot VM（中断あり・低価格） と オンデマンド VM をプロビジョニングモデルで選択できる
• 1ジョブあたりのタスク数や同時実行タスク数には上限があり、これらは Compute Engine 側の vCPU・IP アドレス等のクォータにも依存する
• ジョブはリージョン単位で実行され、アロケーションポリシーで複数ゾーンへの分散も指定できる
• ジョブの実行ログやイベントは Cloud Logging に出力される
• 具体的なクォータ値や上限は変動するため、本番設計時は公式ドキュメントと自プロジェクトの割り当てを確認し、必要に応じて引き上げを申請する

内部の仕組み

Google Cloud Batch にジョブを投入すると、サービスはアロケーションポリシーに従って必要な Compute Engine VM を自動でプロビジョニングします。各 VM 上でタスク（コンテナまたはスクリプト）が実行され、タスクグループで指定した並列数に応じて複数の VM・タスクが同時に走ります。処理が完了すると、確保した VM は自動的に破棄され、アイドルな計算資源を抱え続けません。

配列ジョブでは、同一のタスク定義に対してタスクごとに一意のインデックスが割り当てられ、各タスクはそのインデックスを環境変数として受け取って処理対象のデータを切り替えます。これにより、入力ファイルの分割処理やパラメータ掃引のような埋め込み並列なワークロードを、コードをほとんど変えずにスケールアウトできます。

リソース確保では、Spot VM を優先しつつ容量が逼迫したときの挙動を設計できます。VM やストレージ（Cloud Storage のマウントなど）、ネットワークは既存の Google Cloud 基盤を利用するため、VPC・サービスアカウント・Cloud Storage といった周辺サービスと自然に統合されます。

設計パターン / ベストプラクティス

• 中断を許容できる処理は Spot VM を主に使い、確保失敗時のフォールバックを考慮してコストを最小化する
• 大量の独立タスクは配列ジョブで表現し、1タスク=1処理単位に切り出して並列度を上げる
• 1タスクの粒度は短すぎず長すぎずに調整する。細かすぎるとオーバーヘッドが増え、粗すぎると中断時の再実行コストが高くなる
• 入出力は Cloud Storage を介して受け渡し、VM はステートレスに保つ（VM 破棄でデータが消えても再実行できる設計）
• 権限は専用のサービスアカウントを VM に割り当て、必要な API・バケットだけに絞る
• リソースが取れないリスクに備え、複数ゾーンへ分散できるアロケーションポリシーにする
• 定期処理は Cloud Scheduler などからジョブ投入をトリガーし、スケジュール実行を実現する

運用・監視

• ジョブとタスクの**状態（実行中・成功・失敗）**は API やコンソールで確認でき、失敗タスクの数や原因を追跡できる
• タスクの標準出力・標準エラーやイベントは Cloud Logging に集約されるため、ログベースのアラートや調査ができる
• VM のリソース利用状況は Cloud Monitoring のメトリクスで把握し、マシンタイプや並列度の調整に活かす
• 失敗が出たら、まず**リソース確保の失敗（クォータ・Spot 中断）**か、**タスク内処理の失敗（イメージ取得・権限・アプリエラー）**かを切り分ける
• リトライ方針を定義しておき、一時的な失敗は自動再実行、恒久的な失敗は早期に打ち切ってコストの無駄を防ぐ

コスト

Google Cloud Batch 自体の利用に対する追加料金は基本的に発生せず、課金は実行のために確保した Compute Engine VM やストレージ・ネットワークなどの基盤リソースに対して行われます。つまりコスト最適化の鍵は、どのような VM をどれだけの時間使うかにあります。

セキュリティ

• ジョブ実行 VM には専用のサービスアカウントを割り当て、必要な API と Cloud Storage バケットだけに限定する（AWS のジョブロール相当）
• VM は特定の VPC・サブネットに配置し、外部 IP を付けないなどネットワーク到達範囲を最小化する
• 機密情報は環境変数に直書きせず、Secret Manager から取得する
• コンテナイメージは Artifact Registry に保管し、取得権限を絞る
• ジョブの作成・実行・参照は IAM のロールで制御し、誰がどのジョブを操作できるかを最小権限で割り当てる

Well-Architected の観点

• パフォーマンス効率: 配列ジョブと並列度の設計で、独立タスクを水平にスケールアウトしてスループットを最大化できる。マシンタイプを処理特性に合わせることでリソースを無駄なく使う
• コスト最適化: 処理後に VM を自動破棄しアイドル課金を避ける。Spot VM を主に使い、必要な分だけ確保することで単価と総コストを抑える
• 信頼性の観点では、冪等なタスク設計と複数ゾーンへの分散で、Spot 中断や一時的な確保失敗に耐える構成にする

試験で問われるポイント

関連サービス・比較

Google Cloud 内での棲み分けとしては、常駐する HTTP サービスやジョブ的処理を手軽に動かすなら Cloud Run、Kubernetes 前提の複雑なワークロードなら GKE、そして大量の計算リソースをまとめて確保して回す純粋なバッチ処理なら Google Cloud Batch、という整理になります。

ハンズオン / CLI例

# ジョブ定義（JSON）を用意して Batch ジョブを投入する例
# task.json には runnables（実行するスクリプトやコンテナ）、taskCount（並列タスク数）、
# allocationPolicy（マシンタイプや Spot などのプロビジョニングモデル）を記述する

# ジョブを作成して実行を開始
gcloud batch jobs submit my-batch-job \
  --location=asia-northeast1 \
  --config=task.json

# ジョブの状態を確認
gcloud batch jobs describe my-batch-job \
  --location=asia-northeast1

# プロジェクト内のジョブ一覧を表示
gcloud batch jobs list \
  --location=asia-northeast1

# 完了・不要になったジョブを削除
gcloud batch jobs delete my-batch-job \
  --location=asia-northeast1