シリーズの記事パート 12 では、Spring Cloud Function AWS アプリケーションから作成された GraalVM 22 ランタイムを使用した GraalVM ネイティブ イメージを含むカスタム ランタイムを使用して Lambda 関数を開発およびデプロイする方法を検討しました。パート 13 では、1024 MB のメモリを備えたこのような Lambda 関数のパフォーマンス (コールド スタートとウォーム スタート) を測定しました。
この記事では、コストとパフォーマンスのトレードオフを調査するために、256 MB から 1536 MB までの異なるメモリ設定でこのアプローチを使用して Lambda 関数のパフォーマンス (コールド スタートとウォーム スタート) を測定します。
この記事シリーズのパート 13 で説明したのとまったく同じ実験を再利用しますが、メモリ設定は 256 MB から 1536 MB の間で異なります。
実験の結果は次のとおりです:
コールド (c) およびウォーム (m) の開始時間 (ミリ秒):
Memory setting | 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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|
256 MB | 1634.84 | 1659.54 | 1691.35 | 1778.03 | 1785.15 | 1785.7 | 6.56 | 6.99 | 7.63 | 18.33 | 372.54 | 857.7 |
512 MB | 1244.44 | 1278.48 | 1313.45 | 1414.28 | 1421.36 | 1421.94 | 6.66 | 7.10 | 7.94 | 25.41 | 181.86 | 414.99 |
768 MB | 1111.53 | 1126.07 | 1139.66 | 1192.08 | 1202.86 | 1203.07 | 6.58 | 6.93 | 7.48 | 12.46 | 115.18 | 278.91 |
1024 MB | 1051.03 | 1061.58 | 1080.86 | 1119.34 | 1149.45 | 1230.28 | 6.45 | 6.77 | 7.33 | 12.50 | 90.92 | 218.17 |
1280 MB | 1022.02 | 1035.39 | 1058.41 | 1065.76 | 1104.64 | 1174.79 | 6.58 | 6.96 | 7.54 | 12.37 | 70.77 | 271.13 |
1536 MB | 1009.83 | 1029.20 | 1048.41 | 1161.32 | 1116.24 | 1148.24 | 6.66 | 7.04 | 7.75 | 12.08 | 63.03 | 215.62 |
この記事では、パート 12 で紹介した Spring Cloud Function AWS アプリケーションから作成された GraalVM 21 ランタイムと GraalVM Native Image を含むカスタム ランタイムを使用し、256 ~ 1536 MB の異なるメモリ設定を持つ Lambda 関数のコールド スタートとウォーム スタートを測定しました。
記事「GraalVM ネイティブ イメージを使用した純粋な Lambda 関数 - 異なる Lambda メモリ設定を使用したコールド スタートとウォーム スタートの測定」で説明されているのと同様のことが観察されます。 ウォーム スタート時間は、256 MB や 512 MB などの低い Lambda 関数メモリ設定でも互いに非常に近く、主に高いパーセンタイルで違いが見られます (>= p90)。コールドスタート時間は、256 MB と 512 MB では非常に長く、768 MB のメモリから開始すると、Lambda に追加のメモリを与えることで少しだけ減少しますが、1024 MB を超えるメモリでは目立った違いはありません。 パフォーマンス要件に応じて、サンプル アプリケーションで最初に指定した 1024 MB よりも少ないメモリを Lambda に与えることができ、768 MB またはそれよりも少ないメモリで非常に優れた価格パフォーマンスのトレードオフを実現できます。
パート 13 の結論で説明したのと同じ観察結果も共有しました。コールド スタート時間を、記事「GraalVM ネイティブ イメージを使用した純粋な Lambda 関数 - 異なる Lambda メモリ設定を使用したコールド スタートとウォーム スタートの測定」で測定された時間と比較すると、(ここで、Lambda 関数は Spring Boot などのフレームワークを使用しません)、純粋な Lambda 関数を使用すると、各パーセンタイルの値が約 0.5 ~ 0.6 秒低くなります。個人的には、サンプル Spring Boot 3 アプリケーションには、コールド スタート時間の大きな違いを説明できないため、最適化の可能性があると考えています。私の (おそらく単純な) 予想は、AWS Lambda および GraalVM ネイティブ イメージで Spring Boot 3 フレームワークを使用すると、純粋な Lambda 関数の使用と比較して、コールド スタート時間が 0.2 ~ 0.3 増加するだけである可能性があるということです。
この記事の公開時点では、使用されているフレームワークとツールの新しいバージョン (GraalVM 23 ランタイム、Spring Boot 3.4、および Spring Cloud Function ライブラリのバージョン更新) が利用可能になっているため、バージョンを変更して GraalVM Native を再コンパイルする必要があります。シリーズのパート 2 の指示に従って画像を作成し、パフォーマンスを再測定します。また、これらのバージョンでの新しい測定結果を近々公開し、サンプル アプリケーションをアップグレードする予定です。
以上がAWS Lambda での Spring Boot アプリケーション - パート GraalVM ネイティブ イメージとメモリ設定を使用したコールド スタートとウォーム スタートの測定の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。