サーバーレス環境のクライアントドライバー接続を最適化する

Amazon Keyspaces との通信には、既存の任意の Apache Cassandra クライアントドライバーを使用できます。Amazon Keyspaces はサーバーレスサービスなので、アプリケーションのスループットニーズに合わせてクライアントドライバーの接続設定を最適化することをおすすめします。このトピックでは、アプリケーションに必要な接続数の計算方法や、接続のモニタリングやエラー処理などのベストプラクティスを紹介します。

Amazon Keyspaces における接続の働き

このセクションでは、Amazon Keyspaces におけるクライアントドライバー接続の働きの概要を説明します。Cassandra クライアントドライバーの設定を誤ると Amazon Keyspaces で PerConnectionRequestExceeded イベントが発生するおそれがあるので、これらのエラーや同様の接続エラーを回避するため、クライアントドライバー設定で適切な接続数を設定する必要があります。

Amazon Keyspaces に接続する場合、ドライバーには初期接続を確立するためのシードエンドポイントが必要です。Amazon Keyspaces はDNS、 を使用して、利用可能な多数のエンドポイントの 1 つに初期接続をルーティングします。エンドポイントはネットワークロードバランサーにアタッチされ、フリート内のリクエストハンドラーの 1 つとの接続がロードバランサーによって確立されます。最初の接続が確立すると、クライアントドライバーは利用可能なすべてのエンドポイントに関する情報を system.peers テーブルから収集します。この情報から、クライアントドライバーはリストされたエンドポイントとの追加の接続を作成できます。クライアントドライバーが作成できる接続数は、クライアントドライバー設定で指定されたローカル接続数が上限になります。デフォルトでは、ほとんどのクライアントドライバーが、エンドポイントごとに 1 つの接続を確立し、Cassandra までの接続プールを確立し、その接続プールに対してクエリのロードバランスを行います。同じエンドポイントに複数の接続を確立できますが、ネットワークロードバランサーの背後では、それらの接続は、さまざまなリクエストハンドラーにつながっている場合があります。パブリックエンドポイント経由で接続するとき、system.peers テーブルに記載された 9 つのエンドポイントのそれぞれに 1 つの接続を確立すると、異なるリクエストハンドラーに対して 9 つの接続が作成されます。

Amazon Keyspaces で接続を設定する方法

Amazon Keyspaces は、TCP接続ごとに 1 秒あたり最大 3,000 件のCQLクエリをサポートします。ドライバーが確立できる接続数に制限がないため、オーバーヘッド、トラフィックバースト、ロードバランシングの向上を可能にするために、接続ごとに 1 秒あたり 500 個のCQLリクエストのみをターゲットにすることをお勧めします。以下の手順に従って、ドライバーの接続がアプリケーションのニーズに合わせて正しく設定されていることを確認してください。

この数を増やすには、接続プールでドライバーが維持管理している各 IP アドレスの接続数の増加をおすすめします。

• ほとんどの Cassandra ドライバーで、Cassandra までの接続プールが確立され、その接続プールでクエリのロードバランスが行われます。ほとんどのドライバーは、デフォルト動作で、エンドポイントごとに 1 本の接続を確立します。Amazon Keyspaces では 9 つのピア IP アドレスがドライバーに公開されているため、ほとんどのドライバーのデフォルト動作に従えば、接続数は 9 本になります。Amazon Keyspaces はTCP、接続あたり 1 秒あたり最大 3,000 CQLクエリをサポートするため、デフォルト設定を使用するドライバーの最大CQLクエリスループットは 1 秒あたり 27,000 CQLクエリです。ドライバーのデフォルト設定を使用する場合、1 つの接続で 1 秒あたり最大CQLクエリスループットである 3,000 を超えるCQLクエリを処理する必要がある場合があります。その場合、PerConnectionRequestExceeded イベントが発生するおそれがあります。

• PerConnectionRequestExceeded イベントを回避するには、エンドポイントごとの追加接続を作成してスループットが分散するようにドライバーを設定する必要があります。

• Amazon Keyspaces のベストプラクティスとして、各接続が 1 秒あたり 500 件のCQLクエリをサポートできると仮定します。

• つまり、9 つの利用可能なエンドポイントに分散された 1 秒あたり推定 27,000 件のCQLクエリをサポートする必要がある本番アプリケーションでは、エンドポイントごとに 6 つの接続を設定する必要があります。これにより、各接続が 1 秒あたり 500 件以下のリクエストを処理できます。

