しばやん雑記

Azure Serverless とメイドさんが大好きなフリーランスのプログラマーのブログ

Azure Container Apps の特徴と Azure Web Apps / Azure Functions との違い

Ignite 2021 で発表された Azure Container Apps について、実際に触って調べたのでいろいろと所感を書きます。特に Web Apps / Azure Functions との違い・使い分けについて重視しました。

名前から分かるようにコンテナーの実行に特化したサービスです。既報の通り Kubernetes 上で動作していますが Kubernetes の知識が無くても簡単に扱えるようになっています。

最新の Serverless サービスなだけあって、全体的に設計が洗練されている印象を持っています。最初からログ周りは Log Analytics ベースになっているのも好印象です。

提供される機能と App Service との違い

まだプレビューなので機能は少なめですが、現時点で提供されている Container Apps の機能は以下のような感じです。カスタム VNET 機能がないと色々始まらない気はしますが、まだ提供されていないようです。

  • Container App
    • 1 つ以上のコンテナーを実行可能、ライフサイクルが同じなので実質 Sidecar 向けか
    • KEDA で管理されたスケーリング、Dapr でイベント駆動と Microservices 向けの機能を提供
    • エンドポイントを Internal / External それぞれに公開可能
    • 同じ Container App Environment 内にある Container App 間は通信可能
    • GitHub Actions を使った Continuous deployment
    • Web App / Azure Function に相当する
  • Container App Environment
    • ネットワークが分離された環境を表すリソース
    • 中身は App Service Kubernetes Environment な模様*1
    • カスタム VNET サポートは Container App Environment 単位になると思われる
    • App Service Plan / App Service Environment に相当する

上手く Kubernetes 部分が隠されているように感じます。開発者がアプリケーションの実装に集中できるというのは、Azure の PaaS / Serverless において不変の思想ですね。

個人的には Azure Spring Cloud から Spring 成分を抜き取ったものが Azure Container Apps だと感じました。AKS と違ってリソースも非常にシンプルです。

f:id:shiba-yan:20211104041136p:plain

Container Apps が公開されて多くの人が思ったのは「今後 Azure Functions と Web Apps はどうなるのか」という点だと思います。そのあたりは自分の中で結論は出ているので書きます。

これまでは Azure Functions や Web Apps の制限に引っかかった場合*2は、次の選択肢が実質 AKS になるという中々ハードな道でした。これは流石に厳しすぎますね。

雑にそれぞれのサービスの特徴をまとめると以下のようになると思います。Azure Functions と Web Apps が Container Apps に取って代わられるというわけではなく、App Service と AKS 間の差が大きかった部分を上手く埋めてきたという印象です。

  • Azure Functions
    • イベント駆動アプリケーション向け
    • 完全に自動化された HTTP / イベントベースのオートスケーリング
    • Azure Functions SDK と Binding / Trigger でサービス依存のコードを書く必要なし
  • Web Apps
    • Web アプリケーション / API 向け
    • Azure Monitor メトリックベースのオートスケーリング
    • カスタムドメイン / TLS 証明書 / 認証・認可 / デプロイといった Web アプリケーションに必要な機能が組み込まれている
    • Windows / Linux に対応、Custom Container にも対応
  • Container Apps
    • Web アプリケーション / イベント駆動アプリケーション向け
    • Managed KEDA / Dapr / AKS という感じ、Kubernetes を意識せずに使えるのは大きなメリット
    • バックグラウンドで常時稼働するアプリケーションを実装可能
    • Microservices を採用したアプリケーションを作る際には今後一択になりそう
  • AKS
    • Container App ではリソースが足りない場合に検討したい*3
    • 全部自分で管理したい場合には視野に入る、その分運用が大変

Azure Functions と Web Apps で多くのサービスを持つ Microservices アプリケーションを開発するのは難しいですが、逆に Container Apps でシングルコンテナーのアプリケーションを 1 つだけ動かすのも、あまりにもオーバースペックだと感じます。

どちらかに統一する必要はなく、両方を要件に合わせて適切に使っていけば良いです。個人的には AKS の出番ほぼなくなったかなと思っています。

HTTP/2 や gRPC への対応

