Azure Container Appsで構築するマイクロサービスの実務ガイド

マイクロサービスをコンテナで運用したいものの、Kubernetes クラスターの構築と保守までは抱え込みたくない。こうした要望に応えるのが Azure Container Apps（ACA）です。ACA は Kubernetes と KEDA を基盤としたサーバーレスコンテナ実行環境であり、ノードやコントロールプレーンの管理を意識せずにコンテナを稼働できます。本稿では、2026 年時点の機能を前提に、マイクロサービスを設計・デプロイするうえで押さえておきたい要素を実務目線で整理します。

Azure Container Apps の位置づけ

ACA は AKS（Azure Kubernetes Service）のように raw な Kubernetes API を露出せず、アプリケーション単位の抽象化を提供します。開発者が扱うのは「コンテナアプリ」と、それらをまとめる「環境（Environment）」という単位であり、ノードプールやマニフェストの詳細管理は基盤側に委譲されます。

特徴を整理すると次のようになります。

• サーバーレス実行 — ノードの容量計画やパッチ適用を運用対象から外せる
• KEDA ベースの自動スケール — HTTP 同時実行数、CPU/メモリ、Azure Service Bus のキュー長などのイベントに応じてレプリカ数を増減する
• ゼロスケール — 無トラフィック時にレプリカを 0 まで縮小し、アイドル時のコストを抑える
• Dapr のビルトイン統合 — サービス呼び出し、状態管理、pub/sub をサイドカーとして利用できる

マネージド度の高さと引き換えに、カスタムのアドミッションコントローラーや任意の Operator を持ち込むといった Kubernetes ネイティブの自由度は制限されます。この線引きが AKS との使い分けの起点になります。

環境・リビジョン・Ingress・トラフィック分割

ACA のデプロイ単位は環境の中に配置される個々のコンテナアプリです。環境は同一の仮想ネットワーク境界と Log Analytics ワークスペースを共有する論理的な括りであり、相互に通信するマイクロサービス群は同じ環境にまとめるのが基本形になります。

リビジョンとトラフィック分割

コンテナアプリの設定やイメージを更新すると、ACA は不変な「リビジョン」を生成します。複数のリビジョンを同時にアクティブにでき、それぞれへ流すトラフィックの比率を宣言的に指定できます。たとえば安定版に 90 パーセント、新版に 10 パーセントを割り当てれば、そのままカナリアリリースになります。問題がなければ比率を段階的に移し、異常があれば旧リビジョンへ即座に戻せます。

Ingress

各アプリには HTTP/TCP の Ingress を設定できます。外部公開（external）と環境内限定（internal）を選べるため、フロント境界のサービスだけを外部公開し、バックエンドのサービスは環境内からのみ到達可能にする、といった構成が自然に表現できます。TLS 終端やスティッキーセッションもマネージドで提供されます。

Dapr によるサービス間連携

分散アプリケーションで反復的に登場する関心事を、ACA は Dapr（Distributed Application Runtime）のサイドカーとして吸収します。アプリごとに dapr を有効化し、App ID を割り当てるだけでサイドカーが注入されます。主に使う機能は次の三つです。

• サービス呼び出し — App ID を宛先にした HTTP/gRPC 呼び出しで、名前解決・リトライ・mTLS を Dapr 側が担う
• 状態管理 — Azure Cosmos DB や Redis などを状態ストアとして統一 API で読み書きする
• pub/sub — Azure Service Bus や Event Hubs をブローカーに、発行・購読を疎結合に実装する

コンポーネントは環境スコープで定義し、どのアプリからアクセスできるかを scopes で制御します。以下は状態ストアを Bicep で定義する例です。

resource stateStore 'Microsoft.App/managedEnvironments/daprComponents@2024-03-01' = {
  name: 'statestore'
  parent: containerAppEnv
  properties: {
    componentType: 'state.azure.cosmosdb'
    version: 'v1'
    metadata: [
      { name: 'url', value: cosmosAccountUri }
      { name: 'database', value: 'appstate' }
      { name: 'collection', value: 'state' }
    ]
    secrets: [
      { name: 'master-key', value: cosmosPrimaryKey }
    ]
    scopes: [ 'order-service', 'inventory-service' ]
  }
}

スケーリングと Jobs、ワークロードプロファイル

KEDA スケールルール

スケール条件はアプリごとに複数定義でき、最小・最大レプリカ数の範囲内で増減します。HTTP スケールに加え、キュー長やカスタムメトリクスに反応させることで、非同期ワーカーの負荷追従が容易になります。最小レプリカを 0 にすればゼロスケールが有効になり、常時稼働が必要なサービスは 1 以上を指定します。

Jobs

常駐サービスとは別に、ACA には有限時間で完了する処理を扱う Jobs があります。手動実行、cron によるスケジュール実行、イベント駆動実行の三方式に対応し、バッチ処理やキュー消費型のワーカーを常駐アプリと同じ環境・同じスケール基盤の上で動かせます。

