Azure + Spring Boot = サーバレス - Julien Dubois氏とのQ&A

原文(投稿日：2020/09/16)へのリンク

Microsoftは、同社のJaクラウドとJavaエコシステムへの注目がニューノーマルであることを、繰り返し証明しているようです。Azure Functionsのサポート言語にはかなり前からJavaが加わっていますが、Julien Dubois氏はSpring BootをAzureで試して、この組み合わせがAzureのサーバレスコンピューティングに持つ意味について確認しました。InfoQは今回、Spring BootアプリケーションをAzure上で試験した経験について、氏に詳しく聞きました。

InfoQ: InfoQ読者のために、質問に回答する時間を割いて頂いてありがとうございます。まずは自己紹介と、Microsoftでの役割、日々の仕事について教えてください。

Julien Dubois: 私はJavaコミュニティに20年以上関わっています。コミュニティではおもに、JHipsterの作者、Java Championのひとりとして知られています。仕事の面では、MicrosoftでJava Cloud Developer Advocacyチームをまとめています。Developer Relations部門における私たちチームの役割は、Java開発者たちとのコンタクトを通じて、Azureを彼らにとって最高のプラットフォームにすることです。日々の仕事としては、Javaコミュニティやパートナとのさまざまな協力活動を通じてフィードバックを収集し、ドキュメントの改善や、エンジニアリングチームの協力の下でプロダクトやサービスのエンハンスを行っています。

InfiQ: MicrosoftはJava開発者のパワーハウスになったように思うのですが、それがMicrosoftにもたらしたものは何でしたか？

Jilien Dubois: Microsoftはこれまでに11人のJava Championを雇用しました。当社にはJavaに対する強力なサポート力とプランがあります。さらに、Azureだけではありません。LinkedInやMinecraftでも、たくさんのJava開発者が活動しているのです！

私がMicrosoftに来たのは、何よりも子供の頃に夢を見せてくれた企業だったからであり、米国企業にリモートで働くことが希望だったからです。会社の価値観や精神も好きですし、テクノロジに携わるひとりとして成長し、学ぶ上で最高の場所のひとつなのです。

InfoQ: Microsoftに来たことは、JHipsterにどのような意味があったのでしょう？何らかの形で影響はありましたか？

Julien Dubois: JHipsterの作者であることは、採用される上で間違いなく役に立ちました。そのおかげで、JHipsterというOSSでの生活とはまったく違う、Microsoftでのプロフェッショナルな生活を手に入れることができたのです。JHipsterに費やす時間は確実に少なくなりましたが、それはMicrosoftにおける役割のためだけではありません。今年4人目の子供が生まれたことや、あるいはCOVID-19も、自由な時間が少なくなった理由になっています。JHipsterにとって素晴らしいのは、これによってコミュニティの他の人たちが成長し、結果的にはおそらく、プロジェクトがより強力でより安定したものになったことです。

InfoQ: MicrosoftはJavaとクラウドエコシステムの一級市民(first citizen)になりつつあるように思えるのですが、そうなのでしょうか？

Julien Dubois: すでにそうなっていると思います。MicrosoftではAzureなど、多数のプロダクトでJavaを広範に使用していますから、一級市民であることは間違いありません。例えば、PaaSサービスのAzure App Serviceや、サーバレスサービスであるAzure FunctionsでもJavaをサポートしています。私はAzure Spring Cloudに深く関わってきました。これはVMwareのSpringチームとの協力の下で開発された、Springに特化したサービスです。ですから、そうですね、当社はJavaに深く関わっていますし、近い将来、それはさらに強いものになるでしょう。

InfoQ: サーバレスのムーブメントが勢いを増していますが、これについてはどう思われますか？実運用のレベルには、どの程度達しているのでしょうか？

Julien Dubois: Azure Functionsを実際に運用しているカスタマはたくさんいますし、Javaワークロードを実行しているクライアントも多数あります。この分野ではとてもエキサイティングなことが起きていますが、それでも、まだ始まりに過ぎないと思います。Javaはもともと、サーバレスにとって最適なものではありません。サーバレス関数のコストの低減、コールドスタート時間の短縮、監視機能やスケールアップ機能の向上など、将来的に実行可能な改善はまだたくさんあります。Azureのサーバレスの変更でエンジニアリングチームと協力できるのが、私の仕事の中で気に入っていることのひとつです。

