AWS SnapStart - パート Lambda レイヤーを使用した Java によるコールド スタートとウォーム スタートの測定 (2)

導入

ブログ記事「Java 21 Lambda 関数のレイヤーを作成、公開、使用する方法」では、Java 21 で最初の Lambda レイヤーを公開する方法を説明しました。記事「Lambda レイヤーを使用した Java 21 でのコールド スタートとウォーム スタートの測定」(1)この Lambda レイヤーを使用してアプリケーションを作成し、SnapStart を有効にしない場合と SnapStart を有効にしてコールド スタート時間とウォーム スタート時間を測定し、DynamoDB 呼び出しプライミングの最適化も適用して、Lambda レイヤーを使用せず、POM ファイル内のすべての依存関係を提供せずに結果を測定値と比較しました。これは、「Java 21 でさまざまな Lambda メモリ設定を使用してコールドとウォームの測定を開始する」という記事で実行しました。この記事では、すべての依存関係を含む別の Lambda レイヤーを作成し、このレイヤーをアプリケーションで使用し、同じ測定を実行して、結果を前の実験と比較します。

すべての依存関係を持つ Lambda レイヤーを使用した Java 21 でのコールド スタートとウォーム スタートの測定

調査のために、サンプル Lambda レイヤーを使用して、Java 21 ランタイムで Lambda レイヤーを作成し、すべて の依存関係をレイヤーにパッケージ化します。

• dynamodb
• ラムダ
• Apache クライアント
• aws-lambda-java-core
• aws-lambda-java-events
• org-crac
• slf4j-simple
• ジャクソン-データフォーマット-xml

サンプル アプリケーションも使用します。 AWS SAM テンプレートには基本的に 2 つの Lambda 関数が定義されており、どちらも API Gateway リクエストに応答し、API Gateway から受け取った ID によって DynamoDB から製品を取得します。 1 つの Lambda 関数 GetProductByIdWithPureJava21LambdaWithAllLayer は SnapStart の有無にかかわらず使用でき、2 つ目の Lambda 関数 GetProductByIdWithPureJava21LambdaAndPrimingWithAllLayer は SnapStart と DynamoDB リクエスト呼び出しプライミングを使用します。

AWS SAM テンプレートの Lambda 関数に対して以前に作成したすべての依存関係を含む Lambda レイヤーを使用するには、次のように Lambda 関数に Layers パラメータを追加する必要があります。

    Type: AWS::Serverless::Function
    Properties:
      FunctionName: GetProductByIdWithPureJava21LambdaWithAllLayer
      AutoPublishAlias: liveVersion
      Layers:
        - !Sub arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:layer:aws-pure-java-21-common-lambda-layer:1
      Handler: software.amazonaws.example.product.handler.GetProductByIdHandler::handleRequest

レイヤー ARN (バージョンを含む) を独自のものに置き換えてください。これは、レイヤーコマンド (aws lambda public-layer-version) の発行の場合の出力です。

pom.xml では、スコープ 提供 (アタッチされた Lambda レイヤーによって) を持つすべての依存関係が表示されます。

以下の実験の結果は、約 1 時間実行された実験で 100 回を超えるコールド スタートと約 100,000 回のウォーム スタートを再現したことに基づいています。そのために (および前回の記事の実験で) 負荷テスト ツールを使用しましたが、Serverless-artillery や Postman など、好きなツールを使用できます。
これらすべての実験は、Lambda 関数に 1024 MB のメモリを与え、環境変数 JAVA_TOOL_OPTIONS: "-XX:+TieredCompilation -XX:TieredStopAtLevel=1" (プロファイリングなしのクライアント コンパイル) を介して次のコンパイル オプションを渡すことによって実行しました。

以下の表には、記事「異なる Lambda メモリを使用した Java 21 でのコールド スタートとウォーム スタートの測定」で行った、Lambda レイヤーを使用しない (および POM ファイル内のすべての依存関係を提供する) 測定結果も示します。共通の Lambda レイヤーを使用して直接比較する場合の設定と測定値。
略語 c はコールド スタートを表し、w はウォーム スタートを表します。

スナップスタートなしのコールド (c) およびウォーム (w) の開始時間 (ミリ秒):

