Azure Database for PostgreSQL の接続プール戦略 - PgBouncer を使用したフレキシブル サーバー

適用対象: Azure Database for PostgreSQL - フレキシブル サーバー

Azure Database for PostgreSQL フレキシブル サーバーの接続プール メカニズムを選択するための戦略的ガイダンス。

はじめに

Azure Database for PostgreSQL フレキシブル サーバーを使用する場合、データベースへの接続を確立するには、クライアント アプリケーションとサーバーの間に通信チャネルを作成する必要があります。 このチャネルは、データの管理、クエリの実行、トランザクションの開始を担当します。 接続が確立されると、クライアント アプリケーションはサーバーにコマンドを送信し、応答を受け取ることができるようになります。 ただし、操作ごとに新しい接続を作成すると、ミッション クリティカルなアプリケーションにパフォーマンスの問題が発生する可能性があります。 新しい接続が作成されるたびに、Azure Database for PostgreSQL フレキシブル サーバーは postmaster プロセスを使って新しいプロセスを生成するため、より多くのリソースを消費します。

この問題を軽減するには、接続プールを使って、Azure Database for PostgreSQL フレキシブル サーバーで再利用できる接続のキャッシュを作成します。 アプリケーションまたはクライアントが接続を要求すると、接続プールから作成されます。 セッションまたはトランザクションが完了すると、再利用できるように接続はプールに戻されます。 接続を再利用することで、リソースの使用量が削減され、パフォーマンスが向上します。

接続プールにはさまざまなツールがありますが、このセクションでは、PgBouncer を使って接続プールを使うさまざまな戦略について説明します。

PgBouncer とは

PgBouncer は、PostgreSQL 用に設計された効率的な接続プーラーであり、1 つ以上のデータベースに対する複数のクライアント接続を管理するための処理時間を短縮し、リソース使用量を最適化するという利点があります。 PgBouncer には、接続のローテーションのために 3 種類のプール モードが組み込まれています。

• セッション プール: この方法を使って、クライアントの接続の全期間にわたってサーバー接続をクライアント アプリケーションに割り当てます。 クライアント アプリケーションが切断されると、PgBouncer はすぐにサーバー接続をプールに戻します。 セッション プール メカニズムは、オープン ソース PgBouncer の既定のモードです。 PgBouncer の構成に関する記事を参照してください。
• トランザクション プール: トランザクション プールを使うと、トランザクション中、サーバー接続はクライアント アプリケーション専用になります。 トランザクションが正常に完了すると、PgBouncer はサーバー接続をインテリジェントに解放し、プール内で再び使用できるようにします。 トランザクション プールは、Azure Database for PostgreSQL フレキシブル サーバーの組み込み PgBouncer の既定のモードであり、準備されたトランザクションをサポートしていません。
• ステートメント プール: ステートメント プールでは、個々のステートメントごとにサーバー接続がクライアント アプリケーションに割り当てられます。 ステートメントが完了すると、サーバー接続はすぐに接続プールに戻されます。 このモードでは、複数のステートメント トランザクションはサポートされないことに注意してください。

PgBouncer の効果的な使用方法は、3 種類の使用パターンに分類できます。

• PgBouncer とアプリケーション コロケーションのデプロイ
• アプリケーションに依存しない一元的な PgBouncer のデプロイ
• 組み込みの PgBouncer とデータベースのデプロイ

これらの各パターンには、独自の利点と欠点があります。

1. PgBouncer とアプリケーション コロケーションのデプロイ

この方法を利用する場合、PgBouncer はアプリケーションがホストされているのと同じサーバーにデプロイされます。 次に示すように、従来の仮想マシン上、またはマイクロサービスベースのアーキテクチャ内にアプリケーションと PgBouncer をデプロイできます。

I. アプリケーション VM にデプロイされた PgBouncer

アプリケーションが Azure VM 上で実行されている場合は、同じ VM 上に PgBouncer を設定できます。 PgBouncer を Azure Database for PostgreSQL フレキシブル サーバーの接続プール プロキシとしてインストールし、構成するには、このリンクに記載されている手順に従ってください。

アプリケーション サーバーに PgBouncer をデプロイすると、特に Azure Database for PostgreSQL フレキシブル サーバー データベースを操作する際に、いくつかの利点が得られます。 このデプロイ方法の主な利点と制限の一部を次に示します。

