Azure Container Apps 触ってみた～レイテンシ編

# はじめに
Azure で一番簡単にコンテナオーケストレーションを実現する Azure Container Apps について、挙動確認やら色々な計測をしたものを紹介するシリーズ予定の記事になります。

- [事前環境準備](https://qiita.com/shyamagu/items/15f5b67bf8fff2c926dc)
- **レイテンシを測ってみた(※本記事の内容です)**
- ARM テンプレート化してみる(予定)
- スケールの挙動を見てみる(予定)

というわけで、今回は、ネットワークレイテンシについて、Azure Container Apps の動きを見てみます

# そもそも、Azure Container Apps って何さ？
乱暴にいうと、マネージドなAKS、です
- k8s そのものや、下回りの仮想マシンなどの管理は不要
- KEDA によるスケーリング（0スケール可能）
- Envoy によるトラフィック制御
- Dapr によるサービス連携など

あたりが大きな特徴ですね。AKS に比べると細かい部分の設定調整などはできませんが、ざっくり上記の代表的な動きができる便利サービスです。あとはARMテンプレート/bicep で周辺系のサービス( DB など)含めて全部記載できるものメリットになるかなと。k8s なのに、YAML 不要！

# 測ったみた環境について
下図のような Azure Container Apps 環境をベースに、ネットワークレイテンシを計測してみました。

なお、今回は [choi](https://github.com/shyamagu/choi) という通信をリレーするアプリケーションをコンテナとして 4つ使っています。
choi はパブリックなコンテナとして、 **shyamagu/choi:http** を指定すれば構築できるのでこういう環境構築ではとても便利なソフトウェアです

この環境の構築については、[Azure Container Apps 触ってみた～環境準備編](https://qiita.com/shyamagu/items/15f5b67bf8fff2c926dc)をご参照ください。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/977156/970aec2f-e6db-4c58-3795-2ba6744e441d.png" width=70%>

## 測ってみたパート1

まずは以下のルートで各コンテナアプリ間のレイテンシを見てみました。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/977156/b5167055-2ce9-5ef3-78b0-b52cd32a7f83.png" width=70%>

計測のために choi に各接続先を入力していきます。
- SERVER1 の choi uri :　**container-app-1 のURL(external)**
- SERVER2 の choi uri :　**container-app-2 のURL(internal)**
- (+ADD)して、SERVER3 のuriには、**http://localhost:3500/v1.0/invoke/dapr-app3/method/test**
- (+ADD)して、SERVER4 のuriには、**http://localhost:4000/**

SERVER3 のURLは、daprを経由して App3を呼ぶための記載です。SDKとか使えばこんな呼び出し方しないでいいんですが、choiの場合はこういう形でdapr連携できます
SERVER4 はローカルのコンテナを呼ぶので、localhostにポート番号で記載しています。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/977156/00e5d6eb-3f90-3741-fdbc-7e58764dca51.png" width=50%>

またスケールの設定をデフォルトにした場合、リクエストスケール 0-10 でスケールしてしまうので、ゆっくりと処理を流しています。
1秒間隔で10リクエスト指定ですね
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/977156/5e012400-0831-223d-b004-34c776a19772.png" width=50%>

結果は、↓となりました！
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/977156/126fe0dc-6f80-c219-656a-15281fff3112.png" width=80%>

公開されている App1 から、内部イングレス経由の App2 呼び出しが、グラフの赤線と青線の間になります。7 ms~ 11 ms ですね。結構ぶれますね。（とわいえ数ミリ秒ですが）

App2 から Dapr を経由して App3 を呼び出しているのが、グラフの青線と緑線の間になります。4 ms ~ 7ms ですね。内部イングレス経由に比べて高速＆安定しているように見えますね。

最後に App3 から App4、同じ筐体内でローカル呼び出ししているのが、緑線と黄色線の間です。2 ms ~ 4ms ですね。やはり早い。


## 測ってみたパート2

順序が影響していると嫌なので、次に以下のルートで各コンテナアプリ間のレイテンシを見てみます。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/977156/cffe1810-f9ec-1303-0466-4bcf325f4d72.png" width=70%>

choiの設定としては、さっきのやつの順序をいれかえればよいので、以下となります。

- SERVER1 の choi uri :　**container-app-1 のURL(external)**
- SERVER2 の choi uri :　**http://localhost:3500/v1.0/invoke/dapr-app3/method/test**
- (+ADD)して、SERVER3 のuriには、**http://localhost:4000/**
- (+ADD)して、SERVER4 のuriには、**container-app-2 のURL(internal)**

先ほどと同じく、1秒間隔で10回リクエストを投げると・・・

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/977156/4ef6166a-56cb-d255-6198-754dfc2a9696.png" width=80%>

今度は、公開されている App1 から、Dapr 経由の App3 呼び出しが、グラフの赤線と青線の間になります。5 ms~ 7 ms ですね。大体さっきと同じような数字ですね。

次に App3 から App4、同じ筐体内でローカル呼び出ししているのが、青線と緑線の間です。2 ms ~ 4ms で一緒ですね。やはり早い。そらそうなんですが。

最後に App4 から インターナルイングレスを経由して App2 を呼び出しているのが、グラフの緑線と黄線の間になります。なんかはねちゃって、7 ms ~ 22ms ですね。やはり遅くて安定しませんでした。

# おわりに
計測した結果からは、ローカル呼び出しが最速かつ最安定、次にDapr経由、一番遅くて安定していなかったのが内部イングレス経由になりました。
とはいえ、せいぜいが20ミリ秒もない差なので、現実的なアプリの処理時間を加味すれば、いずれもほぼ差分はないように見えそうですが…
またクラウド上なので、計測をやるごとに突如遅くなったりもしますので、この数字に厳密な意味はないというところですが…

それでも**できるだけネットワークを高速＆安定**にさせたいのであれば、Dapr を経由したコンテナアプリ間の呼び出しが求められるシナリオもありそうですね。

なお今回は http でやりましたが、gRPC でやればもう少し高速化すると思われます。これも機会があればやってみたいなと思います。