Experiment	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
with all dependencies Lambda Layer	2824.33	2884.24	2963.14	3324.07	3622.44	3625.58	5.50	6.20	7.16	15.50	46.19	1278.41
with common Lambda Layer	3497.91	3597.18	3695.58	3800.47	3908.33	4011.71	5.82	6.72	8.00	17.97	55.48	1709.13
w/o Lambda Layer	3157.6	3213.85	3270.8	3428.2	3601.12	3725.02	5.77	6.50	7.81	20.65	90.20	1423.63

プライミングなしの SnapStart によるコールド (c) およびウォーム (w) スタート時間 (ms):

Experiment	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
with all dependencies Lambda Layer	1706.64	1767.40	1893.59	2314.91	2646.68	2647.33	5.59	6.25	7.21	15.75	48.06	1403.71
with common Lambda Layer	2047.12	2124.24	2439.49	2705.52	2735.43	2831.59	5.68	6.40	7.45	17.06	48.45	2139.74
w/o Lambda Layer	1626.69	1741.10	2040.99	2219.75	2319.54	2321.64	5.64	6.41	7.87	21.40	99.81	1355.09

SnapStart と DynamoDB 呼び出しのプライミングによるコールド (c) およびウォーム (w) スタート時間 (ミリ秒単位):

Experiment	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
with all dependencies Lambda Layer	747.47	786.56	932.23	1099.38	1666.18	1666.62	5.42	5.91	7.39	16.39	45.09	574.61
with common Lambda Layer	713.88	766.38	1141.94	1181.41	1214.94	1215.32	5.59	6.30	7.39	16.39	45.09	574.61
w/o Lambda Layer	702.55	759.52	1038.50	1169.66	1179.05	1179.36	5.73	6.51	7.87	21.75	92.19	328.41

結論

この記事では、すべての依存関係を持つ Lambda レイヤーを使用してアプリケーションを作成し、SnapStart を有効にしない場合と SnapStart を有効にしてコールド スタート時間とウォーム スタート時間を測定し、DynamoDB 呼び出しプライミングの最適化も適用して、結果を Lambda を使用しない測定結果と比較しました。これは、記事「Java 21 でのコールド スタートとウォーム スタートの測定」で、異なる Lambda メモリ設定と共通の Lambda レイヤーを使用して実行しました。

結果に多少の偏差があったとしても、すべての依存関係を持つ Lambda レイヤーを使用して複数の測定を行った後、傾向は常に同じでした。

• SnapStart を有効にしていない場合、この Lambda レイヤーでのコールド スタートは、p90 までのパーセンタイルで、Lambda レイヤーを使用しない場合よりも最大数百ミリ秒低かったです (これには驚きました)。
• SnapStart を有効にし、DynamoDB リクエストのプライミングを使用しない場合、コールド スタートは、パーセンタイルに応じて、すべての依存関係を持つ Lambda レイヤーを優先するか、Lambda レイヤーをまったく使用しない Lambda を優先するかによって異なります。
• DynamoDB リクエストのプライミングで SnapStart を使用した場合、すべての依存関係を持つ Lambda レイヤーを使用した場合、コールド スタートは両方のユースケースでパーセンタイルが p99 までは近かったが、p99.9 以上ではパーセンタイルが高くなりました。 したがって、結果はユースケースごとに大きく異なりました。私が常に観察しているのは、すべての依存関係を持つ Lambda レイヤーを使用した場合、すべての測定結果の範囲が非常に大きく (p50 値と最大値の差が 800 ～ 900 ミリ秒)、Lambda レイヤーをまったく使用しない場合は同じ範囲がはるかに低かったということです。
• この記事の測定値を一般的な Lambda レイヤーでの測定値と比較すると、最初の 2 つの実験 (SnapStart が有効になっていない場合と、SnapStart が有効になっているがプライミングが適用されていない場合) とその逆で Lambda レイヤーのすべての依存関係を使用した場合のコールド スタートが低かったことがわかります。 SnapStart が有効で、DynamoDB の呼び出しが準備されている場合。
• Lambda 関数のウォーム スタート/実行時間は、すべてのユースケースで非常に近かったです。

したがって、Lambda レイヤーの使用法 (そこに何を配置するか、アプリケーションの依存関係として何を提供するかによって異なります) は予測不可能性を追加するため、常に独自の測定を行う必要があります。

以上がAWS SnapStart - パート Lambda レイヤーを使用した Java によるコールド スタートとウォーム スタートの測定 (2)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。