メリット:

• 待機時間の短縮: 同じアプリケーション VM に PgBouncer をデプロイすると、プライマリ アプリケーションと接続プーラー間は近接しているため、通信が効率的になります。 アプリケーション VM に PgBouncer をデプロイすると、待機時間が最小限に抑えられ、スムーズで迅速な操作が可能になります。
• セキュリティの向上: PgBouncer は、アプリケーションとデータベース間のセキュリティで保護された仲介者として機能し、追加のセキュリティ層を提供します。 認証と暗号化を適用して、許可されたクライアントのみがデータベースにアクセスできるように確保できます。

全般的には、PgBouncer をアプリケーション サーバーにデプロイすると、Azure Database for PostgreSQL フレキシブル サーバー データベースへの接続を管理する上で、より効率的、安全、かつスケーラブルなアプローチを実現し、アプリケーションのパフォーマンスと信頼性を向上させることができます。

制限事項:

• 単一障害点: PgBouncer をアプリケーション サーバー上に単一インスタンスとしてデプロイした場合、単一障害点になる可能性があります。 PgBouncer インスタンスがダウンすると、データベース接続プール全体が中断され、アプリケーションのダウンタイムが生じる可能性があります。 単一障害点を軽減するには、ロード バランサーの背後に複数の PgBouncer インスタンスを設定して高可用性を実現します。
• 限られたスケーラビリティ: PgBouncer のスケーラビリティは、デプロイ先のサーバーの容量によって異なります。 アプリケーション サーバーが接続上限に達すると、PgBouncer がボトルネックとなり、アプリケーションをスケーリングする機能が制限される可能性があります。 必要に応じて、接続負荷を複数の PgBouncer インスタンスに分散するか、アプリケーション レベルでの接続プールなどの代替ソリューションを検討します。
• 構成の複雑さ: PgBouncer の構成と微調整は複雑になることがあります。接続制限、プールのサイズ設定、負荷分散などの要素を考慮する場合は特にそうです。 管理者は、アプリケーションの要件に合わせて PgBouncer の構成を慎重に調整し、最適なパフォーマンスと安定性を確保する必要があります。

これらの制限事項と利点を比較し、実際のアプリケーションとデータベースのセットアップにとって PgBouncer が正しい選択かどうかを評価することが重要です。

II. AKS サイドカーとしてデプロイされた PgBouncer

PgBouncer をサイドカー コンテナーとして利用することができるのは、アプリケーションがコンテナー化され、Azure Kubernetes Service (AKS)、Azure Container Instance (ACI)、Azure Container Apps (ACA)、Azure Red Hat OpenShift (ARO)上で実行されている場合です。 サイドカー パターンは、オートバイに取り付けられるサイドカーの概念からインスピレーションを得ており、サイドカー コンテナーと呼ばれる補助コンテナーが親アプリケーションにアタッチされます。 このパターンを使って機能を拡張し、補助的なサポートを提供することで、親アプリケーションを強化できます。

通常、サイドカー パターンはコンテナーと共に使われ、アトミック コンテナー グループとして共通のスケジュールが設定されます。 PgBouncer を AKS サイドカーにデプロイすると、アプリケーションとサイドカーのライフサイクルが緊密に結合され、ホスト名やネットワークなどのリソースが共有されるので、リソースが効率的に使われます。 PgBouncer サイドカーは、Azure Kubernetes Service (AKS) の同じポッド内のアプリケーション コンテナーと共に 1 対 1 のマッピングで動作し、Azure Database for PostgreSQL フレキシブル サーバーの接続プール プロキシとして機能します。

通常、このサイドカー パターンは、アトミック コンテナー グループとして共通のスケジュールが設定されたコンテナーで使われます。 サイドカー パターンは、アプリケーションとサイドカーのライフサイクルを強固にバインドし、ホスト名やネットワークなどのリソースを共有します。 PgBouncer にこのセットアップを使うことで、接続管理を最適化し、アプリケーションと Azure Database for PostgreSQL フレキシブル サーバー インスタンス間の効率的な通信を促進できます。

Microsoft は、Microsoft コンテナー レジストリで PgBouncer サイドカー プロキシ イメージを公開しています。

詳細については、こちらを参照してください

