全国の Aerospike ユーザーのみなさまこんにちは。アドテク本部の makocchi です。

 

先日開催された Aerospike Meetup in Tokyo #3 において、Aerospike CDO の Srini 氏より

最近の Aerospike の version では migration のパフォーマンスが改善されているという話をして頂いたのですが、

果たして本当に改善されたのか？、改善されたとしたらどれくらい改善されたのか？って気になっちゃいますよね！

ということでさっそくいろいろな version の migration 速度を検証してみました！

 

検証に使用した Aerospike の version について

今回の検証では Aerospike の数ある version の中から 3.N 系の最新を比較対象として選択しました。

すなわち 3.7 系では 3.7.5.1、3.6 系では 3.6.4 といった具合です。

最新の 3.8 系に関しては検証時の最新である 3.8.4 を選択しています。

 

検証用のデータについて

検証用のデータに関しては単純な single record を単一の namespace (aerobench)と単一の set (test) にひたすら入れています。

こんな感じのデータです。

データを投入する方法はいろいろありますが、aerospike-loader なんてのもありますので是非使ってみてください。

今回の検証用のデータは 10,000,000 record (10 Million)用意しました。

投入後に asbackup を使って backup を取っておきます。

検証用のデータを復元させて初期化する時にはこちらの backup を使います。

 

namespace の設定は下記の通りです。

今回は device を使わずに in-memory にしました。

default-ttl は 0 にしてますが、これは検証用のデータが expire or evict されると嫌だなと思って 0 にしてあります。

memory 使用率が high-water-memory-pct を超えなければ問題ないのですが、もし同じような検証される方がいたら注意して下さい。

最近の Aerospike(3.6.1以降) では set-disable-eviction なんて option も出てきています。今回は古い version も検証する為、設定には入れませんでした。

namespace 以外の部分は network の heartbeat を mesh に変更しただけで、他は default の設定にしました。

 

replication-factor は 3 にしているのですが、Aerospike の default は 2 なんですよね。

余談ですが、日本の企業の方は 3 にしていることが多いそうです。(弊社もほぼ全ての cluster で 3 になってます)

海外は 2 が多いらしいです。

 

検証の方法

今回の検証では準備として 3 node で cluster を構成した後、下記の項目についてそれぞれ migration の時間を計測しました。

・新規の 4 台目の node を追加する (join)

・4 node になった後に 1 node を落として 3 node に戻す (leave)

純粋な migration の速度を見たかったので migration 中は read/write の operation は cluster に対し行っていません。

検証が終わったら asd を全 node で落としてデータを綺麗にした後に、asrestore からデータを復元して次の検証に進んでいます。

 

migration の時間の定義ですが、4 台目の node の asd が起動(または停止)してから

すべての node の migrate_rx_objs および migrate_tx_objs が 0 になるまでの時間としました。

今回の検証では log には migrations – complete と出ていても migrate_rx_objs や migrate_tx_objs が 0 になってなければ完了と判断していません。

これに関しては正直悩んだんですがちょっと厳密にしてみました。

(3.8.4 についてはmigrate-rx-instance-count および migrate-tx-instance-count になります)

 

また、個人的にも興味があったので migrate-threads の値(default は 1)を変えることでどれくらい migration の速度に影響があるのか知りたかったので

migrate-threads が 1, 2, 4 の場合で 3 パターン計測しました。

 

検証に使用した node の Spec

検証に使用した node は全て 4 core / 14GB mem / 10G network となっています。

OS には CentOS 6 を使用しました。

 

検証結果：新規の 4 台目の node を追加する (join)

まずは新規 node 追加時の migration に掛かった時間(sec) の結果です。

3.4 系から 3.5 系に version が上がったタイミングで migration の速度がかなり改善されていることがわかります。

Release Notes によると 3.5.8 において migration の performance が改善されているようでした。

Performance enhancements:

Clustering – Migration performance improved by modifying initial partition balancing scheme for nodes joining a cluster.

特に migrate-threads が少ない場合は顕著に時間差が出ていますね。

 

また、さらに 3.7 系になったタイミングで migration の速度が改善されています。

これは 3.7.0.1 において Migration Improvements の記述が Release Notes に書かれていることからも分かります。

 

3.8 系は検証した全ての version の中で migration が最速で完了しています。

Release Notes では特に migration に関わる記述は無かったのですが、3.8 系は XDR(Cross Datacenter Replication) の機能を

内部的に仕組みを変えて改善しているので、きっとその改善の副産物なのではと思いました(あくまで個人的な予想です)。

 

こちらのグラフは version 毎に migrate-threads の設定によって migration の速度がどう変わったのか、

先程のグラフを並べ直したグラフになります。

migrate-threads を 1 から 2 に増やすことで migration の時間を半分くらいに減らすことはできました。

さすがに thread を 4 にすることで 4 分の 1 までは減ってくれませんでしたが、

migration の速度を上げたい場合は migrate-threads を調整するのが一番簡単なのではないでしょうか。

ただし気を付けなければならないのは migrate-threads を上げればそれだけ cluster に対する負荷があがり、

migration 中は read/write の latency が上がる可能性があるということです。

latency は上げたくない、でも migration を早く終わらせたい、なんて場合は migrate-threads を如何に上手く調整できるのかが運用のキモになってきます。

その点、3.8 系になるともう thread が 1 でも充分な速度が出ていますので

3.8 系を運用する場合は大分気が楽になるのかなと思います。

 

検証結果：4 node になった後に 1 node を落として 3 node に戻す (leave)

さて次は縮退時の migration の速度の結果です。

新規 node 追加の検証結果に比べるとあまり version 間での時間差は大きくなりませんでした。

また migration が完了する時間が新規 node 追加の時よりも早いという結果になりました。

縮退の場合ですと 3.5.8 での migration の改善よりも 3.7.0.1 の migration の改善の方がインパクトがあったようですね。

 

こちらの検証も version 毎に並べ直してグラフにしてみました。

縮退時の migration の速度も migrate-threads の値が効果的に働いているということが分かります。

 

 

まとめ

version が上がるにつれて migration の速度もどんどん改善されていることが検証で判明しました。

特に 3.8 系は migration に掛かる時間が 3 系の初期の version よりもかなり改善されています。

 

 

障害が発生して node が落ちたりした際にはなるべく早く migration は終わって欲しいものですよね。

ちなみに Aerospike は異なる version の node が混在しても cluster を組むことができます。(注意するポイントはありますが)

ですので 1 台ずつ version を上げていくことも可能です。

古い version で動かしている cluster があるのであれば、是非 version を上げることを検討してみてください！

 

 

さて、今回の弊社の検証ではこのような結果になりましたが、いかがでしたでしょうか。

実は migration に関わる option は migrate-threads 以外にもいろいろあります。

migrate-threads 以外の option がどのくらい速度に影響があるのかも気になるところですね。

複数の namespace を使った場合や secondary index を使っていた場合に migration の速度がどう変化するのか、

そういった検証も今後やっていきたいと思います。

 

また、Aerospike の blog に書かれているのですが version 3.8.3 から Rapid Rebalance というアルゴリズムが採用されました。

今回の検証では migration 中に write が発生していない為、Rapid Rebalance の効果については検証できていないのですが

次の記事では Rapid Rebalance の検証もしたいと思っています。