この記事では、Azure Database for PostgreSQLフレキシブル サーバーの接続プール メカニズムを選択するための戦略的なガイダンスを提供します。
イントロダクション
Azure Database for PostgreSQLフレキシブル サーバーを使用する場合は、クライアント アプリケーションとサーバー間の通信チャネルを確立して、データベースへの接続を作成します。 このチャネルでは、データの管理、クエリの実行、トランザクションの開始が行われます。 接続を確立すると、クライアント アプリケーションはサーバーにコマンドを送信し、応答を受け取ることができます。 ただし、各操作に新しい接続を作成すると、ミッション クリティカルなアプリケーションのパフォーマンスの問題が発生する可能性があります。 新しい接続を作成するたびに、Azure Database for PostgreSQLポストマスター プロセスを使用して新しいプロセスを開始します。このプロセスでは、より多くのリソースが消費されます。
この問題に対処するには、接続プールを使用して、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 とデータベースのデプロイ
これらの各パターンには、独自の長所と短所があります。
PgBouncer とアプリケーションコロケーションのデプロイ
この方法を使用する場合は、アプリケーションがホストされているのと同じサーバーに PgBouncer をデプロイします。 強調表示されているように、アプリケーションと PgBouncer は、従来の仮想マシンまたはマイクロサービス ベースのアーキテクチャ内にデプロイできます。
アプリケーション VM にデプロイされた PgBouncer
アプリケーションが Azure VM 上で実行されている場合は、同じ VM 上に PgBouncer を設定できます。 Azure Database for PostgreSQL フレキシブル サーバーで PgBouncer を接続プーリング プロキシとしてインストールして構成するには、「PgBouncer 接続プール プロキシをインストールしてセットアップする手順」を参照してください。
アプリケーション サーバーに PgBouncer をデプロイすると、特に Azure Database for PostgreSQL フレキシブル サーバー データベースを操作する際に、いくつかの利点が得られます。 このデプロイ方法の主な利点と制限事項の一部を次に示します。
メリット:
- 待機時間の短縮: 同じアプリケーション VM に PgBouncer をデプロイすることで、プライマリ アプリケーションと接続プーラーの間の通信が効率的になります。 アプリケーション VM に PgBouncer をデプロイすると、待機時間が最小限になり、スムーズで迅速な対話が保証されます。
- セキュリティの向上:PgBouncer は、アプリケーションとデータベース間のセキュリティで保護された仲介者として機能し、追加のセキュリティ層を提供します。 認証と暗号化を適用して、許可されたクライアントのみがデータベースにアクセスできるように確保できます。
全般的には、PgBouncer をアプリケーション サーバーにデプロイすると、Azure Database for PostgreSQL フレキシブル サーバー データベースへの接続を管理する上で、より効率的、安全、かつスケーラブルなアプローチを実現し、アプリケーションのパフォーマンスと信頼性を向上させることができます。
Limitations:
- 単一障害点: PgBouncer を単一のインスタンスとしてアプリケーション サーバーにデプロイすると、単一障害点になる可能性があります。 PgBouncer インスタンスがダウンすると、データベース接続プール全体が中断され、アプリケーションのダウンタイムが生じる可能性があります。 この単一障害点を軽減するには、高可用性のためにロード バランサーの背後に複数の PgBouncer インスタンスを設定します。
- 限られたスケーラビリティ: PgBouncer のスケーラビリティは、デプロイ先のサーバーの容量によって異なります。 アプリケーション サーバーが接続制限に達すると、PgBouncer がボトルネックになり、アプリケーションをスケーリングする機能が制限される可能性があります。 複数の PgBouncer インスタンス間で接続負荷を分散したり、アプリケーション レベルでの接続プールなどの代替ソリューションを検討したりする必要がある場合があります。
- 構成の複雑さ: PgBouncer の構成と微調整は複雑になることがあります。接続制限、プールのサイズ設定、負荷分散などの要素を考慮する場合は特にそうです。 管理者は、アプリケーションの要件に合わせて PgBouncer の構成を慎重に調整し、最適なパフォーマンスと安定性を確保する必要があります。
これらの制限事項を利点と比較検討し、PgBouncer が特定のアプリケーションとデータベースのセットアップに適した選択肢であるかどうかを評価します。
AKS サイドカーとしてデプロイされた PgBouncer
PgBouncer は、アプリケーションがコンテナー化され、Azure Kubernetes Service (AKS)、Azure Container Instance (ACI)、Azure Container Apps (ACA)、または Azure Red Hat OpenShift (ARO) 上で実行されている場合に、サイドカー コンテナーとして使用できます。 サイドカーパターンは、オートバイに取り付けるサイドカーの概念からインスピレーションを得ています。 サイドカー コンテナーと呼ばれる補助コンテナーは、親アプリケーションにアタッチされます。 このパターンを使って機能を拡張し、補助的なサポートを提供することで、親アプリケーションを強化できます。
AKS サイドカーに PgBouncer をデプロイすると、アプリケーションとサイドカーのライフサイクルが密に結合され、ホスト名やネットワークなどのリソースが共有され、リソースが効率的に使用されます。 PgBouncer サイドカーは、Azure Kubernetes Service (AKS)の同じポッド内のアプリケーション コンテナーと共に 1 対 1 のマッピングで動作し、Azure Database for PostgreSQLフレキシブル サーバーの接続プーリング プロキシとして機能します。
Microsoftは、PgBouncer サイドカー プロキシ イメージMicrosoftコンテナー レジストリに発行します。
詳細については、こちらを参照してください。
このデプロイ方法の主な利点と制限事項の一部を次に示します。
メリット:
- 待機時間の短縮: AKS サイドカーとして PgBouncer をデプロイすると、プライマリ アプリケーションと接続プーラー間は近接しているため、通信がシームレスかつ効率的になります。 AKS サイドカーに PgBouncer をデプロイすると、待機時間が最小限に抑えられ、スムーズで迅速な対話が確保されます。
- 管理とデプロイの簡略化:PgBouncer とアプリケーション コンテナーの緊密な結合により、管理とデプロイのプロセスが簡略化されます。 どちらのコンポーネントも緊密に統合されているため、より簡単に管理し、シームレスに調整できます。
- 高可用性と接続の回復性: アプリケーション コンテナーの障害または再起動が発生した場合、 PgBouncer サイドカー コンテナーは密接に従い、高可用性を確保します。 このセットアップにすると、接続の回復性を確保し、フェールオーバーが発生しても予測可能なパフォーマンスを維持できるので、信頼性が高く堅牢なシステムに貢献します。
PgBouncer を AKS サイドカーとして検討すると、これらの利点を利用してアプリケーションのパフォーマンスを向上させ、管理を合理化し、接続プーラーの継続的な可用性を確保できます。
Limitations:
- 接続パフォーマンスの問題: サイドカー PgBouncer を実行する数千のポッドを使用する大規模なアプリケーションでは、データベース接続の枯渇に関連する潜在的な課題が発生する可能性があります。 このような状況の結果、パフォーマンスの低下とサービスの中断が発生する可能性があります。 各ポッドにサイドカー PgBouncer をデプロイすると、データベース サーバーへのコンカレント接続数が増え、容量を超える可能性があります。 その結果、データベースが大量の受信接続の処理に苦労し、応答時間の増加やサービスの停止などのパフォーマンスの問題が発生する可能性があります。
- 複雑なデプロイ: サイドカー パターンを使用すると、同じポッド内で 2 つのコンテナーを実行する必要があるため、デプロイ プロセスの複雑さが 1 レベル高くなります。 この複雑さは、トラブルシューティングとデバッグアクティビティを複雑にする可能性があり、問題を特定して解決するために余分な労力が必要になります。
- スケーリングの課題: サイドカー パターンは、高いスケーラビリティを必要とするアプリケーションにとって理想的な選択肢ではない可能性があります。 サイドカー コンテナーを含めると、より多くのリソース要件が課される可能性があり、効果的に作成および管理できるポッドの数が制限される可能性があります。
このサイドカー パターンを考慮しながら、デプロイの複雑さとスケーラビリティの要件のトレードオフを慎重に評価して、特定のアプリケーション シナリオに最適なアプローチを決定します。
アプリケーションに依存しない - 一元化された PgBouncer デプロイ
この方法を使用する場合は、アプリケーションに依存しない一元化されたサービスとして PgBouncer をデプロイします。 次のセクションで強調されているように、PgBouncer サービスは、従来の仮想マシンまたはマイクロサービス ベースのアーキテクチャ内にデプロイできます。
Azure Load Balancerの背後にある Ubuntu VM にデプロイされた PgBouncer
次の図に示すように、Azure Load Balancerの背後にあるアプリケーションとデータベース レイヤーの間に PgBouncer 接続プロキシを設定します。 このパターンでは、単一障害点を軽減するために、サービスとしてロード バランサーの背後に複数の PgBouncer インスタンスをデプロイします。 このパターンは、アプリケーション がAzure アプリ Services や Azure Functions などのマネージド サービス上で実行し、既存のインフラストラクチャとの簡単な統合のために PgBouncer に接続するシナリオにも適しています。
フレキシブル サーバーを使用して PgBouncer 接続プーリング プロキシAzure Database for PostgreSQLインストールおよび設定するには、「PgBouncer 接続プーリング プロキシをインストールしてセットアップする手順」を参照してください。
このデプロイ方法の主な利点と制限事項の一部を次に示します。
メリット:
- 単一障害点の削除:複数の PgBouncer インスタンスがAzure Load Balancerの背後にあるので、アプリケーション接続は単一の PgBouncer VM の障害の影響を受けません。
- 管理サービスとのシームレスな統合: アプリケーションが Azure アプリ Services や Azure Functions などの管理サービス プラットフォーム上でホストされている場合、PgBouncer を VM 上にデプロイすることで、既存のインフラストラクチャと簡単に統合できます。
- Azure VM でのセットアップの簡略化: 既に Azure VM 上でアプリケーションを実行している場合、同じ VM 上で PgBouncer を設定するのは簡単です。 VM に PgBouncer をデプロイすると、PgBouncer がアプリケーションに近接してデプロイされ、ネットワーク待機時間が最小限に抑えられ、パフォーマンスが最大化されます。
- 非侵入構成:VM に PgBouncer をデプロイすると、Azure Database for PostgreSQLフレキシブル サーバーでパラメーターを変更しないようにできます。 この構成は、Azure Database for PostgreSQLフレキシブル サーバーで PgBouncer を構成する場合に便利です。 たとえば、Azure Database for PostgreSQLフレキシブル サーバーで SSLMODE パラメーターを "必須" に変更すると、SSLMODE=FALSE に依存する特定のアプリケーションが失敗する可能性があります。 PgBouncer を別の VM にデプロイすると、PgBouncer の恩恵を受けながら、既定のサーバー構成を維持できます。
これらの利点を考慮すると、VM に PgBouncer をデプロイした場合、Azure インフラストラクチャ上で実行されているアプリケーションのパフォーマンスと互換性を強化するための便利で効率的なソリューションを実現できます。
Limitations:
- 管理オーバーヘッド: VM に PgBouncer を インストールすると、複数の構成ファイルを管理するための管理オーバーヘッドが発生する可能性があります。 このセットアップにより、バージョンのアップグレード、新しいリリース、製品の更新に対応するのが困難になります。
- 機能パリティ:従来の PostgreSQL から Azure Database for PostgreSQL フレキシブル サーバーに移行し、PgBouncer を使用している場合は、いくつかの機能ギャップが存在する可能性があります。 たとえば、Azure Database for PostgreSQL での md5 のサポートが不足しています。
AKS 内のサービスとしてデプロイされた一元化された PgBouncer
何百ものポッドで構成されるAzure Kubernetes Service (AKS)で、高度にスケーラブルで大規模なコンテナー化されたデプロイを使用している場合、または複数のアプリケーションが共有データベースに接続する必要がある場合は、サイドカー コンテナーではなくスタンドアロン サービスとして PgBouncer を使用します。
PgBouncer を別のサービスとして使用することで、アプリケーションの接続プールをより広範な規模で効率的に管理および処理できます。 このアプローチにより、接続プール機能が一元化され、複数のアプリケーションが最適なパフォーマンスとリソース使用率を維持しながら、同じデータベース リソースに接続できるようになります。
Microsoft コンテナー レジストリで発行された PgBouncer サイドカー プロキシ イメージを使用して、サービスを作成してデプロイします。
このデプロイ方法の主な利点と制限事項の一部を次に示します。
メリット:
- 信頼性の向上:PgBouncer をスタンドアロン サービスとしてデプロイすると、高可用性の方法で構成できます。 この構成により、接続プール インフラストラクチャの全体的な信頼性が向上し、障害や中断が発生した場合でも継続的な可用性が確保されます。
- 最適なリソース使用率: アプリケーションまたはデータベース サーバーのリソースが限られている場合は、 PgBouncer サービスの実行専用の別のマシンが有利な場合があります。 十分なリソースを持つマシンに PgBouncer をデプロイすることで、最適なパフォーマンスを確保し、リソースの競合の問題を防ぐことができます。
- 一元化された接続管理: データベース接続の一元化された管理が要件の場合、スタンドアロンの PgBouncer サービスの方が合理的なアプローチです。 接続管理タスクを一元化されたサービスに統合することで、複数のアプリケーションにまたがるデータベース接続を効果的に監視および制御できるため、管理を簡略化し、整合性を確保できます。
PgBouncer を AKS 内のスタンドアロン サービスとして考慮することで、これらの利点を活用して、信頼性の向上、リソースの効率化、データベース接続の一元管理を実現できます。
Limitations:
- N/W 待機時間の増加:PgBouncer をスタンドアロン サービスとしてデプロイする場合は、より多くの待機時間が導入される可能性を考慮してください。 この待機時間は、アプリケーションと PgBouncer サービスがネットワーク経由で接続を渡す必要があるために発生します。 アプリケーションの待機時間の要件を評価し、一元化された接続管理と潜在的な待機時間の問題とのトレードオフを検討します。
スタンドアロン サービスとして実行されている PgBouncer には、一元的な管理やリソースの最適化などの利点が用意されていますが、アプリケーションのパフォーマンスに対する潜在的な待機時間の影響を評価して、特定の要件に合わせて調整します。
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 Database for PostgreSQLフレキシブル サーバーで組み込みの PgBouncer を使用することで、個別のインストールや複雑なセットアップは必要ありません。 パラメーターから直接簡単に構成できるため、手間のかからないエクスペリエンスを実現できます。
- マネージド サービスの利便性:マネージド サービスとして、他のAzureマネージド サービスの利点を享受できます。 この特典には自動更新が含まれており、手動メンテナンスが不要になり、 PgBouncer が最新の機能とセキュリティ パッチを使用して最新の状態に保たれます。
- パブリック接続とプライベート接続のサポート:Azure Database for PostgreSQLフレキシブル サーバーの組み込みの PgBouncer は、パブリック接続とプライベート接続の両方をサポートします。 このサポートにより、特定の要件に応じて、プライベート ネットワーク経由でセキュリティで保護された接続を確立したり、外部に接続したりできます。
- 高可用性 (HA): フェールオーバーが発生し、スタンバイ サーバーがプライマリ ロールに昇格した場合、PgBouncer は、アプリケーション接続文字列を変更することなく、新しく昇格したスタンバイ上でシームレスに再起動します。 この機能により、継続的な可用性が確保され、アプリケーションの中断が最小限に抑えられます。
- コスト効率: VM やコンテナーなどの追加のコンピューティング料金を支払う必要がないため、コスト効率は高くなりますが、同じマシンで実行されている別のプロセスであるため、CPU に影響があります。
Azure Database for PostgreSQLフレキシブル サーバーで組み込みの PgBouncer を使用することで、簡素化された構成、マネージド サービスの信頼性、さまざまなプーリング モードのサポート、およびフェールオーバー シナリオ中のシームレスな高可用性の利便性を享受できます。
Limitations:
- Burstable ではサポートされません:PgBouncer は現在、バースト可能なサーバー コンピューティング レベルではサポートされていません。 コンピューティング レベルを General Purpose または Memory Optimized から Burstable レベルに変更した場合、PgBouncer の機能は失われます。
- 再起動後に接続を再確立します。 スケール操作、HA フェールオーバー、または再起動中にサーバーが再起動されるたびに、 PgBouncer はサーバー仮想マシンと共に再起動します。 そのため、既存の接続を再確立する必要があります。
この記事では、PgBouncer を実装するさまざまな方法について説明します。 次の表は、選択するデプロイ方法をまとめたものです。
| 選択条件 | App VM 上の PgBouncer | ALB を使う VM 上の PgBouncer* | AKS サイドカー上の PgBouncer | サービスとしての PgBouncer | Azure Database for PostgreSQL 組み込み PgBouncer |
|---|---|---|---|---|---|
| 簡略化された管理 | 
|
|
|
|
|
| HA |
|
|
|
|
|
| コンテナー化されたアプリ |
|
|
|
|
|
| ネットワーク オーバーヘッドと待機時間の軽減 |
|
|
|
|
|
| 監視とデバッグの詳細な制御 |
|
|
|
|
|
凡例
| 難易度 | 記号 |
|---|---|
| Easy |
|
| ミディアム |
|
| 困難 |
|
*ALB: Azure Load Balancer。