このデプロイ方法の主な利点と制限の一部を次に示します。

メリット:

• 待機時間の短縮: AKS サイドカーとして PgBouncer をデプロイすると、プライマリ アプリケーションと接続プーラー間は近接しているため、通信がシームレスかつ効率的になります。 AKS サイドカーに PgBouncer をデプロイすると、待機時間が最小限に抑えられ、スムーズで迅速な対話が確保されます。
• 管理とデプロイの簡略化:PgBouncer とアプリケーション コンテナーの緊密な結合により、管理とデプロイのプロセスが簡略化されます。 両コンポーネントが緊密に統合されるので、管理とシームレスな調整が容易になります。
• 高可用性と接続の回復性: アプリケーション コンテナーの障害または再起動が発生した場合、PgBouncer サイドカー コンテナーが密接にフォローし、高可用性を確保します。 このセットアップにすると、接続の回復性を確保し、フェールオーバーが発生しても予測可能なパフォーマンスを維持できるので、信頼性が高く堅牢なシステムに貢献します。

PgBouncer を AKS サイドカーとして検討すると、これらの利点を利用してアプリケーションのパフォーマンスを向上させ、管理を合理化し、接続プーラーの継続的な可用性を確保できます。

制限事項:

• 接続パフォーマンスの問題: それぞれがサイドカー PgBouncer を実行している数千のポッドを利用する大規模なアプリケーションの場合、データベース接続の枯渇に関連する潜在的な問題が発生する可能性があります。 このような状況の結果、パフォーマンスの低下とサービスの中断が発生する可能性があります。 各ポッドにサイドカー PgBouncer をデプロイすると、データベース サーバーへのコンカレント接続数が増え、容量を超える可能性があります。 その結果、データベースは大量の受信接続の処理に苦労し、応答時間の増加やサービス停止などのパフォーマンスの問題が発生する可能性があります。
• 複雑なデプロイ: サイドカー パターンを使うと、同じポッド内で 2 つのコンテナーを実行する必要があるため、デプロイ プロセスの複雑さが 1 レベル高くなります。 その結果、トラブルシューティングやデバッグの作業が複雑になり、問題を特定して解決する労力が増える可能性があります。
• スケーリングの課題: 高いスケーラビリティを必要とするアプリケーションには、サイドカー パターンは理想的な選択肢ではないことがある点に注意が重要です。 サイドカー コンテナーを含めると、リソース要件が増え、効果的に作成および管理できるポッドの数が制限される可能性があります。

このサイドカー パターンを検討するには、デプロイの複雑さとスケーラビリティ要件のトレードオフを慎重に評価して、実際のアプリケーション シナリオに最適なアプローチを決定することが重要です。

2. アプリケーションに依存しない - 一元的な PgBouncer のデプロイ

この方法を利用する場合、アプリケーションに関係なく、PgBouncer は一元化されたサービスとしてデプロイされます。 次に示すように、従来の仮想マシン上、またはマイクロサービスベースのアーキテクチャ内に PgBouncer サービスをデプロイできます。

I. Azure Load Balancer の背後にある ubuntu VM にデプロイされた PgBouncer

この図に示すように、PgBouncer 接続プロキシは、Azure Load Balancer の背後にあるアプリケーション層とデータベース層の間に設定されます。 このパターンでは、単一障害点を軽減するためのサービスとして、複数の PgBouncer インスタンスがロード バランサーの背後にデプロイされます。 このパターンは、アプリケーション がAzure App Services や Azure Functions などのマネージド サービス上で実行し、既存のインフラストラクチャとの簡単な統合のために PgBouncer に接続するシナリオにも適しています。

Azure Database for PostgreSQL フレキシブル サーバーで PgBouncer 接続プール プロキシをインストールし、設定するには、こちらのリンクを参照してください。

このデプロイ方法の主な利点と制限の一部を次に示します。

メリット:

