オープンソースデータベースプロキシ比較：PgBouncer vs ProxySQL vs Pgpool-II で接続を最適化する

大量の同時接続がデータベースのパフォーマンスをボトルネックにすることがあります。データベースプロキシを使うと、コネクションプーリング・クエリキャッシュ・ロードバランシング・フェイルオーバーを実現でき、アプリサイドのコード変更なしにスケールアウトできます。

データベースプロキシが必要な理由

PostgreSQL/MySQLはコネクションごとにプロセス/スレッドを生成するため、数千の同時接続でメモリとCPUが枯渇します。プロキシは以下を解決します:

• コネクションプーリング: 100クライアント→10DBコネクションに圧縮
• ロードバランシング: 読み取りをレプリカに分散
• クエリキャッシュ: 同じSELECTを繰り返しDBに投げない
• 自動フェイルオーバー: プライマリ障害時にレプリカへ切り替え

主要ツールの概要

PgBouncer

PostgreSQL専用の超軽量コネクションプーラーです。シングルバイナリで数MBのメモリしか使わず、GitHubやHerokuなど大規模プロダクションで実績があります。

# pgbouncer.ini
[databases]
mydb = host=postgres-primary port=5432 dbname=mydb

[pgbouncer]
listen_port = 6432
listen_addr = 0.0.0.0
auth_type = md5
auth_file = /etc/pgbouncer/userlist.txt

# pool_mode の選択
# session   - 1接続を1セッション中保持（最も安全）
# transaction - トランザクション単位で接続を返却（高スループット・推奨）
# statement  - 文単位（トランザクション不可・特殊用途）
pool_mode = transaction
max_client_conn = 10000
default_pool_size = 25
server_idle_timeout = 600

# Dockerで起動
docker run -d   -p 6432:6432   -v ./pgbouncer.ini:/etc/pgbouncer/pgbouncer.ini   -v ./userlist.txt:/etc/pgbouncer/userlist.txt   edoburu/pgbouncer

# 統計情報の確認
psql -p 6432 -U pgbouncer pgbouncer -c "SHOW STATS;"
psql -p 6432 -U pgbouncer pgbouncer -c "SHOW POOLS;"

ProxySQL

MySQL/MariaDB向けの高機能プロキシです。クエリルーティング・クエリキャッシュ・マルチプレクシング・リードレプリカへの自動振り分けを提供します。

# Dockerで起動
docker run -d   --name proxysql   -p 6033:6033   -p 6032:6032   proxysql/proxysql

# 管理インターフェースに接続
mysql -u admin -padmin -h 127.0.0.1 -P 6032 --prompt "ProxySQL Admin> "

-- MySQLサーバーを登録
INSERT INTO mysql_servers (hostgroup_id, hostname, port, weight) VALUES
  (0, 'mysql-primary', 3306, 100),    -- 書き込みグループ
  (1, 'mysql-replica1', 3306, 100),   -- 読み取りグループ
  (1, 'mysql-replica2', 3306, 100);

-- クエリルールの設定（SELECTをレプリカへ）
INSERT INTO mysql_query_rules (active, match_pattern, destination_hostgroup, apply)
  VALUES (1, '^SELECT', 1, 1);

-- 変更を反映
LOAD MYSQL SERVERS TO RUNTIME;
LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;
SAVE MYSQL QUERY RULES TO DISK;

Pgpool-II

PostgreSQLのコネクションプーリング・ロードバランシング・レプリケーション・フェイルオーバーを統合したプロキシです。PgBouncerより機能が多い分、設定が複雑です。

# 自動フェイルオーバーを含む設定
backend_hostname0 = 'pg-primary'
backend_port0 = 5432
backend_weight0 = 1
backend_flag0 = 'ALLOW_TO_FAILOVER'

backend_hostname1 = 'pg-replica1'
backend_port1 = 5432
backend_weight1 = 1
backend_flag1 = 'ALLOW_TO_FAILOVER'

load_balance_mode = on
master_slave_mode = on
master_slave_sub_mode = 'stream'

# WATCHDOGで高可用性プロキシクラスター
use_watchdog = on
wd_hostname = 'pgpool-1'
wd_port = 9000

機能比較表

