AWS SDK for Java を使用した Amazon Aurora サーバーレスのデータ API - コールド スタートとウォーム スタートの部分最適化戦略

導入

Data API と AWS SDK for Java を使用して Lambda 関数から Amazon Aurora Serverless v2 に接続する方法に関するシリーズの前の記事では、基本的なコールド スタートとウォーム スタートの測定を行い、Data API と JDBC の間のコールド スタートとウォーム スタートを比較しました。プライミングありとプライミングなしのスナップスタートの効果を測定しました。

シリーズのこのパートでは、コールド スタートとウォーム スタートの最適化戦略を紹介します。

コールド スタートとウォーム スタートの最適化戦略

コールド スタート時間とウォーム スタート時間の適切なバランスを見つけるには、以下で紹介する最適化手法を試すことができます。 PostgreSQL データベースで Data API と Amazon Aurora Serverless v2 を使用するものでは測定を行っていませんが、代わりに DynamoDB データベースを使用する同様のシナリオでは測定を行っていません。関連記事への参照を提供します。

• さまざまな Lambda メモリ設定を試してください。これまでのすべての測定は、Lambda 関数用に 1024 MB のメモリを使用して実行されました。メモリ設定を変えると、正当な価格でパフォーマンスが向上する可能性があります。 DynamoDB での測定の説明については、記事「異なる Lambda メモリ設定を使用した Java 21 でのコールド スタートとウォーム スタートとデプロイメント時間の測定」を参照してください。
• Lambda 関数のさまざまな Java コンパイル オプションを試してください。これまでの測定はすべて、Lambda 関数のコンパイル オプション「-XX:+TieredCompilation -XX:TieredStopAtLevel=1」を使用して実行されました。 JAVA_TOOL_OPTIONS と呼ばれる環境変数を使用して Lambda 関数に提供できるオプションは他にもあり、コールド スタートとウォーム スタートの異なるトレードオフを持つことができます。 DynamoDB での測定の説明については、記事「Java 21 でのさまざまなコンパイル オプションを使用したコールド スタートとウォーム スタートの測定」を参照してください。
• さまざまな同期 HTTP クライアントを試して、Data API 経由でデータベースへの HTTP 接続を確立します。これまでのすべての測定は、デフォルトの同期 HTTP クライアントである Apache を使用して実行されました。 UrlConnection や AWS CRT HTTP クライアントなど、コールド スタートとウォーム スタートで異なるパフォーマンスのトレードオフを提供するオプションもあります。

これは、RdsDataClient を作成/構築するときに AWS CRT HTTP クライアントを使用する例です。 URLConnectionクライアントも同様に設定できます。

RdsDataClient.builder().httpClient(AwsCrtHttpClient.create()).build()

次のように、使用中の HTTP クライアントへの依存関係を pom.xml に含めることも忘れないでください。

     <dependency>
        <groupId>software.amazon.awssdk</groupId>
        <artifactId>aws-crt-client</artifactId>
     </dependency>

説明、コード例、DynamoDB での測定については、記事「さまざまな同期 HTTP クライアントを使用した Java 21 でのコールド スタートとウォーム スタートの測定」を参照してください。

• Data API の非同期 HTTP クライアントがユースケースのオプションであるかどうかを確認してください。デフォルトの非同期 HTTP クライアントは NettyNio です。コールド スタートとウォーム スタートに対して異なるパフォーマンス トレードオフを提供する AWS CRT 非同期 HTTP クライアントという別のオプションもあります。

これは、RdsDataAsyncClient (非同期 HTTP クライアントを使用する場合に構築する必要があります) を作成/構築するときに、非同期 AWS CRT HTTP クライアントを使用する例です。

RdsDataAsyncClient.builder().httpClient(AwsCrtAsyncHttpClient.create()).build()

次のように、使用中の HTTP クライアントへの依存関係を pom.xml に含めることも忘れないでください。

     <dependency>
        <groupId>software.amazon.awssdk</groupId>
        <artifactId>aws-crt-client</artifactId>
     </dependency>

この場合、Java 非同期プログラミング モデル (これ自体が議論のトピックです) を使用する必要があるため、RDSDataAsyncClient での各メソッド呼び出しは Java CompletableFuture オブジェクトを返します。説明、コード例、DynamoDB での測定については、記事「さまざまな非同期 HTTP クライアントを使用した Java 21 でのコールド スタートとウォーム スタートの測定」を参照してください。

すべての潜在的な最適化戦略について、Lambda 関数で SnapStart を有効にし、前の記事「Data API とシリーズの SnapStart の出会い」で説明したように、DynamoDB 呼び出しプライミングの影響をさらに測定できます。

私の記事で説明したコールド スタートに対するスナップショット階層型キャッシュの影響にも注意してください。私はいつも、新しいバージョンの Lambda 関数をデプロイした後の最初 100 回のコールド スタートのコールド スタート測定を提供します。階層化キャッシュを使用すると、後続の呼び出しが増えるにつれてコールド スタートが大幅に減少することを測定して説明しました。一定量の呼び出しの後、特定の Lambda バージョンでは一定のままになります。

結論

この記事では、Data API for Amazon Aurora Serverless v2 と AWS SDK for Java を使用したコールド スタートとウォーム スタートの最適化戦略を提供しました。これを検討して、独自のユースケースに最適なパフォーマンスを見つけることができます。

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