Azure Container Apps / AKS

解決する課題

• コンテナを本番で安定運用したい（落ちたら再起動、負荷で増減、ローリング更新）
• クラスターや Kubernetes の運用をしたくない → Container Apps
• リクエストが無いときは0 台まで縮めて課金を止めたい（ゼロスケール）
• イベント（キュー長・トピック）に応じてコンシューマーを自動増減したい
• Kubernetes の API・エコシステム（Helm / Operator / CRD）がどうしても必要 → AKS

主要概念と用語

• コンテナーアプリ環境（Environment）: 複数のアプリを束ねる境界。同一仮想ネットワークとログ送信先（Log Analytics）を共有する
• アプリ（Container App）: デプロイ単位。1つ以上のコンテナを持つ
• リビジョン（Revision）: アプリのイミュータブルなスナップショット。トラフィック分割で Blue/Green・カナリアが可能
• レプリカ / スケールルール: リビジョンの実体（Pod 相当）。KEDA ベースのルールで HTTP 同時実行数・CPU・キュー長などに応じて増減
• イングレス: 外部/内部公開の設定。自動で HTTPS・TLS 終端・L7 ルーティングを提供
• Dapr: サービス間呼び出し・状態管理・Pub/Sub を抽象化するサイドカー（任意で有効化）
• （AKS 側）ノードプール / Pod / マネージドコントロールプレーン: AKS は Kubernetes そのもの。コントロールプレーンは Microsoft が管理し無償、課金はワーカーノード（VM）に対して発生

仕様・制限・クォータ

• Container Apps はサーバーレス。レプリカ単位で CPU / メモリを割り当て、最小レプリカ 0（ゼロスケール）〜 最大レプリカの範囲で自動スケール
• スケール制御は KEDA（HTTP・CPU・メモリ・キューなど多数のスケーラー）、内部のサービス検出とロードバランシングは標準提供
• 環境は **Consumption（従量）**プランと、専用ハードウェア・分離が要る場合の **Dedicated（ワークロードプロファイル）**プランを混在可能
• サブスクリプション / リージョンごとにコア数などのクォータがあり、引き上げ申請が可能
• AKS は Kubernetes バージョンのアップグレード、ノードプールの VM サイズ・台数、Cluster Autoscaler などを自分で設計する

内部の仕組み

Container Apps は内部的に Kubernetes + KEDA + Dapr + Envoy を基盤にしていますが、それらは完全に隠蔽されています。利用者はコンテナイメージとスケールルール・イングレスだけを宣言し、ノードやコントロールプレーンの存在を意識しません。Envoy が L7 イングレス（HTTPS 終端・トラフィック分割）を担い、KEDA がイベント/メトリクスに応じてレプリカを 0 台からでも増減させます。

一方 AKS は、Microsoft がマネージドコントロールプレーン（API サーバー・etcd・スケジューラ）を運用し、利用者はワーカーノード（VM）のノードプールを保有します。Pod のスケジューリング・Cluster Autoscaler・アップグレードを自分で制御でき、Kubernetes の全機能（CRD・Operator・Helm）を使えます。

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

• 運用を最小化しゼロスケールしたいなら Container Apps、Kubernetes エコシステムや細かなノード制御が要るなら AKS
• リビジョンのトラフィック分割でカナリア / Blue-Green デプロイ（例: 新リビジョンへ 10% → 100%）
• マイクロサービス間連携は Dapr で疎結合化（サービス呼び出し・Pub/Sub・状態管理）
• 状態はコンテナ外（Azure Cache for Redis / Cosmos DB / Blob）へ逃がし、レプリカをステートレスに保つ
• イメージは Azure Container Registry（ACR） に置き、マネージド ID でレジストリ認証（パスワードレス）

運用・監視

• Azure Monitor / Log Analytics にコンテナの標準出力ログとメトリクスを集約。コンソールログ・システムログをクエリ可能
• レプリカが起動しない → イメージ取得権限（ACR / マネージド ID）、CPU/メモリ割り当て、環境の仮想ネットワーク/サブネットを確認
• デプロイ後にトラフィックが流れない → リビジョンのアクティブ状態とトラフィック配分、イングレスのターゲットポートを確認
• AKS は Container Insights と kubectl でノード/Pod を可視化・調査

コスト

セキュリティ

• マネージド ID をアプリ/クラスターに付与し、ACR や Key Vault・他 Azure リソースへ資格情報なしでアクセス（AWS の IAM ロール相当）
• シークレットはアプリのシークレット参照または Key Vault から注入し、イメージや環境変数の平文埋め込みを避ける
• ネットワークは仮想ネットワーク統合で内部公開（内部イングレス）、必要に応じて NSG で制限。AKS は Azure RBAC for Kubernetes と Entra ID 連携で認可
• イメージは ACR で脆弱性スキャン（Microsoft Defender for Containers）

関連サービス・比較（AWS との対応）

ハンズオン / CLI例

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

# Container Apps 環境を作成（Log Analytics は自動作成される）
az containerapp env create \
  --name demo-env \
  --resource-group demo-rg \
  --location japaneast

# コンテナアプリを作成（外部公開・ポート80・自動スケール 1〜5）
az containerapp create \
  --name web \
  --resource-group demo-rg \
  --environment demo-env \
  --image mcr.microsoft.com/k8se/quickstart:latest \
  --target-port 80 \
  --ingress external \
  --min-replicas 1 \
  --max-replicas 5

# 公開 FQDN を確認
az containerapp show \
  --name web --resource-group demo-rg \
  --query properties.configuration.ingress.fqdn -o tsv

# 新イメージで更新（新リビジョンが作成される）
az containerapp update \
  --name web --resource-group demo-rg \
  --image mcr.microsoft.com/k8se/quickstart:v2

# （参考）AKS クラスターを作成する場合
az aks create \
  --resource-group demo-rg \
  --name demo-aks \
  --node-count 2 \
  --generate-ssh-keys
az aks get-credentials --resource-group demo-rg --name demo-aks