導(dǎo)入

サーバーレス コードを操作する場(chǎng)合の非常に一般的なアプローチは、コールド スタートが非常に速いという評(píng)判を考慮して、Python、Node、または Go アプリケーションとしてコードを記述することです。

しかし、AWS Lambda などのサーバーレス環(huán)境をターゲットとする既存の Java アプリケーションに直面したらどうなるでしょうか?おそらくコード ベースの大部分は Java をホストしており、再利用したいツールとライブラリの豊富なエコシステムを開発しました。このようなアプリケーション全體を別の言語(yǔ)で書き直すにはコストがかかり、言うまでもなく、靜的タイプセーフやコンパイル時(shí)間の最適化などの機(jī)能を放棄することになります。

少し前、私はまさにこのシナリオに直面しました。Java で書かれた 9 つの AWS Lambda アプリは、コールド スタートで非常に遅くなり、一部のアプリが時(shí)折タイムアウトするほどでした。

問(wèn)題の Lambda は API Gateway の背後に配置され、対応する REST API を呼び出すことで管理タスクに使用されました。この機(jī)能はあまり頻繁に使用されていなかったため、コールド スタートが発生するのは避けられませんでした。ただし、これは重要なサービスではなかったため、これらの Lambda を回収できるかどうかを判斷するための実験には絶好の機(jī)會(huì)でした。

この問(wèn)題に対処するために GraalVM や Quarkus などのフレームワークをうまく使用している開発者に関する他のいくつかのブログ投稿に出會(huì)うまで、それほど時(shí)間はかかりませんでした。そこで私は自分で試してみることにしました。

しかし、そもそもこれらのツールは何なのでしょうか?

GraalVM

要するに、GraalVM は、Java をネイティブ イメージにコンパイルし、Graal JVM を使用して実行できるツールセットが付屬する Java 仮想マシンです。

通常、Java は「Just In Time」(JIT) コンパイラーを利用します。これは、名前が示すように、コードの実行中に最適化とコンパイルを?qū)g行します。 JVM オプティマイザーがプログラムの実行を常に監(jiān)視し、時(shí)間の経過(guò)とともにパフォーマンスの向上につながる微調(diào)整を?qū)g行するため、長(zhǎng)時(shí)間実行されるアプリケーションはこの恩恵を受けます。

これは、アプリケーションが一度インスタンス化され、數(shù)時(shí)間以上実行されることが予想される場(chǎng)合には最適ですが、Kubernetes、AWS Lambda、および Java アプリケーションを迅速に起動(dòng)し、実行することを期待するバッチ ジョブを扱う場(chǎng)合には、あまり良くありません。時(shí)間に敏感な操作と需要に応じた規(guī)模 - 自動(dòng)車愛(ài)好家にとってターボラグといえば。

ここで、GraalVM のネイティブ イメージ機(jī)能が役に立ちます。 JIT コンパイラーを使用する代わりに、コードを事前にコンパイルする (AOT) という非常に異なるアプローチを選択します。靜的コード分析を使用してパイを事前にベイクし、ビルド時(shí)に特定のクラスを事前初期化して、アプリケーション コードが実行されるときにいつでも起動(dòng)できるようにします。

結(jié)果は?非常に高速なコールド スタートにより、アプリの有効期間が短く、すぐに起動(dòng)する必要があるサーバーレス ドメインでネイティブ イメージが非常に機(jī)能します。

注意すべき點(diǎn)の 1 つは、GraalVM は AOT に対応していますが、Java で書かれた GraalVM の新しい JIT コンパイラを考慮すると、既存の JVM のドロップイン置き換えとしても機(jī)能し、パフォーマンスが向上するということです。

しかし、待ってください、それだけではありません!ネイティブ イメージには既知の実行パス上にあるコードのみが含まれるため、脂肪は削除され、保持することが明示的に宣言されていないすべての Java クラスは使用できなくなります。実行が予想されるビットのみを保持するため、アプリケーションのセキュリティが向上します。

ホストを侵害する手段としてリモート コード実行を使用する悪名高い Log4J 脆弱性を例に考えてみましょう。ネイティブ イメージでは、攻撃を伝達(dá)するために必要なライブラリ コードの部分にさえ到達(dá)できないため、ガジェット チェーンが成功する可能性は非常に低いです。

クォーカス

Quarkus は、サーバーレス アプリケーション用に最適化された Java フレームワークで、AWS Lambda をネイティブ実行可能ファイルとして特別に設(shè)定および構(gòu)築するための拡張機(jī)能を提供することで、ネイティブ イメージの構(gòu)築を容易にするツールボックスが付屬しています。