InfoQ: この分野に参入する上で、Microsoftはどのようなツールを開発したのでしょうか？他のクラウドプロバイダのサービスの、どのようなツールが必要でしたか？それは他のプロバイダとも統合が可能なものなのでしょうか？

Julien Dubois: ランタイムや言語特有のワーカ(Javaワーカなど)、CLI、IDEプラグインなどを用意しました。すべてオープンソースです。当社のPaaSサービスであるAzure App Serviceと同じ基盤上に構築されていて、運用環境で実証済の機能を、極めて少ない制限で提供します。この方法によって、非常に短期間でこの分野に参入し、極めて完成度の高いサービスを提供することができました。他のクラウドプロバイダを経験した方々には驚くべきことかも知れません。大きな違いは、関数を異なるクライアントから同時に呼び出すことができる点です。実際に、従来のアプリケーションと同じように、複数のスレッドを使うことが可能なのです。これによってパフォーマンスとコストが大きく改善されるだけでなく、Javaの利用者にとっては、コールドスタートアップ時間の面でもメリットがあります。

他のクラウドプロバイダとの相互運用性に関する懸念に対しては、古くからのSpringユーザとして話したいと思います。私たちはSpringチームと密接に関わりながら開発を進めているので、Spring Cloud Functionを使ったワークロードのデプロイが可能になっています。プロバイダ間での小さな違いはありますし、実際に私も現在、そのひとつの修正を行っているところなのですが、基本的には同じSpring Bootコードを、抽象化を使って任意のクラウドプロバイダ上で動作させることは可能なはずです。J2EEの時代から常に行われていたことを、Springも行っているのです。すなわち、抽象化によって、コードを変更しなくてもプロバイダを変更することが可能なのです。

InfoQ: Azure以外のプロバイダを使ったことはありますか？Azureと比較して、どう思いますか？

Julien Dubois: コンサルタントをしていた頃に、たくさん使いました。AWS、GCP、Herokuなどは当然ですが、もっと小規模な、単純なVMやネットワークソリューションを提供するものも長く使っていました。

まず何よりも、私はPaaSユーザです — VMやKubernetes、SQLデータベースを管理したくはありません。今日では素晴らしいPaaSソリューションがあって、安価に使用できるのですから、自分で何かをしようというのは時間の無駄ですし、運用上の選択としても適切ではありません。大手クラウドプロバイダが提案できるものと競合するのは不可能です。現在、大手クラウドプロバイダにはそれぞれのアドバンテージがありますし、私もAzureの競合サービスで素晴らしいエクスペリエンスを経験しています。例えばJHipster Onlineは、当初から私たちを支援してくれたGCP上で運用されています。JHipsterユーザの大半は、最初はHerokuを使います。HerokuチームがJHipsterに合うように素晴らしい仕事をしてくれたおかげで、無償ティアでも十分に使用できるからです。どれも選択肢としては十分ですし、幸運なことにJavaは、どのプラットフォームでも快適に動作します。

InfoQ: Azure Functionの資料には、HTTPネイティブなプログラミング言語であればAzure Functionsの開発が可能だとありますが、実際のところJavaはどうなのでしょうか？Java Azure Functionを記述する上で、何か必要なものはありますか？

Julien Dubois: Azure上でJava関数を実行するのには、実際には2つの方法があります。クラシックな方法としては、公式なJavaワーカがあります。ドキュメントやAPIも充実しています。多くの人がこの方法を使用していますし、JDKのサポートや監視機能が充実している点でも推奨できる方法です。マシンの事前ウォームアップなど、さまざまなトリックを駆使して改善しているので、コールドスタートのパフォーマンスもかなりよいはずです。

次に、非公式な方法として、HTTPに関してあなたが今話したような、"Azure Functionsカスタムハンドラ"という新機能があります。この方法では、当社のHTTPブローカが知っているのは相手がHTTPサーバであるということだけす。アプリケーションに関しては何も感知していません。このため、こちら側での監視やチューニングは不可能になりますが、アプリケーションを自由な方法で開発することが可能になります。私を含むすべての人たちが今試しているのが、GaalVMのネイティブイメージを使用したJava関数の構築です。Spring Cloud Functionsを使用した場合など、いくつかのケースではすでに実現しています。実運用で安全に使用できるまでにはまだ長い道程がありますが、最新の優れたテクノロジを使いたいのであれば、間違いなく面白いものです。

InfoQ: Java8はAzure Functionsのサポート対象プログラミング言語のひとつですが、エクスペリエンスとしてはどうでしたか？

