翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
サーバーレス環境のクライアントドライバー接続を最適化する
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 サービスのエンドポイントに到達し、ロードバランサーに進み、認証と承認の後にCQLリクエストがストレージレイヤーに到達する方法を示す図。](images/keyspaces_bp-connections.png)
Amazon Keyspaces で接続を設定する方法
Amazon Keyspaces は、TCP接続ごとに 1 秒あたり最大 3,000 件のCQLクエリをサポートします。ドライバーが確立できる接続数に制限がないため、オーバーヘッド、トラフィックバースト、および負荷分散を改善するために、1 秒あたり 500 CQLリクエストのみを対象にすることをお勧めします。以下の手順に従って、ドライバーの接続がアプリケーションのニーズに合わせて正しく設定されていることを確認してください。
この数を増やすには、接続プールでドライバーが維持管理している各 IP アドレスの接続数の増加をおすすめします。
-
ほとんどの Cassandra ドライバーで、Cassandra までの接続プールが確立され、その接続プールでクエリのロードバランスが行われます。ほとんどのドライバーは、デフォルト動作で、エンドポイントごとに 1 本の接続を確立します。Amazon Keyspaces では 9 つのピア IP アドレスがドライバーに公開されているため、ほとんどのドライバーのデフォルト動作に従えば、接続数は 9 本になります。Amazon Keyspaces は、TCP接続CQLごとに 1 秒あたり最大 3,000 クエリをサポートしているため、デフォルト設定を使用するドライバーの最大CQLクエリスループットは 1 秒あたり 27,000 CQLクエリです。ドライバーのデフォルト設定を使用する場合、1 つの接続で 1 秒あたり 3,000 CQLクエリの最大CQLクエリスループットを超える処理が必要になる場合があります。その場合、
PerConnectionRequestExceeded
イベントが発生するおそれがあります。 PerConnectionRequestExceeded
イベントを回避するには、エンドポイントごとの追加接続を作成してスループットが分散するようにドライバーを設定する必要があります。Amazon Keyspaces のベストプラクティスとして、各接続が 1 秒あたり 500 CQLクエリをサポートできると仮定します。
つまり、9 つの利用可能なエンドポイントに分散された 1 秒あたり推定 27,000 件のCQLクエリをサポートする必要がある本番アプリケーションでは、エンドポイントごとに 6 つの接続を設定する必要があります。これにより、各接続が 1 秒あたり 500 件以下のリクエストを処理できます。
アプリケーションのニーズに基づいて、ドライバーに設定する必要がある IP アドレスごとの接続数を計算します。
アプリケーションのエンドポイントごとに設定が要な接続数を決定するため、次の例で考えてみましょう。アプリケーションには、10,000、5,000INSERT
、5,000 DELETE
オペレーションで構成される 1 秒あたり 20,000 SELECT
件のCQLクエリをサポートする必要があります。Java アプリケーションは、Amazon Elastic Container Service (Amazon ECS) の 3 つのインスタンスで実行されており、各インスタンスは Amazon Keyspaces への 1 つのセッションを確立します。ドライバーに設定する必要がある接続数を推定できる計算では、次の入力を使用します。
アプリケーションがサポートする必要がある 1 秒あたりのリクエスト数。
利用可能なインスタンスの数を、メンテナンスや障害を考慮して 1 つ減らした数です。
利用可能なエンドポイント数。パブリックエンドポイント経由で接続している場合、利用可能なエンドポイントは 9 つになります。VPC エンドポイントを使用している場合は、リージョンに応じて 2~5 つのエンドポイントを使用できます。
Amazon Keyspaces のベストプラクティスとして、接続ごとに 1 秒CQLあたり 500 クエリを使用します。
結果は切り上げてください。
この例では、計算式は次のようになります。
20,000 CQL queries / (3 instances - 1 failure) / 9 public endpoints / 500 CQL queries per second = ROUND(2.22) = 3
この計算から、このドライバー設定ではエンドポイントごとに 3 本のローカル接続を指定する必要があります。リモート接続の場合は、エンドポイントごとに 1 本のみの接続を設定します。
Amazon Keyspaces のVPCエンドポイント経由で接続を設定する方法
プライベートVPCエンドポイント経由で接続する場合、3 つのエンドポイントが使用可能である可能性が最も高くなります。VPC エンドポイントの数は、アベイラビリティーゾーンの数と、割り当てられた 内のサブネットの数に基づいて、リージョンごとに異なる場合がありますVPC。米国東部 (バージニア北部) リージョンには 5 つのアベイラビリティーゾーンがあり、最大 5 つの Amazon Keyspaces エンドポイントを設定できます。米国西部 (北カリフォルニア) リージョンには 2 つのアベイラビリティーゾーンがあり、最大 2 つの Amazon Keyspaces エンドポイントを使用できます。エンドポイントの数は規模には影響しませんが、ドライバー設定で確立する必要のある接続数は増えます。次の例を考えます。アプリケーションは 20,000 件のCQLクエリをサポートしている必要があり、ECS各インスタンスが Amazon Keyspaces への 1 つのセッションを確立する Amazon の 3 つのインスタンスで実行されています。唯一の違いは、異なる で使用できるエンドポイントの数です 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 アカウント、Amazon Keyspaces エンドポイントは 1 つだけ表示される可能性があります。繰り返しますが、これは 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 の 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 本のアクティブな接続が表示されています。
![VPC エンドポイントを通過する接続の Cloudwatch ダッシュボードのメトリクスを示すスクリーンショット。使用されるメトリクスは ActiveConnections および です BytesProcessed。](images/keyspaces_bp_cw.png)
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 が用意した再試行ポリシーを使用できます。この再試行ポリシーは、同じエンドポイントですが、異なる接続間で再試行します。
での Java のエクスポネンシャル再試行ポリシーの例は、Amazon Keyspaces Java コード例