はじめに
にゃーん。趣味でポスグレをやっている者だ。
今回はPostgreSQL 16のlibpqに追加されたロードバランス機能について書いてみました。
概要
| 項目 | 内容 |
|---|---|
| タイトル | Support load balancing in libpq |
| Topic | Clients |
| Last Modified | 2023-03-29 |
| ステータス | commited |
| commit id | 7f5b19817eaf38e70ad1153db4e644ee9456853e |
| 概要 | libpqにロードバランス動作を指定する接続文字列が追加された |
変更内容
PostgreSQLのクライアントライブラリlibpqの接続文字列として、load_balance_hostsが追加されました。
この接続文字列は現状、以下の2つの値に対応しています。
| 値 | 意味 |
|---|---|
| disable | ホスト間のロードバランシングは行われない。ホストは提供された順に試行され、アドレスはDNSまたはhostsファイルから受信した順に試行される。 |
| random | ホストまたはアドレスは、ランダムな順序で試行される。この方法で、複数のPostgreSQLサーバに接続を負荷分散することができる。 |
デフォルトはdisableです。PostgreSQL 15までの挙動もdisableと同じになります。
今回はこのload_balance_hostsにrandomを指定してロードバランスの挙動を確認してみます。
libpqへの変更が意味するもの
libpqへこの機能が追加されたということは、libpqを用いたクライアントアプリケーションで、その恩恵が受けられることを意味します。
PostgreSQLの標準パッケージで提供されるクライアントアプリケーションでは、libpqが使用されているため、クライアントアプリケーション側でロードバランス機能の修正なしに、ロードバランス機能が使用可能になります。
（もっとも実際に有益なのは、psqlやpgbenchくらいかもしれませんが）
検証
今回の検証は(commit 0070b66fef21e909adb283f7faa7b1978836ad75)時点(2023-04-01)のリポジトリからビルドして検証しています。
検証環境
1つのEC2インスタンス上にポートを分けたデータベースクラスタを3つ(NODE1～NODE3)立てて、それに対して、psqlを使ってランダムに接続できるかを確認します。
| データベースクラスタ | ポート番号 |
|---|---|
| NODE1 | 16010 |
| NODE2 | 16020 |
| NODE3 | 16030 |
psqlによる確認
psqlで接続する場合、明示的に--host, --port, --usernameなどのオプションで指定することが多いとは思いますが、実はデータベース名として接続文字列を渡すことも可能です。
以下はデータベース名として接続文字列を渡して接続する例です。
$ psql 'port=16010 dbname=testdb'
Null display is "(null)".
psql (16devel)
Type "help" for help.
postgres@testdb=#
なので、今回追加されたロードバランス機能も接続文字列として与えることができます。
（そのため、psql側でロードバランス用のオプション等はなくても動作する）
検証環境でしめした3つのノードに対してランダムに接続し、接続先のPostgreSQLパラメータportをSHOWコマンドで表示する例を示します。
指定する接続文字列の内容は以下となります。
| キーワード | 設定値 | 意味 |
|---|---|---|
| host | localhost,localhost,localhost | 今回は3ノードとも同一EC2上に作っているので、全て同じlocalhostを指定する。 |
| port | 16010,16020,16030 | 今回は3ノードを別ポートに設定している。 hostの数とカンマリストを合わせる必要がある。 |
| load_balance_hosts | random | これをrandomに指定するとロードバランスする。 |
| dbname | testdb | データベース名もリスト指定可能だが、今回は1つのみ指定。 この場合、どのportに接続しても接続先のデータベース名はtestdbになる。 |
$ psql 'host=localhost,localhost,localhost port=16010,16020,16030 load_balance_hosts=random dbname=testdb' -c "SHOW port"
Null display is "(null)".
port
-------
16010
(1 row)
$ psql 'host=localhost,localhost,localhost port=16010,16020,16030 load_balance_hosts=random dbname=testdb' -c "SHOW port"
Null display is "(null)".
port
-------
16030
(1 row)
$ psql 'host=localhost,localhost,localhost port=16010,16020,16030 load_balance_hosts=random dbname=testdb' -c "SHOW port"
Null display is "(null)".
port
-------
16020
(1 row)
$
データベースクラスタに接続し、そこのポート番号設定を出力することで、きちんとランダムに接続先が選択されていることがわかります。
指定したhost/portのデータベースクラスタが停止している場合
この場合、停止したデータベースクラスタが選択されてもエラーにはなりません。
これは、load_balance_hosts=random指定時の挙動がリストの中からランダムに選択するのではなく、ランダムな順序で接続を試行するからです。
例えばリストの中に停止したhost/portのデータベースクラスタがあり、それが最初に選択された場合（すぐに接続エラーとなる場合）は次のリストによる接続を試行するためです。
port=16020で接続するデータベースクラスタを停止して、先程と同じ接続文字列で接続をしてみます。
$ pg_ctl stop -D /data/pgdata/16-node2/ -l /tmp/pg16-node2.log
waiting for server to shut down.... done
server stopped
$ psql 'host=localhost,localhost,localhost port=16010,16020,16030 load_balance_hosts=random dbname=testdb' -c "SHOW port"Null display is "(null)".
port
-------
16030
(1 row)
$ psql 'host=localhost,localhost,localhost port=16010,16020,16030 load_balance_hosts=random dbname=testdb' -c "SHOW port"
Null display is "(null)".
port
-------
16030
(1 row)
$ psql 'host=localhost,localhost,localhost port=16010,16020,16030 load_balance_hosts=random dbname=testdb' -c "SHOW port"
Null display is "(null)".
port
-------
16010
(1 row)
$ psql 'host=localhost,localhost,localhost port=16010,16020,16030 load_balance_hosts=random dbname=testdb' -c "SHOW port"
Null display is "(null)".
port
-------
16010
(1 row)
$
（今回の4回の接続試行では、偶然、port=16020 が1回も選択されていない可能性はありますが、特にエラーとしてクライアントに通知されるわけではないので、そこは実はわからなかったりします・・・）
さて、勘の良い人なら気づくかもしれませんが、接続試行時にエラーが返るまで時間がかかるケース(TCP/IPレベルで接続できなくてタイムアウトまで待たされるようなケース)はどうするのか、という問題があります。
なので、load_balance_hostsを指定する場合（その場合にはhostやportに複数リストを指定すると思うので）は、connect_timeoutの設定も合わせて接続文字列に含めたほうが良さそうです。
pgbenchでロードバランスを試す
psqlの検証で説明したように、libpqを使っているアプリケーションであれば、このload_balance_hostsの恩恵を受けられます。そして、pgbenchでもlibpqを使っているので、他のロードバランサを間に入れることなく複数のデータベースサーバに処理を分散させることができるのでは？と思うわけです。
PostgreSQLのpgbench自体のオプションとして、ロードバランス指定のオプションや、複数のホスト指定は明示的に書かれてはいませんが、psqlと同じようにpgbenchでもデータベース名を指定するため、同じように接続文字列を指定したらいけるのでは？ということで試してみます。
まず、port=16010,16020,16030の各データベースクラスタ(データベース名は全てtestdb)をpgbenchの初期化モードで初期化しておきます。
$ pgbench -p 16010 -i -s 10 --unlogged-table -q testdb
dropping old tables...
creating tables...
generating data (client-side)...
1000000 of 1000000 tuples (100%) done (elapsed 0.90 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done in 1.44 s (drop tables 0.03 s, create tables 0.01 s, client-side generate 0.93 s, vacuum 0.16 s, primary keys 0.31 s).
$ pgbench -p 16020 -i -s 10 --unlogged-table -q testdb
dropping old tables...
creating tables...
generating data (client-side)...
1000000 of 1000000 tuples (100%) done (elapsed 0.89 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done in 1.45 s (drop tables 0.03 s, create tables 0.01 s, client-side generate 0.92 s, vacuum 0.18 s, primary keys 0.31 s).
$ pgbench -p 16030 -i -s 10 --unlogged-table -q testdb
dropping old tables...
creating tables...
generating data (client-side)...
1000000 of 1000000 tuples (100%) done (elapsed 0.90 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done in 2.10 s (drop tables 0.03 s, create tables 0.01 s, client-side generate 0.92 s, vacuum 0.16 s, primary keys 0.97 s).
$
この3つのデータベースクラスタに対して1つのpgbenchを実行してランダムに処理を振り分けてみます。
pgbenchの実行オプションは以下とします。
| オプション | 設定値 | 補足 |
|---|---|---|
| -b | tpcb-like | デフォルトトランザクション。 pgbench_historyへの1件の挿入も行われる |
| -C | (なし) | トランザクション毎に毎回接続を行う。 |
| -c | 2 | 同時接続数を2にする |
| -t | 500 | 1接続あたり500回トランザクションを実行する。 今回は同時接続数=2なので合計1000トランザクションが実行される。 |
| データベース名 | 'host=localhost,localhost,localhost port=16010,16020,16030 load_balance_hosts=random dbname=testdb' | ここでload_balance_hostsを指定する。 |
この設定でpgbenchを実行してみます。
$ pgbench -b tpcb-like -C -c 2 -t 500 'host=localhost,localhost,localhost port=16010,16020,16030 load_balance_hosts=random db
name=testdb'
pgbench (16devel)
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 10
query mode: simple
number of clients: 2
number of threads: 1
maximum number of tries: 1
number of transactions per client: 500
number of transactions actually processed: 1000/1000
number of failed transactions: 0 (0.000%)
latency average = 7.161 ms
average connection time = 2.285 ms
tps = 279.275158 (including reconnection times)
$
なお、最初にVAACUUMを実行していますが、このVACUUMがどのデータベースクラスタのtestdbに対して実行されたのかはわかりませんｗ
実際に測定する場合には、VACUUM自体は別途各データベースクラスタに対して事前実行し、pgbench実行時には-n(--no-vacuum)をしたほうが良さそうです。
さて、pgbenchの実行が終わったので、各データベースクラスタのpgbench_historyの件数を見てみます。
$ psql -p 16010 -U postgres testdb -c "SELECT COUNT(*) FROM pgbench_history"
Null display is "(null)".
count
-------
349
(1 row)
$ psql -p 16020 -U postgres testdb -c "SELECT COUNT(*) FROM pgbench_history"
Null display is "(null)".
count
-------
320
(1 row)
$ psql -p 16030 -U postgres testdb -c "SELECT COUNT(*) FROM pgbench_history"
Null display is "(null)".
count
-------
331
(1 row)
$
お、なんかそれっぽくロードバランスされているようですね。
おわりに
PostgreSQL 16に入る予定のlibpqのロードバランス機能の確認と、pgbench単体でのロードバランス方法について調べてみました。
別件で調べている、PostgreSQL 16の疑似マルチマスタ構成へのpgbenchでの性能検証時にも、このやり方が使えそうです。