コネクションプールの仕組み ― DBへの接続を使い回す技術

実はそれだとすごく遅いんだ。DB接続って裏側ではTCPの3ウェイハンドシェイク、SSL/TLSネゴシエーション、DBの認証処理…と何段階もの手続きが走るんだよ。1回の接続確立に10〜100ミリ秒かかることもある。リクエストのたびにこれをやってたら、1秒間に数百リクエスト来るWebアプリではボトルネックになっちゃうね。

そこで登場するのが「コネクションプール」だよ。あらかじめ何本かのDB接続を作っておいて、プールに入れておく。アプリが接続を使いたいときはプールから1本借りて、使い終わったらプールに返す。借りる・返すだけだから、毎回ゼロから接続を作るコストがなくなるんだ。図書館の本の貸し出しみたいなイメージだね。

プールの設定にはいくつか重要なパラメータがあるよ。まず「最小サイズ（minimumIdle）」はアイドル時でも維持する接続数。「最大サイズ（maximumPoolSize）」はプールが持てる接続の上限。他にも「アイドルタイムアウト」で使われていない接続を一定時間後に閉じたり、「最大ライフタイム（maxLifetime）」で接続を定期的に作り直してメモリリークやDB側のタイムアウトを防いだりするんだ。

Javaなら HikariCP が事実上の標準だね。Spring Bootのデフォルトにもなってる。PostgreSQLを使うチームなら PgBouncer という専用のコネクションプーラーを間に挟むことも多いよ。Goの database/sql パッケージにはプール機能が言語標準で組み込まれてる。どの技術でも「接続を使い回す」基本思想は同じだよ。

それが「プール枯渇（Pool Exhaustion）」と呼ばれる怖い状態だよ。新しいリクエストが来ても空き接続がないから、タイムアウトまで待たされる。最悪の場合、接続を借りたまま返さないコードがあると、プール内の接続が全部ロックされてデッドロック状態になる。1つのスロークエリが全体を巻き込んで障害になるケースもあるから、接続は必ず try-finally や using ブロックで確実に返却するのが鉄則だよ。

モニタリングが大事だね。見るべき指標は主に3つ。「アクティブ接続数」は今使われている接続、「アイドル接続数」はプールで待機中の接続、「待機スレッド数」は空き接続を待っている数だよ。待機スレッド数が増え始めたらプールサイズが足りないサイン。あとはスロークエリの検出も重要で、1本の遅いクエリが接続を長時間占有するとプール全体に波及するからね。

いい質問だね。サーバーレスはコネクションプールの天敵とも言える存在だよ。Lambda が同時に100個起動すると、それぞれがプールを作るから合計で数百〜数千のDB接続が一気に張られてしまう。DBの max_connections を簡単に超えちゃうんだ。この問題の解決策として、AWSなら RDS Proxy、PostgreSQLなら PgBouncer をDB手前に置いて、Lambda からの大量接続をプロキシ側で集約する方法が主流だよ。

RDS Proxy や PgBouncer は「多対少」の接続マッピングをしてくれるんだ。たとえば Lambda 側からは100本の接続が来ても、プロキシがDB側には10本だけ接続を維持して、リクエストを順番にさばく。Lambda のインスタンスが消えても、プロキシ側のDB接続はそのまま再利用できるから、接続・切断のオーバーヘッドも激減するんだよ。

HikariCP の作者が提唱した有名な公式があるよ。「最適接続数 = (CPUコア数 x 2) + ディスクスピンドル数」。SSDならスピンドル数は1と考えるから、4コアのサーバーなら 4x2+1 = 9本が目安。多ければいいってものじゃなくて、プールを大きくしすぎるとコンテキストスイッチやDB側のメモリ消費が増えて逆に遅くなるんだ。PostgreSQLの公式ドキュメントでも数百の接続は非推奨とされてるよ。

あるよ。HikariCP には「pool-litter」検出という機能があって、借りた接続を返さないコードを検出してくれるんだ。leakDetectionThreshold を設定すると、指定時間以上返却されない接続のスタックトレースをログに出してくれる。実際の現場では、接続リーク1箇所が原因でサービス全体が30分ダウンした事例もある。プールサイズを闇雲に増やして対処すると、今度はDB側が耐えられなくなる。根本原因の特定が最優先だよ。