Fragments of verbose memory

冗長な記憶の断片 - Web技術のメモをほぼ毎日更新

Feb 24, 2026 - 日記

Tokioランタイムがデータベースプロキシを変える: PgDogのベンチマークから見るRust非同期I/Oの実力

pgdog-rust-tokio-async-benchmark cover image

PostgreSQLのコネクションプーラーとして長年使われてきたPgBouncer 。しかし、50接続を超えると性能が頭打ちになる問題をご存知でしょうか。

この課題を解決するために登場したのが、Rust製の新しいデータベースプロキシPgDog です。PgBouncerと比較して、50接続以上の環境で約10%高速に動作します。

本記事では、PgDogの公式ベンチマーク結果を元に、Rust/Tokioの非同期I/Oアーキテクチャがデータベースプロキシにもたらす性能向上を解説します。

PgDogとは

PgDog は、PostgreSQL向けのコネクションプーラー、ロードバランサー、シャーダーを統合したプロキシです。Rustで実装され、Tokio 非同期ランタイムを採用しています。

主な特徴は以下の通りです。

  • マルチスレッド対応: 複数CPUコアを活用
  • 非同期I/O: epoll/kqueueによる高効率なソケット管理
  • トランザクションプーリング: PgBouncerと同様のモード
  • シャーディング機能: アプリケーション変更なしで水平スケール

Coinbase、Ramp、Modal、BitStackなどの企業で採用されています。

ベンチマーク結果: PgBouncer vs PgDog

公式ブログのベンチマーク記事 から、主要な結果を見ていきます。

テスト環境

  • マシン: AMD Ryzen 7 5800X（8コア16スレッド）、64GB RAM
  • OS: Arch Linux（最新カーネル）
  • ツール: pgbench（SELECT専用、-Sオプション）
  • 構成: すべてlocalhost上で実行（ネットワーク遅延を排除）

結果サマリー

接続数PgDog (TPS)PgBouncer (TPS)差分
115,52216,729-7.2%
10100,615101,449-0.8%
50112,11289,287+25.5%
100110,68889,146+24.1%
250108,28188,381+22.5%
1,000102,18981,021+26.1%
2,00092,78376,178+21.8%

注目ポイント: 50接続を境に、PgDogが明確に優位になります。1〜10接続ではPgBouncerがわずかに速いものの、実運用で重要な50接続以上では20〜26%の性能向上を達成しています。

なぜTokioが速いのか

非同期I/Oの仕組み

PgDogが採用するTokio は、Rust向けの非同期ランタイムです。以下の特徴により、I/Oバウンドなワークロードで高いパフォーマンスを発揮します。

タスクベースの並行処理

Tokioは「タスク」という軽量な実行単位を使います。タスクはOSスレッドよりはるかに軽量で、数万〜数十万のタスクを同時に管理できます。

1
2
3
4
5

// Tokioのタスク例（疑似コード）
tokio::spawn(async {
    let data = socket_a.read().await; // I/O待機中は他のタスクへ
    socket_b.write(data).await;       // 書き込み完了まで待機
});

epollによる効率的なイベント管理

Linuxのepollシステムコールにより、数万のソケットを効率的に監視します。I/O可能になったソケットだけを処理するため、無駄なポーリングが発生しません。

PgBouncerとの設計比較

項目PgBouncerPgDog
アーキテクチャシングルスレッドマルチスレッド（Tokio）
I/Oモデルlibevent （epoll）Tokio（epoll）
並行処理イベントループ非同期タスク
並行性シングルスレッド制約マルチスレッドで高い並行性

PgBouncerはシングルスレッドのため、1つのCPUコアしか使えません。対してPgDogは複数コアを活用し、接続数が増えるほど性能差が開きます。

実運用での考慮点

PgDogが有利なケース

以下の条件に当てはまる場合、PgDogへの移行を検討する価値があります。

  • 接続数が50以上: ベンチマークで明確な優位性
  • マルチコアサーバ: 4コア以上で効果が顕著
  • 高スループットOLTP: トランザクション数が多い環境
  • 将来的なシャーディング: 水平スケールを見据えた設計

PgBouncerが依然有利なケース

一方、以下の状況ではPgBouncerの方が適しています。

  • 接続数が10以下: わずかながらPgBouncerが高速
  • 枯れた安定性重視: 20年以上の運用実績
  • シンプルな構成: プーリング機能のみで十分

移行時の注意点

PgDogは2024年にオープンソース化されたばかりです。以下の点に注意してください。

  • 成熟度: PgBouncerほどの運用実績はまだない
  • 機能差: 一部のPgBouncer機能が未実装の可能性
  • コミュニティ: ドキュメントやトラブルシューティング情報が限定的

本番環境への導入前に、ステージング環境での十分な検証をおすすめします。

Rust/Tokioの他の活用例

データベースプロキシ以外でも、Rust/Tokioは高性能なネットワークアプリケーションで採用が進んでいます。

  • Linkerd : Kubernetesサービスメッシュ
  • Vector : 高性能ログ収集パイプライン
  • Tremor : イベントストリーミング処理

これらはいずれも、I/Oバウンドなワークロードで従来のC/C++実装を上回る性能を達成しています。

まとめ

PgDogのベンチマーク結果から、Rust/Tokioの非同期I/Oアーキテクチャがデータベースプロキシにもたらす性能向上を確認しました。

重要なポイント:

  • 50接続以上でPgBouncerより20〜26%高速
  • Tokioのマルチスレッド非同期I/Oが性能の鍵
  • 高スループットOLTP環境で特に有効
  • 新しいプロジェクトのため、本番導入は慎重に

PostgreSQLの接続プーリングを見直す際、PgDogは有力な選択肢の一つです。特に、将来的なシャーディングを見据えた設計では、コネクションプーラーとシャーダーを統合できるメリットが大きいでしょう。

まずは開発環境でPgDogを試し、ベンチマークを取ってみることをおすすめします。

参考リンク