C1 コンパイラ

Lambda の最適化の過(guò)程で、別の最適化手法にも遭遇しました。そのような最適化の 1 つは、Lambda の実行中に C1 コンパイラーを排他的に使用する提案であり、これによりコールド スタートの高速化が約束されました。通常、JVM 內(nèi)で実行される Java アプリケーションは、高速ではあるが最適性が低い C1 と、その後に低速ではあるが長(zhǎng)時(shí)間実行される Java アプリケーションに最適なパフォーマンスを提供する C2 で構(gòu)成される階層型コンパイルを使用します。 Lambda の壽命が短いことを考えると、C2 コンパイルのメリットはごくわずかです。

AWS Lambda の C1 コンパイルを構(gòu)成するプロセスを説明するガイドは、ここから入手できます。

もちろん、私が実施している GraalVM マスタープランと比較して、この手法がどの程度の改善をもたらすかを知りたかったので、以下の調(diào)査結(jié)果にも含めました。

JVM の階層型コンパイルと GraalVM の新しい JIT コンパイラーの詳細(xì)については、この Baeldung の記事を參照してください。

「でも、ちょっと待って、AWS SnapStart についてはどうですか?」

皮肉なことに、私が変更を本番環(huán)境に出荷してから數(shù)か月後、AWS は最新の SnapStart 機(jī)能を考案しました。これは、実行中の Lambda のスナップショットを取得し、最初から再初期化するのではなく、スナップショット イメージを使用します。復(fù)元ポイントはコールド スタートの高速化を約束します。 GraalVM の使用が無(wú)駄な労力であったかどうかを確認(rèn)するために試してみる必要があり、それも調(diào)査結(jié)果に含めました。

SnapStart を最大限に活用するには、beforeCheckpoint フックと afterRestore フックを利用するためにコードのリファクタリングが必要になることに注意してください (詳細(xì)はこちら)。可能であれば大きなコード変更を避けたかったため、これらのメソッドを?qū)g裝したりコードを再配置したりすることなく、この機(jī)能を「そのまま」使用しました。

マスタープラン

GraalVM に戻りましょう。驚いたことに、このソリューションを組み込んだ後は、ビルド構(gòu)成ファイルといくつかの必要なメタデータの追加と調(diào)整を除いて、Java コードの変更はまったく必要ありませんでした。

うますぎる話ですね?

少しかもしれない。 Java の世界では AOT コンパイルを使用していることを考えると、多くのライブラリが依存するリフレクション、プロキシ、インターフェイス、サービス レジストリなどの言語(yǔ)機(jī)能の使用に関しては、一定の課題が生じます。このため、GraalVM コンパイラでは、特定のクラスとサービスを最終アーティファクトに含めることができるように、明示的に登録する追加の構(gòu)成メタデータを宣言する必要があります。 GraalVM は、実行可能ファイルと一緒に実行するために使用できるいわゆるエージェントを提供し、必要な構(gòu)成を自動(dòng)的に識(shí)別することで、このプロセスを容易にします。

Quarkus は、よく知られているライブラリを「ネイティブ イメージ フレンドリー」にするための拡張機(jī)能をいくつか提供していますが、私が既存のコード ベースで作業(yè)していたことを考えると、私の目標(biāo)は、大きなリファクタリング (または、さらに言えばコードの変更) を避けることでした。 )、ネイティブ イメージを正常に生成するために既存のライブラリに必要な構(gòu)成ファイルを作成することにしました。

