ApsaraDB RDS:コネクションプーリングの設定

接続プールのタイプを選択

ApsaraDB RDS for MySQL では、2 種類の接続プールタイプが提供されています。ワークロードに最も適したタイプを選択するため、以下の質問をご確認ください。

接続はセッション全体にわたって維持されますか、それとも短時間接続ですか？

• 永続接続（Druid、DBCP、c3p0、HikariCP などの組み込みプールを持つ Web フレームワーク）：コネクションプーリングを無効化します。この場合、プロキシによる追加価値はなく、アプリケーションレベルのプールで十分です。

• 短時間接続（PHP スクリプト、サーバーレス関数、リクエストごとに接続を確立するパターン）：コネクションプーリングを有効化し、以降の手順に進んでください。

インスタンスの接続制限に達していますか、あるいはワークロードでトランザクションレベルの制限のいずれかが適用されていますか？

デフォルトでは、コネクションプーリングは無効化されています。接続プールのタイプを変更した場合、その変更は新規接続にのみ適用されます。

制限事項

以下の表では、各プールモードでサポートされる操作および機能を比較しています。タイプを選択する前に、これらの内容をご確認ください。

データベースプロキシのバージョン V1.13.11 以降の場合：

SELECT FOUND_ROWS() を SELECT SQL_CALC_FOUND_ROWS * FROM t1 LIMIT * の後に実行すると、正確な結果が返されます。ただし、このパターンは MySQL では推奨されていません。代わりに SELECT COUNT(*) FROM tb1 を使用してください。詳細については、「FOUND_ROWS()」をご参照ください。

SELECT LAST_INSERT_ID() を INSERT 文の後に実行すると、正確な結果が返されます。

接続がロックされた場合（上記の操作によってトリガーされる）、その接続は明示的に閉じられるまでプールに戻すことができません。実質的に、その接続のライフタイム中は、セッションレベルのプーリングと同様の動作になります。

セッションレベル変数の使用に関する注意事項：トランザクションレベルの接続プーリングでは、リクエスト内の以下の変数が一致するようにマッチングされます：sql_mode、character_set_server、collation_server、および time_zone。リクエストにその他のセッションレベルのシステム変数が含まれる場合、接続確立後にクライアント側で明示的に SET 文を実行して、これらの変数を構成する必要があります。そうしないと、システム変数が再構成された接続がプールから選択・再利用される可能性があります。

仕組み

データベースプロキシは、各接続を 2 つのセグメントに分割します。1 つはアプリケーションとプロキシ間のフロントエンド接続、もう 1 つはプロキシとデータベース間のバックエンド接続です。

トランザクションレベルの接続プーリング

複数のセッションが単一のバックエンド接続を共有します。クライアントが接続しても、プロキシは直ちにバックエンド接続を開きません。代わりに、トランザクションの実行準備が整った時点で、プールから利用可能なバックエンド接続を選択します。

バックエンド接続が利用可能であるとは、その user および dbname の値が指定されたシステム変数の値と一致することを意味します。

• 一致する接続が存在する場合、プロキシはそれを使用します。トランザクションが完了すると、プロキシは接続をプールに戻しますが、セッションは終了せずに継続できます。

• 一致する接続が存在しない場合、プロキシは新しい接続を開きます。

アイドル状態のセッションはバックエンド接続を保持しないため、多数の進行中のセッションが少数のバックエンド接続を多重化できます（N セッション : 1 バックエンド接続）。これにより、接続確立頻度およびオープン状態の接続総数の両方が削減されます。

データベースプロキシは、接続数に厳密な上限を設けていません。最大値は、ご利用の ApsaraDB RDS インスタンスの仕様によって決定されます。

セッションレベルの接続プーリング

1 つのセッションが 1 つのバックエンド接続を占有します（N セッション : N バックエンド接続）。セッション開始時に、プロキシはプール内で利用可能なバックエンド接続を検索します。

バックエンド接続が利用可能であるとは、その user、clientip、および dbname の値がすべて一致することを意味します。

