AWS Batch

AWS Batch は、科学計算・データ処理・レンダリング・ETL のような「大量の独立したジョブをまとめて実行する」用途向けのフルマネージドサービスです。ジョブの数や規模に応じて計算資源を自動でスケールさせるため、利用者はクラスタの構築・スケーリング・パッチ適用といった運用作業から解放されます。

解決する課題

従来、バッチ処理を自前で運用する場合は、ジョブのキューイング、実行ノードのプロビジョニング、負荷に応じたスケールアウトとスケールイン、失敗時のリトライ、そしてアイドル時のコスト削減まで、すべてを自分で設計・実装する必要がありました。固定サイズのクラスタを用意すると、ピーク時には足りず、閑散時には資源が遊んでコストが無駄になります。

AWS Batch は、投入されたジョブの要求量に応じて計算資源を動的に確保し、ジョブが終われば自動で縮小します。これにより、過剰なプロビジョニングを避けつつ、ピーク負荷にも追従できます。スポットインスタンスと組み合わせれば、コストを大きく抑えながら大規模な計算を回せる点が大きな価値です。

主要概念と用語

• ジョブ: 実行の最小単位。コンテナイメージ、コマンド、必要な vCPU やメモリといったリソース要求を持つ。シェルスクリプトやバイナリ、機械学習の推論・学習処理などをコンテナとして実行する。
• ジョブ定義: ジョブの実行方法を記したテンプレート。使用するコンテナイメージ、リソース要求、環境変数、IAM ロール、リトライ戦略、タイムアウトなどを定義する。投入時に一部を上書きできる。
• ジョブキュー: 投入されたジョブが実行を待つ待ち行列。優先度を設定でき、1つのキューを複数の計算環境に紐づけられる。優先度の高いキューや、より優先順位の高い計算環境から順にスケジューリングされる。
• 計算環境（コンピューティング環境）: ジョブを実際に動かすリソースの集合。マネージド型では Batch が EC2 やスポット、Fargate を自動で起動・終了する。アンマネージド型では利用者が用意した基盤を使う。
• スケジューラ: キュー内のジョブと計算環境を突き合わせ、依存関係や優先度を考慮して、どのジョブをどこで実行するかを決める制御ロジック。
• 配列ジョブ: 1回の投入で多数の子ジョブを生成する仕組み。各子ジョブにはインデックスが割り当てられ、入力データの分割処理に向く。
• ジョブ依存関係: あるジョブの完了を別のジョブの開始条件にする指定。これにより簡易的なワークフローを表現できる。

仕様・制限・クォータ

• 実行基盤として、オンデマンド EC2、スポット EC2、Fargate、Fargate スポットを選択できる。GPU を要求するジョブには GPU 対応インスタンスを割り当てられる。
• ジョブはコンテナとして実行されるため、コンテナイメージを用意する必要がある。Fargate を使う場合はサーバ管理が一切不要になる。
• ジョブには再試行回数やタイムアウトを設定でき、終了コードや理由に基づいて条件付きでリトライさせることもできる。
• 配列ジョブでは1回の投入で多数の子ジョブを扱えるため、大規模なファンアウト処理に向く。
• アカウントごとのジョブキュー数、計算環境数、同時実行ジョブ数などにはクォータが設定されている。これらは変動するため、最新値はサービスクォータの画面で確認するのが望ましい。EC2 側のインスタンス上限にも実質的に制約される点に注意する。

内部の仕組み

ジョブを投入すると、まずジョブキューに格納されます。スケジューラはキューを定期的に評価し、待機中のジョブのリソース要求の合計を見て、紐づく計算環境にどれだけのキャパシティが必要かを判断します。マネージド型の計算環境では、Batch がこの判断に基づいて EC2 インスタンスを起動したり、Fargate タスクを起動したりします。

計算環境には希望 vCPU・最小 vCPU・最大 vCPU といった設定があり、最小値を高くすると常時待機分のコストが発生する代わりに起動遅延を抑えられ、最小値をゼロにするとアイドル時のコストを抑えられます。EC2 ベースの計算環境では、Batch が複数のインスタンスタイプから最適なものを選ぶ方式を選択でき、ジョブのリソース要求に合わせて効率よくビンパッキングします。ジョブが完了してキューが空になると、不要になったインスタンスは自動的に終了し、コストが発生しなくなります。

スポットを使う計算環境では、価格や中断のリスクを考慮した割り当てが行われ、中断されたジョブはリトライ設定に従って再実行されます。

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

