Project Leyden を Quarkus に統合した方法

Java の世界では、Java アプリケーションをネイティブ実行可能ファイルにコンパイルする GraalVM ネイティブイメージの登場により、Ahead-of-Time (AOT) コンパイルが注目を集めるようになりました。

これは Java エコシステムに大きな影響を与え、Java アプリケーションの起動パフォーマンスにとって画期的なものでした。

しかし、これにはいくつかの欠点があります。

全体として、ネイティブイメージは起動時間とフットプリントが主要な目標である場合に優れた選択肢です。

しかし、すべてのアプリケーションがこれらの側面を最適化するわけではありません。一部のアプリケーションは、ピークスループット、開発速度、デバッグ容易性、既存ツールとの互換性を優先します。ここで Leyden が興味深いものになります。これは、従来の JVM モデルに近いままで、起動とフットプリントの改善を目指します。

Project Leyden は GraalVM ネイティブイメージと同じ根本的な問題に対処しますが、異なるアプローチを取っています。

AOT キャッシュはまさにその通り、キャッシュです。キャッシュにクラスが存在しない場合は、通常通りロードおよびリンクされます。

Project Leyden は、クラスのロードとリンクを最適化することで起動時間を短縮します。JVM にプロファイリング情報を提供することでウォームアップ時間を短縮し、コンパイルされたコード自体がキャッシュに保存されるようになれば、さらに短縮されるでしょう。

とはいえ、Project Leyden も魔法ではありません。現在の形式では以下のようになります。

私たちの見解では、Project Leyden はパフォーマンスと互換性の魅力的なバランスを非常に合理的なコストで提供し、JVM 上で実行される多くの Java アプリケーションのデフォルトのデプロイメントワークフローの一部となる可能性があります。

OpenJDK 25 では、以下の Project Leyden 関連 JEP が利用可能です。

これらの JEP が連携することで、OpenJDK 25 から Project Leyden を完全に利用できるようになります。

追加の JEP は OpenJDK 26 以降で計画されています。

お使いの Quarkus アプリケーションが target/quarkus-app/ ディレクトリーにパッケージされているのをご覧になっているかもしれませんが、常にそうだったわけではありません。Quarkus の初期の頃は、他のほとんどの Java フレームワークと同様に、依存関係を lib/ ディレクトリーに配置して、target/ に従来のランナー JAR をビルドしていました。

Quarkus の現在のデフォルトパッケージングは fast-jar と呼ばれています。その主要な目標の 1 つは、クラスローディングを最適化することです。

これを達成するために、独自のクラスローダーを導入しました。このクラスローダーは、たとえば、package name → jar file マッピングをメモリーに保持します。また、META-INF/services のような特定の場所の完全なディレクトリーインデックスを維持するなど、追加の最適化も含まれています。これらはこのパッケージングが行うことのほんの一部ですが、いくつかの文脈を提供できるはずです。

このパッケージングは従来の JVM 環境では非常に優れたパフォーマンスを発揮しますが、Project Leyden とはうまく連携しません。

Project Leyden は保守的なアプローチをとっており、標準の JDK クラスローダーによってロードされたクラスのみをキャッシュします。つまり、AOT キャッシュを最大限に活用したい場合は、カスタムクラスローダーは許可されません。

正確には、AOT キャッシュを最大限に活用したい場合、クラス をロードするためにカスタムクラスローダーを使用することはできません。ただし、リソース のロードのみを目的としてカスタムクラスローダーを使用することはできます。

これが、Project Leyden 専用のパッケージングである aot-jar を開発した理由です。AOT が有効になっている場合、これは自動的に選択され、移行が完全に透過的になります。これは fast-jar パッケージングと同じファイルレイアウトを使用します。

すべての クラス のローディングを JDK クラスローダーに委譲することに加えて、このパッケージングにはいくつかの特定の特性があります。

