Azure Container Instances (ACI)

解決する課題

• コンテナを1つだけ手早く動かしたい。クラスターやノードの用意はしたくない
• バッチ処理・データ変換・CI のビルドジョブなど、短時間で終わる単発のタスクを実行したい
• 突発的な負荷に対して、既存のオーケストレーターからバースト用のコンテナを切り出して実行したい
• VM を立てるほどではないが、コンテナイメージはそのまま動かしたい
• 起動から終了までの実行した分だけ課金したい（アイドル中の固定費を避けたい）

主要概念と用語

• コンテナーグループ（Container Group）: ACI のデプロイ単位。1つ以上のコンテナをまとめ、同一ホスト・同一ネットワーク・同一ストレージを共有する。Kubernetes の Pod に相当する考え方
• イメージ: 起動するコンテナイメージ。Docker Hub や Azure Container Registry などのレジストリから取得する
• 再起動ポリシー（Restart Policy）: コンテナ終了時の挙動。常に再起動する「Always」、失敗時のみの「OnFailure」、再起動しない「Never」から選ぶ。バッチ用途では Never か OnFailure を使う
• OS の種類: Linux コンテナと Windows コンテナのどちらかをコンテナーグループ単位で選ぶ
• CPU / メモリ割り当て: コンテナーグループに割り当てる vCPU とメモリ量。リソース単位で課金される
• マウント: Azure Files 共有や空ディレクトリ、シークレットなどをボリュームとしてコンテナに割り当てる
• コンテナーグループ プロファイル / Confidential: GPU や機密コンピューティングなど、用途に応じた実行形態の選択肢

仕様・制限・クォータ

• ACI はオーケストレーション機能を持たない。自動スケール・ローリング更新・自己復旧（再スケジュール）は提供されず、これらが必要なら上位サービスに任せる
• デプロイの最小単位はコンテナーグループで、グループ内のコンテナはリソースとライフサイクルを共有する
• コンテナーグループに割り当て可能なvCPU・メモリには上限があり、リージョンや OS 種別によって異なる。GPU 利用など特殊なケースは提供リージョンが限られる
• サブスクリプション / リージョン単位のクォータがあり、必要に応じて引き上げを申請できる
• 公開時はパブリック IP と FQDN を割り当てるか、仮想ネットワークに統合してプライベート IP で動かす形を選ぶ
• 起動は速いが、常時稼働の Web アプリのように無停止で長期運用する設計には向かない。長期常駐なら Container Apps や AKS を検討する

内部の仕組み

ACI では、利用者がコンテナイメージとリソース量を宣言すると、Azure がマネージドな基盤上に隔離されたコンテナーグループを割り当てて起動します。ホスト OS・ハイパーバイザー・パッチ適用などの基盤運用は Azure 側が担い、利用者はノードやクラスターの存在を意識しません。各コンテナーグループはハイパーバイザーレベルで分離され、マルチテナント環境でも他テナントのワークロードから隔離されます。

コンテナーグループ内の複数コンテナは同じネットワーク名前空間を共有し、localhost 経由で相互通信できるほか、同じボリュームをマウントできます。これはサイドカーパターン（メインのコンテナにログ転送やプロキシのコンテナを併走させる構成）を組むのに適しています。一方で、グループをまたいだスケジューリングやサービス検出、ロードバランシングといったオーケストレーターの責務は ACI 自身には存在しません。複数グループを束ねて運用したい場合は、KEDA や AKS の Virtual Node 経由で ACI を「バースト先の実行基盤」として使う構成が一般的です。

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

• 短命なジョブ向けに使う: バッチ・ETL・スケジュール実行・CI のビルドエージェントなど、終わったら破棄するワークロードに向く。再起動ポリシーは Never か OnFailure にする
• イベント起動と組み合わせる: Logic Apps や Azure Functions、KEDA から ACI のコンテナーグループを起動し、処理が終われば停止する構成にすると無駄なアイドル課金を避けられる
• AKS のバースト先にする: AKS の Virtual Node（Virtual Kubelet 経由）を使うと、ノードプールが埋まったときに Pod を ACI 上に逃がし、ノード増設なしで瞬間的な負荷を吸収できる
• 状態を外部に逃がす: 永続データは Azure Files や Blob、データベースに保存し、コンテナ自体はステートレスに保つ
• イメージは Azure Container Registry に置く: マネージド ID でレジストリ認証を行い、レジストリのパスワードを埋め込まない

