Rapid Rebalance Aerospike v3.8.3

2016/08/02Aerospike Meetup #4 in Tokyo上原 誠

Web系企業でAerospikeとか Cassandraとかクラウドとか Hadoopとかやってました今日は日本のコミュニティ代表

上原 誠 (@pioho07)

ポケモントレーナーレベル :１２チーム：赤

マイグレーションのつらたん (´ ・ ω ・ `)運用上必ずある”静的なコンフィグ変更”、” AS バージョンアップ”、”ノードメンテナンス”で必ずマイグレーションは走ります マイグレーション中はレプリケーションファクタがマイナス１ マイグレーションの時間が長い (3TB くらいだと 20h 超え ) クラスタ内のノード全台にバージョンアップする場合、マイグレーション終了を待つ必要があるので、所要時間は↑掛けるノード数 (5 台ノードクラスタだと 1 週間 ) マイグレーション速度のスレッド調整は手動 マイグレーション中の負荷がサービスに若干影響出ることも

マイグレーションについては今回説明しないのでこの辺見てね

Rapid Rebalance in v3.8.3 in June.

Rapid っていい響じゃないか！

Introリンク切れやノード再起動のような、クラスタ構成の変更後に、パーティションのリバランスや同期を行うプロセスをマイグレーションと言います。 3.8.3 から、このマイグレーションは、従来のものに比べて、 40 倍の速度で行うことができるようになりました。システム運用チームは、アップグレードや静的設定の変更等を非常に短時間で行うことができるようになります。また、マイグレーション動作時のレイテンシへの影響を小さくすることができるようになりました。

Intro マイグレーションはリンク障害、ノードリスタート時のリバランスと同期プロセス EE の v3.8.3 ではこのマイグレーションが 40 倍速くなった※ 新規ノード追加とかフォーマットされたノード追加、また多分ノード削除時も Rapid 対象外。つまりメンテナンスや障害によるプロセスのリスタートやネットワークの瞬断のような一時的な状況を Rapid Rebalance は想定している。

要約

High-Level Design移行データの受信側から送信側にパーティション内のデータのメタデータを digest の順番で送信し、送信側では、自分側のパーティション内のデータと比較し、どのデータを送るのかの判断をします。この判断には、 conflict resolution （競合回避）を使い、送信側が勝ったデータのみを受信側に送信します。

High-Level Design 受信側から送信側にパーティションのメタデータを送る。 送信側でデータを比較し送る必要があるデータを判断し送る。この判断には generation か last-update-time のいずれかを使って判定する。

要約

Challenges３つあります。① マイグレーションは fabric 層の上で動作し、これは、メッセージの順番を変える可能性があります。そのため、メタデータを順番通りに送ることは難題で、今回、シーケンス番号を付加することにしました。送信側が一つ前のシーケンス番号をack した場合のみ、受信側から次の番号のものを送り、送信側は最終番号を管理することになっています。もし、小さな番号を受け取った場合、 ack を返しますが、処理は行いません。これにより、メッセージは順番通りに到着することになります。タイムアウトや再送信の場合、メッセージは、順番通り、かつ、一回しか処理されません。

Challenges② 受信側から送信側にメタデータを送る際に、一つ一つのレコードのメタデータを送ると非常に遅くなるため、このメタデータを 128KB の固まり（以下、バッチ）にして送ることにしました。

Challenges③ いつでも、このメタデータを送る方法が速い訳ではありません。送信側のデータが非常に少ない場合、受信側のメタデータを送ることの方が、送信側の全てのデータをそのまま送ることよりもコストがかかる可能性もあります。そこで、平均として、メタデータの 1 つのバッチで、 1 つのみのレコードを送るようなパーティションには、この RR を適用しない（従来と同じにように、すべてのデータを送る）ことにしました。

Challneges ① メタデータを順番通り送るためシーケンス番号を付加しました。送信側が 1 つ前の ack を確認してから次のバッチを受け取る。最終番号を管理してる。もし若い番号を受け取っても処理しない。 ② メタデータをレコード単位ではなく 128KB単位 ( バッチ )で送る ③ データ量によってはメタデータのやりとりのコストが大きくなるので、 RR を使わず従来の方法で送る場合もある

要約

Implementation① 送信側から受信側に、開始メッセージ（ RR をサポートしていることとそのパーティション内のデータ数を含む）を送る。② 受信側は、 (Challenge③) を考慮して、 RR を使うか否かのack を返します。③ 受信側が RR を利用する場合、メタデータのバッチを生成するための producer と consumer のスレッドを立てます。④ producer スレッドは、対象のパーティション内のデータをスキャンし、メタデータ・バッチを作成し、キューに入れます。

Implementation⑤ consumer スレッドは、キューからバッチを取りだし、シーケンス番号を付けて、送信側に送ります。 consumer は、受信側から ack が返ってくるまでは、次のバッチの処理を開始しません。⑥ 並行して、送信側は、受信側が RR をサポートしているかを含んだ開始メッセージを受け取り、マイグレーションのためのデータのスキャンを開始します。 RR がサポートされている場合、メタデータ・キューをブロックします（ここちょっと詳細不明、 1 つづつ処理する為？でもキューでしょ？）。⑦ 送信側が受信側からのバッチを受け取った後、それをローカルのキューに入れ、受信側に ack を返します。⑧. 送信側では、バッチの内容を調べ、受信側に送るデータの判断をします。

Implementation ①～⑧あとでお読みください。。要約

Conclusion

運用者にとり、 RR を利用することで、サーバのアップグレードや静的設定の変更等の際のマイグレーションを日単位から分単位に短縮することが可能になります。

Conclusion 運用者はハッピーになるでしょう要約

検証環境 Aerospike Server SpecAerospike Server x3, Replication Factor 2OS CentOS6,m3.xlarge,SSD 100GB x3, IOPS 3000SSD Capacity 900GB(HWM 50%)MEM Capacity 42GB(HWM 60%)Before Binary ： aerospike-server-community-3.6.3-el6After Binary ： aerospike-server-enterprise-3.8.4-el6

検証環境 ClientJava Client Library 3.2.4

Aerospike Management Console 3.6.9aerospike-amc-enterprise-3.6.9-el6.x86_64.rpm

旧バージョンで試す※データやスペックなど環境によって結果は変わります。あしからず。一例として参考にしてもらえればと。./run_benchmarks -h xxx.xxx.xxx.xxx -p 3000 -n test -k 100000000 -l 30 -s 1 -o S:1500 -w RU,0 -z 16約 1億件のデータでレプリ込で３００ GB の容量1 レコード 1500byte でちょっとでかい。。

Let’s Try!プロセスのリスタート実施

12 時間くらいかかった。。SSD 本数とか IOPS とか低めにしてたのもあるかと

１台プロセスをリスタート。１０：５４ 1 時間 15 分くらいしてノードイン、 12:16 にクラスタイン

Versionup to v3.8.4

Versionup to v3.8.4

１台プロセスをリスタート。１０：５４ 1 時間 15 分くらいしてノードイン、 12:16 にクラスタイン

versionup to v3.8.4

１台プロセスをリスタート。１０：５４ 1 時間 15 分くらいしてノードイン、 12:16 にクラスタイン

新バージョンで試す※データやスペックなど環境によって結果は変わります。あしからず。一例として参考にしてもらえればと。Let’s Try!バージョンアップ後、プロセスのリスタート実施 ( データはそのまま同じ ) 。

ノードのクラスタイン確認。 02:42:26

Let’s Try!バージョンアップ後同じデータに対してプロセスのリスタート実施

Mean of Partitions log

absent: Number of partitions not owned by this nodesync: Number of non-master partitions owned by this nodeactual: Number of master partitions owned by this node actual + sync + absent = 4096 partitions for the namespace

マイグレーション完了確認。 02:43:39

１分１３秒

40 倍どころじゃないけど600 倍近い・・

READ/WRITE しながらマイグレーションしてなかった、、 (´ ・ ω ・ `)

WRITE: 20000TPS くらいREAD: 2000TPS くらい

5 分プロセス落としてから起動する

ノードクラスタイン確認。 03:01:32

マイグレーション完了確認。 03:17:39

１６分０７秒

４４倍！ほう！！

サーバー側負荷こんな感じNo Migration

Migration

※ちなみにノードのクラスタアウトもテストしましたが RR のような速度は出ていません。正確な値を出す時間はありませんでしたが RR 適用外確定です。そりゃそうだね。

まさかのドキュメント通り早い今回の定常的に数万レベルの WRTE されてる状態も Aerospike のワークロードケースとしてベターじゃないかなRapid Rebalance の処理フローを絵にしてますが、この感性は日本人にはないなぁ・・

はい、地味な機能ですよね。地味だけれども運用する人にとったらこれはうれしい私は運用してたらほんとうれしい

Rapid Rebalance so good!

But this is the Enterprise Edition functionality.

Mr. Braian

Please also add in a Community Edition.

Thankyou very match

今日はこれを言いに来ましたご清聴ありがとうございました