App Service では IIS が gRPC に必要な HTTP/2 機能への対応が遅かったので、現時点でも gRPC は使うことが出来ないですが Container App では問題なく利用できます。気になったので中の人に確認を取りました。

適当に ASP.NET Core で gRPC サービスを作成して Container App にデプロイして、コンソールアプリケーションから利用できるか試しましたがすんなり動きました。

Container App の設定で Transport を Http2 に設定して試しましたが、デフォルトでは Auto なので実は変更しなくても問題なく通る疑惑もあります。

f:id:shiba-yan:20211103192300p:plain

若干はまった点としては ASP.NET Core で gRPC サービスと Dockerfile を作成すると、デフォルトで 80 番ポートが EXPOSE されていたので、Container App にデプロイした際に 80 番が優先して使われてしまい、gRPC が通らなくなっていました。

443 番だけ EXPOSE してデプロイしなおせば動くようになりました。エラーメッセージが Envoy のものだったので若干わかりにくかったです。

アプリケーションのデプロイ

既に Azure Portal には Continuous deployment の設定が用意されていますが、中身は App Service と同様に GitHub Actions の Workflow を自動的に作成する機能のようです。

Azure CLI を使うので Service Principal が必要なのはわかりますが、少し面倒ですね。

f:id:shiba-yan:20211104161536p:plain

Docker Image をビルドして、ACR にプッシュ出来れば問題ないので、Azure Pipelines を使った CI/CD も当然ながら問題ないです。現在は Azure CLI が使われていますが、将来的には Container App へのデプロイ用 Action や Task も用意されるでしょう。

価格について

課金体系は Azure Container Instances と Azure Functions の Consumption Plan を混ぜたようなものになっていて、正直なところ計算がとても面倒に感じました。GiB/sec はあまり好きではないです。

1 vCPU 当たりの金額を考えると、ACI の 1 vCPU と比べると 2.6 倍高いことになります。メモリは課金方法が違うように思うので比較は難しいですが、ACI よりも安くなることはありえないでしょう。機能が多いので価格が ACI よりも高くなるのは当然ですね。

アイドル時間は割引価格になるのはとても良いですね。App Service はアプリケーションがアイドルになっていても App Service Plan があれば通常課金されるので、真似してもらいたさがあります。

しかし常時コンテナーが起動しっぱなしで、アイドル時間がほぼ無い場合は割高になるはずなので、どれほどアイドル状態に落とせるかが重要になるはずです。ユースケースによっては App Service の Premium V2 よりも高くなることもあるでしょうし、ゲームのように常にリクエストが大量に発生するサービスでは、Dedicated なインスタンスの方が適しているので、将来的にはオプションで用意されるかもしれません。

リクエスト数課金は gRPC や WebSocket のようなコネクション張りっぱなしの場合にどうなるのか少し気になります。その場合のスケーリングも同様ですが、KEDA を調べればわかりそうです。

まとめ

App Service と同じチームによって開発された Container Apps は、Azure において Serverless なコンピューティングの重要な選択肢になることは間違いありません。以下に自分なりのまとめを雑に書きました。

  • イベント駆動アプリケーションを作りたい
    • Azure Functions
  • C# や Node.js で動く Web アプリケーションを作りたい
    • Web Apps
  • SPA / SSG を使った Web アプリケーションを作りたい
    • Static Web Apps
  • 利用したい言語が Azure Functions でサポートされていない
    • Container Apps
  • バックグラウンドで常時稼働するサービスを作りたい
    • Container Apps
  • 大規模に Microservices を採用したアプリケーションを作りたい
    • Container Apps
  • GPU インスタンスなど特殊なインスタンスが必要な場合
    • AKS

まだネットワーク周りの機能がサポートされていないので Container Apps が使える場面は少ないのですが、App Service のように機能が拡充されると AKS を使う必要がほぼ無いという状況になる気がします。

とはいえ、自分の中では Azure Functions と Web Apps が最初の選択肢になることは変わらないです。まずは Azure Functions / Web Apps で実現できるか検討し、その後に Container Apps を検討することになります。

*1:アイコンも App Service Environment 系と同じデザインになっている

*2:特に gRPC とか

*3:GPU インスタンスや特定の CPU、大量のメモリが必要なケースなど