HAProxyおよびPGBouncerを使用したPostgreSQLの高可用性/スケーラビリティ

Webアプリケーション用に複数のPostgreSQLサーバーがあります。通常、1つのマスターとホットスタンバイモードの複数のスレーブ（非同期ストリーミングレプリケーション）。

接続プーリングにPGBouncerを使用します：ローカルホスト上のデータベースに接続する各PGサーバー（ポート6432）にインストールされた1つのインスタンス。トランザクションプールモードを使用します。

スレーブ上の読み取り専用接続の負荷を分散するために、HAProxy（v1.5）を次のような設定で使用します：

listen pgsql_pool 0.0.0.0:10001
        mode tcp
        option pgsql-check user ha
        balance roundrobin
        server master 10.0.0.1:6432 check backup
        server slave1 10.0.0.2:6432 check
        server slave2 10.0.0.3:6432 check
        server slave3 10.0.0.4:6432 check

したがって、私のWebアプリケーションはhaproxy（ポート10001）に接続します。これは、各PGスレーブ上に構成された複数のpgbouncerで接続を負荷分散します。

ここに私の現在のアーキテクチャの表現グラフがあります：

これは次のように非常にうまく機能しますが、いくつかの実装がまったく異なることを認識しています。Webアプリケーションは、複数のPGサーバーで負荷分散するHAproxyに接続する単一のPGBouncerインスタンスに接続します。

最善のアプローチは何ですか？最初のもの（私の現在のもの）または2番目のものですか？あるソリューションが他のソリューションより優れている点はありますか？

ありがとう

HAProxy-> PGBouncer-> PGServer approchの既存の構成の方が優れています。そしてそれは機能します。その理由は次のとおりです。HAProxyは接続を異なるサーバーにリダイレクトします。これにより、データベース接続のMACアドレスが変更されます。そのため、PGBouncerがHAProxyより上にある場合、プール内の接続はMACアドレスの変更により無効になります。

pgbouncerは、postgresサーバーとのプールで接続を維持します。TCP接続の確立時間は、大規模な環境では重要です。

多数のDBリクエストを行うクライアントは、リクエストごとにリモートPGBouncerとの接続を設定する必要があります。これは、PgBouncerをローカルで実行する（アプリケーションがpgbouncerにローカルで接続する）よりも高価であり、pgBouncerはリモートPGサーバーとの接続プールを維持します。

そのため、特にPGBouncerがクライアントアプリケーションに対してローカルである場合、IMO、PGBouncer-> HAProxy-> PGServerは、HAProxy-> PGBouncer-> PGServerよりも優れているようです。

私はドナテロが提供する答えに反対しなければなりません。

アプリケーションがローカルプールを使用してDB接続を管理していない場合は、DBを照会する必要があるたびに新しい接続を作成します。これはPgBouncerを使用した場合とまったく同じように発生するため、使用すると非常に優れた改善が得られます。

PgBouncerがPostgreSQL接続をプールして管理している場合、接続がDBに直接開かれている場合と比較して、アプリが接続を開くのに費やす時間は大幅に減少します。これは、PGが接続が要求されるたびに資格情報とすべてを確認および検証するのが非常に遅いためです。

そのため、App-> HAProxy-> [PgBouncer-> PostgreSQL]のアプローチの方が適しています。PgBouncerはPGへの接続時間を節約するためです。プーリングモードも同様に考慮することが重要です。アプリの動作に注意する必要があります。ほとんどトランザクションですか？それとも、同時実行性の高い小さなSQL文を大量に実行するのでしょうか？これらのパラメーターはすべて、パフォーマンスに影響を与えます。