• 一致する接続が存在する場合、プロキシはそれを再利用し、ハンドシェイクのオーバーヘッドを回避します。

• 一致する接続が存在しない場合、プロキシは新しい接続を開きます。

セッションが終了すると、プロキシはバックエンド接続をプールに戻し、次のセッションで再利用できるようにします。これにより、接続確立のオーバーヘッドが削減されますが、オープン状態の接続総数は削減されません。

セッションがアクティブな間は、そのバックエンド接続は他のセッションで使用できません。たとえステートメント間でセッションがアイドル状態であっても同様です。

注意事項

• IP 固有のアカウント権限: 接続プーリングでは、アカウントの IP ごとの権限はサポートされていません。アカウントがソース IP によって異なる権限を持つ場合（例：192.xx.xx.1 からの database_a へのアクセスは可能ですが、192.xx.xx.2 からはできません）、既存の接続が再利用されたときに権限エラーが発生する可能性があります。

• アプリケーションレベルのプール：プロキシのコネクションプーリングは、アプリケーションレベルのプール（Druid、DBCP、c3p0、HikariCP）と干渉しません。アプリケーションが既に独自のプールを管理している場合、プロキシレベルでのコネクションプーリングを有効にする必要はありません。

• 遅延クエリ：コネクションプーリングは、遅延 SQL クエリによって引き起こされる接続の蓄積を解決しません。クエリを最適化するか、インスタンスレベルで問題を特定・解決してください。

• プロキシのバージョンおよびエンドポイントタイプ：バージョン 2.9.1 より前のプロキシでは、読み取り専用エンドポイントでのコネクションプーリングはサポートされていません。バージョン 2.9.1 以降では、読み書きエンドポイントおよび読み取り専用エンドポイントの両方でコネクションプーリングがサポートされます。

• wait_timeout の動作：トランザクションレベルの接続プーリングが有効な場合、wait_timeout パラメーターがクライアントで効果を発揮しない場合があります。プロキシは各リクエストごとにプールから接続を選択します。wait_timeout が経過すると、バックエンド接続のみが閉じられ、クライアント側の接続は開いたままになります。

• 接続の再利用検出：SELECT CONNECTION_ID() を実行して現在のスレッド ID を取得します。同一クライアントセッション内のリクエスト間でスレッド ID が変化する場合、接続がプールから再利用されていることを意味します。

• SHOW PROCESSLIST の動作：トランザクションレベルの接続プーリングが有効な場合、フロントエンドのスレッド ID とバックエンドのスレッド ID は異なります。このため、プロセスが正常に終了した後でも KILL コマンドがエラーを返すことがあります。プロセスの状態を確認するには、再度 SHOW PROCESSLIST を実行してください。また、プロキシは、すべてのプライマリ、セカンダリ、および読み取り専用インスタンスからの結果を集約してから、アプリケーションに返します。SHOW PROCESSLIST または SQL Explorer および Audit 機能に表示される IP アドレスおよびポートは、実際のクライアントアドレスと異なる場合があります。詳細については、「SQL Explorer および Audit 機能の使用」をご参照ください。

コネクションプーリングの有効化

よくある質問

プールには最大で何接続まで保持できますか？

プール自体には固定の上限はありません。アプリケーションがインスタンスの接続制限に近づいている場合、トランザクションレベルの接続プーリングを有効化することで、より少ないバックエンド接続上でセッションを多重化できます。

アイドル状態の接続は、プール内でどのくらいの期間保持されますか？

プール内の接続は、閉じられるまで 10 秒間生存します。

コネクションプーリングはパフォーマンスに影響を与えますか？

短時間接続のワークロードでは、コネクションプーリングを有効化することで、インスタンスのパフォーマンスが約 10 % 向上します。

トランザクションレベルのプーリングとセッションレベルのプーリングの違いは何ですか？

アプリケーションがプロキシから切断されました。これはコネクションプーリングが原因ですか？

必ずしもそうとは限りません。切断の原因は、切断時の具体的な状況に依存し、コネクションプーリングとは関係ない場合もあります。

API リファレンス