Azure Container Appsにおけるパターンごとのネットワーク構成図を解説

# はじめに
3回に分けてAzure Container Apps（以下、ACA）の内部ネットワーク構造に注目し、深堀りしていきます。
以下の流れで説明していきます。

第1回目：Azure Container Appsにおける基本的なネットワークの概念を解説
第2回目：Azure Container Appsにおいて選択できるネットワークオプションとパラメータを解説
第3回目：Azure Container Appsにおけるパターンごとのネットワーク構成図を解説

今回は第3回目で、**ACAにおけるパターンごとのネットワーク構成図**について解説していきます。

# 前回の記事

https://qiita.com/maplejava/items/e2ba406af12a018f03d8

https://qiita.com/maplejava/items/62517f945fe34c3cea96

# 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の設定が可能になる。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/6158fdb9-481c-d7ec-4c1a-fa16ce7eaa9e.png)


### Revision
ACAの特定のバージョン（断面）のこと。
構成管理のための概念。

その他、ACAの基礎知識は以下の記事を参考にしてください。

https://qiita.com/maplejava/items/22a4b431d70e092b7d68

# ACAのネットワークオプションのパターン
以下のパターンごとにネットワーク構成を整理します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/ab5ff5f7-714b-3128-ec82-202e936a7cdc.png)

# 調査方法
MSドキュメントの閲覧やサポートリクエストに加え、前スライドのパターンごとにACAEとACAを作成し、以下のことを実施した。
- ACAE、ACAの作成時に同時に作成されるリソース（ロードバランサなど）の設定値を確認する
- ACAEを統合したVNetの「接続デバイス」を確認する
ACAEを統合したVNetにPrivate DNS Zoneを接続し、VNetに接続されているリソースのホスト名とIPアドレスの対応を確認する。
- ACAの「コンソール」画面からACA内のコンテナにSSH接続し、tcpdumpやipコマンドから情報を取得する

（例）パターン1のACAに統合したVNetの「接続デバイス」の一部
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/fa00797a-1b0b-420f-596f-a829eb502708.png)

# パターン1の構成図とポイント
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/b975511c-866e-c169-3b5b-4cc6a7994bb1.png)

ネットワーク構成は以下のようなイメージ。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/58d7f584-9e9a-8d39-997c-d051db9dadc4.png)

右側のプライベート環境にいるAzure VMからACAにアクセスする際の通信フローは以下のようなイメージ。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/423c0abb-fd7b-6b1e-7e49-1bf72a8cf406.png)

### ポイント1
Ingressの実態はACA内のPodであり、revision間でInboundのトラフィックを負荷分散している。
### ポイント2
ACAと同時に作成される「kubernetes-internal」LBはEnvironment内の各ACAにInboundのトラフィックを負荷分散している。
### ポイント3
ACAと同時に作成される「kubernetes」LBはACA内のアプリ内でOutboundの通信が必要な時に使用される。
内部的にはPod→Node→LBの順番にトラフィックが運搬される。

# パターン2の構成図とポイント
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/3dbb6835-5851-edc5-d3c4-ade7dd6e9c2a.png)

ネットワーク構成は以下のようなイメージ。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/1751b9f9-604d-63c4-1795-1851db6bfa43.png)


右側のプライベート環境にいるAzure VMからACAにアクセスする際の通信フローは以下のようなイメージ。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/8fc0dc70-9f48-19c9-479c-87a59b70966a.png)

### ポイント1
「仮想IP」を「外部」にしていることから、パターン1の時に作成されたLBは作成されない
### ポイント2
ACAと同時に作成される「kubernetes」LBは、 Environment内の各ACAにInboundのトラフィックを負荷分散している。 
また、ACA内のアプリ内でOutboundの通信が必要な時にも使用される。

# パターン3の構成図とポイント
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/377e8c44-dfcf-3f08-554f-722f3ee67051.png)

ネットワーク構成とアクセス時の通信フローは以下のようなイメージ。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/0b3943c3-1d0b-cb33-8e08-3de557662249.png)

### ポイント1
ワークロードオプションにした場合Outbound用のLBが非可視になる。
この点についてAzureサポートリクエストを行ったところ、新規のオプションであるワークロードオプションではLB等は非可視となっているが、**実態としては存在している**旨回答を頂いた。
### ポイント2
Ingressの実態はACA内のPodであり、revision間でInboundのトラフィックを負荷分散している。
### ポイント3
パターン1と名前は異なるものの役割は同じで、ACAと同時に作成される「capp-svc-lb」LBはEnvironment内の各ACAにInboundのトラフィックを負荷分散している。

# パターン4の構成図とポイント
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/9f148de4-d9cd-f43b-0879-e0dcbbe39718.png)


ネットワーク構成とアクセス時の通信フローは以下のようなイメージ。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/c45ab80a-915e-8b3d-3580-6950d8b8179e.png)

### ポイント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の比較
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/0570796c-f48b-2580-ddc2-22fc7a2fb60b.png)

こちらもサポートリクエストしたところ、100.100.x.xはワークロードオプションにおいてシステムリソースが使用するIPレンジとして確保されている領域であった。
パターン3の通信（内部LB⇔VMSS）はVNet間で完結しているため、VNetレンジのIPが使用されている。
パターン4の通信（外部LB⇔VMSS）はVNet内に通信が完結していないことから、外部LBから見たときのIPアドレスとしてシステムリソースのIPアドレスが使用されている。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2475719/4293cfe9-a23c-69f4-33c0-02e54d610867.png)

参考

https://learn.microsoft.com/ja-jp/azure/container-apps/networking?tabs=workload-profiles-env%2Cazure-cli

# おわりに
3回にわたってACAの内部的なネットワーク構造について整理しました。
ACAのようなマネージドサービスにおいても、内部的な仕組みを理解しておくことは役立つと思いますので、是非参考にしてみて下さい。