こんにちは、みんな！ これは Quarkus に関するシリーズの XNUMX 番目の投稿です。今日はネイティブ コンパイルについて話します。
に合わせて調整された Java スタックです 。 もちろん、ここでやるべきことはたくさんありますが、JVM や多数のフレームワークの最適化など、多くの側面でうまく取り組んできました。 開発者からの関心が高まっている Quarkus の機能の XNUMX つは、C や C++ と同様に、Java コードを特定のオペレーティング システム用の実行可能ファイルに変換する包括的でシームレスなアプローチ (いわゆる「ネイティブ コンパイル」) です。通常、ビルド、テスト、展開のサイクルの終わりに発生します。
また、以下で説明するようにネイティブ コンパイルは重要ですが、スタック全体に実装したパフォーマンスの向上のおかげで、Quarkus は最も一般的な Java マシンである OpenJDK Hotspot 上で非常にうまく動作することに注意してください。 したがって、ネイティブ コンパイルは、必要に応じて使用できる追加のボーナスとして考慮する必要があります。 実際、Quarkus はネイティブ イメージに関して OpenJDK に大きく依存しています。 また、開発者に広く受け入れられている開発モードでは、ホットスポットに実装された動的コード実行の高度な機能により、ほぼ瞬時に変更をテストできます。 さらに、ネイティブ GraalVM イメージを作成するときは、OpenJDK クラス ライブラリと HotSpot 機能が使用されます。
すべてがすでに完全に最適化されているのに、なぜネイティブ コンパイルが必要なのでしょうか? 以下ではこの質問に答えていきます。
明らかなことから始めましょう: Red Hat には、プロジェクト開発中に JVM、スタック、フレームワークを最適化した豊富な経験があります , 日付:
- プラットフォーム上のクラウドで動作する最初のアプリケーション サーバー .
- コンピュータ上で実行される最初のアプリケーション サーバー .
- 最初に実行するアプリケーション サーバー .
- デバイス上で実行されるさまざまなプロジェクト .
私たちは長年にわたって、クラウドやリソースに制約のあるデバイス (IoT) で Java アプリケーションを実行するという課題に取り組んできて、パフォーマンスとメモリの最適化の点で JVM を最大限に活用する方法を学びました。 他の多くの人と同様に、私たちは長い間 Java アプリケーションのネイティブ コンパイルに取り組んできました。 , , とさえ そして私たちは、このアプローチの長所と短所をよく知っています (たとえば、「一度ビルドすればどこでも実行できる」という普遍性と、コンパイルされたアプリケーションの方が小さくて高速に実行できるという事実のどちらを選択するかというジレンマ)。
これらの長所と短所を考慮することがなぜ重要なのでしょうか? 場合によっては、それらの比率が決定的なものになるためです。
- たとえば、サーバーレス/イベント駆動型環境では、 イベントに応答する時間を確保するために、（ハードまたはソフト）リアルタイムで。 存続期間の長い永続サービスとは異なり、ここではコールド スタートの期間により、リクエストに対する応答時間が大幅に増加します。 JVM の起動には依然としてかなりの時間がかかります。場合によっては純粋なハードウェア方法で短縮できますが、5 秒と XNUMX ミリ秒の差が生死を分ける可能性があります。 はい、ここで Java マシンのホット リザーブの作成を試すことができます (たとえば、 ) しかし、これ自体は、負荷が増加したときにリクエストを処理するのに十分な JVM があることを保証するものではありません。 そして経済的な観点から見ると、これはおそらく最も正しい選択肢ではありません。
- さらに、よく現れる別の側面として、マルチテナントがあります。 JVM はその機能においてオペレーティング システムに非常に近づいているにもかかわらず、Linux で慣れ親しんでいるプロセスの分離を行うことはまだできません。 したがって、XNUMX つのスレッドに障害が発生すると、Java マシン全体がダウンする可能性があります。 多くの人は、障害の影響を最小限に抑えるために、各ユーザーのアプリケーションに個別の JVM を専用にすることで、この欠点を回避しようとします。 これは非常に論理的ですが、スケーリングにはあまり適合しません。
- さらに、クラウド指向アプリケーションの場合、ホスト上のサービスの密度が重要な指標となります。 方法論への移行 、マイクロサービス、Kubernetes により、アプリケーションごとの Java マシンの数が増加します。 つまり、一方では、これらすべてが弾力性と信頼性を提供しますが、同時にサービスの観点からベースメモリの消費も増加し、これらの費用の一部は必ずしも厳密に必要であるとは限りません。 ここで、静的にコンパイルされた実行可能ファイルは、最終イメージにサービスが実際に使用するフレームワークの部分 (JDK 自体を含む) のみが含まれる場合、低レベルのデッドコードの除去などのさまざまな最適化手法によって恩恵を受けます。 したがって、Quarkus ネイティブ コンパイルは、セキュリティを損なうことなくサービス インスタンスをホスト上に高密度に配置するのに役立ちます。
実際、Quarkus プロジェクト参加者の観点からネイティブ コンパイルの正当性を理解するには、上記の議論だけで十分です。 しかし、技術的ではない、しかし重要な理由がもう XNUMX つあります。近年、多くのプログラマーや開発会社が Java を放棄し、新しいプログラミング言語を選択しています。これは、Java は、その JVM、スタック、フレームワークとともに、あまりにも重要なものになったと考えられています。メモリを大量に消費する、遅すぎるなど。
ただし、問題を解決するために同じツールを使用する習慣は、 。 場合によっては、一歩下がって別のことを探したほうがよい場合もあります。 そして、Quarkus が人々に立ち止まって考えさせるなら、それは Java エコシステム全体にとって良いことです。 Quarkus は、より効率的なアプリケーションを構築する方法についての革新的なビューを表し、Java をサーバーレスなどの新しいアプリケーション アーキテクチャとの関連性を高めます。 さらに、Quarkus はその拡張性により、Java 拡張機能のエコシステム全体を備え、すぐに使えるアプリケーションのネイティブ コンパイルをサポートするフレームワークの数を大幅に増やすことが期待されています。
出所： habr.com