Aerospike meetup04 Tokyo

1. Rapid Rebalance
Aerospike v3.8.3
2016/08/02
Aerospike Meetup #4 in Tokyo
上原 誠

2. Web系企業で
AerospikeとかCassandraとかクラウドとかHadoopとかやってました
今日は日本のコミュニティ代表
上原 誠 (@pioho07)
ポケモントレーナーレベル:１２
チーム：赤

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

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

5. Rapid Rebalance in v3.8.3 in June.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

21. 検証環境
 Client
Java Client Library 3.2.4
 Aerospike Management Console 3.6.9
aerospike-amc-enterprise-3.6.9-el6.x86_64.rpm

22. 旧バージョンで試す
※データやスペックなど環境によって結果は変わります。あしからず。
一例として参考にしてもらえればと。
./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!
プロセスのリスタート実施

23. 12時間くらいかかった。。
SSD本数とかIOPSとか低めにしてたのもあるかと
 １台プロセスをリスタート。１０：５４
 1時間15分くらいしてノードイン、12:16にクラスタイン

24. Versionup to v3.8.4

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

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

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

28. ノードのクラスタイン確認。02:42:26
Let’s Try!
バージョンアップ後同じデータに対してプロセスのリスタート実施
Mean of Partitions log
absent: Number of partitions not owned by this node
sync: Number of non-master partitions owned by this node
actual: Number of master partitions owned by this node
actual + sync + absent = 4096 partitions for the namespace

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

30. １分１３秒

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

32. READ/WRITEしながらマイグレーション
してなかった、、(´・ω・`)
WRITE: 20000TPSくらい
READ: 2000TPSくらい
5分プロセス落としてから起動する

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

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

35. １６分０７秒

36. ４４倍！
ほう！！

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

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

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

40. Rapid Rebalance so good!

41. But this is the Enterprise Edition functionality.

42. Mr. Braian

43. Please also add in a Community Edition.

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