トランザクションモードの外部コネクションプーラー

アプリ内プールでは足りない場面

コネクションプーリングで見たとおり、アプリ内プールは接続の確立コストを償却しますが、前提として「DBサーバーが受け付けられる接続数」の枠内で動きます。ところがサーバーレス関数やKubernetesの水平スケールでは、アプリのインスタンス数自体が数十〜数千に増減し、各インスタンスが自前のプールを持てば合計接続数はDB側の上限（PostgreSQLのmax_connections）を容易に超えます。DBの1接続はメモリ上にプロセスまたはスレッドとバックエンド状態を抱えるため、接続数が増えるほどコンテキストスイッチとメモリ消費が支配的になり、実クエリの処理能力そのものが落ちます。

この問題を解くのが、DBの手前に立つ外部コネクションプーラー（PgBouncer、pgcatなど）です。アプリからは大量の論理接続を受け付けつつ、DBへの物理接続は少数に絞って多重化します。多重化の粒度をどこに置くかで、プーラーの動作モードが分かれます。

3つのプーリングモード

セッションモードは素朴な転送に近く、クライアントが張った論理接続に物理接続を固定で割り当てます。安全ですが、多重化率が低く「大量の論理接続をDBの少数接続に集約する」という外部プーラー本来の目的をほぼ果たせません。

トランザクションモードは、物理接続をクライアントではなく進行中のトランザクションに貸し出します。BEGIN（暗黙のものを含む）からCOMMIT/ROLLBACKまでの間だけ1本の物理接続を専有し、トランザクションが終わった瞬間にプールへ返却、別のクライアントの次のトランザクションに使い回されます。アイドル時間（クライアントがクエリを送っていない待ち時間）が物理接続を塞がないため、同時接続クライアント数がDBの実接続数の何倍にもなる環境で多重化率を大きく稼げます。実務で「外部プーラー」と言うときはこのモードを指すことが多く、以降はこのモードに絞って内部動作を追います。

トランザクション境界での状態リセット

トランザクションモードの要は、COMMIT/ROLLBACKの瞬間にプーラーが物理接続を次の借り手へ回す前に状態を初期化することです。素朴には「トランザクションが閉じたのだから中身は空」に見えますが、実際にリセットが必要な残存状態は複数あります。

トランザクションモードでの1サイクル:
  1. クライアントAの論理接続がトランザクション開始（BEGIN）を送る
  2. プーラーが空いている物理接続Pをアサイン
  3. A宛のクエリをすべてPへ中継
  4. COMMIT/ROLLBACKを受信
  5. Pに対しDISCARD ALL相当のリセットを実行（実装依存）
  6. Pをプールへ返却、別クライアントBの次トランザクションで再利用可能に

ここで見落とされがちなのが、リセットしても消せない、あるいはそもそもリセット前に次のトランザクションへ持ち越せない性質を持つ機能群です。

なぜ「リセットすれば直せる」問題ではないかというと、これらの機能はいずれも物理接続そのものに紐づく状態であり、トランザクションモードが多重化のために意図的に破壊している「クライアントと物理接続の1対1対応」を前提にしているからです。DISCARD ALLで変数やプランはクリアできても、そもそも次に同じクライアントが同じ物理接続に着地する保証がない以上、セッションを跨ぐ状態の存在自体が成立しません。

セッションモードとの使い分け

もう一つの軸はMVCCとガベージコレクションへの影響です。トランザクションモードは物理接続を素早く手放すため、長時間アイドルのままトランザクションを開けっぱなしにする「アプリのバグ」が起きにくく、結果として最古の生きたスナップショットが古いまま固定されるリスクも下がります。プーラーが強制的にトランザクションを短命化させる副次効果と言えます。ただし分散環境で厳密な一貫性を保証するCalvin方式の決定的トランザクションのように、そもそも実行順序をスケジューラが事前決定する設計とは異なり、外部プーラーはあくまで物理接続の使い回しを最適化するレイヤーであり、トランザクションの実行順序やロック競合そのものは変えない点に注意が必要です。

外部プーラーのトランザクションモードは、大量のアプリインスタンスからDBを守る強力な手段である一方、「セッション」という概念そのものをアプリから見えなくする設計です。プリペアドステートメント・一時テーブル・advisoryロックを使うコードは、導入前に必ず洗い出しておく必要があります。