導入

ブログ投稿「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) スタート時間 (ms):

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

SnapStart および DynamoDB 呼び出しプライミングを使用したコールド (c) およびウォーム (w) スタート時間 (ms:

結論

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

実験結果を実際に確認するために、一般的な Lambda レイヤーを使用して測定を複数回実行しました。これらの測定間の結果に多少の差異があったとしても、傾向は常に同じでした。SnapStart を有効にしていない場合、または有効にして DynamoDB 呼び出しのプライミングを使用していない場合、共通の Lambda を使用して コールド スタート が発生します。すべての依存関係を POM ファイルのみにパッケージ化する場合と比較して、レイヤーは数百ミリ秒高かったです。 Lambda 関数に対して SnapStart が有効になっていて、DynamoDB 呼び出しプライミングが適用されている場合にのみ、両方のアプローチで コールド スタート が非常に近くなりました。これはおそらく、作成されたスナップショットにすべてがすでに存在していたという事実によるものです。

Lambda 関数の ウォーム スタート は、両方のユースケース (Lambda レイヤーを使用する場合と使用しない場合) およびすべての実験 (SnapStart を有効にする場合と使用しない場合) のほぼすべてのパーセンタイルで非常に近かったです。ただし、共通の Lambda レイヤーを使用すると、常に最大値のより高い結果が得られます。

次の記事では、Lambda レイヤーの実験を続けます。今回は、一般的な依存関係 (この記事のような) だけでなく、このアプリケーションの実行に必要なすべての依存関係を含む Lambda レイヤーを作成、公開、使用し、両方の実験の結果を比較します。