はじめに
3回に分けてAzure Container Apps（以下、ACA）の内部ネットワーク構造に注目し、深堀りしていきます。
以下の流れで説明していきます。
第1回目：Azure Container Appsにおける基本的なネットワークの概念を解説
第2回目：Azure Container Appsにおいて選択できるネットワークオプションとパラメータを解説
第3回目：Azure Container Appsにおけるパターンごとのネットワーク構成図を解説
今回は第3回目で、ACAにおけるパターンごとのネットワーク構成図について解説していきます。
前回の記事
ACAとは
- 2022年5月にGAした、コンテナベースのアプリケーションを簡単にデプロイ、管理、スケールできるサービス
- フルマネージドk8sベースのアプリケーションプラットフォーム
- k8sが提供する高い可用性、セキュリティ、スケーラビリティの恩恵を受けつつ、k8sの管理は不要
- KEDA、Dapr、EnvoyといったCNCFプロジェクトの成果物をマネージドサービスとして提供する
用語
Azure Container Apps Environment
Azure Container Apps Environment（以降、ACAE）は、ACAのインスタンスをホストするための論理的な境界。
ACAEは、アプリケーションが実行されるネットワーク、セキュリティ、およびリソースの設定を提供する。
ACAE内のアプリケーションは、同じリージョン内で物理的に近い場所に配置され、低遅延の通信を実現する。
ちなみに、Azure portalから作成する場合、ACAEの画面からACAEのみを新規作成することはできない（2024年7月初時点）。なので、ACAの作成画面にてACAEの「新規作成」を選択することでACAEの設定が可能になる。
Revision
ACAの特定のバージョン（断面）のこと。
構成管理のための概念。
その他、ACAの基礎知識は以下の記事を参考にしてください。
ACAのネットワークオプションのパターン
以下のパターンごとにネットワーク構成を整理します。
調査方法
MSドキュメントの閲覧やサポートリクエストに加え、前スライドのパターンごとにACAEとACAを作成し、以下のことを実施した。
- ACAE、ACAの作成時に同時に作成されるリソース（ロードバランサなど）の設定値を確認する
- ACAEを統合したVNetの「接続デバイス」を確認する
ACAEを統合したVNetにPrivate DNS Zoneを接続し、VNetに接続されているリソースのホスト名とIPアドレスの対応を確認する。 - ACAの「コンソール」画面からACA内のコンテナにSSH接続し、tcpdumpやipコマンドから情報を取得する
（例）パターン1のACAに統合したVNetの「接続デバイス」の一部
パターン1の構成図とポイント
ネットワーク構成は以下のようなイメージ。
右側のプライベート環境にいるAzure VMからACAにアクセスする際の通信フローは以下のようなイメージ。
ポイント1
Ingressの実態はACA内のPodであり、revision間でInboundのトラフィックを負荷分散している。
ポイント2
ACAと同時に作成される「kubernetes-internal」LBはEnvironment内の各ACAにInboundのトラフィックを負荷分散している。
ポイント3
ACAと同時に作成される「kubernetes」LBはACA内のアプリ内でOutboundの通信が必要な時に使用される。
内部的にはPod→Node→LBの順番にトラフィックが運搬される。
パターン2の構成図とポイント
ネットワーク構成は以下のようなイメージ。
右側のプライベート環境にいるAzure VMからACAにアクセスする際の通信フローは以下のようなイメージ。
ポイント1
「仮想IP」を「外部」にしていることから、パターン1の時に作成されたLBは作成されない
ポイント2
ACAと同時に作成される「kubernetes」LBは、 Environment内の各ACAにInboundのトラフィックを負荷分散している。
また、ACA内のアプリ内でOutboundの通信が必要な時にも使用される。
パターン3の構成図とポイント
ネットワーク構成とアクセス時の通信フローは以下のようなイメージ。
ポイント1
ワークロードオプションにした場合Outbound用のLBが非可視になる。
この点についてAzureサポートリクエストを行ったところ、新規のオプションであるワークロードオプションではLB等は非可視となっているが、実態としては存在している旨回答を頂いた。
ポイント2
Ingressの実態はACA内のPodであり、revision間でInboundのトラフィックを負荷分散している。
ポイント3
パターン1と名前は異なるものの役割は同じで、ACAと同時に作成される「capp-svc-lb」LBはEnvironment内の各ACAにInboundのトラフィックを負荷分散している。
パターン4の構成図とポイント
ネットワーク構成とアクセス時の通信フローは以下のようなイメージ。
ポイント1
「仮想IP」を「外部」にしていることから、パターン3の時に作成された内部用LBは作成されない
ポイント2
ACAと同時に作成される「capp-svc-lb」LBは、 Environment内の各ACAにInboundのトラフィックを負荷分散している。
また、ACA内のアプリ内でOutboundの通信が必要な時にも使用される。
しかし、Outbound用のパブリックIPは非可視となる。
検証時に気になったこと
パターン3（ワークロード・内部）の時とパターン4（ワークロード・外部）の時で、LBから見たときのVMSSのIPアドレスを比較すると、パターン4のVMSSはVNetのレンジではない謎の100.100.x.xのIPとなっている。
ワークロードオプションにおけるLBの比較
こちらもサポートリクエストしたところ、100.100.x.xはワークロードオプションにおいてシステムリソースが使用するIPレンジとして確保されている領域であった。
パターン3の通信（内部LB⇔VMSS）はVNet間で完結しているため、VNetレンジのIPが使用されている。
パターン4の通信（外部LB⇔VMSS）はVNet内に通信が完結していないことから、外部LBから見たときのIPアドレスとしてシステムリソースのIPアドレスが使用されている。
参考
おわりに
3回にわたってACAの内部的なネットワーク構造について整理しました。
ACAのようなマネージドサービスにおいても、内部的な仕組みを理解しておくことは役立つと思いますので、是非参考にしてみて下さい。