• 単一障害点がなくなる: Azure Load Balancer の背後には複数の PgBouncer インスタンスがあるため、アプリケーションの接続が 1 つの PgBouncer VM の障害によって影響を受けることはありません。
• 管理サービスとのシームレスな統合: アプリケーションが Azure App Services や Azure Functions などの管理サービス プラットフォーム上でホストされている場合、PgBouncer を VM 上にデプロイすることで、既存のインフラストラクチャと簡単に統合できます。
• Azure VM でのセットアップの簡略化: 既に Azure VM 上でアプリケーションを実行している場合、同じ VM 上で PgBouncer を設定するのは簡単です。 VM に PgBouncer をデプロイすると、PgBouncer はアプリケーションに近接してデプロイされるので、ネットワーク待機時間を最小限に抑え、パフォーマンスを最大化することができます。
• 侵襲性のない構成: PgBouncer を VM にデプロイすると、Azure Database for PostgreSQL フレキシブル サーバー上のサーバー パラメーターを変更せずに済みます。 これは、Azure Database for PostgreSQL フレキシブル サーバー インスタンスで PgBouncer を構成する場合に便利です。 たとえば、Azure Database for PostgreSQL フレキシブル サーバー上で SSLMODE パラメーターを "必須" に変更すると、SSLMODE=FALSE に依存する特定のアプリケーションが失敗する可能性があります。 PgBouncer を別の VM にデプロイすると、PgBouncer の恩恵を受けながら、既定のサーバー構成を維持できます。

これらの利点を考慮すると、VM に PgBouncer をデプロイした場合、Azure インフラストラクチャ上で実行されているアプリケーションのパフォーマンスと互換性を強化するための便利で効率的なソリューションを実現できます。

制限事項:

• 管理のオーバーヘッド:PgBouncer は VM にインストールされるので、複数の構成ファイルを管理するために管理のオーバーヘッドが生じる可能性があります。 そのため、バージョンのアップグレード、新しいリリース、製品の更新プログラムへの対処が困難になります。
• 機能パリティ: 従来の PostgreSQL から Azure Database for PostgreSQL フレキシブル サーバーに移行し、PgBouncer を使っている場合は、機能のギャップがいくつか存在する可能性があります。 たとえば、Azure Database for PostgreSQL フレキシブル サーバーでは md5 のサポートがありません。

II. AKS 内のサービスとしてデプロイされた一元化された PgBouncer

Azure Kubernetes Service (AKS) 上の数百のポッドから構成される、非常にスケーラブルで大規模なコンテナー化されたデプロイを使っている場合、または複数のアプリケーションが 1 つの共有データベースに接続する必要がある状況では、サイドカー コンテナーではなくスタンドアロン サービスとして PgBouncer を採用できます。

PgBouncer を別のサービスとして利用することで、より大規模なアプリケーションの接続プールを効率的に管理および処理できます。 このアプローチにより、接続プール機能の一元化が可能になり、複数のアプリケーションが同じデータベース リソースに接続できるだけでなく、最適なパフォーマンスとリソース使用率を維持できます。

Microsoft コンテナー レジストリで公開されている PgBouncer サイドカー プロキシ イメージは、サービスの作成とデプロイに使用できます。

このデプロイ方法の主な利点と制限の一部を次に示します。

メリット:

• 信頼性の向上:PgBouncer をスタンドアロン サービスとしてデプロイすると、可用性の高い方法で構成できます。 これにより、接続プール インフラストラクチャの全体的な信頼性が向上し、障害や中断が発生した場合でも継続的な可用性が確保されます。
• 最適なリソース使用率: アプリケーションまたはデータベース サーバーのリソースが限られている場合は、PgBouncer サービスの実行専用として別のマシンを選ぶ方が良い可能性があります。 十分なリソースがあるマシンに PgBouncer をデプロイすると、最適なパフォーマンスを確保し、リソース競合の問題を防ぐことができます。
• 一元化された接続管理: データベース接続の一元化された管理が要件の場合、スタンドアロンの PgBouncer サービスの方が合理的なアプローチです。 接続管理タスクを一元化されたサービスに統合することで、複数のアプリケーションにまたがるデータベース接続を効果的に監視および制御できるため、管理を簡略化し、整合性を確保できます。

PgBouncer を AKS 内のスタンドアロン サービスとして考慮することで、これらの利点を活用して、信頼性の向上、リソースの効率化、データベース接続の一元管理を実現できます。

制限事項:

• N/W 待機時間の増加:PgBouncer をスタンドアロン サービスとしてデプロイする場合、待機時間が長くなる可能性を考慮することが重要です。 これは、アプリケーションと PgBouncer サービス間の接続はネットワーク経由で渡す必要があるためです。 アプリケーションの待機時間の要件を評価し、一元化された接続管理と潜在的な待機時間の問題のトレードオフを考慮することが重要です。

