コネクションプール とは？

TCP接続の確立、認証処理、セッション初期化などで数十ミリ秒かかる。1回なら大したことないけど、Webアプリで毎リクエストごとに接続・切断を繰り返すと膨大な無駄になる。コネクションプールなら最初に確立した接続を使い回すから、その無駄がなくなるんだ。

大きすぎるとDBサーバーのメモリやCPUを圧迫するし、小さすぎると接続待ちが発生する。一般的には「CPUコア数 × 2 + ディスク数」が目安と言われている（HikariCPの推奨値）。ただしこれも負荷パターンによるから、実際に計測して調整するのが大事。

コネクションリークという問題が起きる。プールの接続が全部借りっぱなしになると、新しいリクエストが接続を取得できずにタイムアウトしてアプリが止まる。try-finallyやusingで確実にcloseする、リークを検知するタイムアウト設定を入れるなどの対策が必要だよ。

いいところに気づいたね。Lambda等のサーバーレスは呼び出しごとにインスタンスが起動・破棄されるから、各インスタンスがプールを作ると接続数が爆発する。100個のLambdaが同時に10接続ずつプールしたら1000接続になってDBが耐えられない。AWS RDS ProxyやPgBouncerのような「DBの前に立つプロキシ型のプール」で接続を集約するのが定番の解決策なんだけど、プロキシ自体がボトルネックになるケースもあって、設計の見極めは簡単じゃないんだ。