Azure Batch

解決する課題

数百〜数千コア規模の計算を、サーバー群の調達・スケジューラ運用なしで並列実行できます。

• 大量の入力を並列に処理したい（レンダリング、シミュレーション、ETL、メディア変換、遺伝子解析など）
• ジョブのキューイングとスケジューリング、VM 群へのタスク割り当てを自前で書きたくない
• 負荷の波に合わせて計算ノードを自動で増減し、不要時は0 台まで落としてコストを抑えたい
• 中断を許容できるワークロードをスポット（低優先度）VMで安く回したい

主要概念と用語

• プール（Pool）: タスクを実行する計算ノード（VM）の集合。OS イメージ、VM サイズ、ノード数、自動スケール式を指定する
• ノード（Node）: プール内の 1 台の VM。タスクはこのノード上で実行される
• ジョブ（Job）: 複数タスクをまとめる論理単位。実行先のプールを関連付ける
• タスク（Task）: 実行の最小単位。1 つのコマンドラインとして 1 ノード上で動く
• 自動スケール（Autoscale）: キューの長さなどのメトリクスを使った数式でノード数を増減する仕組み
• スポット／低優先度ノード: 余剰容量を安価に使うノード。**中断（プリエンプション）**され得る代わりに割引が大きい
• アプリケーションパッケージ: タスクが使う実行ファイルや依存をノードへ配布する仕組み
• タスク依存関係: 「A の完了後に B」を表現する依存定義（DAG 的な制御）

仕様・制限・クォータ

• ノードには Windows / Linux の Marketplace イメージやカスタムイメージを使用でき、VM サイズもシリーズから選べる（GPU 系を含む）
• サブスクリプション・リージョンごとに コア（vCPU）クォータやプール数・ジョブ数の上限があり、引き上げ申請が可能
• スポット（低優先度）ノードはいつでも中断され得るため、専用ノードとは別枠のクォータで管理される
• 1 タスクのファイル出力やリトライ回数、タスクの最大保持期間など、ジョブ／タスク単位の設定で実行挙動を制御する
• 具体的なクォータ数値は変動するため、計画時は対象リージョンの最新値を確認する

内部の仕組み

Azure Batch は ジョブスケジューラとプール管理を担うマネージドな制御プレーンです。利用者はプール（VM 群）とジョブ（タスクの集合）を定義し、Batch サービスがタスクを空きノードへ割り当てて実行します。各ノードでは Batch エージェントがタスクを起動し、標準出力・標準エラーやリトライを管理します。

• プールは自動スケール式に従い、キューに溜まったタスク量などに応じてノードを増減する（不要時は 0 台まで縮小可能）
• 専用ノードとスポット（低優先度）ノードを混在させ、ベースを専用・上積みをスポットといった構成にできる
• タスクは冪等に作っておくと、ノード中断やリトライ時に安全に再実行できる

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

• タスクを冪等・ステートレスに作り、入出力は Blob Storage 等の外部に置く（ノードはいつでも消えてよい状態にする）
• 入力配布はアプリケーションパッケージやリソースファイルで行い、ノード起動を標準化する
• 専用ノードで最低限の処理能力を確保しつつ、変動分をスポットノードで吸収してコスト最適化する
• 大量タスクはタスク依存関係で順序付けし、前処理→本処理→集約のパイプラインを組む
• 似たワークロードでも、Web/API 寄りなら Container Apps Jobs や AKS、関数粒度なら Azure Functions と役割を切り分ける

運用・監視

• メトリクス・ログは Azure Monitor に集約し、ノード数、タスクの失敗率、キュー滞留などを監視・アラートする
• 失敗タスクは標準出力・標準エラーファイルや終了コードで原因を切り分ける
• スケールが想定通りに効かない場合は、自動スケール式とクォータ上限、ノードの起動失敗を確認する
• デプロイ・実行は az batch CLI や SDK、各種パイプラインから自動化する

コスト

Batch サービス自体に追加料金はかからず、起動した計算ノード（VM）とストレージ・ネットワークの利用分が主なコストです。

• 不要時に 0 台まで縮小する自動スケールと、スポットノードの活用が削減の二本柱
• リザーブドインスタンスや Savings Plan の対象 VM を選べば、定常的な専用ノード分をさらに割り引ける場合がある（要計測）

セキュリティ

• ノードからの他リソースアクセスはマネージド IDを使い、資格情報のハードコードを避ける（AWS の IAM ロール相当）
• 秘密情報は Key Vault で管理し、接続文字列やキーをタスク定義・スクリプトに直書きしない
• ネットワーク分離が必要なら、プールを仮想ネットワークへ配置し、プライベートエンドポイントで Batch アカウントへ接続する
• アカウントやプール操作の権限は Microsoft Entra ID と RBAC で最小化する

Well-Architected の観点

• パフォーマンス効率: タスクを細かく分割して並列度を上げ、自動スケールで需要に追随する。VM サイズはワークロード特性（CPU／メモリ／GPU）に合わせて選ぶ
• コスト最適化: アイドル時に 0 台まで縮小し、中断許容ワークロードはスポットノードへ寄せる。中間データは早期削除し、ストレージ転送量を抑える

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# リソースグループと Batch アカウントを作成
az group create --name demo-rg --location japaneast
az batch account create \
  --name demobatchacct \
  --resource-group demo-rg \
  --location japaneast

# Batch アカウントに CLI をログイン（以降のコマンドの対象を設定）
az batch account login \
  --name demobatchacct \
  --resource-group demo-rg

# Ubuntu のプールを作成（専用 2 ノードで開始）
az batch pool create \
  --id demo-pool \
  --vm-size Standard_D2s_v3 \
  --target-dedicated-nodes 2 \
  --image canonical:0001-com-ubuntu-server-jammy:22_04-lts \
  --node-agent-sku-id "batch.node.ubuntu 22.04"

# ジョブを作成し、プールに関連付け
az batch job create \
  --id demo-job \
  --pool-id demo-pool

# タスクを 1 つ投入（コマンドラインを実行）
az batch task create \
  --job-id demo-job \
  --task-id task1 \
  --command-line "/bin/bash -c 'echo Hello from Azure Batch'"