導入

これまで、arm64 アーキテクチャの一部のユースケース (DynamoDB リクエストの作成など) で Java 21 ランタイムを使用した Lambda 関数のパフォーマンス (ウォーム スタート時間とコールド スタート時間) を測定していませんでした。これは、SnapStart がサポートされていなかったためです。 SnapStart が有効になっている x86_64 アーキテクチャの Java 21 ランタイムを備えた Lambda は、arm64 アーキテクチャを備えた Lambda よりも優れたパフォーマンスを発揮します (追加のプライミング最適化によりさらに優れています)。しかし、2024 年 7 月 18 日、AWS は、AWS Lambda が ARM64 アーキテクチャを使用する SnapStart for Java 関数をサポートするようになったと発表しました。したがって、Lambda 関数のアーキテクチャの選択も考慮して、コールド スタート時間とウォーム スタート時間の測定を開始することは理にかなっています。現在の AWS Lambda のメモリ設定と実行期間の価格設定では、arm64 アーキテクチャの Lambda は約 100 時間かかることが知られています。 x86_64 アーキテクチャの Lambda より 25% 安い。

このトピックについては、成長を続ける AWS Lambda SnapStart シリーズに追加せず、別の記事シリーズを作成することにしました。

アプリケーション例のコールド スタートとウォーム スタートの測定

この実験では、記事「AWS Lambda SnapStart - Java 21 Lambda コールド スタートの測定」で紹介されたアプリケーションを再利用します。サンプル アプリケーションのコードは次のとおりです。基本的に 2 つの主要な Lambda 関数があり、どちらも API Gateway リクエストに応答して、指定された ID で製品を作成し (PutProductFunction Lambda 関数を参照)、指定された ID で製品を取得します (GetProductByIdFunction Lambda 関数を参照)。 SnapStart を有効にしても無効にしても、両方の Lambda 関数を使用できます。追加の Lambda 関数 GetProductByIdWithPrimingFunction があり、SnapStart 対応 Lambda 関数の DynamoDB リクエスト プライミングの効果を個別に測定するために作成しました。プライミングの効果について詳しくは、私の記事「AWS Lambda SnapStart - プライミング、エンドツーエンドのレイテンシー、デプロイメント時間の測定」を参照してください。

すべての Lambda 関数で SnapStart を有効にするには、SAM テンプレート内の次のコメントを解除してください:

Globals:
  Function:
    CodeUri: target/aws-pure-lambda-snap-start-21-1.0.0-SNAPSHOT.jar
    ...
    SnapStart:
     ApplyOn: PublishedVersions  
   ...

すべての Lambda 関数ではなく、個々の Lambda 関数に対してのみ SnapStart を使用したい場合は、グローバル関数レベルではなく Lambda 関数レベルでこの SnapStart 定義を適用する必要があります。

すべての Lambda 関数には、開始点として次の設定があります:

• 1024 MB メモリ設定
• DynamoDB データベースとの通信に使用されるデフォルトの HTTP Apache クライアント
• Java コンパイル オプション「-XX: TieredCompilation -XX:TieredStopAtLevel=1」は、コールド スタート時間とウォーム スタート時間の間に非常に優れたトレードオフを提供することが証明されました

SAM テンプレートに、次のようにグローバル Lambda 関数セクションで Lambda アーキテクチャを定義できる機能を追加しました。

Globals:
  Function:
    CodeUri: target/aws-pure-lambda-snap-start-21-1.0.0-SNAPSHOT.jar
    ...
    Architectures:
      #- arm64
      - x86_64   

Lambda 関数に使用したいアーキテクチャのコメントを解除するだけです。

Java が「一度書けば、どこでも実行できる」としても、事前にインストールしておいた Graviton プロセッサ (arm64/aarch64 アーキテクチャに基づく) を備えた t4g AWS EC2 インスタンス上で arm64 測定用のアプリケーション jar ファイルをコンパイルして構築しました。 Linux aarch64 用 Amazon Corretto 21。この瓶はここで見つけることができます。

また、同じ Corretto Java 21 の最新ランタイム バージョン (測定時点では Java 21.v17 でした) を使用して、同等の結果を得るため、x86_64 アーキテクチャのすべてを再度測定しました。

以下の実験の結果は、100 回を超えるコールド スタートと約 100,000 回のウォーム スタートの再現に基づいています。そのために (および前回の記事の実験で) 負荷テスト ツールを使用しましたが、Serverless-artillery や Postman など、好きなツールを使用できます。 また、アプリケーションの新しいソース コード (再) デプロイメントの直後に測定を開始したことに注意することも重要です。コールド スタートではスナップショット階層型キャッシュの影響もあることにも注意してください。通常、最初の呼び出しは遅くなり、特定の呼び出し数に達するまで後続の呼び出しは速くなります。

次に、「既存の ID による製品の取得」のすべての測定値 (SnapStart が有効でプライミング測定値の場合は Lambda 関数 GetProductByIdFunction および GetProductByIdWithPrimingFunction) のケースをまとめてみましょう。

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

結論

この記事では、3 つのユースケースについて、DynamoDB データベースに接続する Lambda 関数のコールド スタート時間とウォーム スタート時間の測定値を比較しました。

• Lambda 関数で SnapStart が有効になっていない
• Lambda 関数で SnapStart が有効になっていますが、プライミング最適化は行われていません
• Lambda 関数で SnapStart が有効になっており、DynamoDB リクエストがプライミングされています

x86_64 アーキテクチャを使用すると、arm64 アーキテクチャと比較してすべてのコールド スタート時間とウォーム スタート時間が短縮されることがわかりました。しかし、arm64 アーキテクチャの Lambda の価格は x86_64 アーキテクチャ より 25% 安いため、非常に興味深いコストパフォーマンスのトレードオフが生じます。

3 つのユースケースすべてに対する測定値:

• arm64 アーキテクチャでの Lambda のコールド スタート時間は、x86_64 アーキテクチャと比較して、多くのパーセンタイルで 10 ～ 20% (非常にまれな場合にのみ 25 ～ 27%) 遅くなりました。
• arm64 アーキテクチャでの Lambda ウォーム スタート時間は、多くのパーセンタイルで、x86_64 アーキテクチャと比較して 5 ～ 10% 遅いだけでした。

したがって、このサンプル アプリケーションにとって arm64 アーキテクチャの選択は非常に合理的です。 arm64 アーキテクチャの SnapStart サポートは最近導入されたばかりなので、将来的にはパフォーマンスが向上することも期待されています。ユースケースに応じて独自の測定を行ってください。

記事の次の部分では、同じパフォーマンス測定を行いますが、Lambda メモリを 256 MB から 2048 MB の間の異なる値に設定し、結果を比較します。