比較項目	PgBouncer	ProxySQL	Pgpool-II
対応DB	PostgreSQL専用	MySQL/MariaDB	PostgreSQL専用
コネクションプーリング	✅ 高性能	✅	✅
クエリルーティング	❌	✅ 高機能	✅
クエリキャッシュ	❌	✅	✅
読み書き分離	❌	✅	✅
自動フェイルオーバー	❌	✅	✅
並列クエリ	❌	❌	✅
設定の容易さ	★★★★★	★★★☆☆	★★☆☆☆
メモリ使用量	極小（数MB）	中程度	中程度
実績・普及	★★★★★	★★★★☆	★★★☆☆
ライセンス	ISC	GPL 3.0	BSD
GitHub Stars	6k+	6k+	2k+

Kubernetes環境でのデプロイ

# PgBouncerをKubernetesでデプロイ
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pgbouncer
spec:
  replicas: 2
  template:
    spec:
      containers:
      - name: pgbouncer
        image: edoburu/pgbouncer
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-secret
              key: url
        - name: POOL_MODE
          value: "transaction"
        - name: MAX_CLIENT_CONN
          value: "5000"
        ports:
        - containerPort: 5432
        resources:
          requests:
            memory: "64Mi"
            cpu: "100m"
          limits:
            memory: "128Mi"
            cpu: "500m"

データベース管理ツールはDevOpsカテゴリ（/categories/devops）で一覧でき、セキュリティ関連ツールはセキュリティカテゴリ（/categories/security）でも探せます。

FAQ

Q. PgBouncerのpool_modeはどれを選べばいいですか？

A. 通常はtransactionモードを推奨します。sessionモードはDBコネクションをセッション全体で保持するため、プーリングの効果が低いです。transactionモードはトランザクション終了後にコネクションをプールに返却します。ただしSET文・LISTEN/NOTIFY・プリペアドステートメント（サーバー側）が一部制限されます。statementモードはトランザクションを使わないクエリのみが対象で、非常に特殊な用途です。

Q. ProxySQLのクエリキャッシュはRedisとどう違いますか？

A. ProxySQLのクエリキャッシュはDBレイヤーで自動的に機能し、アプリコードの変更が不要です。Redisはアプリがキャッシュロジックを実装する必要があります。ただしProxySQLのキャッシュはクエリの完全一致が前提で、Redisのようにキャッシュを明示的に無効化（PURGE）するAPIはありません。本番ではProxySQLのキャッシュをウォームアップ用途に、メインキャッシュはRedisで管理するのが一般的です。

Q. PgBouncerとPgpool-IIを同時に使うことはできますか？

A. 可能ですが、通常は必要ありません。PgBouncerをコネクションプーラーとして配置し、その背後にPgpool-IIでレプリカへのロードバランシングを設定するアーキテクチャは存在します。ただし設定の複雑さが増すため、最初はPgBouncerだけで始め、読み書き分離が必要になった時点でHAProxy等を追加する方が管理しやすいです。

Q. RDS・Cloud SQLなどマネージドDBでもプロキシは必要ですか？

A. RDS Proxyなどクラウドネイティブのプロキシが提供されており、コネクションプーリングの問題の多くはそちらで解決できます。ただし料金が追加でかかること・設定の自由度が低いこと・マルチクラウド構成では使えないことが理由で、オープンソースプロキシを選ぶケースも多いです。

Q. MaxScaleはProxySQLと比べてどうですか？

A. MariaDB MaxScaleもMySQLプロキシの有力な選択肢です。ProxySQLと同等以上の機能を持ちますが、ライセンスがBSL（Business Source License）でいくつかの商用利用に制限があります。オープンソースのみを使いたい場合はProxySQLを選ぶことが多いです。

まとめ

ユースケース	推奨ツール
PostgreSQLコネクションプーリング	PgBouncer
MySQL読み書き分離・クエリルーティング	ProxySQL
PostgreSQLHA・フェイルオーバー	Pgpool-II
Kubernetes環境での導入容易性	PgBouncer

関連外部リソース

• PgBouncer GitHubリポジトリ↗
• ProxySQL GitHubリポジトリ↗
• Pgpool-II公式ドキュメント↗
• PostgreSQLコネクション管理ベストプラクティス↗