Azure Database for PostgreSQL フレキシブル サーバーで PgBouncer 1.25.1 が GA になりました。実務上の結論はシンプルで、組み込みの接続プーリングを 1.25.1 ベースで使えるようになり、短命接続やアイドル接続の多いアプリでは、同じホスト名のまま 6432 番ポートへ切り替えることで接続オーバーヘッドを下げやすくなります。Microsoft は 2026年4月8日に一般提供を案内しており、公式ドキュメントでも Flexible Server に配備される PgBouncer バージョンを 1.25.1 としています。(Microsoft)
ただし、導入の成否は「新しい版かどうか」よりも「アプリがトランザクションプーリングに合うか」で決まります。Azure の組み込み PgBouncer は既定で transaction モードを使うため、セッション状態に依存する実装や prepared statements の扱いを先に点検することが重要です。(Microsoft Learn)
| 見るポイント | この記事の結論 |
|---|---|
| 今回の GA | Azure の組み込み PgBouncer 1.25.1 サポートが一般提供になった |
| まずやること | QA 環境で 5432 → 6432 に切り替えて互換性テストをする |
| 特に向く構成 | API、Functions、App Service、マイクロサービスなど短命接続が多い構成 |
| 最重要チェック | トランザクションプーリング互換性、prepared statements、Burstable 非対応 |
PgBouncer 1.25.1 GA で何が変わったのか
今回の発表で押さえるべきなのは、「Azure Database for PostgreSQL フレキシブル サーバーに組み込まれた PgBouncer が 1.25.1 を前提に使えるようになった」という点です。Azure Updates では、PgBouncer は組み込みの接続プーリング機能として、低オーバーヘッドで数千接続までスケールしやすくし、接続オーバーヘッドとワークロード全体の信頼性を改善すると案内しています。さらに Flexible Server へ完全統合されているため、別 VM やコンテナで PgBouncer を立てて管理する必要はありません。(Microsoft)
Azure 利用者の視点で見ると、今回の価値は「Azure 独自の巨大な新機能が増えた」ことより、「マネージドな接続プーラーの土台が 1.25.1 系へ上がり、上流コミュニティの性能改善、プロトコル改善、セキュリティ修正、安定性修正を取り込める」ことにあります。PgBouncer 上流の 1.25.0 では、LDAP 認証、クライアント側 direct TLS 接続、transaction_timeout、TLS 1.3 cipher 設定、ad hoc SCRAM 認証の性能改善などが追加され、1.25.1 では CVE-2025-12819 の修正に加え、SCRAM、メモリリーク、警告ログまわりの不具合が修正されています。(pgbouncer.org)
一方で、Azure で実際に運用者が触れる設定面は Azure が公開しているサーバーパラメーターが基準です。上流 changelog に載る機能すべてが、そのまま Azure ポータルやサーバーパラメーターとして露出するとは限りません。実務では、上流の変更点を参考にしつつ、最終判断は Azure のドキュメントに載っている操作可能なパラメーターで行うのが安全です。(Microsoft Learn)
まず恩恵を受けやすいワークロード
Azure のドキュメントでは、PgBouncer は「頻繁な接続チャーンによってパフォーマンスが低下しやすいトランザクション系アプリ」に特に有効とされています。つまり、HTTP リクエストごとに接続が増減しやすい API サーバー、Azure Functions、App Service、コンテナ化されたマイクロサービスのような構成ほど相性がよい、という理解でほぼ間違いありません。組み込み PgBouncer の既定プールモードも transaction なので、短い処理を高並列で回す用途に向きます。(Microsoft Learn)
| 向きやすい構成 | 理由 |
|---|---|
| API サーバー / Functions / App Service | 接続の作成・破棄が多く、トランザクションプーリングの恩恵が出やすい |
| 多数のアプリインスタンスを持つ構成 | クライアント接続を DB 側の少数接続へ集約しやすい |
| アイドル接続が多い業務アプリ | 接続維持コストを圧縮しやすい |
逆に、接続数自体が少なく、長時間同じセッションを握り続けるアプリでは効果が限定的です。また、セッション状態に依存する実装は、既定のトランザクションプーリングと衝突しやすいため注意が必要です。Burstsable コンピューティング レベルでは、Azure の組み込み PgBouncer 自体がサポートされません。(pgbouncer.org)
切り替え前に必ず確認したい互換性
トランザクションプーリングで壊れやすいもの
PgBouncer の公式 feature map では、transaction pooling で次の機能が非互換とされています。ここに引っかかるなら、6432 への単純切り替えは危険です。(pgbouncer.org)
SET/RESETLISTENWITH HOLD CURSORPREPARE / DEALLOCATEPRESERVE/DELETE ROWSの temp table- セッションレベル advisory lock
これらは「SQL が通るかどうか」ではなく、「接続がトランザクション単位で別サーバー接続へ付け替わる」という PgBouncer の前提と相性が悪いのが本質です。アプリがユーザーごとのセッション変数やコネクション単位の状態を暗黙に期待していると、テストでは再現しにくい不具合になりやすいので、実コードと ORM の設定を必ず見直してください。(pgbouncer.org)
prepared statements と ORM の注意
Azure のドキュメントでは、現在の PgBouncer は transaction mode でも prepared statements を扱えますが、そのためには pgbouncer.max_prepared_statements を 0 より大きい値に設定する必要があります。既定値は 0 なので、何もしなければ無効です。また、サポート対象はプロトコルレベルの named prepared statementsであり、SQL として送る PREPARE 文とは扱いが異なります。(Microsoft Learn)
ここが現場でいちばんハマりやすいポイントです。たとえば ORM やドライバが server-side prepared statements を多用していると、6432 に切り替えた直後に「一部のクエリだけ失敗する」「高負荷時だけ化ける」という形で表面化しがちです。PgBouncer 公式 FAQ では、JDBC なら prepareThreshold=0 で prepared statements を無効化する方法が案内されており、PHP/PDO では、現時点の公式 FAQ で PHP 8.4 以上かつ libpq 17 の組み合わせ以外は互換性に注意するよう案内されています。古い PHP/PDO 系では PDO::ATTR_EMULATE_PREPARES=true に寄せる判断も候補です。(pgbouncer.org)
startup parameters の見落とし
接続直後に追加の startup parameters を送るクライアントも注意が必要です。PgBouncer の公式 feature map では、確実に追跡される startup parameters に範囲があり、それ以外は track_extra_parameters や ignore_startup_parameters の考え方が関わります。Azure 側でも pgbouncer.ignore_startup_parameters が公開されています。接続直後の互換性エラーや、特定ドライバだけ接続に失敗するケースでは、この論点を疑う価値があります。(Microsoft Learn)
Azure Database for PostgreSQL フレキシブル サーバーでの有効化手順
組み込み PgBouncer の使い方自体はシンプルです。基本は次の流れで十分です。(Microsoft Learn)
- Azure ポータルの Server parameters で
pgbouncer.enabledをtrueにする。 - アプリの接続先を、同じホスト名のまま 5432 から 6432 へ変更する。
- まず QA 環境で互換性を確認する。
- 問題がなければ本番の接続先を 6432 に切り替える。
pgbouncer.enabled は動的パラメーターで、サーバー再起動は不要です。ただし、このパラメーター自体が見えない場合は、Burstable で動いていないかを先に確認してください。Azure では General Purpose または Memory Optimized でのみ組み込み PgBouncer が使えます。(Microsoft Learn)
地味ですが、実務で役立つ注意点もあります。Azure のドキュメントでは、PgBouncer を有効化して保存したあと、Server parameters ペインを閉じて開き直さないと全パラメーターが見えないことがあると案内されています。設定項目が足りないように見えたら、まず UI を開き直してください。(Microsoft Learn)
疎通確認は、同じホスト名でポートだけ 6432 に変えれば十分です。Microsoft Entra 認証もサポートされています。(Microsoft Learn)
psql "host=<server>.postgres.database.azure.com port=6432 dbname=<db> user=<user> password=<password> sslmode=require"まずはこの形で接続できることを確認してから、アプリケーション側の接続文字列を切り替えるのが安全です。(Microsoft Learn)
先に見直すべき設定
Azure の公式ドキュメントで確認できる主な既定値は、pgbouncer.enabled=false、pgbouncer.pool_mode=transaction、pgbouncer.default_pool_size=50、pgbouncer.max_client_conn=5000、pgbouncer.max_prepared_statements=0、pgbouncer.query_wait_timeout=120、pgbouncer.server_idle_timeout=600、pgbouncer.min_pool_size=0 です。(Microsoft Learn)
設定は、次の順で見ると外しにくくなります。
pool_mode
まずは既定のtransactionを前提に考えます。セッション機能が必要だからといってすぐsessionに寄せると、PgBouncer の旨味そのものが薄れます。アプリのセッション依存を減らせるかを先に見る方が失敗しにくいです。default_pool_size
Web リクエスト数ではなく、同時に DB で実行される実処理数を基準に考えるべき値です。待機接続が増え続けるのに DB 側の余力があるなら、ここを少しずつ上げる余地があります。max_client_conn
フロント側の接続をどこまで受けるかの上限です。アプリインスタンス数が多い構成では重要ですが、やみくもに大きくすると「受けられるがさばけない」状態を作りやすいので、必ずメトリクスとセットで見ます。max_prepared_statements
ORM やドライバが protocol-level prepared statements を使うなら最重要です。既定では無効なので、「prepared statements を使う前提のアプリなのに設定していない」というミスは非常によく起こります。query_wait_timeout
ここでタイムアウトが出たとき、最初にやるべきは値を伸ばすことではありません。まずは slow query と pool saturation のどちらかを切り分ける方が先です。server_idle_timeoutとmin_pool_size
バックエンド接続をどれだけ温存するかのバランスを決めます。アイドル接続がだぶつくならserver_idle_timeout側、毎回コールドスタート気味ならmin_pool_size側を疑うと整理しやすくなります。
各パラメーターの意味と既定値は Azure のサーバーパラメーター定義に基づいています。(Microsoft Learn)
監視とトラブルシューティングの勘所
PgBouncer を本番で使うなら、切り替えと同時に監視も入れるべきです。Azure では PgBouncer メトリクスを使って、アクティブ接続、待機接続、アイドル接続、総プール接続数、プール数を監視できます。メトリクスは 1 分間隔で出力され、最大 93 日の履歴を保持しますが、metrics.pgbouncer_diagnostics は既定で無効です。(Microsoft Learn)
最初に見るべきメトリクスはこの 5 つです。(Microsoft Learn)
client_connections_waiting
クライアントがサーバー接続を待っている数。増え続けるなら、SQL が遅いか、default_pool_sizeが小さいか、その両方です。server_connections_active
実際にバックエンドで使われている接続数。DB 側の実負荷と付き合わせて見ます。server_connections_idle
待機中のバックエンド接続数。長時間高止まりするなら、プールを持ちすぎている可能性があります。total_pooled_connections
いま何本の接続をプールとして抱えているかを見るための基本指標です。num_pools
データベース単位でプールがどう増えているかを把握できます。マルチ DB 構成では見落としにくくなります。
ログも有効です。Azure Database for PostgreSQL フレキシブル サーバーは、認証失敗、接続ライフサイクル、エラー、サーバー状態の変化などを PgBouncer ログとして出せます。Log Analytics では AzureDiagnostics の Category == "PostgreSQLFlexPGBouncer"、またはリソース固有スキーマの PGSQLPgBouncer テーブルで確認できます。接続切断や pool exhaustion の切り分けに有効です。(Microsoft Learn)
リアルタイムで状態を見たいなら、管理コンソールも便利です。pgBouncer.stats_users に既存ユーザーを設定したうえで、pgbouncer データベースへ 6432 で接続すると、SHOW HELP、SHOW POOLS、SHOW DATABASES、SHOW STATS を実行できます。メトリクスが時系列分析向けなのに対し、こちらは“いま詰まっているか”を見るのに向いています。(Microsoft Learn)
見落としやすい注意点
組み込み PgBouncer は便利ですが、Azure 固有の制約もあります。まず、Burstable では使えません。General Purpose や Memory Optimized から Burstable に変更すると、組み込み PgBouncer の機能は失われます。コスト最適化のつもりで SKU を落として、あとから接続まわりが崩れるケースは珍しくありません。(Microsoft Learn)
次に、スケール操作、HA フェールオーバー、再起動では PgBouncer も一緒に再起動されるため、既存接続の再確立が必要です。ただし、ゾーン冗長 HA の場合でも、フェールオーバー後の接続文字列自体は変えなくてよいと Azure は案内しています。つまり「接続先を変える」のではなく、「クライアントの再接続ロジックを正しく持つ」ことが重要です。(Microsoft Learn)
最後に、メトリクスとログは後回しにしないことです。PgBouncer は入れた瞬間よりも、「負荷がかかったときに何が詰まっているかを可視化できるか」で価値が決まります。監視を入れずに 6432 へ切り替えると、効果が出たのか、逆に待ち行列を増やしたのかを判断できません。(Microsoft Learn)
まとめ
PgBouncer 1.25.1 の GA は、Azure Database for PostgreSQL フレキシブル サーバーで組み込みの接続プーリングをより安心して使うための節目と捉えるのが実務的です。短命接続が多いワークロードでは導入価値が高く、別基盤で PgBouncer を運用しなくてよい点も大きなメリットです。一方で、既定はトランザクションプーリングなので、セッション依存の実装、prepared statements、Burstable 非対応、再接続前提の設計は必ず確認してください。(Microsoft)
次にやることは 3 つです。
1 つ目は、QA 環境で 5432 から 6432 へ切り替えて回帰テストをすること。
2 つ目は、prepared statements と startup parameters、セッション依存機能の有無を洗い出すこと。
3 つ目は、metrics.pgbouncer_diagnostics と PgBouncer ログを有効にしてから負荷試験を行うことです。ここまでやれば、「PgBouncer 1.25.1 が Azure PostgreSQL で使えるようになった」ことを、ニュースではなく実運用の改善につなげられます。(Microsoft Learn)
コメント