Azure Container Apps Jobs

解決する課題

• バッチ処理・データ変換・レポート生成など、処理が終わったら停止する短命なタスクをコンテナで実行したい
• クラスタやノードを構えず、サーバーレスでジョブだけを回したい
• 毎晩・毎時など、スケジュール（cron）で定期的に処理を起動したい
• キューにメッセージが溜まったら自動でワーカーを起動し、空になったら止めたい（イベント駆動）
• 大量の入力を分割して並列に処理し、全体の完了を待ちたい
• 常駐する Web アプリではなく、走り切って終わるワークロードに課金を絞りたい

主要概念と用語

• ジョブ（Job）: Container Apps におけるバッチ実行の定義。コンテナイメージとリソース、起動方式（トリガー）を宣言する。常駐するアプリとは別のリソース種別
• ジョブ実行（Job Execution）: ジョブを起動するたびに作られる1回分の実行インスタンス。完了すると終了し、成功・失敗の状態を持つ
• レプリカ（Replica）: 1回のジョブ実行内で動くコンテナの実体。並列実行では複数のレプリカが同時に走る
• トリガー種別（Trigger Type）: ジョブの起動方式。手動（Manual）、スケジュール（Schedule）、イベント駆動（Event）の3つから選ぶ
• 手動トリガー: API や CLI から明示的に実行を開始する方式。アドホックなバッチや、外部システムからのキック向き
• スケジュールトリガー: cron 式に従って定期実行する方式。夜間バッチや定期レポートに使う
• イベントトリガー: KEDA のスケーラーでキュー長などのメトリクスを監視し、条件を満たすとジョブ実行を起動する方式
• 並列処理（Parallelism）: 1回の実行で同時に走らせるレプリカ数。分割した入力を並列で捌くのに使う
• 再試行回数（Replica Retry Limit）/ タイムアウト: レプリカが失敗したときの再試行上限と、実行を打ち切るまでの上限時間
• コンテナアプリ環境（Environment）: ジョブとアプリを束ねる境界。同一の仮想ネットワークとログ送信先（Log Analytics）を共有する

仕様・制限・クォータ

• ジョブは Container Apps の環境（Environment）内に作成し、アプリと同じ環境・ネットワーク・ログ基盤を共有できる
• 起動方式は手動・スケジュール・イベント駆動の3種類。スケジュールは cron 式、イベント駆動は KEDA スケーラー（キュー長など）で制御する
• 各ジョブ実行には並列レプリカ数と、成功と判定するために完了が必要なレプリカ数を設定でき、分割処理の完了条件を表現できる
• レプリカ単位で再試行回数と実行タイムアウトを設定する。失敗したレプリカは上限まで再試行される
• レプリカに割り当てる vCPU・メモリには上限があり、環境のプラン（Consumption / Dedicated ワークロードプロファイル）によって範囲が異なる
• サブスクリプション / リージョン単位のクォータがあり、同時実行数やコア数は必要に応じて引き上げを申請できる
• ジョブは走り切って終わる前提であり、無停止で常駐させる Web サービスには向かない。常駐用途は通常の Container Apps（アプリ）を使う

内部の仕組み

ジョブはアプリと同じ Container Apps 基盤の上に構築されますが、ライフサイクルが異なります。アプリが「リクエストを受け続ける常駐レプリカ」であるのに対し、ジョブは「起動して処理し、完了したら終了するレプリカ」を作ります。利用者はコンテナイメージと並列数・再試行・トリガーを宣言するだけで、ノードやスケジューラの存在は意識しません。

スケジュールトリガーでは、内部のスケジューラが cron 式を評価し、時刻が来るとジョブ実行を起動してレプリカを立ち上げます。イベントトリガーでは KEDA がキュー長などのメトリクスを定期的に評価し、メッセージが溜まっていれば必要な数だけジョブ実行を起動し、処理対象が無くなれば新たな起動を止めます。これにより、待機中はレプリカが存在せず、アイドル時間に課金が発生しにくい構造になっています。

並列処理では、1回の実行で複数のレプリカを同時に起動し、それぞれが入力の一部を担当します。設定した「完了が必要なレプリカ数」を満たすとその実行は成功と見なされ、失敗したレプリカは再試行上限の範囲で再実行されます。タイムアウトを超えた実行は打ち切られ、失敗として記録されます。

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

