APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

トップ > Azure > 3つの特徴で理解するAzure Container Appsの概要

3つの特徴で理解するAzure Container Appsの概要

Azure Azure Container Apps Dapr
＜ techblogAPCについて（はじめにお読み下さい） ＞

こんにちは、コンテナソリューション事業部の松崎です。

本記事では、サーバレス型のコンテナ基盤 Azure Container Apps (ACA) の概要を解説します。

ACAの特徴

ACAの特性は大きく3つに分類できます。

ACAの3つの特徴

  • (1) AKS Cluster と Kubernetes リソースの抽象化
  • (2) KEDAのマネージドサービス化 + 柔軟なスケーリング設定
  • (3) Dapr Control Planeのマネージドサービス化

1. AKS Cluster と Kubernetes リソースの抽象化

ACAはインフラ (Kubernetes) の詳細を隠ぺいし、開発者の関心から分離するコンセプトで作られています。（図１）

図1 : ACAとAKSの管理スコープの違い

ACAにおいてKubernetes クラスターは Container Apps Environment という仮想的なエンティティに抽象化されています。そのため、ユーザーからはKubernetes内部の詳細を意識する事なくコンテナをデプロイすることができます。（図２）

図2 : ACAのリソース構造

同様にKubernetes ManifestについてもACAでは不可視なリソースという扱いになっており、その詳細は隠ぺいされています。AKSではアプリケーションのデプロイに際し、ユーザーがManifestファイルを作成する必要がありますが、ACAではDockerイメージと幾つかのACA専用の設定項目を選ぶだけでアプリケーションのデプロイが可能です。

デプロイ後のリソースのCRUD操作についても、ACAではKubernetes APIではなくACAの専用APIを経由して操作をします。そのため、ユーザーは kubectl(1) の操作方法やKubernetes Manifestなどについての知識がなくてもコンテナを操作できます。

このような特性には、利点と欠点があります。

利点

  • ACAを活用することで、インフラの詳細を知らなくてもアプリケーションをデプロイ・管理することができます。 これによりアプリケーション開発時の学習コストと認知負荷(cognitive load)が大幅に軽減され、開発効率・ベロシティの向上が期待できます。
  • ACAを導入すると、Kubernetesクラスタ と Kubernetes リソースの管理の運用負荷が大幅に削減されます。これによりインフラTotal Cost of Owenership(TCO)が低減され、より少ない要員／人件費でシステムを営むことが可能になります。

欠点

  • 要件に応じて柔軟にKubernetesクラスタやKubernetesリソースの構成をカスタマイズする自由度はAKSに比べると乏しいです。また、Platform as a Productの観点でプラットフォームチームが継続的にインフラの機能追加を続け、ユーザー(開発者)の利用価値を向上させたいと考える際は、機能の拡張性が高いAKSの方が適している可能性があります。

2. KEDAのマネージドサービス化 + 柔軟なスケーリング設定

ACAではオプション機能として、Kubernetes Event-Driven Autoscaling (KEDA) を使ったスケーリング機能が用意されています。KEDAはKubernetesのスケーリング能力を拡張するプロジェクトで、Event Driven ArchitectureにおいてMessaging BrokerをScalingさせることを主要課題に設定しています。KEDAを使うことで、Horizontal Pod Autoscaler (HPA) では難しかったより柔軟な条件でのスケーリングが実現できます。

また、スケール時のレプリカ数の最小値を 0 にすることで、リクエストが発生の場合のみオンデマンドでコンテナをプロビジョニングする構成も可能です。この特性を前述の柔軟なスケールトリガと組み合わせることで、アプリケーションの伸縮自在性の確保と課金効率の高いリソース利用が期待できます。

2022年3月現在、ACAでは以下の4種のスケールトリガが用意されています。

AKSとACAの機能を比較する際の注意点：

実はKEDAはAKSでも利用できます。 *1

では、AKSとACAではKEDAについて機能差分はないの？という話になりますが、共同責任モデル(Shared responsibility model)の考え方が異なります。

AKSではKEDA Control Plane(Operator/Controller)をユーザーにて管理する必要があります。具体的にはユーザーの責務において、故障時の復旧処置やセキュリティ脆弱性への対処が必要です。

対してACAではKEDA Control Plane(Operator/Controller)はアドオン化されておりMicrosoftにより管理されます。そのため構築・運用コストが大幅に削減されています。つまり、ACAではKEDAがマネージドサービスとして提供されているということです。

3. Dapr Control Planeのマネージドサービス化

ACAではオプション機能として、Distributed Application Runtime (Dapr) の利用が可能です。Daprは「分散システム(Microservices)を作るための便利なコンポーネント集」であり、「Microserviceのプロトタイプを短期間で高速に開発したい」などのユースケースと親和性が高いです。「便利なコンポーネント」の具体例としては以下のような機能群が提供されます。

  • サービスディスカバリ
  • Pub-Sub
  • データベース/永続化ストア( State Management )
  • 可観察性
  • アクター

Daprはまたサイドカーパターンを採用しており、これによりプログラムコード上でインフラストラクチャの詳細を隠ぺいする事に成功しています。Daprを使うことでアプリケーションのコードにインフラについての詳細な知識を記述することなく、ミドルウェアとの通信や他のDaprサービスのサービスディスカバリなどを行うことができます。

DaprもKEDA同様にAKSにインストール可能ですが、共同責任モデルの考え方が異なります。この点は、KEDAと同様です。

おわりに

以上、足早にAzure Container Appsの概要を概観してみました。今だPreviewのサービスではありますが、とても利便性の高いサービスなのでGAが待ち遠しいですね！

*1:Microsoft LearnでAKS上でKEDAを動かすためのコースが用意されているので、詳細はこちらをご覧ください。 https://docs.microsoft.com/ja-jp/learn/modules/aks-app-scale-keda/