Azure Container Apps

Azure Container Apps（ACA）は、Kubernetes と KEDA（Kubernetes Event-Driven Autoscaling）を基盤とする、フルマネージドのサーバーレスコンテナホスティングサービスです。AKS とは異なり、コントロールプレーン、ノードプール、Kubernetes マニフェストを直接管理する必要はありません。代わりに、シンプルな CLI または YAML 定義を使用してコンテナーをデプロイすると、Azure がオーケストレーション全体を処理します。ACA は、スケール ゼロを含む動的なスケーリングが必要なマイクロサービス、API バックエンド、イベント駆動型ワーカー、バックグラウンド処理ジョブに適しています。

Container Apps Environmentは、1 つ以上の Container Apps を実行する分離境界です。環境内のすべてのアプリは、同じ仮想ネットワークと Log Analytics ワークスペースを共有します。環境はリージョンとリソース グループに属します。チーム間またはステージ間（本番とステージングなど）を分離するために、複数の環境をデプロイできます。環境は、必要に応じて独自の仮想ネットワークにVNet 統合し、パブリックインターネットを経由せずに Container Apps と他の Azure サービスとのプライベート通信を可能にできます。

Container App をデプロイするには、コンテナーイメージ（Azure Container Registry または任意のパブリックレジストリから取得）、レプリカ数、環境変数を指定します。外部イングレスを有効にすると、自動生成された HTTPS URL でアプリにパブリックアクセスできるようになります。イングレスの構成には、ターゲットポート、ブルーグリーンデプロイ用のトラフィック分割、HTTP または HTTPS のみを許可するかどうかが含まれます。ACA はデプロイ時にイメージをプルするため、環境にはレジストリからプルする権限が必要です。

Container Apps は、外部メトリックをトリガーにする KEDA スケーラーを使用してスケーリングします。組み込みの KEDA スケーラーには、HTTP トラフィック（レプリカあたりの同時リクエスト数）、Azure Service Bus キューの深さ（待機中のメッセージ数）、Azure Storage Queue、Cron（時間ベース）、CPU/メモリがあります。スケーラーのメトリックが 0 になり、minReplicas が 0 に設定されている場合、Container Apps はスケール ゼロになります。新しいリクエストが到着するまでコンピューティングコストは発生しません。スケール ゼロは、負荷が断続的に発生するイベント駆動型ワーカーに最適です。

Dapr（Distributed Application Runtime）は、マイクロサービスの構築を簡素化する、移植可能なイベント駆動型ランタイムです。Container Apps には Dapr のネイティブ統合機能があり、アプリごとに 1 つのフラグを設定するだけで有効にできます。Dapr は、サービス呼び出し（再試行と mTLS 対応）、パブリッシュ/サブスクライブメッセージング（Service Bus や Event Hubs を抽象化）、状態管理（Redis や Cosmos DB を抽象化）、出力バインディングのためのビルディングブロックを提供します。Dapr を使用すると、マイクロサービスは基盤となるインフラストラクチャの詳細を意識せず、Dapr サイドカーを介して通信できます。

Container App にデプロイするたびに、新しいリビジョンが作成されます。複数リビジョンモードでは、ブルーグリーンデプロイやカナリアデプロイのために、リビジョン間でトラフィックを分割できます。たとえば、新しいリビジョンに 10%、現在の安定版リビジョンに 90% のトラフィックを送信します。新しいリビジョンのエラー率とレイテンシを監視してから、トラフィックの割合を 100% に増やしてください。古いリビジョンは無効化できますが、履歴には保持されるため、トラフィックの割合を戻すだけで即座にロールバックできます。

Container Apps では、構成を注入する方法として、環境変数（機能フラグや API URL などの機密性のない構成用）とシークレット（接続文字列などの機密性の高い値用）の 2 つを使用できます。シークレットは Container App レベルで保存され、環境変数または Dapr コンポーネントから参照されます。最も安全な構成にするには、マネージド ID を使用して Azure Key Vault からシークレットを参照します。これにより、シークレットの値は実行時に取得され、Container App の構成プレーンに保存されることはありません。

Container Apps Jobs は、実行完了型のワークロード（起動して処理を実行し、終了するコンテナー）をサポートするようにプラットフォームを拡張します。ジョブには3種類のトリガーがあります。手動（APIまたはCLI経由で起動）、スケジュール（cron式）、イベント駆動（KEDA scalerが各実行をトリガー）です。ジョブの課金対象は実際の実行時間のみであり、定期的またはイベントへの応答として実行するバッチ処理、レポート生成、データベースの移行、ML推論パイプラインに適しています。

Container Apps は、環境に接続された Log Analytics ワークスペースにシステムログ（リビジョンの作成やスケーリングなどのプラットフォームイベント）とコンソールログ（アプリケーションの標準出力／標準エラー）を送信します。KQLを使用してログをクエリできます：ContainerAppConsoleLogs_CL | where ContainerAppName_s == 'myapi' | project TimeGenerated, Log_s。組み込みのAzure Monitor メトリックには、レプリカ数、リクエスト数、リクエスト遅延、レプリカごとのCPU／メモリ使用率が含まれており、追加設定なしでAzureポータルからすべて利用できます。

適切なAzureコンテナープラットフォームを選択する際、Container Apps は、クラスターを管理せずにKubernetesのメリットを得たいマイクロサービス、イベント駆動ワーカー、APIに最適です。特に、ゼロスケールが有効な場合に適しています。AKS は、Kubernetesを完全に制御したい場合、カスタムオペレーターが必要な場合、または特定のノード構成（GPU、高メモリ）が必要な場合に最適です。App Service は、コンテナー管理のオーバーヘッドなしにシンプルなPaaSモデルを好む開発チームにとって、従来型のWebアプリケーションやAPIに最適です。3つすべてがコンテナーをサポートしますが、違いは管理の複雑さと制御性のバランスにあります。

Container Apps は2種類のイングレスモードをサポートします。外部は、自動TLSが有効なロードバランス済みHTTPSエンドポイント経由でパブリックに到達できます。内部は、同じContainer Apps環境内、またはVNetピアリングされたリソースからのみ到達できます。内部イングレスは、インターネットに決して公開したくないバックエンドサービスに使用します。同じ環境内では、自動生成される内部DNS名 http://myapi を使用してアプリ同士を呼び出せるため、APIゲートウェイをデプロイせずにシンプルなサービス間通信を実現できます。

このレッスンで扱った Microsoft Azure Fundamentals（AZ-900）の概念について、理解度を確認しましょう。

このレッスンでは、Azure Container Apps がクラスター管理なしでKubernetesとKEDAを基盤とするサーバーレスのコンテナーホスティングを提供すること、KEDA scalers によってキューの深さ、HTTPトラフィック、cronスケジュールに基づくゼロスケールが可能になること、そしてDapr統合によってマイクロサービス間の通信と状態管理が簡素化されることを学びました。次は、これらすべてを完全なエンドツーエンドの開発者ワークフローにまとめます。