ワークロードプロファイル

実行基盤は用途に応じて選択します。従量課金（Consumption）はゼロスケール可能で断続的な負荷に向き、専用（Dedicated）は割り当てを固定して安定した性能とネットワーク分離を提供します。加えて GPU 対応プロファイルが用意されており、推論やメディア処理といった負荷を同一環境内に共存させられます。負荷特性の異なるサービスをプロファイル単位で振り分けるのが基本方針になります。

ネットワーク・セキュリティ・監視

環境作成時に既存の VNet サブネットへ統合でき、内部専用（internal）環境として構成すれば外部からのアクセスを遮断したうえでプライベート接続に閉じられます。オンプレミスや他の PaaS との接続は、この VNet 統合を起点に設計します。

認証情報の取り扱いはマネージド ID を基本とします。システム割り当てまたはユーザー割り当ての ID を付与すれば、Azure Container Registry からのイメージ取得や、Key Vault・Cosmos DB といったリソースへのアクセスを、接続文字列を埋め込まずに RBAC で制御できます。アプリ固有のシークレットは ACA のシークレット機能で保持し、Key Vault 参照と組み合わせて集約管理します。

可観測性は環境に紐づく Log Analytics ワークスペースへ集約されます。標準ログとコンソールログ、システムメトリクスがここに送られ、Application Insights と Dapr の分散トレーシングを併用すれば、サービスをまたぐリクエストの経路を追跡できます。分散システムでは障害箇所の特定コストが上がりやすいため、トレーシングと構造化ログは初期構成の段階から組み込んでおくことをお勧めします。

AKS との使い分け

ACA が適するのは、Kubernetes の運用そのものを目的化せず、マイクロサービスやイベント駆動ワーカー、HTTP API を素早く立ち上げたいケースです。ゼロスケールやリビジョン管理、Dapr 統合を追加実装なしに得られる利点が大きく効きます。

一方、クラスター全体の細かな制御が要件になる場合は AKS が優位です。具体的には、任意の Operator や CRD の導入、サービスメッシュの独自運用、GPU やノード構成のきめ細かなチューニング、既存の Kubernetes 資産の踏襲などが挙げられます。運用チームに Kubernetes の知見があり、その自由度を活かせる前提が揃っているなら AKS を選ぶ意義があります。多くの新規プロジェクトでは ACA から始め、制御要件が明確に上回った領域だけを AKS へ移すという段階的な判断が現実的です。

デプロイの実際

小さく検証するなら az CLI が手早く、再現性と構成管理を重視するなら Bicep によるコード化が向きます。まず CLI で環境とアプリを作成する例を示します。

az containerapp env create \
  --name aca-env \
  --resource-group rg-microservices \
  --location japaneast \
  --logs-workspace-id "$LOG_ANALYTICS_ID"

az containerapp create \
  --name order-service \
  --resource-group rg-microservices \
  --environment aca-env \
  --image "$ACR_LOGIN_SERVER/order-service:latest" \
  --ingress internal --target-port 8080 \
  --min-replicas 0 --max-replicas 10 \
  --enable-dapr --dapr-app-id order-service --dapr-app-port 8080 \
  --system-assigned

本番構成は Bicep で宣言し、環境・アプリ・スケールルールを一体で管理します。

resource orderService 'Microsoft.App/containerApps@2024-03-01' = {
  name: 'order-service'
  location: location
  identity: { type: 'SystemAssigned' }
  properties: {
    managedEnvironmentId: containerAppEnv.id
    configuration: {
      dapr: { enabled: true, appId: 'order-service', appPort: 8080 }
      ingress: { external: false, targetPort: 8080 }
    }
    template: {
      containers: [
        {
          name: 'order-service'
          image: '${acrLoginServer}/order-service:latest'
          resources: { cpu: json('0.5'), memory: '1Gi' }
        }
      ]
      scale: {
        minReplicas: 0
        maxReplicas: 10
        rules: [
          {
            name: 'queue-scale'
            custom: {
              type: 'azure-servicebus'
              metadata: { queueName: 'orders', messageCount: '20' }
            }
          }
        ]
      }
    }
  }
}

Bicep をリポジトリで管理し、CI/CD からデプロイする流れに載せておけば、環境間の差異を宣言的に抑えつつ、リビジョンによる安全なリリースを継続的に回せます。

エンハンスド株式会社では、Azure Container Apps を用いたクラウドネイティブ設計と、既存アプリケーションのコンテナ化・マイクロサービス移行を支援しています。現行構成の評価から、環境設計・Dapr 連携・CI/CD 整備まで、要件に応じて伴走します。移行可否の見極めからでもお気軽にご相談ください。

このテーマの全体像は .NET モダナイゼーション完全ガイド にまとめています。