Java xvs arm を使用した AWS Lambda のパフォーマンス - 一部の初期測定

導入

これまで、arm64 アーキテクチャの一部のユースケース (DynamoDB リクエストの実行など) では、SnapStart がサポートされていなかったため、Java 21 ランタイムを使用した Lambda 関数のパフォーマンス (ウォーム スタート時間とコールド スタート時間) を測定していませんでした。 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 の間の異なる値に設定して同じパフォーマンス測定を実行し、結果を比較します。

以上がJava xvs arm を使用した AWS Lambda のパフォーマンス - 一部の初期測定の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。