AWS SDK for Java を使用した Amazon Aurora サーバーレスのデータ API - コールド スタートとウォーム スタートの比較部分: データ API と DynamoDB

導入

シリーズ「Data API for Amazon Aurora Serverless v2 with AWS SDK for Java - Data API meets SnapStart」のパート 7 では、Data を使用して Amazon Aurora Serverless v2 PostgreSQL データベースに接続する Lambda 関数のコールド スタート時間とウォーム スタート時間を測定しました。 3 つのユースケース用の API :

• Lambda 関数で SnapStart が有効になっていない場合
• Lambda 関数で SnapStart が有効になっていますが、プライミング最適化は行われていません
• Lambda 関数で SnapStart を有効にし、プライミング最適化 (PostgreSQL データベースで SQL ステートメントの実行を事前にウォームアップ) を使用します。

この記事では、Amazon Aurora Serverless v2 の Data API の代わりに DynamoDB を使用した場合の測定値と比較したいと思います。

Lambda のコールド スタートとウォーム スタートの比較: Data API for Amazon Aurora Serverless v2 と DynamoDB

Lambda SnapStart に関する私の記事シリーズでは、同様のアプリケーションに対してこのような測定をすでに行っていますが、記事では「異なる Lambda メモリ設定を使用した Java 21 でのウォーム スタートの測定」を参照してください。

Amazon Aurora Serverless v2 の Data API と DynamoDB の両方のアプリケーションは非常に似ています:

• データベースに製品を保存および取得するためのロジックを提供します
• 両方のプロジェクトの Lambda 関数のメモリ設定は 1024 MB です
• デプロイメントアーティファクトのサイズはどちらも約 18 MB です
• 両方のプロジェクトの Lambda 関数は、デフォルトの同期 HTTP Apache クライアントを使用してデータベースと通信します
• 両方のプロジェクトの Lambda 関数は x86_64 アーキテクチャを使用します

次に、すべての測定値をまとめてみましょう。

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

Approach	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
Data API, no SnapStart enabled	3154.35	3237	3284.91	3581.49	3702.12	3764.92	104.68	173.96	271.32	572.11	1482.89	2179.7
DynamoDB, no SnapStart enabled	3157.6	3213.85	3270.8	3428.2	3601.12	3725.02	5.77	6.50	7.81	20.65	90.20	1423.63
Data API, SnapStart enabled without priming	1856.11	1994.61	2467.83	3229.11	3238.80	3241.75	61.02	113.32	185.37	639.35	1973.30	2878.5
DynamoDB, SnapStart enabled without priming	1626.69	1741.10	2040.99	2219.75	2319.54	2321.64	5.64	6.41	7.87	21.40	99.81	1355.09
Data API, SnapStart enabled with priming	990.84	1069.04	1634.84	2120.00	2285.03	2286.9	60.06	106.35	185.37	581.27	1605.37	2658.24
DynamoDB, SnapStart enabled with priming	702.55	759.52	1038.50	1169.66	1179.05	1179.36	5.73	6.51	7.87	21.75	92.19	328.41

結論

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

• Lambda 関数で SnapStart が有効になっていない場合
• Lambda 関数で SnapStart が有効になっていますが、プライミング最適化は行われていません
• Lambda 関数で SnapStart を有効にし、データベースリクエストをプライミングした状態

私たちが観察したことは、Lambda 関数で SnapStart を有効にしない場合のコールド スタート時間は、両方でかなり同等であるということです。 SnapStart が有効になっている場合 (プライミングなし、特にプライミングあり)、Data API for Amazon Aurora Serverless v2 のコールドスタート時間は、特にパーセンタイル >= 90 の場合に大幅に長くなります。私はこの違いを理解するためにさらに深く調べる必要があります。特にプライミングが適用されている場合は、それほど大きくなるとは予想できません。おそらくその理由は、DynamoDB のような AWS ネイティブ サービスが SnapStart をより認識しており、接続の再開をより適切に処理できるためです。

DynamoDB は 1 桁または 2 桁のミリ秒の応答時間で知られているため、DynamoDB と比較して Data API for Amazon Aurora Serverless v2 のウォーム スタート (実行) 時間は常にはるかに長かったです。

以上がAWS SDK for Java を使用した Amazon Aurora サーバーレスのデータ API - コールド スタートとウォーム スタートの比較部分: データ API と DynamoDBの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。