アプリケーションのニーズに基づいて、ドライバーに設定する必要がある IP アドレスごとの接続数を計算します。

アプリケーションのエンドポイントごとに設定が要な接続数を決定するため、次の例で考えてみましょう。10,000、5,000INSERT、5,000 DELETEオペレーションで構成される SELECT1 秒あたり 20,000 CQLクエリをサポートする必要があるアプリケーションがあります。Java アプリケーションは、Amazon Elastic Container Service (Amazon ECS) 上の 3 つのインスタンスで実行され、各インスタンスは Amazon Keyspaces への 1 つのセッションを確立します。ドライバーに設定する必要がある接続数を推定できる計算では、次の入力を使用します。

1. アプリケーションがサポートする必要がある 1 秒あたりのリクエスト数。

2. 利用可能なインスタンスの数を、メンテナンスや障害を考慮して 1 つ減らした数です。

3. 利用可能なエンドポイント数。パブリックエンドポイント経由で接続している場合、利用可能なエンドポイントは 9 つになります。VPC エンドポイントを使用している場合は、リージョンに応じて 2～5 つのエンドポイントを使用できます。

4. Amazon Keyspaces のベストプラクティスとして、接続ごとに 1 秒あたり 500 件のCQLクエリを使用します。

5. 結果は切り上げてください。

この例では、計算式は次のようになります。

20,000 CQL queries / (3 instances - 1 failure) / 9 public endpoints / 500 CQL queries per second = ROUND(2.22) = 3 

この計算から、このドライバー設定ではエンドポイントごとに 3 本のローカル接続を指定する必要があります。リモート接続の場合は、エンドポイントごとに 1 本のみの接続を設定します。

Amazon Keyspaces の接続の再試行ポリシーを設定する方法

Amazon Keyspaces への接続の再試行ポリシーを設定するときは、Amazon Keyspaces の再試行ポリシー を実装することをお勧めしますAmazonKeyspacesExponentialRetryPolicy。この再試行ポリシーは、ドライバーの とは異なる Amazon Keyspaces への接続間で再試行するのに適していますDefaultRetryPolicy。

ではAmazonKeyspacesExponentialRetryPolicy、ニーズを満たす接続の再試行回数を設定できます。デフォルトでは、 の再試行回数AmazonKeyspacesExponentialRetryPolicyは 3 に設定されています。

もう 1 つの利点は、Amazon Keyspaces の再試行ポリシーが、リクエストの試行が失敗した理由を示す、サービスから返された元の例外を返すことです。デフォルトの再試行ポリシーは汎用 のみを返します。これによりNoHostAvailableException、リクエストの失敗に関するインサイトが非表示になる可能性があります。

を使用してリクエスト再試行ポリシーを設定するにはAmazonKeyspacesExponentialRetryPolicy、少数の再試行を設定し、アプリケーションコードで返された例外を処理することをお勧めします。

再試行ポリシーを実装するコード例については、Github の Amazon Keyspaces 再試行ポリシーを参照してください。

Amazon Keyspaces のVPCエンドポイント経由で接続を設定する方法

プライベートVPCエンドポイント経由で接続する場合、3 つのエンドポイントが利用できる可能性が最も高いです。VPC エンドポイントの数は、アベイラビリティーゾーンの数と、割り当てられた 内のサブネットの数に基づいて、リージョンごとに異なる場合がありますVPC。米国東部 (バージニア北部) リージョンには 5 つのアベイラビリティーゾーンがあり、最大 5 つの Amazon Keyspaces エンドポイントを設定できます。米国西部 (北カリフォルニア) リージョンには 2 つのアベイラビリティーゾーンがあり、最大 2 つの Amazon Keyspaces エンドポイントを使用できます。エンドポイントの数は規模には影響しませんが、ドライバー設定で確立する必要のある接続数は増えます。次の例を考えます。アプリケーションは 20,000 件のCQLクエリをサポートする必要があります。Amazon の 3 つのインスタンスで実行され、各インスタンスECSが Amazon Keyspaces への 1 つのセッションを確立します。唯一の違いは、異なる で使用できるエンドポイントの数です AWS リージョン。

米国東部 (バージニア北部) リージョンで必要な接続数:

20,000 CQL queries / (3 instances - 1 failure) / 5 private VPC endpoints / 500 CQL queries per second = 4 local connections

米国西部 (北カリフォルニア) リージョンで必要な接続数:

20,000 CQL queries / (3 instances - 1 failure) / 2 private VPC endpoints / 500 CQL queries per second = 10 local connections