• 冪等に作る: 再試行やタイムアウト後の再実行で同じレプリカが複数回走り得るため、処理は冪等（同じ入力なら何度実行しても結果が同じ）に設計する
• スケジュールは cron で宣言的に: 夜間バッチや定期レポートはスケジュールトリガーで宣言し、外部のスケジューラを別途運用しない
• キュー駆動でワーカーを増減: Storage Queue や Service Bus のキュー長を KEDA で監視し、溜まったときだけイベントトリガーでワーカーを起動して空になれば止める
• 並列度で分割処理: 大きな入力をチャンクに分け、並列レプリカ数を上げて処理時間を短縮する。完了に必要なレプリカ数で全体の成功条件を表現する
• 状態は外部に逃がす: 中間結果や永続データは Blob・キュー・データベースに置き、レプリカ自体はステートレスに保つ
• イメージは Azure Container Registry に置く: マネージド ID でレジストリ認証を行い、レジストリのパスワードを埋め込まない

運用・監視

• Azure Monitor / Log Analytics にジョブ実行のコンソールログとシステムログを集約し、実行ごとの標準出力やイベントをクエリできる
• 各ジョブ実行の状態（実行中・成功・失敗）と終了コードを CLI やポータルで確認し、失敗時は終了コードとログから原因を切り分ける
• レプリカが起動しない場合は、イメージ取得の権限（ACR / マネージド ID）、リソース割り当て、環境の仮想ネットワーク・サブネットを確認する
• 失敗が続く場合は、再試行回数とタイムアウトの設定が処理時間に対して妥当かを見直す。タイムアウトが短すぎると正常な処理まで打ち切られる
• イベント駆動でジョブが起動しないときは、KEDA スケーラーの接続情報とメトリクス条件（対象キュー・しきい値）を確認する
• スケジュール実行がずれて見えるときは、cron 式とタイムゾーンの解釈を確認する

コスト

• 課金は**割り当てた vCPU とメモリ量 × ジョブ実行が走っている時間（実行秒）**を基本とする従量制で、実行していない待機中は課金が積み上がりにくい
• アイドル時にレプリカが存在しないため、たまにしか動かないバッチや定期処理ではコスト効率が良い
• 並列レプリカ数を上げると処理時間は短くなるが、同時に消費するリソース量は増えるため、処理時間とコストのバランスで並列度を決める
• 再試行やタイムアウトの設定が緩すぎると、失敗したレプリカの再実行で実行秒が膨らむことがあるため、上限値を適切に設定する
• 具体的な単価やリソース上限はリージョン・時期で変動するため、料金計算ツールで実際の構成に基づき見積もる

セキュリティ

• マネージド ID をジョブに付与し、Azure Container Registry や Key Vault、他の Azure リソースへ資格情報なしでアクセスする（AWS の IAM ロール相当の考え方）
• シークレットはジョブのシークレット参照または Key Vault から注入し、イメージや環境変数に平文で焼き込まない
• ネットワークは仮想ネットワーク統合でプライベートに閉じ、ジョブから内部リソースへ安全に到達させる。NSG で不要な通信を制限する
• イベントトリガーで参照するキューやイベントソースへの接続も、可能な限りマネージド ID で認証し、接続文字列の平文保持を避ける
• イメージは ACR で脆弱性スキャンを行い、信頼できるイメージのみを実行する

関連サービス・比較

ジョブとアプリは同じ Container Apps の中の別の種別で、走り切るのがジョブ、常駐するのがアプリという住み分けです。さらに単発の使い捨てコンテナだけが要るなら Azure Container Instances（ACI）、定期実行のスケジューラとしてワークフロー連携が要るなら Logic Apps や Azure Functions のタイマートリガーも候補になります。AWS では、ジョブ的な並列バッチに AWS Batch、イベント駆動の短命タスクに Fargate タスク が近い位置づけです。

ハンズオン / CLI例

# 拡張機能とリソースグループ・環境を準備
az extension add --name containerapp --upgrade
az group create --name demo-rg --location japaneast
az containerapp env create \
  --name demo-env \
  --resource-group demo-rg \
  --location japaneast

# 手動トリガーのジョブを作成（再試行2回・タイムアウト1800秒）
az containerapp job create \
  --name manual-job \
  --resource-group demo-rg \
  --environment demo-env \
  --trigger-type Manual \
  --image mcr.microsoft.com/k8se/quickstart-jobs:latest \
  --cpu 0.5 --memory 1.0Gi \
  --replica-timeout 1800 \
  --replica-retry-limit 2

# 手動でジョブ実行を開始する
az containerapp job start \
  --name manual-job \
  --resource-group demo-rg

# スケジュール（毎日午前2時）で動くジョブを作成
az containerapp job create \
  --name nightly-job \
  --resource-group demo-rg \
  --environment demo-env \
  --trigger-type Schedule \
  --cron-expression "0 2 * * *" \
  --image mcr.microsoft.com/k8se/quickstart-jobs:latest \
  --cpu 0.5 --memory 1.0Gi \
  --replica-timeout 1800

# 実行履歴と各実行の状態を確認
az containerapp job execution list \
  --name manual-job \
  --resource-group demo-rg -o table