ネイティブ イメージのコンパイルはリソースを大量に消費(fèi)し、標(biāo)準(zhǔn)の JVM ランタイムを?qū)澫螭趣筏骏啸ぅ去畅`ドのコンパイルに比べてかなり長(zhǎng)い時(shí)間がかかることに注意してください。メモリ不足の問(wèn)題を回避するために、ビルド ノードにより多くの RAM を割り當(dāng)てる必要がある可能性があります。これは取引を妨げるものではありませんが、必ず念頭に置いておく必要があります。

ネイティブ イメージ Lambda をコンパイルしてパッケージ化したので、次はそれらをテスト環(huán)境にデプロイします。通常、Java Lambda は AWS の Java ランタイムを利用して実行します。ただし、Graal JVM 內(nèi)にラップされたアプリコードを含むバイナリアーティファクトであるネイティブイメージを使用しようとしている場(chǎng)合、AWS が提供する「カスタム」Amazon Linux 環(huán)境の 1 つを選択する必要があります。

テスト方法

Postman API コレクションを使用して 9 個(gè)の Lambda すべてにリクエストを送信し、上記の各手法のコールド スタートの応答時(shí)間を測(cè)定しました。常にコールド スタートが発生することを確認(rèn)するために、ターゲット Lambda の設(shè)定をリロードしました。これにより、次の呼び出しではすでにウォーム狀態(tài)になっている可能性のあるインスタンスが使用されなくなります。すべての Lambda は 1GB の RAM で構(gòu)成されました。また、プロセスに時(shí)間がかかることを考慮して、構(gòu)成ごとに 1 回の呼び出しを測(cè)定しました。ただし、観察された応答時(shí)間は非常に明確な狀況を示しています。

結(jié)果

それで、うまくいきましたか？絶対に！結(jié)果は次のとおりです:

そして、明らかな勝者は次のとおりです: GraalVM Native Images - 変更されていない Java Lambda と比較して、平均して 3 倍の高速化が実現(xiàn)しました - タイムアウトがなくなり、応答時(shí)間が大幅に向上しました。これはまさに私が望んでいたものです。達(dá)成します。

コードを変更しないと、SnapStart は思ったほどパフォーマンスが良くありませんでした。 SnapStart 機(jī)能に加えて C1 コンパイラを採(cǎi)用すると、コールド スタート時(shí)間はさらに短縮されましたが、それでも GraalVM のネイティブ イメージを上回ることはできませんでした。だからといって、これが迅速かつ簡(jiǎn)単に実裝できる改善策として実行可能な選択肢ではないというわけではありません。ただし、Lambda を可能な限り最適化する必要があり、構(gòu)成とビルド プロセスを調(diào)整するための時(shí)間とリソースがある場(chǎng)合は、パフォーマンスとセキュリティの點(diǎn)で GraalVM が間違いなく優(yōu)れています。

メモリ使用量

GraalVM が主張しているように、ネイティブ イメージは、通常の JVM に比べて効率的に実行するために必要なリソースが少なくなります。これらの Lambda が動(dòng)作する必要がある RAM の量を減らした場(chǎng)合に、コールド スタートとウォーム スタートのパフォーマンスがどのように維持されるかを確認(rèn)したかったのです。今回は、このテストを?qū)g行するために 1 つの Lambda アプリのみを選択しました。結(jié)果は次のとおりです:

そして彼らは約束を果たしました!通常の JVM Lambda は 256 MB 以下の構(gòu)成を試行するとメモリ不足になりましたが、ネイティブ イメージは段階的ではなく実行を継続しているように見(jiàn)えました。 128 MB が利用可能な最小メモリ オプションでなかったら、どれだけメモリを減らすことができたのだろうか。ネイティブ イメージは、コールド スタートで高速なだけでなく、限られたリソースで作業(yè)する場(chǎng)合でも一貫したパフォーマンスを提供し、運(yùn)用コストの削減につながります。

結(jié)論

Java のエコシステムは豊富かつ広大で、サーバーレス アプリケーションに関して Java を常に活用し続ける多くの新しいテクノロジと機(jī)能強(qiáng)化が日々登場(chǎng)しています。そのような新興テクノロジーの 1 つが GraalVM です。研究プロジェクトとして始まったものは、現(xiàn)在では徐々に採(cǎi)用されており、HotSpot などの標(biāo)準(zhǔn) JVM の実行可能な代替手段として浮上しています。このブログ投稿では、GraalVM が提供する機(jī)能のほんの表面をなぞっただけなので、読者にはさらに詳しく調(diào)べていただくことをお?jiǎng)幛幛筏蓼埂?Adyen (記事リンク) や Facebook (記事リンク) などの企業(yè)からは、GraalVM を利用して時(shí)間とお金を節(jié)約できた成功事例がいくつかあります。

次に Java をオプションとして無(wú)視する場(chǎng)合は、GraalVM を試してみてください。 Spring Boot 3 がすぐに使える GraalVM ネイティブ イメージをサポートするようになったことで、サーバーレス ワークロードにこれまで以上に簡(jiǎn)単にネイティブ イメージを採(cǎi)用して、GraalVM が提供するパフォーマンス、低リソース消費(fèi)、追加されたセキュリティを活用できるようになりました。

以上がJava もサーバーレスにできる: GraalVM を使用した高速コールド スタートの詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國(guó)語(yǔ) Web サイトの他の関連記事を參照してください。