Docker Container Imageを利用したLambda関数 -JavaでLambda関数のコールドスタートとウォームスタートを確認する部分(ランタイム)

導入

小規模シリーズの最初の記事では、Docker コンテナ イメージと Java ランタイムを使用して Lambda 関数を開発およびデプロイする方法を検討しました。私たちは 2 つの使用例を検討しました:

• AWS Lambda ベース Docker コンテナイメージ
• AWS OS のみのベースイメージ

この記事では、このアプローチ AWS Lambda ベース Docker コンテナ イメージを使用して、Lambda 関数のコールド スタートとウォーム スタートを測定します。

AWS Lambda ベースの Docker コンテナイメージと Java (21) ランタイムを使用した Lambda 関数のコールド スタートとウォーム スタートの測定

測定には、最初の部分のサンプル アプリケーションを使用し、Lambda 関数に Java 21 ランタイムを使用します。すべての Lambda 関数に 1024 MB のメモリを与え、JAVA_TOOL_OPTIONS: "-XX:+TieredCompilation -XX:TieredStopAtLevel=1" を使用します。これは、このコンパイル オプションがコールド スタート時間とウォーム スタート時間の間で非常に優れたトレードを提供するためです。

以下の実験の結果は、Lambda 関数 GetProductByIdWithPureJava21GraalVMNativeImageLambda を使用して、1 時間の間に 100 件を超えるコールド スタートと約 100,000 件のウォーム スタートを再現したことに基づいています。この関数は、製品 (保存されている) の取得を担当する Java Lambda ハンドラー クラスにマップされています。 DynamoDB 内）を ID で指定します。このために負荷テスト ツールを使用しましたが、Serverless-artillery や Postman など、好きなツールを使用できます。

コールド (c) およびウォーム (m) の開始時間 (ミリ秒):

c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
3093.26	3219.44	3314.12	4632.16	6513.35	6517.71	5.47	6.20	7.39	17.14	43.03	1386.07

結論

この記事では、このアプローチ AWS Lambda ベースの Docker コンテナ イメージを使用して、Lambda 関数のコールドおよびウォームの開始時間を測定しました。 1024 MB メモリの Lambda と Lambda Java 21 マネージド ランタイムの異なる Lambda メモリ設定を使用した Java 21 でのコールド スタートとウォーム スタートの測定と比較して、非常に大幅なコールド スタート時間と非常に競争力のあるウォーム スタート時間を経験しました。

コールド スタート時間を大幅に短縮する AWS Lambda SnapStart は、現在 Java Corretto 管理のランタイム (11、17、21) でのみ利用可能であり、Docker コンテナ イメージでは利用できません。 jlink ツールを探索して、一連のモジュールとその依存関係をより小さなカスタム ランタイム イメージとクラス データ共有 (CDS) にアセンブルおよび最適化することができます。これは、Java プログラミング言語アプリケーション、特に小規模なアプリケーションの起動時間を短縮するのに役立ちます。設置面積を削減します。 Docker イメージを Java のデプロイメント アーティファクトとして使用する利点は、Java 22 (Java 23 は 2024 年 9 月にリリースされる予定) などの最新の Java ランタイムを使用できることです。

以上がDocker Container Imageを利用したLambda関数 -JavaでLambda関数のコールドスタートとウォームスタートを確認する部分(ランタイム)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。