Julien Dubios: 実は、私たちはすでに、最新のLTSバージョンであるJava 11を使っているのです。私自身としてはJava 14もサポートする予定ですが、現在はまだ大部分のカスタマがJava 8を使っている状況ですので、急ぐつもりはありません。この面での最大の改善は、Linuxをサポートしたことです。意外に思われるかも知れませんが、当社にはLinux上のJavaを必要とする特別なチューニングを行っているカスタマもいるのです。ですが、その成り立ちから、これまではWindows上のJavaしか提供していませんでした。

もうひとつ注目して頂きたいのは、サポートとパッチを適用したJDKを提供するためにAzul Systemsと提携していることです。セキュリティを重視する当社としては、これはカスタマと当社自身にとって非常に重要な部分です。

InfoQ: サーバレスのSpring BootアプリケーションのAzureへのデプロイに成功したということですが、その時の経験について、詳しく教えて頂けますか？

Julien Dubois: 実際には２つの方法を行いました。まず、Spring Cloud Functionを使うオフィシャルな方法を使って、Spring BootアプリケーションをAzure Functinsにデプロイしました。このコードは、Azureの公式なサンプルアプリケーションになっています。この結果は良好でしたが、特別なコンフィギュレーションクラスが必要だという点で、このソリューションには改良の余地があります。そこで現在は、AuzreエンジニアリングチームやSpring Bootチームと共同で、この点の改善に取り組んでいます。

次に、新しい"Azure Functionsカスタムハンドラ"を試して、同じ関数をGraalVMで開発してみました。これにはSpringチームとGraalVMチームの友人たちの手助けを受けましたが、結果は良好です。ただし、実運用環境では十分に使用されていないので、重要なワークロードへの採用はお勧めできません。この作業の過程で、Azure Functionsの不可解な動作をいくつか見つけました。これについては社内で報告し、現在は鋭意修正中です。

InfoQ: 最初から動作したのでしょうか、あるいは、何らかの作業が必要でしたか？

Julien Dubois: 公式にサポートされる方法では、Spring Cloud Functionを使用するAzue特有のコンフィギュレーションファイルはありますが、全体として特別な作業の必要はありません。

ただし、GraalVMを使用する場合は別の話で、それまで誰も試したことがありませんでした。難しい作業の大部分はSpringチームとGraalVMチームが事前に行ってくれましたが、全体をスムーズに動作させるのに2日位かかったのではないかと思います。もちろん、現在は私のGitHubリポジトリを使えますし、資料も整っているので、もっと早く同じ結果を得られるはずです。

InfoQ: Microsoftはこれで、継続的デプロイメント全体のフローで必要なものをすべて揃えたように思われますが、そう考えてよいでしょうか？

Julien Dubois: 事実として、Microsoftがは2つの選択肢を提供しています。現在主流となっているのは、Azure DevOpsと呼ばれるサービスです。極めて完全でパワフルなので、すべての人に推奨できるもののひとつです。JHipsterでも数ヶ月間使用しています。OSSプロジェクト用に寛大な無償ティアが用意されているので、大きな成果を得ることができました。AzureやMicrosoftスタック全体に、完全に統合されているのはもちろんですが、

GitHubでもこの新サービスをGitHub Actionという名称で提供していて、GitHubを使うすべての人が使っているため、驚異的な伸びを見せています。現時点ではまだAzure DevOpsほどパワフルではありませんが、急速に成長していますし、GitHubに統合されているという大きなメリットがあります。これはまた、JHipsterのCI/CDパイプラインをGitHub Actionに移行した最大の理由でもあります。このプロジェクトには大勢のコントリビュータがいて、セットアップの必要なパーミッションも多数あるのですが、組織のアドミニストレータとしての作業はとても簡単なものになりました。私たちのユースケースとしては十分なものなので、このソリューションには非常に満足しています。

InfoQ: QuarkusとAmazon Lambdaにかなり近いように思うのですが、この２つについて試す機会はありましたか？Spring BootとAzureと比べてどうですか？

