インタビュー最近の Ignite イベントで、Microsoft は、ゼロへのスケールなどの機能を備えたコンテナーを展開するためのマネージド サービスである Azure Container Apps のプレビューを公開しました。
バックグラウンドでは Kubernetes を使用し、Dapr と KEDA を補完します。
Azureクラウドでは、完全なKubernetesデプロイメントを実現するAzure Kubernetes Service (AKS)、LinuxとWindowsの両方のコンテナーを実行できるAzure App Service、スタンドアロンで使用したり、サーバーを追加せずにAKSにバーストキャパシティを追加したりできるAzure Container Instanceなど、コンテナーを実行するための様々な方法が既に提供されています。Container Appsの新機能とは何でしょうか?
「Container Apps の主な目的は、基盤となる Kubernetes クラスターを理解、プロビジョニング、管理することなく、コンテナーが相互に検出、通信し、Kubernetes が提供できるアーキテクチャのメリットを享受できるマイクロサービス ソリューションをチームが構築できるように支援することです」と、Microsoft の Azure Apps 製品担当ディレクターの Jeff Hollan 氏は語ります。
「すべてのマイクロサービスがAPIやHTTPエンドポイントを持っているわけではありません」と彼は言います。「多くの場合、マイクロサービスはイベントストリーム、キュー、またはメッセージバスを使用して、プロセス間の連携や耐久性の向上を図っています。」
イベントストリームプロセッサであるKafkaは一般的なパターンだと彼は言います。「コンテナをいくつかデプロイすると、Kafkaトピックをリッスンしている状態になります。Kafkaトピックが空であればコンテナをゼロまでスケールダウンし、1万件のKafkaイベントが発生した場合はコンテナを迅速にスケールアウトします。」
コンテナアプリはKubernetes上で動作しますが、ユーザーからは見えません。「Kubernetesコマンドラインツールのkubectlを使ってクラスターを操作することはできません。Kubernetes上に構築されたAPIと管理機能を使用します。Kubernetesの多くの機能も活用していますが、コンテナアプリ向けに最適化しています」とホラン氏は述べています。
Containers Apps サービスは、Microsoft が支援する 2 つのオープンソース プロジェクトを活用しています。KEDA (Kubernetes Event-driven Autoscaling) はスケーリング機能に役割を果たし、Dapr (Distributed Application Runtime) は追加の API を提供します。Dapr は、コンテナ化されたアプリケーションと並行して「サイドカー」として動作し、状態ストア、イベントバインディング、パブリッシュ/サブスクライブなどのサービスを提供します。
「Daprは現在、インキュベーションプロジェクトとしてCNCFへの寄贈に向けた投票段階にあります」とホラン氏は語る。「Daprはマイクロサービス構築のためのベストプラクティスを数多く提供しています。コンテナアプリであれば、Daprを有効にすると自動的にDaprサイドカーが接続されます。DaprはmTLS、耐障害性リトライ、そして数々の追加テレメトリ機能も搭載する予定です」と彼は語る。
コンテナアプリがゼロまでスケールダウンした場合、新しいリクエストが到着して再起動するまでのレイテンシはどれくらいになるでしょうか?「コード開始時には膨大な変数があります」とホラン氏は言います。「イメージはキャッシュされているか?イメージのサイズはどれくらいか?これはチームが許容範囲として考慮する必要がある点です。ミリ秒単位のレスポンスを求めるのであれば問題ありません。『絶対にゼロまでスケールダウンしない』と言えば大丈夫です。」
この制限は、アイドル状態のインスタンスに対する特別価格設定によって緩和されます。現在、Container Apps はプレビュー段階であり、カナダ、中央ヨーロッパ、北ヨーロッパの各リージョンでのみご利用いただけます。使用量は vCPU、メモリ使用量、リクエスト数ごとに課金され、アイドル状態のインスタンスでは vCPU 料金が 87.5% 削減されます。
無料利用枠では、50時間のvCPU、1GBのメモリ100時間、月間200万リクエストがご利用いただけます。現在の価格設定では、2つのvCPUと2GBのメモリを搭載したインスタンスの場合、月額約51ポンドに加え、100万リクエストあたり0.292ポンドの追加料金がかかります。
コンテナアプリには、コンテナを仮想ネットワークにグループ化する環境があります。
Container Apps は、Azure Container Instances とは異なります。Azure Container Instances では、「コンテナー間の通信は管理されず、自動スケールの概念もありません」と Hollan 氏は言います。
同氏によると、この新しいサービスは、App Service とは大きく異なっており、「Web サイトと Web API をホストするために特別に構築されたサービスであり、すべてが相互に通信するためのマイクロサービス環境という概念はありません。」
コンテナアプリにおいて、「環境」とは、コンテナのグループを囲む分離境界を提供する特定の機能です。各環境は同じ仮想ネットワーク内にあります。
コンテナアプリのもう一つの概念は「リビジョン」です。コンテナアプリが更新されるたびにリビジョンが作成されます。ユースケースの一つとして、管理者がコンテナ化されたアプリケーションの特定のバージョンにトラフィックを誘導できるようにすることが挙げられます。例えば、A/Bテストでトラフィックのごく一部を新しいバージョンに誘導してパフォーマンスを評価するといったケースです。「非アクティブなリビジョンは、コンテナアプリの特定の状態のスナップショットとして保存されます」とドキュメントには説明されています。「非アクティブなリビジョンには料金はかかりません。削除されるまで最大100個のリビジョンが保存されます。」
Windows コンテナを実行しますか? 「プレビューでは、Linux ベースのコンテナのみをサポートします」と Hollan 氏は語ります。
一般公開の日付はまだ不明だが、ホラン氏は、Ignite で公開された現在のパブリック プレビューの「数か月後」になると述べた。
私たちが見てきた限りでは、Container App Serviceの目的は、Kubernetes API自体を煩わすことなく、クラウドネイティブアプリケーションを実現するのに十分なKubernetesを提供することです。これは、GoogleのCloud RunやAWS Fargateといったサービスと競合します。その成功は、開発者がDaprをどれだけうまく受け入れるかにかかっており、無料利用枠とスケール・トゥ・ゼロ機能は実験を促進するでしょう。®