Microsoftは年次開催のBuildカンファレンスで、"Azure application services on Kubernetes"を発表した。以前InfoQのニュースでも取り上げたもので、Azure Arcを使用している。
同社でAzure Application Platformを担当するプロダクトマネージメントディレクタのJeff Hollan氏に、今回の発表の詳細について聞いた。
氏は、Kubernetes上でのAzureアプリケーション運用の背景にある思想や詳細な技術情報、マルチクラウドにおけるAzure Arcの必要性などについて話してくれた。
InfoQ: Azure application servicesをKubernetesに移行した、最も大きな理由について教えてください。既存のKubernetesクラスタを使ってAzure application servicesをデプロイすることは可能なのでしょうか、あるいは、AzureポータルやCLIを使って新たに作成する必要があるのですか？
Hollan: Azureは、Webアプリから関数、API、ワークフローに至るまで、最も包括的なアプリケーションプラットフォームを提供しています。開発者たちは、自身のミッションクリティカルなワークロードを運用する上で、これら目的別エクスペリエンスの価値を高く評価してくれています — たったひとつのCLIコマンドで、コードをクラウドにアップロードして実行できる場合も少なくありません。これらのエクスペリエンスは、Azure内では非常に好まれていますが、他で運用する場合には別の選択肢を探さなくてはなりません。オンプレミスや他のクラウドでの運用が必要なシナリオでは、もっと低いレベルの抽象化、Kubernetesのようなものにドロップダウンする必要があるのです。Kubernetesはパワフルで革新的ではありますが、開発者のワークフロー用に最適化されていないため、この面での支援を望む声が多くのユーザから寄せられていました。
そこで私たちは、開発者がその環境に関わらず、同じツールとサービス抽象化を使用できるような、Azure application servicesの機能を構築したのです。可能な限りフレキシブルにすることにも留意しました。Azure Application Servicesは、既存か新規かに関わらず、任意のKubernetesクラスタ上にインストールすることができます。その上で、当社が10年近い歳月をかけて改善したツールとエクスペリエンスを使うことによって、リッチなWebアプリケーションも、サーバレス関数も、APIも、そしてワークフローも、公開できるようになるのです。
InfoQ: Azure Arcの役割は何でしょう？それぞれのコンポーネントの実装/技術的詳細と、それらがどのように組み合わされているのか、もう少し詳しく説明して頂けますか？
Hollan: Azure Arcを使うことで、使い慣れたツールやサービスを使用することや、アプリケーションを複数のクラスタに一貫性を持ってデプロイすること、環境全体のセキュリティとガバナンスを自動化することが可能になります。さらに、柔軟性を提供し、高速なデプロイを実現し、ひとつの画面でアプリとデータ資産の全体を管理できるようにします。
Azure Arc対応サービスを使うことで、オンプレミスでも、エッジ上でも、さらにはAWSやGCPなど他社クラウド上でも、アプリケーションサービス、データサービス、MLサービスといった、現在使用しているAzureサービスを利用できるようになります。Azure PostgresやAzure SQLのようなArc対応のデータサービスと組み合わせれば、業界最高レベルのフルマネージドクラウドサービスを使って、任意の場所で運用することができるのです。重要なのは、デプロイの方法を変える必要がないことです。既存のツールやプラクティスをそのまま使って、シームレスで一貫性のあるエクスペリエンスのメリットを享受できます。実装の技術面では、Azure Arcは、サービスAPIとインストール先のKubernetesクラスタの間でブリッジとして機能します。ですから開発者は、通常のCLIを使用して関数をデプロイすればよいのです。宛先が自分のクラスタであれば、Azure Arcがセキュアなリレーを通じて、その要求を自分のクラスタにリレーしてくれます。要求がクラスタに到達すれば、クラスタ上で動作しているAzure application servicesが、その要求に応じてアプリやコードの設定を開始します。
計算処理やトラフィックなどは、すべてユーザのクラスタ間で直接受け渡されます — Azure Arcは、Azureの管理するリソース間の管理と監視の橋渡しを行います。アプリケーションのデプロイと管理は、対象がAzureデータセンタであるかユーザ自身のクラスタであるかに関係なく、ひとつの画面で行うことができます。
InfoQ: Kubernetesはプラットフォーム非依存性を実現します。それを使用せず、クラウドネイティブアプリをKubernetes上で直接開発可能とするのであれば、Azure application serviceの付加層としてKubernetesが果たす役割は何なのでしょう？
Hollan: Kubernetesはプラットフォーム非依存性を提供する一方で、汎用的なコンテナオーケストレータでもあります。Kubernetesから、監視、認証、スケーリング、DevSecOpsを統合したアプリケーションに移行するためには、この汎用プラットフォーム上で統合、運用、構築を行う必要があります。AzureアプリケーションサービスやAzure Functionsといったプラットフォームサービスは、監視、認証、スケーリングなどをサービスの組み込み機能として持っていて、開発に必要なエネルギや労力を大幅に低減してくれています。ですから、Kubernetes上で直接開発する場合には、このような付加的な運用ないし設定上のオーバーヘッドに対処することが常に必要なのです。Azure application services on Kubernetesで私たちは、可能な限りの価値を提供したいと考えています。Azureをターゲットとしてワークロードを実行可能であれば、私たちのプラットフォームを直接ターゲットにすることができます。クラスタの管理や設定は必要ありません。より多くのフレキシビリティやコントロールを望むのであれば、Kubernetesをターゲットにすることも可能ですが、監視や認証、スケーリングなどのレイヤを積み重ねる、つまり、汎用クラスタを一端のアプリケーションプラットフォームに作り替える必要があるのです。
InfoQ: 開発や運用の観点から、Azureクラウド上のサービスをコンシュームせずに、Azure application servicesをオンプレミス(あるいは他のクラウド)で運用する場合、どのような問題があるのでしょう？ スケーリングや可観測性などは、どのように動作するのでしょうか？
Hollan: 最も考慮しなくてはならないのは、コードビルドやスケーリングといった機能を階層化しても、基盤となるクラスタのメンテナンスや運用は変わらず必要である、という点です。Kubernetesクラスタの運用状態を管理しなくてはなりませんし、システムの最新化や十分な容量の確保も必要になります。私たちは、フルマネージドなサービスと独自のKubernetesクラスタ上で動作する場合とのアプリケーション動作の一貫性確保に努めました。これにより、自動スケーリングやルーティングなどは同じように動作します。
InfoQ: そのようなデプロイメントを大規模に展開して管理する上で、GitOps(あるいは他の自動化手法)はどの程度考慮されているのでしょうか？
Hollan: これらのエクスペリエンスの構築では、git flowを念頭においていました。複数のクラスタを管理する場合、GitOpsを活用することで、Azure Arcを通じて一貫した設定を行うことができます。これはつまり、設定の変更を"信頼できる情報源(source of truth)"に対して行えば、予め定義されたポリシに従って、Azure Arcがその変更をすべてのクラスタに適用してくれる、ということです。
アプリケーション自体についても、継続的インテグレーションと継続的デプロイメントでGitを使うことを推奨しています。これにより、変更をgitフローを通じて検証、テスト、デプロイすることが可能になります。今回のapplication servicesのリリースと合わせて、2つのアプリテンプレートもリリースしました。これらは任意の場所で運用可能なアプリ開発の出発点になると同時に、強力なガバナンスおよびバージョン管理ストーリを備えています。
InfoQ: 最後になりますが、さらなるAzureサービスをKubernetes上のエッジに移行する計画やロードマップについて教えてください。
Hollan: Azure Arc上のapplication servicesに現在向けられている関心と、そこに参加するユーザには大きな期待を持っています。現時点における最大の目標は、プレビューを終了して一般公開(GA)に進むことです。そのためには、Kubernetes内で実行する場合のサポート機能を引き続き充実させること、ユーザフィードバックに基づいて現在のエクスペリエンスをイテレーションすること、などが必要です。可能な限り多くのチームの協力を得て、場所を選ばず動作する生産的エクスペリエンスを構築したいと思っています。質問やフィードバックを、どんどんお寄せください！
技術的な詳細については、 technical blogに記載がある。Buildでの講演記録には、技術的な詳細に関するウォークスルーとデモが含まれている。