運用・監視

• Azure Monitor / Log Analytics にコンテナの標準出力ログとメトリクスを集約できる。ログのクエリやイベントの確認が可能
• コンテナが起動しない場合は、イメージ取得の権限（レジストリ認証・マネージド ID）、リソース割り当て、対象リージョンでの提供可否を確認する
• 単発ジョブでは、再起動ポリシーが意図どおりかを確認する。Always のままだと終了したジョブが再起動を繰り返し、課金が止まらないことがある
• コンテナの状態（起動中・実行完了・失敗）やイベントは CLI やポータルで参照でき、終了コードから失敗原因を切り分ける
• 自己復旧や再スケジュールは行われないため、確実な完了が必要なジョブはリトライ制御を呼び出し側に持たせる

コスト

• 課金は割り当てた vCPU とメモリ量 × 実行秒数を基本とする従量制で、コンテナーグループが稼働している時間に対して発生する
• アイドル中の固定費が発生しにくいため、たまにしか動かない単発処理ではコスト効率が良い
• 逆に、常時稼働で高負荷のワークロードでは、ノードを確保して回す AKS や、ゼロスケールと従量課金を両立する Container Apps の方が有利になる場合がある
• 停止し忘れたコンテナーグループや、Always ポリシーで再起動し続けるコンテナは課金が積み上がるため、不要なグループは確実に削除・停止する
• 具体的な単価やリソース上限はリージョン・時期で変動するため、料金計算ツールで実際の構成に基づき見積もる

セキュリティ

• マネージド ID をコンテナーグループに付与し、Azure Container Registry や Key Vault などへ資格情報なしでアクセスする（AWS の IAM ロール相当の考え方）
• シークレットはシークレットボリュームや Key Vault から注入し、イメージや環境変数に平文で焼き込まない
• ネットワークは仮想ネットワーク統合でプライベート IP のみに閉じ、不要なパブリック公開を避ける。公開が必要な場合のみ FQDN とパブリック IP を割り当てる
• 各コンテナーグループはハイパーバイザーレベルで分離され、テナント間の隔離が保たれる
• 機密性の高い処理には、**機密コンテナー（Confidential containers）**などの分離強化の選択肢を検討する

Well-Architected の観点

• 運用性（Operational Excellence）: クラスター運用が不要で、コンテナを宣言するだけで起動できるため運用負荷が小さい。ただし自己復旧やスケールは持たないので、信頼性が要る処理は呼び出し側や上位サービスで補う
• コスト最適化（Cost Optimization）: 実行した分だけの従量課金で、たまにしか動かないワークロードのアイドル費用を抑えられる。停止し忘れと再起動ポリシーの誤設定がコスト増の主因になりやすい

試験で問われるポイント

関連サービス・比較

ACI は単発実行に割り切ったサービスのため、本番の常時運用やスケールが必要な場合は Azure Container Apps（サーバーレスでゼロスケール対応）や AKS（素の Kubernetes）を選びます。AWS でいう Fargate と ECS / EKS の関係に近い住み分けです。

ハンズオン / CLI例

# リソースグループを準備
az group create --name demo-rg --location japaneast

# 単発コンテナを起動（外部公開・1 vCPU / 1.5 GB・再起動しない）
az container create \
  --resource-group demo-rg \
  --name demo-aci \
  --image mcr.microsoft.com/azuredocs/aci-helloworld:latest \
  --cpu 1 \
  --memory 1.5 \
  --ports 80 \
  --ip-address Public \
  --restart-policy Never

# 公開 FQDN と状態を確認
az container show \
  --resource-group demo-rg \
  --name demo-aci \
  --query "{fqdn:ipAddress.fqdn, state:instanceView.state}" -o table

# コンテナのログを取得
az container logs \
  --resource-group demo-rg \
  --name demo-aci

# 単発バッチとして実行（処理が終わったら削除）
az container create \
  --resource-group demo-rg \
  --name batch-job \
  --image mcr.microsoft.com/azuredocs/aci-wordcount:latest \
  --restart-policy OnFailure \
  --no-wait

# 使い終わったコンテナーグループを削除（課金を止める）
az container delete \
  --resource-group demo-rg \
  --name demo-aci \
  --yes