PgBouncerのスループットを4倍にスケールさせる方法
We scaled PgBouncer to 4x throughput
PgBouncerはシングルスレッドで動作するため、1つのCPUコアしか使用しない。ClickHouse Managed Postgresでは、この問題を解決するためにPgBouncerプロセスを複数起動し、カーネルのso_reuseport機能を用いて単一ポートにバインドすることで、複数のコアに負荷を分散させている。これにより、受信接続は単一のエンドポイントに接続されるが、実際には複数のPgBouncerプロセスにロードバランシングされる。この構成の課題はクエリキャンセル処理であり、Peering機能を用いて、異なるプロセスにルーティングされたキャンセルリクエストを正しいセッションに転送することで解決している。トランザクションモードでのプーリングと、接続予算のフリート全体での分割により、Postgresへの過剰な負荷を防いでいる。16vCPUのインスタンスでテストした結果、シングルプロセス構成では最大87kトランザクション/秒だったのに対し、16プロセス構成では約336kトランザクション/秒と約4倍のスループットを達成した。CPU使用率も、シングルプロセスでは1コアに集中していたのに対し、フリート構成では複数のコアに分散され、全体で約52%(EC2 CloudWatchメトリクスでは約60%)に達した。このフリート構成はClickHouse Managed Postgresでデフォルトで提供されている。
- ClickHouse Managed PostgresがPgBouncerのマルチプロセス構成により、シングルプロセス時87k TPSから約336k TPSへ約4倍のスループット向上を達成
- カーネルのso_reuseport機能を用いて複数のPgBouncerプロセスを単一ポートにバインドし、負荷を複数コアに分散する方式を採用
- Peering機能により異なるプロセスにルーティングされたクエリキャンセルリクエストを正しいセッションに転送する課題を解決
- 16vCPUインスタンスでテストし、シングルプロセスでは1コア集中だったCPU負荷がフリート構成では複数コアに分散、全体約52〜60%の使用率に
ClickHouse Managed PostgresがPgBouncerのマルチプロセス化により約4倍のスループット向上(87k→336k TPS)を達成した点は、PostgreSQL周辺ツールのスケーラビリティ課題に対する実用的な解決策を示している。so_reuseport+Peeringによるクエリキャンセル処理の工夫は、本番運用での実装コストを下げる設計であり、Managed PostgreSQLサービスを提供する事業者にとって競争力強化につながる技術的優位性と言える。