Yakstは、海外の役立つブログ記事などを人力で翻訳して公開するプロジェクトです。
8年以上前投稿 修正あり

レイテンシーが大きい環境下でのPercona XtraDB Cluster(Percona Data Performance Blogより)

レイテンシーが大きなネットワーク環境下でPercona XtraDB Clusterをどのように扱うか、どのような設定をすればスループットおよびレスポンスが向上させられるか、についてのPercona Data Performance Blogの記事をご紹介します。

原文
Percona XtraDB Cluster in a high latency network environment - MySQL Performance Blog (English)
翻訳依頼者
B5aa4f809000b9147289650532e83932
翻訳者
B5aa4f809000b9147289650532e83932 taka-h
翻訳レビュアー
D98ee74ffe0fafbdc83b23907dda3665 doublemarket
原著者への翻訳報告
未報告


出典について

この記事は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

両方の場合に対してスループットおよびレスポンスを比べてみましょう。

throughput

response

数値化すると次のようになります

設定 スループット(平均), tps  95%レスポンス時間(平均), ms
遅延なし 2698              27.43
7msの遅延 739             571.40

ご覧の通り、大きな違いがあります!スループットとレスポンスが分散していることも非常に重要です。一見したところ、これに対応するパラメータは2つあります。

evs.send_window変数はレプリケーションで一度に送るデータパケットの最大数を定義しています。WAN環境では、デフォルト値よりかなり大きな値を設定するとよいでしょう(例えば512)。

それではあるノードに7msの遅延がある場合について、クラスターを--wsrep_provider_options="evs.send_window=512;evs.user_send_window=512"オプションで起動してみましょう。

スループットとレスポンスはどのように変化するでしょうか?見てみましょう。

optimized throughput

optimized response

数値化すると次のようになります

設定 スループット(平均), tps  95%レスポンス時間(平均), ms
遅延なし 2698              27.43
7msの遅延 739             571.40
7msの遅延(最適化済)       2346             46.85

パフォーマンス上のペナルティーがまだいくらか発生していることがみてとれます。最終的に高速なレスポンスタイムをあるノードからえることはできませんが、デフォルトの設定と比べると大きく改善しています。

高帯域なネットワークでping応答時間が大きなノードがある場合は、evs.send_windowevs.user_send_windowを変更することを検討してみてください。

次の記事
仮想列を使ってJSONドキュメントにインデックスを作成する(MySQL Server Blogより)
前の記事
MySQL 5.7のJSON機能を試してみる(MySQL Server Blogより)

Feed small 記事フィード

新着記事Twitterアカウント