• ステートレスで冪等なジョブにする。スポット中断やリトライで同じジョブが複数回実行されても結果が壊れないよう設計する。中間結果は S3 などの外部ストレージに保存する。
• 中断に強い処理にはスポットを積極的に使い、納期が厳しく中断を許容できない処理にはオンデマンドを使うなど、キューと計算環境を用途別に分ける。
• ジョブのリソース要求は実測に基づいて適切に設定する。要求が過大だとインスタンス1台あたりの同時実行数が減り、過小だと OOM などで失敗する。
• 多数の小さな処理は配列ジョブにまとめ、依存関係を使って前処理・本処理・後処理の順序を表現する。
• 大規模なファンアウトと複雑なワークフロー制御が必要な場合は、Step Functions から Batch ジョブを起動して全体の流れを管理する。

運用・監視

• ジョブの標準出力・標準エラーは CloudWatch Logs に送られるため、失敗時の原因調査はログを起点に行う。
• ジョブの状態は SUBMITTED から始まり、PENDING、RUNNABLE、STARTING、RUNNING を経て、SUCCEEDED または FAILED に至る。RUNNABLE のまま進まない場合は、計算環境の最大 vCPU 不足、サブネットや IAM の設定、インスタンス容量の不足などを疑う。
• ジョブの状態変化は EventBridge のイベントとして受け取れるため、完了通知や後続処理のトリガに使える。
• 計算環境やキューのメトリクスを CloudWatch で監視し、待機時間が長い場合は最大 vCPU や優先度を見直す。

コスト

AWS Batch サービス自体には追加料金はかかりません。課金されるのは、ジョブを実行するために起動された EC2 インスタンスや Fargate、関連する EBS ボリューム、データ転送、CloudWatch Logs などの基盤リソースの利用料です。

コスト削減の主役はスポットの活用です。中断耐性のあるジョブをスポットで動かすことで、オンデマンドに比べて大幅な割安料金で大規模計算を回せます。また、計算環境の最小 vCPU をゼロにしてアイドル時のインスタンスを残さない、ジョブのリソース要求を適正化して1インスタンスあたりの実行効率を上げる、といった工夫も効果的です。具体的な料金は地域やインスタンスタイプで変動するため、最新の料金表で確認してください。

セキュリティ

• ジョブにはジョブ実行に使う IAM ロールを割り当て、ジョブが必要とする AWS リソースへのアクセス権限のみを最小権限で付与する。
• ジョブを VPC 内のプライベートサブネットで実行し、必要な通信のみをセキュリティグループで許可する。S3 などへのアクセスは VPC エンドポイント経由にできる。
• コンテナイメージは ECR のプライベートリポジトリに置き、イメージスキャンで脆弱性を確認する。
• 保存データと転送データの暗号化を有効にし、ジョブが扱う機密情報は Secrets Manager や Parameter Store から取得する。

Well-Architected の観点

• パフォーマンス効率: ジョブの要求量に応じて計算資源が自動でスケールするため、ピーク負荷に追従しつつ過剰なプロビジョニングを避けられる。GPU や特定インスタンスタイプの要求にも対応できる。
• コスト最適化: スポットの活用とアイドル時の自動縮小により、使った分だけ支払うモデルを実現できる。Batch 自体は無料で、基盤リソースのみが課金対象。
• 信頼性: リトライやタイムアウト、ジョブ依存関係により、失敗や中断に強い処理を組める。冪等な設計と組み合わせると堅牢になる。
• 運用上の優秀性: ログとイベントを CloudWatch や EventBridge に集約でき、自動化と監視を組み込みやすい。

試験で問われるポイント

関連サービス・比較

短時間で完結する大量のバッチジョブを「キュー＋自動スケールする計算環境」で回すのが AWS Batch です。一方、AWS Lambda はイベント駆動で短時間の関数を実行するサーバレスサービスで、性質が異なります。長時間・大容量・GPU を要するジョブには Batch、短時間で軽量なイベント処理には Lambda が向きます。

ハンズオン / CLI例

以下は、ジョブ定義を登録し、既存のジョブキューにジョブを投入して状態を確認する一連の流れです。計算環境とジョブキューはあらかじめ作成済みである前提です。

# ジョブ定義を登録する（コンテナ型、Fargate 実行を想定）
aws batch register-job-definition \
  --job-definition-name my-batch-job \
  --type container \
  --platform-capabilities FARGATE \
  --container-properties '{
    "image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-job:latest",
    "resourceRequirements": [
      {"type": "VCPU", "value": "1"},
      {"type": "MEMORY", "value": "2048"}
    ],
    "executionRoleArn": "arn:aws:iam::123456789012:role/myBatchExecutionRole"
  }'

# ジョブを既存のキューに投入する
aws batch submit-job \
  --job-name my-job-run-001 \
  --job-queue my-job-queue \
  --job-definition my-batch-job

# 投入したジョブの状態を確認する
aws batch describe-jobs --jobs <ジョブID>