出典について
この記事はThe Percona Data Performance Blog内のVadim Tkachenko氏によるPercona XtraDB Cluster in a high latency network environment(2016/3/14)を翻訳したものです。
このブログ投稿では、レイテンシーが大きなネットワーク環境下でPercona XtraDB Clusterをどのように扱うかについて議論したいと思います。
最近、10GBネットワークをまたいで稼働しているPercona XtraDB Clusterがある環境で仕事をしていましたが、ノードの1つが離れた場所にあり、ping応答時間(ping time)が一般的に期待するより大きい状態でした。
例えば、次の例はローカルクラスター内のノード間のping応答時間を表しています。
ping 172.16.0.1 -s 1024
PING 172.16.0.1 (172.16.0.1) 1024(1052) bytes of data.
1032 bytes from 172.16.0.1: icmp_seq=1 ttl=64 time=0.144 ms
1032 bytes from 172.16.0.1: icmp_seq=2 ttl=64 time=0.110 ms
1032 bytes from 172.16.0.1: icmp_seq=3 ttl=64 time=0.109 ms
1032 bytes from 172.16.0.1: icmp_seq=4 ttl=64 time=0.125 ms
概してping応答時間は、0.1msである、といえます。
仮に、あるノードのping応答時間が7msだったとしましょう。デフォルトの設定のPercona XtraDB Clusterではこのケースをうまく扱えません。しかしながら、いいお知らせがあります。少し設定を変えるだけで劇的に性能が改善できます。あとは何を変えれば良いかがわかれば良いだけです！
このケースについて振り返ってみましょう、テストには次のsysbenchを利用します。
sysbench --test=tests/db/oltp.lua --oltp_tables_count=100 --oltp_table_size=1000000 --num-threads=50 --mysql-host=172.16.0.4 --mysql-user=sbtest --oltp-read-only=off --max-time=3600 --max-requests=0 --report-interval=10 --rand-type=uniform --rand-init=on run
最初に全てのノードでレイテンシーが等しい(0.1ms)場合、次に1ノードが7msのレイテンシーがある場合を紹介します。Linuxではこの状態を次のコマンドで簡単に実現できます。
# ネットワークパケットに7msの遅延を発生させます
tc qdisc add dev eno2 root netem delay 7ms
# 遅延を解消させるためには次のコマンドを実行します
# tc qdisc del dev eno2 root netem
両方の場合に対してスループットおよびレスポンスを比べてみましょう。
数値化すると次のようになります
| 設定 | スループット(平均), tps | 95%レスポンス時間(平均), ms |
|---|---|---|
| 遅延なし | 2698 | 27.43 |
| 7msの遅延 | 739 | 571.40 |
ご覧の通り、大きな違いがあります！スループットとレスポンスが分散していることも非常に重要です。一見したところ、これに対応するパラメータは2つあります。
- evs.send_window (https://www.percona.com/doc/percona-xtradb-cluster/5.6/wsrep-provider-index.html#evs.send_window)
- evs.user_send_window (https://www.percona.com/doc/percona-xtradb-cluster/5.6/wsrep-provider-index.html#evs.usersendwindow)
evs.send_window変数はレプリケーションで一度に送るデータパケットの最大数を定義しています。WAN環境では、デフォルト値よりかなり大きな値を設定するとよいでしょう(例えば512)。
それではあるノードに7msの遅延がある場合について、クラスターを--wsrep_provider_options="evs.send_window=512;evs.user_send_window=512"オプションで起動してみましょう。
スループットとレスポンスはどのように変化するでしょうか？見てみましょう。
数値化すると次のようになります
| 設定 | スループット(平均), tps | 95%レスポンス時間(平均), ms |
|---|---|---|
| 遅延なし | 2698 | 27.43 |
| 7msの遅延 | 739 | 571.40 |
| 7msの遅延(最適化済) | 2346 | 46.85 |
パフォーマンス上のペナルティーがまだいくらか発生していることがみてとれます。最終的に高速なレスポンスタイムをあるノードからえることはできませんが、デフォルトの設定と比べると大きく改善しています。
高帯域なネットワークでping応答時間が大きなノードがある場合は、evs.send_windowとevs.user_send_windowを変更することを検討してみてください。
