サーバーレス環境のクライアントドライバー接続を最適化する - Amazon Keyspaces (Apache Cassandra 向け)
働き接続を設定する方法再試行ポリシーを設定する方法VPC エンドポイント接続接続をモニタリングする方法接続エラーの処理方法

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

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

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

Amazon Keyspaces における接続の働き

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

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

ドライバーによって確立された接続がまず Amazon Keyspaces サービスのエンドポイントに到達し、ロードバランサーに進み、認証と認可を経て CQL リクエストがストレージレイヤーに到達する様子を示した図。

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

Amazon Keyspaces は、TCP 接続 1 つにつき 1 秒あたり最大 3,000 の CQL クエリに対応しています。ドライバーが確立できる接続数には制限がないため、オーバーヘッド、トラフィックバースト、負荷分散を考慮して、1 接続あたり 1 秒あたり 500 件の CQL リクエストのみを目標にすることをおすすめします。以下の手順に従って、ドライバーの接続がアプリケーションのニーズに合わせて正しく設定されていることを確認してください。

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

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

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

  • Amazon Keyspaces のベストプラクティスとしては、各接続でサポートできる想定 CQL クエリ数を毎秒 500 件としています。

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

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

アプリケーションのエンドポイントごとに設定が要な接続数を決定するため、次の例で考えてみましょう。例えば、10,000INSERT、5,000SELECT、5,000DELETE 件の操作からなる、1 秒あたり 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 Keyspaces へのセッションが 1 件確立される Amazon ECS 上の 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 テーブルに入力するには、Amazon Keyspaces には追加の権限が必要です。詳細については、「インターフェイス VPC エンドポイント情報を含む system.peers テーブルエントリの入力」を参照してください。

別の VPC エンドポイントを使用してプライベート 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

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

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

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

VPC エンドポイントを通過する接続のメトリクスが Cloudwatch ダッシュボードに表示されているスクリーンショット。使用されているメトリクスは ActiveConnections と BytesProcessed です。

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 には VPC エンドポイントの接続に使用できるエンドポイントが 1 ～ 3 つあるため、アプリケーションログには NoHostAvailableException 以外に WriteTimeout 例外と ReadTimeout 例外も表示される場合があります。Amazon Keyspaces が用意した再試行ポリシーを使用できます。この再試行ポリシーは、同じエンドポイントですが、異なる接続間で再試行します。

GitHub の Java の指数再試行ポリシーの例は、Amazon Keyspaces Java コード例リポジトリにあります。その他の言語サンプルは、Github の Amazon Keyspaces コード例リポジトリにあります。