Aerospike deep dive migration

Aerospike Migration

Aerospike Deep Dive 2015/06/24

CyberZ 上原誠

2 株式会社サイバーエージェント

自己紹介

・～2012年2月某SIerでインフラ周りに従事・ 2012年3月サイバーエージェント入社

- Amebaスマフォプラットフォームの構築

- 統合ログ解析基盤やオンラインデータベースの

インフラミドルウェア部分を担当

- Hadoop､HBase、Flume

・上原誠 (@pioho07)

【名前】

【経歴】



5 株式会社サイバーエージェント株式会社サイバーエージェント


本日の内容


本日の内容

・Intro1. What’s a Migration

・Intro2. What’s a Partition

・Intro3. What’s Partition Map

・Case1. ノード追加 (スケールアウト)


Intro1. What’s a Migration


クラスタ基本状態・３ノードクラスタ

・Replication Factor ２

・Block Size 128K


Intro1. What’s a Migration

X

分散システムなので、レプリカを作ってデータを分散配置

データはパーティションという単位で配置

X’

Y

Y’

マスタ：Ｘ

レプリカ：Ｘ’



すべて自動なので気にしなくていいです。


Intro2. What’s a Partition

14

クラスタ

株式会社サイバーエージェント

クラスタ内のデータを４０９６個に分割した単位


・・・


Partition レコード

レコード

レコード

レコードを入れるバケツ



レコードをパーティションに均等に分散



・・・

レコード・・・レコードレコード

レコードが均等に散る

4096個のバケツ



どう均等か？



レコードをどのパーティションに入れるか？

Partition1

レコード

Partition2



Every key is hashed into a 20 byte (fixed length) string using a hash function すべてのキーはハッシュ関数を使用して20バイト（固定長）の文字列にハッシュされる RIPEMD-160を使ってる。 128ビットだとセキュリティの問題があったとかで、256ビットだと計算重いので160ビットを使った感じ

１

パーティション ID の計算


21

レコード1


Key1 ・・・・・・

20 byte digest hash １



12 bits of this hash are used to compute the partition id ハッシュ結果の先頭１２ビットを、パーティションIDを計算するために使用する

２

パーティション ID の計算


23

レコード1


Key1

・・・・・・

20 byte digest

12 bit

Partition ID 2 (0～4095のどれか)

レコードの入るパーティションIDを計算

hash １

２


※例えば２


Partition1

レコード１

Partition2

hash

レコード



パーティションをサーバーに均等に分散する



Server１ Server２ Server３

・・・

バケツが均等に散る



各サーバーのMAC AddressとPartition ID（0-4095)を使って計算した値をソートする。これによりPartition IDごとの各ノードの順番を決める ※どう計算してるかは不明この順番は何度やっても同じ結果が得られるこの順番を並べたものをパーティションマップと言う

３

Partition Map 作成



Partition ID 2 (0～4095のどれか)

Partition Map作成

“Partition ID ＋ノードのMAC Address”でソートこれでノードの順番が確定する

PID M S

0 A B C

1 C B A

2 B C A

：

Partition Map

３



Intro3. What’s Partition Map


Partition ID Master Slave

0 A B C

1 C B A

2 B C A

：

4095 C A B

Partition Mapが構築されると以下のように足切りを行う Replication Factorが2なら左2列がMasterとSlaveとして使われる

Server B

Server A Partition Map

PID 0 (Master)

PID 0 (Slave)

PID 1 (Slave)


31

Client


PID Master Slave

0 A B

1 C B

2 B C

Clientからのアクセスは1ホップ。 Client側にMapがあるので、PID2のMasterデータはServer Bにあると1発で分かる

Server B

Server A

PID 2 (Master) PID 1

(Slave) レコード1

Par t i tion ID Mas t er S l av e

0 A B

1 C B

2 B C

：

4095 C A


32

Server B


・データのリバランスや配置はPartitionの単位で行われる毎秒Clientからサーバーにアクセス、Partition MapのGenerationが新しければ自身のMapを更新・ハッシュ関数を使って均等に分散させる。オフィシャルだと１～２％程度の誤差・手動シャーディング不要、パーティション分割は自動オートシャーディング、オートバランシング

Aerospike Smart Partition Algorithm

Server A

P P Server C

P

P P P


Case1. ノード追加 (スケールアウト)


A

B

C

Case1. ノード追加(スケールアウト) 現在のクラスタ状態

・３ノードクラスタ

・Replication Factor ２


PartitionID Master Slave

0 A B C

1 C B A

2 B C A

3 A C B

4 C A B

：

：

4095 C A B

Case1. ノード追加(スケールアウト) 現在のPartition Map

Partition Map


A

B

C

D

Case1. ノード追加(スケールアウト) ノードDが追加された状態

NEW


A

B

C

D

Case1. ノード追加(スケールアウト) ・ノードが追加されると、ノードリストが更新されGossipプロトコルで伝達。全ノードのノードリストができてからMap作成に移る

ノードリスト

A,B,C

ノードリスト

A,B,C,D

ノードCは

まだ伝達されてない

ノードリスト

A,B,C,D NEW