このパッケージング形式は新しいものであるため、実際の使用状況からフィードバックを収集したいと考えています。

AOT キャッシュは、それを生成するために使用されるトレーニングデータの質に依存します。トレーニングフェーズ中、JVM はロードおよびリンクされたクラスを記録し、メソッドプロファイリングデータを収集します。トレーニングワークロードがより代表的であるほど、結果として得られるキャッシュはより効果的です。

私たちは、Quarkus ユーザーにとってトレーニングが可能な限りシームレスであることを望みました。既存の統合テストインフラストラクチャーを活用するのが自然な選択でした。つまり、すでに @QuarkusIntegrationTest テストがある場合、それらをトレーニングワークロードとして利用できます。

AOT トレーニングが有効な場合、以下のフローになります。

これは実用的かつ効果的です。あなたはすでにアプリケーションを検証するために統合テストを作成しており、それらはAOTキャッシュ用の比較的現実的なトレーニングデータも生成します。

私たちは、Quarkus で Leyden を有効にするのが、1 つのフラグで済む操作であることを望みました。

quarkus.package.jar.aot.enabled=true を設定するだけで十分です。Quarkus は自動的に aot-jar パッケージングに切り替わり、AOT パイプライン全体を設定します。

Maven では、完全なフローは単一のコマンドです。

これにより、アプリケーションがビルドされ、AOT トレーニングを伴う統合テストが実行され、target/quarkus-app/ に app.aot キャッシュファイルが生成されます。

AOT キャッシュを使用してアプリケーションを実行するのも同様に簡単です。

また、AOT をコンテナーイメージエクステンション (Jib、Docker、Podman) と統合しました。AOT を有効にしてコンテナーイメージをビルドする際、Quarkus は次の処理を行います。

このエンドツーエンドの統合は、単一のコマンドでソースコードから AOT 最適化されたコンテナーイメージへの移行を意味します。

Leyden は、小規模アプリケーションと非常に大規模なアプリケーションの両方で起動時間を大幅に改善します。ネイティブ実行可能ファイルの起動速度には及ばないものの、その結果は依然として素晴らしいものです。

ここで少し立ち止まりましょう。JVM で Quarkus REST アプリケーションをわずか 80 ms で起動できました。

確かに、単一のエンドポイントを持つシンプルな REST アプリケーションですが、それでもフル機能の REST 実装に依存しています。そして、JVM で動作します。

非常に大規模なアプリケーションでも、結果は同様に印象的です。起動時間を 71% 削減できました。

驚くことではありませんが、Container Image に AOT キャッシュファイルを含める必要もあるため、Leyden はイメージサイズを増加させます。

Quarkus REST アプリケーションの場合、最小サイズは約 40 MB です。アプリケーションが大きくなるにつれてキャッシュサイズも大きくなります。

一方、ネイティブ化すると、完全な JVM を含める必要がなくなるため、Container Image サイズが大幅に削減されます。

RSS の観点では、Project Leyden は状況を大きく変えませんが、ネイティブ実行可能ファイルは大幅に低いメモリフットプリントを提供します。

メモリ使用量の削減は、今のところ Project Leyden の主要な目標ではありませんが、将来的に進化する可能性があります。

この時点で、「すべてをネイティブにしないのはなぜだろう？」と考えているかもしれません。私たちが概説した すべての理由から、あなたにとって意味のある場合にネイティブを使用してください。

スループットの問題もあります。適切なセットアップがなかったため、私たちはスループットの数値を独自に収集していませんが、一部の同僚が隔離された環境でテストを実行しており、最近 新しいベンチマーク結果 を公開しました。ネイティブ実行可能ファイルは、少なくとも Mandrel と GraalVM CE で今日オープンソースとして利用できるものについては、通常、スループットが低くなる傾向があります。

ここが Project Leyden が真価を発揮する点です。通常の JVM と比較して起動時間が大幅に高速になりながらも、JVM で実行することのすべての利点を保持します。