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

導入

ブログ投稿「Java 21 Lambda 関数のレイヤーを作成、公開、使用する方法」では、Java 21 を使用した最初の Lambda レイヤーを公開しました。この記事では、この Lambda レイヤーを使用してアプリケーションを作成し、コールド スタートとウォーム スタートを測定します。 SnapStart を有効にしない場合と、SnapStart を有効にして DynamoDB 呼び出しプライミング最適化も適用した場合の 2 回です。また、Lambda レイヤーを使用せず、記事「異なる Lambda メモリ設定を使用した Java 21 でのコールド スタートとウォーム スタートの測定」で行ったすべての依存関係を POM ファイルに提供せずに、結果を測定結果と比較します。

Java 21 で Lambda レイヤーを使用してコールドとウォームの測定を開始する

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

Lambda レイヤー経由で提供される依存関係は、アプリケーションの pom.xml ファイル内で「provided」スコープを持ちます。

記事「Java 21 Lambda 関数の公開レイヤーを作成して使用する方法」で作成した Lambda レイヤーを AWS SAM テンプレートの Lambda 関数にアタッチするには、次のように Lambda 関数に Layers パラメーターを追加する必要があります。

    Type: AWS::Serverless::Function
    Properties:
      FunctionName: GetProductByIdWithPureJava21LambdaWithCommonLayer
      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) の出力である独自の ARN に置き換えてください。

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

以下の表では、記事「Java 21 でコールド スタートとウォーム スタートを測定する。異なる Lambda メモリ設定を使用して、両方を直接比較する」から取得した 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 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 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 호출 프라이밍(ms)을 사용한 콜드(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 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를 사용하지 않고 측정값과 비교했습니다. 다양한 Lambda 메모리 설정을 사용하여 Java 21의 콜드 및 웜 스타트 측정 문서에서 수행한 POM 파일의 모든 종속성을 제공합니다.

실험 결과를 실제로 확인하기 위해 공통 람다 레이어를 사용하여 여러 번 측정을 수행했습니다. 측정 결과에 약간의 차이가 있더라도 추세는 항상 같았습니다. SnapStart를 활성화하지 않거나 활성화했지만 DynamoDB 호출 프라이밍을 사용하지 않으면 일반 Lambda를 사용하여 콜드 스타트가 발생했습니다. 레이어는 POM 파일에만 모든 종속성을 패키징하는 것과 비교하여 수백 밀리초 더 높았습니다. Lambda 함수에 대해 SnapStart가 활성화되고 DynamoDB 호출 프라이밍이 적용된 경우에만 두 접근 방식의 콜드 스타트가 매우 유사했는데, 이는 모든 것이 이미 생성된 스냅샷에 있었기 때문일 것입니다.

Lambda 함수의 웜 스타트는 거의 모든 백분위수에 대한 사용 사례(Lambda 레이어 사용 여부와 상관없이)와 모든 실험(SnapStart 활성화 여부에 관계없이)에서 매우 유사했습니다. 하지만 공통 Lambda 레이어를 사용하면 항상 최대값에 대해 더 높은 결과를 얻었습니다.

다음 기사에서는 Lambda 레이어에 대한 실험을 계속하겠습니다. 이번에는 이 기사와 같은 공통 종속성뿐만 아니라 이 애플리케이션을 실행하는 데 필요한 모든 종속성을 포함하는 Lambda 계층을 생성, 게시 및 사용한 다음 두 실험의 결과를 비교해 보겠습니다.

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