0 A D B C

1 C B D A

2 B D C A

3 A C B D

4 D C A B

：

：

4095 C A D B

Case1. ノード追加(スケールアウト) ノードDが追加された状態のPartition Map

・Introで行ったようにMapを作成する

順番はMACアドレスを付加した形でソートするので、PIDごとの既存ノードの順序は変わらない。

赤字のように新規ノードDがその間に入ってくる



0 A D B C

1 C B D A

2 B D C A

3 A C B D

4 D C A B

：

：

4095 C A D B

Case1. ノード追加(スケールアウト) ・既存ノードの順序が変わらなので元々あるデータが活かせる。

平滑に分散させているにも関わらずマイグレーションの処理は少ない点が美しい

例えばPID0のA、B、Cの順序は変わってない


0 A B C

1 C B A

2 B C A

3 A C B

4 C A B

：

：

4095 C A B

Before After



0 A D

1 C B

2 B D

3 A C

4 D C

：

：

4095 C A

・ノードDは空っぽなのでデータがあるノードからコピーされる

・DがSlaveの場合、ClientからのアクセスはMasterに行く(PID0)。

・DがMasterの場合、ClientからのアクセスはDへのコピーが終わるまではデータがあるSlaveノードCに行き、コピーが終わるとDにアクセスが発生する(PID4)※あとで補足

※2台同時に追加したような場合、Master,Slave両方に新規ノードが割り当たりデータがない状態がありえるが、その時は赤枠の外の右側のノードからコピーがされる、通信もコピーが終わるまで赤枠外のノードを優先

Case1. ノード追加(スケールアウト)


・PID4の場合、既存サーバーCから新規サーバーDへコピー開始


Server C Server D

PID 4 (Slave)

PID4に着目

PID 4 (Master)

NEW


・ClientからのアクセスはSlave側が担う

・ある時点のスナップショットのコピーは続いてる (C=>D)

・PID4への書き込みは、D側ではJournalというメモリ上の記憶領域に


Server C Server D

PID 4 (Slave)

PID 4 (Master)

Client

Journal (コピー先はServerD)

Journal PID4のNew


・ある時点のスナップショットコピーが終わると、Journal上のデータをフラッシュする(あるまとまったブロック単位)

・Partition Mapを更新しClientがMap更新することでサーバーDはMasterとしての役割を始める


Server C Server D

PID 4 (Slave)

Client

Journal PID4のNew

PID 4 (Master)


・DがMasterとして機能している通常状態。

・Clientからの書き込みはMasterであるDのメモリに書き、SlaveであるCのメモリにも書いたらClientにAckを返す

・非同期でSSDにフラッシュ


Server C Server D

PID 4 (Slave)

Client

Journal 書き込みデータ

PID 4 (Master)

Journal

書き込みデータ

３

１

２

４４



0 A D B C

1 C B D A

2 B D C A

3 A C B D

4 D C A B

：

：

4095 C A D B


・赤枠全体の構築が終わるのを待つ訳ではなく、PIDの行ごとの更新をClientが自身に反映

※実際、モニタリングツールからは正常に見えない状態がある

Clientからの通信は問題ないが、asmonitorやAMCでの状態遷移が1分くらい正常な状態を返さなかった。

こわい・・

次のスライドで

ノードDが追加された状態のPartition Map


正常時 What’s Up !


・PIDごとの更新が終わるとクライアントのPartition Mapが更新される

赤枠全体の構築が終わるのを待つ訳ではなく、PIDの行ごとに更新をクライアントに反映

※実際、モニタリングツールからは正常に見えない状態があった。asmonitorやAMCでの状態遷移が1分くらい正常な状態を返さなかった。クライアントからの通信はほぼ問題なし。

こわい・・

ノード追加直後 What’s Up !


What’s Up ! AMCも暴れた（ ³ω³）ﾌｧｯ


What’s Up ! しばらくすると


What’s Up ! AMCもグリーン


1分くらい問題ないと言えば問題ない

なおしてほしいけど


What’s Up !

それよりもマイグレーション中の注意点↓


What’s Up ! ノード追加時の

Cacti



0 A D B C

1 C B D A

2 B D C A

3 A C B D

4 D C A B

：

：

4095 C A D B

レプリ2だとノード追加後はコピーが終わるまでは

レプリ１の状態になる


0 A B C

1 C B A

2 B C A

3 A C B

4 C A B

：

：

4095 C A B

ノードD追加前ノードD追加後


マイグレーション中はレプリ1になる


Replication Factor は３にしよう

デフォは２


実際マイグレーションは18時間くらい

マイグレ速度調整なし

クラスタ容量2TBくらい

3台=>4台にした時

鎧なしはきつい><

issue上げました(ぼそ・・)


ご清聴ありがとうございました！

俺


参考資料

https://www.aerospike.com/docs/architecture/clustering.html

https://www.aerospike.com/docs/architecture/data-distribution.html

http://www.slideshare.net/PeterMilne1/principles-of-high-load-vilnius-january-2015

https://www.aerospike.com/docs/architecture/clustering.html

Technology

Aerospike deep dive migration