Julien Dubois: LambdaでQuarkusを試したことはありませんが、Azureでならあります！実際に当社では、Spring、Quarkus、Micronautのチームと同じような共同作業をしています。ですから、主流のJavaフレームワーク3つが同じように、当社のサービス上でサポートされていることになります。現在はすべてのフレームワークがJVM上でほぼ同じように動作しているので、エクスペリエンスも極めて近いものになっています。現在の試験領域として大きな可能性を持っているのは、これらのフレームワークをAzure Functions上で、GraalVMを使って動作させることです。これがゲームチェンジャーになることは間違いありませんが、JVMと同じレベルのサポートを提供するのが非常に難しいのです。つまり、少なくとも短期的には、開発者側により大きな責任を負ってもらうことになります。例を挙げてみましょう — 当社はJVMユーザに対して、マネージドOSとJVMを提供しています。ですから、JVMにセキュリティ上の問題があれば、当社がパッチを実施することになります。ユーザであるあなたは何も気にする必要はありません。さらに、当社はAzul SystemsのJVMバージョンをサポート付きで使用しているので、セキュリティ上の問題が公開される前にパッチを適用することも可能です。対照的に、同じことをGraalVMで行おうとすれば、当面はユーザ自身で行うことになります。Azure側では単なるバイナリとしか見えないので、バイナリをアップグレードしたり、パッチを当てたりするのはユーザであるあなたの責任になるのです。

InfoQ: Azureを使用したサーバレスアプリに最も適したシナリオは何だと思われますか？今からスクラッチで開発する必要が生じたならば、それを使用しますか？それはなぜですか？

Julien Dubois: 当社では、数多くのさまざまなクライアントが、まったく違うシナリオで成功を収めています。ですから"最適"なシナリオを一概に言うのは難しいのですが、少なくとも最も大きく、興味深いユースケースについて話すことはできます。それは、ある非常に有名なフランス企業で、その提供するサービスを数千万という多くの人たちが使っているのですが、時間や日によってその使い方がさまざまなのです。このサービスは一般的には夜に多く使われていて、その利用数は公的なイベントや発表によって非常に多くなる場合があります。同社のオフィスが近かったので、COVID-19以前に訪問する機会があったのですが、ピーク時間中の使用量は信じられないほとのものでした。これらの人々がAzure Functions上でJavaとSpringを実行するのですが、同社のインスタンスプールは使用量に応じて自動的に拡大および縮小するので、一切のメンテナンス作業が不要になっています。結果として、同社は自身のコードとビジネス機能に集中して、その他は何もしなくても負荷が処理されてうまく機能していますので、素晴らしいシナリオであることは間違いありません。これによって多くのトラブルが回避されていますし、費用面でも大きなメリットがあったと思います。

InfoQ: 運用中のアプリケーションをAzureのサーバレスモデルに移行する作業は、どの程度複雑なのでしょうか？

Julien Dubois: 私はJavaに関わっているので、ごく一般的なシナリオとして、Tomcat上で動作する古いSpring Bootアプリケーションについて説明したいと思います。これをサーバレスモデルに移行する方法は2つあります。いわゆる"リフト・アンド・シフト"によるものと、すべてを再構築(re-architect)する方法です。

"リフト・アンド・シフト"の場合に問題になるのは、すべてのSpring MVCコントローラをSpring Cloud Functionに移植しなければならないことでしょう。これを達成するためのさまざまな方法やトリックがあり、いくつかの制限もありますが、いずれにしてもそれほど費用をかけずに動作するようになるはずです。同時に、ビジネスコードにはそれほど手を入れる必要がないので、重要な機能を損なうこともないでしょう。

次に、Azure Functionsの動作方法は、古いSpring Bootアプリケーションとはまったく違います。Hibernate2次キャッシュやデータベース接続プールの有用性には変わりありませんが、持続時間が非常に短くなるため効果が低下することは容易に理解できるでしょう。分散キャッシュの使用が、ここでは大きな問題になります。また、関数は単一ノードのTomcatサーバよりもはるかにスケールアップ性能がよいので、そのような負荷に対処する設計のされていないデータベースが、それまでのようにうまく動作しない可能性もあります。その場合には、代わりにCosmosDBのようなデータベースを使うか、あるいはRedisなどのキャッシングソリューションを使う方法があります。いずれもAzureでは広く利用されているオプションです。これによって作業量は多くなりますが、サーバレスプラットフォームのメリットをフルに活用するには、これが唯一の方法なのです。これが"re-architecting"と私たちが呼んでいるもので、クラウドプラットフォームのアドバンテージを余すところなく利用するためには、アプリケーション全体を転換する必要があるのです。

InfoQ: 他のクラウドプロバイダからの移行についてはどうでしょう？

