コネクションプールとは？接続の再利用・枯渇・サイズ設定を図解

ひよこ

DBには毎回つなぎ直しているの？

ペンギン先生

毎回つなぐ方法もあるけれど、接続には通信や認証などの準備が必要なんだ。プールは接続を保持して再利用し、その準備の繰り返しを減らす仕組みだよ。何ミリ秒速くなるかは環境によるんだ。

ひよこ

使うときはどうするの？

ペンギン先生

アプリがプールから接続を借り、SQLやトランザクションを終えたら返すよ。返却は実際のネットワーク切断とは別。例外が起きても返すよう、ライブラリが提供する構文やfinallyなどを使うんだ。

ひよこ

何本でも用意すれば速くなる？

ペンギン先生

増やしすぎるとDB側の処理やメモリの負担になるよ。各アプリのプール最大数を足した値が、DB全体の接続予算に収まるかも確認しよう。管理用接続やほかのサービスの分も残す必要があるんだ。

ひよこ

全部貸し出し中になったら？

ペンギン先生

実装に応じて空き待ちになり、制限時間を超えると接続取得が失敗するよ。返し忘れだけでなく、遅いSQL、長いトランザクション、ロック待ちでも起きる。枯渇したことだけでデッドロックとは断定できないんだ。

ひよこ

監視では何を見るの？

ペンギン先生

使用中・空き接続数に加え、接続を借りるまでの待ち時間、取得失敗、SQLとトランザクションの時間を見るよ。待ちが増えても、すぐ最大数を増やすのではなく、DBの負荷と接続を返す処理を調べよう。

ひよこ

HikariCPの設定にはどんな意味があるの？

ペンギン先生

maximumPoolSizeは最大数、connectionTimeoutは借りるまでの待ち時間などを設定するよ。maxLifetimeは接続の寿命で、使い終わった後の更新に関係する。leakDetectionThresholdは長時間返らない接続をログに出す機能で、自動修復ではないんだ。

ひよこ

PgBouncerも同じもの？

ペンギン先生

接続の再利用という目的は共通だけれど、PgBouncerはPostgreSQLの手前に置けるプロキシだよ。transaction poolingではトランザクションの間だけDB側の接続を割り当てる。セッション状態に依存する機能は互換性の確認が必要なんだ。

ひよこ

サーバーレスならどう考える？

ペンギン先生

実行環境が増えると、それぞれのプールが接続を持つ可能性があるよ。外部プーラーを使っても同時実行・待ち時間・DBの処理能力の制約は消えない。最大の実行環境数と接続数を見積もって検証しよう。

接続予算を全体で計算する

例として、アプリの実行環境が最大8個、1個あたりプール上限10本なら、アプリ側の上限合計は8 × 10 = 80本です。ほかのサービスや管理用に20本必要なら、合計100本の予算になります。これは推奨設定ではなく、足し忘れを防ぐ計算例です。DBの許容量や実際に処理できる並列数を別に確認します。

タイムアウトの種類を混同しない

HikariCPの設定名をすべてのライブラリの共通名として扱わないでください。leakDetectionThresholdの警告はリークの疑いであり、正当に長い処理でも出る場合があります。

「CPUコア数だけで最適本数」は決められない

HikariCPの資料には接続数の経験則がありますが、SSDを一律に「スピンドル数1」とする万能式ではありません。少ない本数から負荷試験を行い、処理量、応答時間、DBの飽和を見て調整します。PgBouncerのtransaction poolingを使うときは、SETや一時テーブルなどのセッション依存機能も公式の互換表で確認しましょう。

参考資料

確認日：2026年9月26日。製品の仕様・料金・対応環境は導入時にも確認してください。

• HikariCP configuration：プール上限・取得待ち・寿命・リーク検出。
• HikariCP: About Pool Sizing：接続数と並列度、経験則の前提。
• PgBouncer features：プーリングモードとセッション機能の制約。