Red Hatは先頃、GraalVMおよびOpenJDK HotSpot用に開発された、KubernetesネイティブなJavaフレームワークのQuarkusをリリースした。
コンテナ、Kubernetes、マイクロサービス、ファンクション・アズ・ア・サービス(Faas）、クラウドネイティブアプリケーションが、より高いレベルの生産性と効率性を提供するクラウド時代において、Quarkusは、極めて興味深い選択肢のひとつとして登場した。
Red Hatのシニアプリンシパル・プロダクトマネージャのJohn Clingan氏と、同社エンジニアリング担当バイスプレジデントのMark Little氏に話を聞いた。
InfoQ: Quarkusは、JavaをKubernetesおよびサーバレス環境におけるリーディングプラットフォームとすることを目標としていますが、このアイデアはどのように生まれたのでしょうか？開発には何年間、取り組んでいますか？
Red Hat: Red Hatは、コンテナ内でJVMを使用する場合に生じる制約に対して、早い段階で気付いた企業のひとつです。この制約を解決するために貢献してきましたし、現在も貢献しています。この件に関しては、先日のRed Hat Developerブログの記事でも論じています。現在では、JVM上のJavaアプリケーションはコンテナ内で正常に実行できます。当社のユーザも、この組み合わせを実働環境で運用しています。しかし、いくつかの制約はまだ残っています。その中には、JVMの改善では解決が難しいものもあるのです。
そのような制約のひとつが、JVM上でエンタープライズJavaアプリケーションを実行する場合の起動時間とメモリ消費量です。Red Hatでは、Java用のGnuコンパイラやAvianプロジェクトと同じようなソリューションを検討してきたのですが、Javaコミュニティの一部としてGraalVMが発表された時、このコミュニティと共同開発を行うことに多くの可能性を見出したのです。
InfoQ: Red HatがQuarkusを開発したきっかけは何でしたか？
Red Hat: GraalVMの機能を知った時、私たちは、そのメリットをすべて享受するために包括的なアプローチが必要であること、VMレベルだけではなく、フレームワークのレベルで問題を検討しなければならないこと、この２つに気付きました。GraalVM用にネイティブアプリケーションをJavaで開発する場合、GraalVMのメリットを享受する上で、いくつかの制約が存在します。それはおもに、リフレクションのような、よりダイナミックな機能に関わるものです。依存関係の少ないアプリケーションでこの課題を解決することは、さほど難しくはありませんが、エンタープライズJavaアプリケーションを開発する場合には、すぐに大変なことになります。
開発者が使用するフレームワークはさまざまですが、人気のあるフレームワークのひとつにHibernateがあります。データベースコンテンツに簡単にアクセス可能なことから、最も多く利用されている、オブジェクトーリレーショナルマッピングフレームワークです。HibernateをGraalVM上で最適に運用するためには、Hibernate内部に関する極めて深い知識が必要です。それを効果的に実施するには、JVMとGraalVMの両方の動作について詳しく知っていなければなりません。試験作業を行う中で、私たちは、GraalVMの特異性を他のフレームワークが容易に取り入れられるような、共通アーキテクチャを構築するチャンスを見つけたのです。
Eclipse MicroProfile実装プロジェクト(SmallRye)やRESTEasyなど、さらに多くのプロジェクトを移植するために、Quarkusの拡張システムを使用しました。プロジェクトのリストは現在およそ40に達して、さらに拡張を続けています。Quarkus自体にも、swagger-uiに最初のコミュニティ拡張が行われました。その結果、エンタープライズJava開発者がJava EE、MicroProfile、あるいはSpringのいずれを使っているかに関わらず、使いやすく、馴染みやすいJavaスタックが完成したのです。
InfoQ: Quarkusがリリースされて間もなく、Thorntail 4.xの開発終了と、Thorntail 2.xが2020年11月までサポートされることが発表されました。Quarkusは、PayaraやTomitribeといった他のJavaミドルウェアベンダに、どのような影響を与えるでしょうか？
Red Hat ：Quarkusは、拡張APIや拡張エコシステム、インペラティブとリアクティブとの統合プログラミングモデルなど、非常に革新的な機能をいくつも実現しています。他のベンダに最も大きく影響するのは、Eclipse MicroProfileに関する部分でしょう。その分野では、次世代のエンタープライズJava仕様に協力します。MicroProfileが狙っているのは、クラウドネイティブなJavaです。インペラティブとリアクティブのと統合プログラミングモデルを採用したQuarkusは、よりモダンなクラウドネイティブデプロイメントシナリオを目指す方法のひとつの例なのです。
Quarkusで学んだこれらのアイデアと、その他の実装(PayaraやTomitribe)がMicroProfileやJakarta EEを通じて業界を進めてきた中で学んだことは、ひとつに組み合わせることが可能です。仕様作成に着手する前に、まず最初に革新が必要であることを忘れてはなりません。アイデアが仕様に取り入れられるには、数年とは言わなくても、数ヶ月を要する場合があります。時間が必要なのです。
InfoQ: 開発者はQuarkusに何を期待できるのでしょうか？
- Kubernetesにおける理想的なコンテナファースト・エクスペリエンス
- サーバレスJavaのコールドスタートを可能にする、ミリ秒単位の起動時間の実現と、より応答性とスケール性の高い環境のサポート
- 標準的なJavaプロセスの10分の1という最小フットプリントによる、従来よりもはるかに高い密度の実現と、システム全体の弾力性(elasticity)の向上。
- 12 Factor Appを採用したアーキテクチャによって可能になる、より堅牢で信頼性の高いアプリケーション開発。
- 開発者の本当の喜び
- インペラティブとリアクティブという２つのスタイルのサポートが、適切に統合されたプラットフォーム
- 最高レベルの標準とOSSに基づくこと
InfoQ: ScalaやPythonのように、GraalVMでセキュリティをサポートする言語は、Quarkusで使用できるのでしょうか？もしそうなら、いくつか例を挙げていただけますか？そうでなければ、将来的にはサポートされるのでしょうか？
Red Hat: Javaは現在もなお、エンタープライズユーザやRed Hatユーザにとって主要な言語ですから、私たちが最も注目していることに変わりはありません。Kotlinを含めたJava以外の言語についても実験を行なって、コミュニティの考え方を確認しています。
InfoQ: Quarkus Metricsについて、詳しく教えて頂けますか？
Red Hat: Quarkusでは、Eclipse MicroProfile Metrics仕様を実装したSmallRye Metricsを通じて、アプリケーションをモニタすることができます。アプリケーションの基本的なメトリクスを公開すると同時に、開発者が独自のアプリケーションメトリクスを追加することも可能です。すべてのメトリクスは、アプリケーションの/metricsエンドポイントから参照可能で、Prometheusやその他の監視システムで記録することができます。Quarkusには、ヘルスチェックサポートや分散トレース機能も用意されていて、アプリケーションをOPSフレンドリにしてくれます。
InfoQ: Quarkusのリリースサイクルについては、どのような計画がありますか？
Red Hat: Quarkusは非常に大きな注目を集めているので、できる限り反応をよくしたいと思っています。機能やバグフィックスは数週間単位で提供していますので、十分なフィードバックと開発者への普及が得られたと思うまで、これを継続したいと考えています。
大きな目標のひとつは、コミュニティによる拡張機能開発を支援することです。Quarkusは私たちのエコシステムなのです。
InfoQ: 初期バージョンとの下位互換性を維持する計画はありますか？
Red Hat: 私たちRed Hatとコミュニティにとって、下位互換性は非常に重要なものですが、何分にも若いプロジェクトですので、イノベーションのペースを止めるのは時期尚早です。いつ、どのような理由で、どのようにするかは、コミュニティと協力して決定するつもりです。
しかしQuarkusには、Hibernate, Vert.x, Camel, Netty, RESTEasyといった巨人の肩に乗っている、という利点があります。これらはいずれも成熟したフレームワークで、後方互換性を長く維持しています。Quarkusとしては、これらフレームワークのAPIを単に公開すればよいのです。かなりの数のコミュニティメンバが、Java EEアプリケーションからQuarkusへの移植を、記録的な速さで実施しています。これこそが、成熟したフレームワークと標準を採用したことによる、最大のメリットなのです。
InfoQ: Quarkusのロードマップはどのようになっていますか？
Red Hat: 何しろコミュニティが非常に若いので、まずは人々がQuarkusを何に使っているのか、何を必要としているのかを聞きたいですね。
さらに私たちは、エコシステムを非常に重要視しています。Javaエコシステムが将来的に、この新たなパラダイムシフトを受け入れてくれることを望んでいます。そのため、開発者が愛用してくれるようなフレームワーク用のエクステンションを、可能な限り簡単に開発できるようにするために、多くの努力を払っているのです。
問題なのは、それが難しい場合です。私たちはビジョンを持ってQuarkusをローンチしました。そこに到達するには、やるべきことがたくさんあります。主なテーマをあげてみますが、忘れてはならないのは、コミュニティとそのニーズがロードマップでは何よりも重要である、ということです。
- サーバレス: Quarkusのメモリ使用量の少なさと極限的に高速な起動時間は、FaaS関数のフレームワーク候補として最適です。
- インペラティブとリアクティブ: クラウドネイティブでレジリエントなアプリケーションでは、リアクティブであることが不可欠です。プログラムモデルを統一することで、私たちは、私たちがどこへ行きたいのかを示しました。次は領域を広げる時です。例えば、永続化を実現するための、リアクティブで非ブロックな方法を模索しています。
- セキュリティ: 業界が慣れなければならないCVEの洪水に、どう対処すればよいのか？私たちは、Wildflyの経験から多くを学びました。近い将来には、Quarkusからもよいものを得られると期待しています。
- コンテナとKubernetes: アプリケーションは、デプロイされなければ役に立ちません。コンテナプラットフォーム、特にKubernetes上に、Quarkusアプリケーションが円滑にデプロイできることで、新たに得られる価値はたくさんあります。
InfoQ: 起動時間を短縮するために、どのようなコンパイル時のテクニックを使用しているのでしょうか？
Red Hat: いくつかトリックがありますが、最も興味深いと思われるものについて説明しましょう。Quarkusでの重要なポイントのひとつは、クラスパス検索、リフレクション、コンフィギュレーション解析、メタデータ収集、ランタイムモデル構築といった、フレームワークがこれまで起動時に行ってきたことの多くを、ビルド時に行うようにしたことです。これにはいくつかのメリットがあります。
- アプリケーション起動毎ではなく、ビルド時に1回のみ実施される
- 通常であればJVMのメモリを(クラスメタデータなどで)消費するような、フレームワークのブートストラップに必要なコードがすべて、実行時には存在しない
これによって、Quarkusアプリケーションの起動とリクエスト受信を速くするとともに、メモリオーバヘッドを可能な限り削減することが可能になっています。
Quarkusの拡張でもうひとつ注目すべき点は、GraalVMのデッドコード除去アルゴリズムを、可能な限り支援するように設計されていることです。GraalVMは不要なコールパス検出に関して、極めて優れた処理をしていますが、オプションの依存関係がそのアプリケーションにとって本当にオプションかどうかを知るためには、フレームワークの支援が必要なのです。やや面倒ではありますが、その価値はあります。
InfoQ: このテクノロジを入手するための、最もよい方法は何でしょうか？開発者がコミュニティに参加して質問する上で、望ましい方法はありますか？
Quarkusの入手: Getting Started Guideを参照してください。
Twitter: @QuarkusIO
チャット: Zulip Chat Room
質問: StackOverflow