Julien Dubois: ここではAmazon Lambdaを中心に話しますが、他の大多数のサーバレスプロバイダについても同じだと思います。Azure FunctionsとAmazon Lambdaには大きな違いがあります。Azureでは、アプリケーションの起動から実行までに数分を必要としますが、その間も複数のクライアントがアクセス可能ですし、バックグラウンドスレッドも通常通り動作します。Amazonでは、クライアント毎にひとつのインスタンスが起動されます。バックグラウンドスレッドは多分うまく動作しないでしょう。つまりAzureでは、振る舞いは"普通の"アプリケーションのようであって、違いは実行時間がそれほど長くないことなのです。これは大部分の既存アプリケーションが同じように動作するということです。アプリケーションは障害を処理するように設計されるべきですから、実行時間が(数日や数週ではなく)数分である事実は大きな問題ではないはずです。Azureでは"リフト・アンド・シフト"シナリオが適切に動作するのに対して、他のクラウドプロバイダではおそらくアプリケーションの再構築(re-architecture)が必要になるというのは、このような理由によるものです。ただしAzureであっても、サーバレスアプリケーションを最大限に活用する唯一の方法は再構築です。魔法のような解決策が存在する訳ではありません。

InfoQ: アプリケーションを他のプロバイダに移行するのは簡単なのでしょうか？Azure上でアプリを開発することが、ベンダロックになるのではないですか？

Julien Dubois: 使用するサービスやフレームワークによります！フレームワークに関しては、先程論じたように、Spring Cloud Function、Quarkus、Micronautといったソリューションが、クラウドプロバイダ上で抽象化を提供してくれます。Javaではおそらく、これらフレームワークのいずれかを使うことになると思いますが、それによってコードの大部分がすべてのプラットフォーム上で動作するようになるのです。次のサービスに関しては、CosmosDBを使用した場合には、優れたソリューションですがMicrosoft専用であるため、別のクラウドベンダへ移行する上で障害になるのは明らかです。JHipsterのデモを行った時には、この理由から、どのベンダでも同じように動作するMySQLなどのサービスを使用しました。CosmosDBを使用したい場合は、MongoDB API経由で使用するようにします。こうしておけば、MongoDBをサポートするクラウドプロバイダには簡単に移行できます。

次に、ベンダニュートラルにしようとすると、さまざまな部分で制限を受けることになります。選択したクラウドベンダの提供する、高度な機能の多くは使用できなくなるでしょう。標準SQLのみでデータベースを使おうとする場合と同じようなものです。結果として、割に合わない理由で多くを失うことになります — 移行コストはAPIが異なるだけではなく、すべてのデータを別のサービスに移動させるコストも含まれているからです。

InfoQ: あなたが関わっている2つのプロジェクトをクランチしてみましょう — 開発目的で、JHipsterとAzureを組み合わせることはできないのでしょうか？どのようなものになると思いますか？

Julien Dubois: JHipsterのAzureへのデプロイならば、すでにサポートしています！公式にはAzure Spring CloudとAzure App Serviceをサポートしています。この2つがJava開発者のおもな選択肢ですが、それ以外にも、JHipsterのKubernetesサポートがAzure Kubernetes Service上で動作します。特別な作業は必要ありません。これをもっと進めたいのはもちろんです。現在検討中のアイデアのひとつは、JHipsterのTerraformサポートを充実させることです。実現すれば、もっと複雑なインフラストラクチャをAzure上に生成できるようになります。

InfoQ: Azure Functionsをこれから使い始めようという人に、何かヒントはありますか？

Julien Dubois: Azure Static Web Appsでできるような、シンプルなサーバレスアプリケーションを開発してみることをお勧めします。現時点ではJavaScriptでなければ動作しませんが、無償で使い方もシンプルなので、最初のテストと学習には最適でしょう。Microsoft Lean Webサイトには優れたドキュメントも用意されています。

ここで最も難しいのはそのコンセプトです。それが分かれば、これを他の言語に適用するのは大した問題ではないはずです。

インタビュー回答者について

MicrosoftでJava開発アドボカシ(advocacy)チームのマネージャをめるJulien Dubois氏は、Spring BootとAzureを試験することで、この組み合わせがAzureのサーバレスコンピューティングに対して持つ意味を確認しようとしています。氏はJHipsterプロジェクトの作成者兼開発リーダであると同時に、Java Championでもあります。過去20年間、氏はアーキテクトおよびコンサルタントとして、あらゆる産業にわたるさまざまなカスタマとともに、JavaとSpringテクノロジに取り組んできました。氏の情熱を伝える活動としては、Spring Frameworkに関する著書、100以上の国際カンファレンスでの講演、いくつかのオープンソースプロジェクトの立ち上げ、などがあります。