接続プール

このトピックでは、Bigtable での接続プールの仕組み、Bigtable を使用するアプリケーションに接続プールのサイズが与える影響、デフォルトの接続プール設定の変更が必要な場合について説明します。

このページを読んだ後、接続プールサイズを変更する必要があると判断した場合は、接続プールの構成を参照して、最適なサイズを決定する方法と変更方法を確認してください。各プールの接続数は、Cloud Bigtable 用の Go、C++、または Java クライアント ライブラリを使用する場合にのみ、コードで構成できます。

接続プールの仕組み

接続プール（チャネルプールとも呼ばれます）は、接続レイテンシとパフォーマンスを向上させるために共有され、再利用されるデータベース接続のキャッシュです。接続はラウンドロビン システムで使用されます。

Bigtable を使用する場合、アプリケーション プロセスごとに 1 つのデータ クライアントを作成します。各クライアントには 1 つの接続プールがあります。各接続プールにはいくつかの gRPC 接続があり、それぞれが最大 100 個の同時実行ストリームを処理できます。これらの接続を介して送信されたリクエストは、Google ミドルウェアを経由してテーブルにルーティングされます。ミドルウェア レイヤは多数の負荷分散インスタンスで構成され、各リクエストは最も可用性の高いミドルウェア インスタンスを経由してルーティングされます。

接続（またはチャンネル）は、最大 100 車線の高速道路のように考えることができます。各車線（ストリーム）には、いつでも車（リクエスト）は 1 台だけが通ることができます。Google のミドルウェア レイヤでは、gRPC 接続あたりの同時ストリーム数の上限は 100 に制限され、この数を再構成することはできません。

接続は 1 時間ごとに自動的に更新されます。また、接続がリクエストに 5 分間反映されていない場合、ミドルウェアは接続を自動的に削除し、追加接続が必要になるまで再作成されません。

バックグラウンドで、各チャネルに 1 つのサブチャネルがあります。各サブチャネルには HTTP2 接続があり、TCP を使用してリクエストをバイトに変換し、ミドルウェアを介してテーブルに送信します。このプロセスは Bigtable サービスによってシームレスに処理されるため、何かを構成する必要はありません。

接続プールとトラフィック

接続プールがパフォーマンスに与える影響

理想的には、バッファリングなしでリクエストを処理するのに十分な gRPC 接続が必要です。しかし、使用頻度が低いために頻繁に破棄される接続はそれほど多くありません。

十分な接続がない場合

接続プールでトラフィックを処理するのに十分な接続がない場合、ミドルウェアはリクエストをバッファリングしてキューに入れます。このバッファリングによりトラフィックが遅くなり、1 秒あたりのリクエスト数が減り、リクエストがバックアップされ、レイテンシが増加します。

接続が多すぎる場合

プールの接続数が多すぎる場合（つまり、一部の接続がアイドル状態の場合）、ミドルウェアはアイドル状態の接続を切断します。その後、新しいリクエストが必要になると、新しい接続が再確立されます。つまり、トラフィックが増加すると、リクエストにサーバー側のキャッシュミスが発生し、余分な作業やレイテンシを引き起こす可能性があります。トラフィック レベルが変化するためにこれが頻繁に発生する場合、このアクティビティは、クライアント側で検知されたテール レイテンシの急上昇として現れます。

デフォルト設定を変更するタイミング

デフォルトの接続プールサイズはほとんどのアプリケーションに適しているため、ほとんどの場合、変更する必要はありません。アプリケーションで使用するクライアント ライブラリによっては、接続プールサイズを変更できないことがあります。各プールの接続数は、Cloud Bigtable 用の Go、C++、または Java クライアント ライブラリを使用する場合にのみ、コードで構成できます。

原則として、接続プールは最大の飽和状態に必要な接続数の少なくとも 2 倍が理想です。これにより、トラフィックの変動の余裕を持たせます。たとえば、4 つの接続があり、それぞれが処理できる最大リクエスト数が 100 件である場合、接続あたりのリクエスト数を 10～50 に減らすことで、理想的な接続プールサイズは、少なくとも 2 倍か、8 接続になります。

プール内の接続数を変更することを考慮すべきシグナルは次のとおりです。

低いスループット、クライアント側のテール レイテンシの上昇

一般的なスループットが非常に低い場合（接続ごとに 1 秒あたり 1 リクエスト未満など）、およびアプリケーションのテール レイテンシが定期的に高い場合は、接続を維持するのに十分なトラフィックを送信していない可能性があります。その場合、プール内の接続数を減らす必要があります。適切な数の決定方法については、接続プールの構成をご覧ください。

バッファリングされたリクエスト

クライアント側でリクエストがスタックしている場合は、接続プールが処理できる以上の同時リクエストを送信している可能性があります。最適な数を計算し、必要に応じてコードを変更してください。

リクエストがスタックしているかどうかを判断するには、OpenCensus を使用して grpc.io/client/started_rpcs と grpc.io/client/completed_rpcs の指標の違いを確認します。

仮想環境

まれに、Bigtable クライアントが、アプリケーションが実行されている CPU の数を判別できず、1 つの CPU のみが使用されているかのように接続を割り当てることがあります。たとえば、これは Kubernetes または Docker で仮想 CPU インスタンスを使用している場合などに発生します。この場合は、アプリケーションの QPS とレイテンシに基づいて、ガイドラインに沿ってプールの数を構成する必要があります。

次のステップ