スタンドアロン サービスとして実行される PgBouncer には一元管理やリソースの最適化などの利点がありますが、アプリケーションのパフォーマンスに対する潜在的な待機時間の影響を評価し、実際の要件に適合していることを確認することが重要です。

3.「Azure Database for PostgreSQL フレキシブル サーバーの組み込み PgBouncer」を参照してください

Azure Database for PostgreSQL フレキシブル サーバーでは、組み込みの接続プール ソリューションとして PgBouncer が提供されます。 これは、データベース サーバーごとに有効にできるオプション サービスとして用意されています。 PgBouncer は、Azure Database for PostgreSQL フレキシブル サーバー インスタンスと同じ仮想マシンで実行されます。 数百または数千を超えるほど接続数が増えると、Azure Database for PostgreSQL フレキシブル サーバーでリソースの制限が発生する可能性があります。 このような場合、データベース サーバー側でアイドル状態と有効期間の短い接続の管理を改善できるので、組み込みの PgBouncer に大きな利点があります。

Azure Database for PostgreSQL フレキシブル サーバーで PgBouncer 接続プールを有効にして設定するには、リンクを参照してください。

このデプロイ方法の主な利点と制限の一部を次に示します。

メリット:

• シームレスな構成: Azure Database for PostgreSQL フレキシブル サーバーには組み込み PgBouncer があるので、個別のインストールや複雑なセットアップは必要ありません。 サーバー パラメーターから直接簡単に構成できるため、手間のかからないエクスペリエンスが保証されます。
• 管理サービスの利便性: 管理サービスなので、ユーザーは他の Azure 管理サービスの利点を活用できます。 これには自動更新が含まれているため、手動メンテナンスが不要になり、最新の機能とセキュリティ パッチによって PgBouncer を最新の状態に維持できます。
• パブリック接続およびプライベート接続のサポート: Azure Database for PostgreSQL フレキシブル サーバーに組み込まれた PgBouncer では、パブリック接続とプライベート接続の両方がサポートされています。 そのため、ユーザーは自分の要件に応じてプライベート ネットワーク経由で安全な接続を確立したり、外部に接続したりできます。
• 高可用性 (HA): フェールオーバーが発生し、スタンバイ サーバーがプライマリ ロールに昇格した場合、PgBouncer は、アプリケーション接続文字列を変更することなく、新しく昇格したスタンバイ上でシームレスに再起動します。 そのため、継続的な可用性が確保され、アプリケーションの中断が最小限に抑えられます。
• コスト効率: ユーザーが VM やコンテナーなどの追加のコンピューティングに対して支払う必要がないため、コスト効率が高くなりますが、これは同じコンピューターで実行されている別のプロセスであるため、CPU は影響を受けます。

Azure Database for PostgreSQL フレキシブル サーバーに組み込まれた PgBouncer を使用すると、簡素化された便利な構成、マネージド サービスの信頼性、さまざまなプール モードのサポート、フェールオーバー シナリオでのシームレスな高可用性を活用できます。

制限事項:

• バースト可能ではサポートされていない: 現在、PgBouncer はバースト可能サーバー コンピューティング レベルではサポートされていません。 コンピューティング レベルを汎用またはメモリ最適化からバースト可能レベルに変更した場合、PgBouncer の機能は失われます。
• 再起動後に接続を再確立する: スケール操作中、HA フェールオーバー中、または再起動時にサーバーが再起動されるたびに、PgBouncer もサーバー仮想マシンと共に再起動されます。 そのため、既存の接続を再確立する必要があります。

"PgBouncer を実装するさまざまな方法について説明し、どのデプロイ方法を選ぶべきかを表にまとめています。"

選択条件	App VM 上の PgBouncer	ALB を使う VM 上の PgBouncer*	AKS サイドカー上の PgBouncer	サービスとしての PgBouncer	Azure Database for PostgreSQL フレキシブル サーバーの組み込み PgBouncer
簡素化された管理
HA
コンテナー化されたアプリ
ネットワーク オーバーヘッドと待機時間の軽減
監視とデバッグの詳細な制御

凡例

難易度	記号
簡単
Medium
困難

*ALB: Azure Load Balancer。