重要

プライベートVPCエンドポイントを使用する場合、Amazon Keyspaces が利用可能なVPCエンドポイントを動的に検出し、system.peersテーブルに入力するには、追加のアクセス許可が必要です。詳細については、「インターフェイス VPC エンドポイント情報を含む system.peers テーブルエントリの入力」を参照してください。

別の を使用してプライベートVPCエンドポイントから Amazon Keyspaces にアクセスする場合 AWS アカウント、1 つの Amazon Keyspaces エンドポイントしか表示されない可能性があります。繰り返しますが、これは Amazon Keyspaces へのスループットの規模には影響しませんが、場合によっては、ドライバー設定の接続数を増やす必要があります。この例では、使用可能な 1 つのエンドポイントに同じ計算を行っています。

20,000 CQL queries / (3 instances - 1 failure) / 1 private VPC endpoints / 500 CQL queries per second = 20 local connections

共有 を使用した Amazon Keyspaces へのクロスアカウントアクセスの詳細についてはVPC、「」を参照してください共有のVPCエンドポイントを使用して Amazon Keyspaces へのクロスアカウントアクセスを設定する VPC。

Amazon Keyspaces で接続をモニタリングする方法。

アプリケーションが接続されているエンドポイントの数がすぐにわかるように、検出されたピアの数を system.peers テーブルに記録できます。次の例は、接続が確立されるとピア数を出力する Java コードの例です。

ResultSet result = session.execute(new SimpleStatement("SELECT * FROM system.peers"));

logger.info("number of Amazon Keyspaces endpoints:" + result.all().stream().count());

注記

CQL コンソールまたは AWS コンソールは 内にデプロイされないためVPC、パブリックエンドポイントを使用します。その結果、 の外部にあるアプリケーションからsystem.peersクエリを実行すると、VPCE多くの場合、9 つのピアになります。このとき、各ピアの IP アドレスを印刷しておくと役立つ場合があります。

VPCE Amazon CloudWatch メトリクスを設定することで、VPCエンドポイントを使用する際にピアの数を確認することもできます。では CloudWatch、VPCエンドポイントに確立された接続の数を確認できます。Cassandra ドライバーは、各エンドポイントの接続を確立してCQLクエリを送信し、コントロール接続を確立してシステムテーブル情報を収集します。次の図は、ドライバー設定で 1 つの接続を設定して Amazon Keyspaces に接続した後のVPCエンドポイント CloudWatch メトリクスを示しています。このメトリクスには、1 本のコントロール接続と 5 本の接続 (アベイラビリティーゾーン全体でエンドポイントごとに 1 つ) からなる 6 本のアクティブな接続が表示されています。

CloudWatch グラフを使用して接続数のモニタリングを開始するには、Amazon Keyspaces AWS CloudFormation テンプレートリポジトリで で使用できる GitHub このテンプレートをデプロイします。 https://github.com/aws-samples/amazon-keyspaces-cloudwatch-cloudformation-templates

Amazon Keyspaces での接続エラーの処理方法

接続あたりのリクエストが 3,000 件を超えると、Amazon Keyspaces は PerConnectionRequestExceeded イベントを返し、Cassandra ドライバーは WriteTimeout 例外や ReadTimeout 例外を受け取ります。その場合は、Cassandra の再試行ポリシーまたはアプリケーションで、指数バックオフを設定してこの例外を再試行してください。このとき、追加のリクエストを送信しないように、指数バックオフを設定する必要があります。

デフォルト再試行ポリシーでは、クエリプランの try next host の再試行が試みられます。Amazon Keyspaces はエンドポイントに接続するときに 1～3 つの利用可能なVPCエンドポイントを持つ可能性があるため、アプリケーションログに WriteTimeoutおよび のReadTimeout例外NoHostAvailableExceptionに加えて、 が表示される場合があります。Amazon Keyspaces が用意した再試行ポリシーを使用できます。この再試行ポリシーは、同じエンドポイントですが、異なる接続間で再試行します。

Amazon Keyspaces Java コード例リポジトリで、 での GitHub Java のエクスポネンシャル再試行ポリシーの例を確認できます。 https://github.com/aws-samples/amazon-keyspaces-java-driver-helpers/blob/main/src/main/java/com/aws/ssa/keyspaces/retry/AmazonKeyspacesExponentialRetryPolicy.javaその他の言語サンプルは、Github の Amazon Keyspaces コード例リポジトリにあります。