Download as PDF, PPTX
![Vector Clocks
• 書き込んだ順序を持つ
• 書込/更新時バージョンを上げる
[$nodeId, $version]
例)[C:1] -> [C:2]
• 分断が発生すると異なるバージョンが複数ノードに存在する
例) [C:45,B:1], [C:45,A:1]
• その場合バージョンで因果関係を決められる
• 整合性は読込時解決する
– Read Repair
– アプリケーション実装](https://image.slidesharecdn.com/dynamovoldemort-121221031521-phpapp02/85/voldemort-Dynamo-12-320.jpg)
![Read Repair on Voldemort
• 読込時ノードに存在しないデータ又は
古いバージョンのデータを最新のデータに更新する
• stores.xmlのreplication-factorとpreferred-readsが2以上
に設定することで有効になる
• replication-factor = 3
preferred-reads = 2
データは1ノードのみ存在する場合、
Read Repairで2ノードにデータが存在するようになる
• データのバージョンが比較が出来ない場合
バージョンをすべてクライアントに返す
この場合アプリケーションでハンドルする必要がある
例) [A:10, B:1][A:10, C:1]](https://image.slidesharecdn.com/dynamovoldemort-121221031521-phpapp02/85/voldemort-Dynamo-18-320.jpg)
![Sloppy Quorum
• Quorumとは？
– 議決に必要な定足数
– W + R > N, W > N/2の場合、複製(レプリカ)の整合性が保証できる
• W : ノードへ書き込む数、R：ノードから読み出す数、N：レプリカの数
– Strict Quorum
– サーバ障害又はネットワーク障害で可用性が落ちる
• Sloppy Quorumとは？
– N=3, W=2, R=2
– C, Dノードが障害
– 生存しているノードからreference listを作成
[B,E,F]
– Strict Quorumでは失敗になるが
Key KはB, E, Fへ格納されて書き込みは成功
高可用性保証](https://image.slidesharecdn.com/dynamovoldemort-121221031521-phpapp02/85/voldemort-Dynamo-20-320.jpg)
![Sloppy Quorum and Hinted Handoff on Voldemort
• Sloppy Quorumはない
– C, Dへ繋がらなくても本来書き込むノードでreference listを生成
[B, C, D]
– 書込みはB, C, Dノードに対して行う
– 書込み失敗のエラーを返す
• Hinted Handoff
– 書込み失敗時も実行される
– ノードへ書込みが失敗したらreference list以外の
ノードからランダムでヒントを送るノードを選ぶ
– 5分間隔で1回復旧を行う](https://image.slidesharecdn.com/dynamovoldemort-121221031521-phpapp02/85/voldemort-Dynamo-22-320.jpg)
Uploaded byJoongjin Bae
voldemortの技術 - Dynamoとの比較
Amazon DynamoのクローンであるVoldemortで使われる技術をDynamoと比較しながら説明した資料です。
![[LT] Continuous Delivery](https://cdn.slidesharecdn.com/ss_thumbnails/ltcontinuousdelivery-141103111558-conversion-gate02-thumbnail.jpg?width=640&height=640&fit=bounds)
voldemortの技術 - Dynamoとの比較
- 1. 名前を言ってはいけないあの人 He-Who-Must-Not-Be-Named Voldemort Joongjin Bae twitter: bae_j http://baepiff.blogspot.com/
- 2. Index • Voldemortの紹介 • Voldemortの実現技術 – Consistent Hashing and Replication – Vector Clocking and Read Repair – Sloppy Quorum and Hinted Handoff – Gossip Protocol and Failure Detection
- 3. 名前を言ってはいけないあの人 この方じゃなくて
- 4. Voldemort • Horizontal Scalable • High Available • Distributed Key-Value Store • Clone of Amazon Dynamo
- 5. DynamoとVoldemortの比較 問題 Dynamo Voldemort メリット データの割当 Consistent Hashing Consistent Hashing Incremental Scalability 書込みの高可用性 Vector Clocks & Vector Clocks & Read Repair Read Repair 一時的失敗 Sloppy Quorum & Sloppy Quorum & 可用性と 耐久性 Hinted Handoff Hinted Handoff 永続的失敗 Anti-entropy using Restore from 耐久性 Merkle trees Replica node メンバーシップと Gossip-based Gossip-based 失敗感知 membership membership protocol & failure protocol & failure detection detection
- 6.
- 7. 既存Hashの問題 • シンプルな格納先決め – Node id = key.hash % Nodes.size • シンプルなレプリカ先決め – For(i = 0; I < replica_num; i++) add(node_id + i); • 問題 – ノードの追加/削除発生時全データの移動が発生 この問題を解決するためConsistent Hashing！
- 8. Consistent Hashing onDynamo • 0～2^31-1の輪(hash ring)を用意 • その輪の中にハッシュ値(key)が 均等に分散されるようにノードを置く • データをハッシュ値(key)を計算し 時計回りでノードを検索し格納する • Cassandraも同じConsistent Hashing を使って割当を行う • 図のようにキーKが(A,B)の範囲に 存在するのでマスターノードはB、レプリカノードは時計回りでC,Dに なる
- 9. Consistent Hashing onVoldemort • partition idでhash ringを形成する • Key KをFnv Hashでhash valueを計算し partition id数で割り算し、 master partition idを決定する master = FnvHash(key) % partitions.size() • レプリカは時計周りで同じノード上に存在 しないpartition idを選択する 図では(3,5)が選択される • ノードを追加してもこのhash ring(外側の輪)は変わらない • そのため環境構築後のpartition id変更はできない！
- 10.
- 11. Vector Clocks andRead Repair • DynamoとVoldemortは AP(Availability & Partition-tolerance)を優先したKVS • そのためConsistency(整合性)は100%担保できない • しかしDBとしては整合性も重要 • 書込みの可用性を犠牲しない • 解決方法としてVector ClockとRead Repairを利用し • 書込み時追加作業はほとんど発生しない • 一貫性は読込時解決する
- 12. Vector Clocks • 書き込んだ順序を持つ •書込/更新時バージョンを上げる [$nodeId, $version] 例)[C:1] -> [C:2] • 分断が発生すると異なるバージョンが複数ノードに存在する 例) [C:45,B:1], [C:45,A:1] • その場合バージョンで因果関係を決められる • 整合性は読込時解決する – Read Repair – アプリケーション実装
- 13.
- 14.
- 15.
- 16.
- 17.
- 18. Read Repair onVoldemort • 読込時ノードに存在しないデータ又は 古いバージョンのデータを最新のデータに更新する • stores.xmlのreplication-factorとpreferred-readsが2以上 に設定することで有効になる • replication-factor = 3 preferred-reads = 2 データは1ノードのみ存在する場合、 Read Repairで2ノードにデータが存在するようになる • データのバージョンが比較が出来ない場合 バージョンをすべてクライアントに返す この場合アプリケーションでハンドルする必要がある 例) [A:10, B:1][A:10, C:1]
- 19.
- 20. Sloppy Quorum • Quorumとは？ – 議決に必要な定足数 – W + R > N, W > N/2の場合、複製(レプリカ)の整合性が保証できる • W : ノードへ書き込む数、R：ノードから読み出す数、N：レプリカの数 – Strict Quorum – サーバ障害又はネットワーク障害で可用性が落ちる • Sloppy Quorumとは？ – N=3, W=2, R=2 – C, Dノードが障害 – 生存しているノードからreference listを作成 [B,E,F] – Strict Quorumでは失敗になるが Key KはB, E, Fへ格納されて書き込みは成功 高可用性保証
- 21. Hinted Handoff • HintedHandoffとは – 書き込むべきノードが一時的障害で繋がらない際、そのヒントを他のノード が持ち、後でそのヒントを本来データがあるべきノードへ送信し 復旧する仕組み • Hinted Handoffの実際の流れ – C, Dへ書くべきデータのヒントをE, Fが保持 – C, Dが復活したらヒントを送信 – C, DがKey Kを持つ – E, Fからヒントを削除
- 22. Sloppy Quorum andHinted Handoff on Voldemort • Sloppy Quorumはない – C, Dへ繋がらなくても本来書き込むノードでreference listを生成 [B, C, D] – 書込みはB, C, Dノードに対して行う – 書込み失敗のエラーを返す • Hinted Handoff – 書込み失敗時も実行される – ノードへ書込みが失敗したらreference list以外の ノードからランダムでヒントを送るノードを選ぶ – 5分間隔で1回復旧を行う
- 23.
- 24. Anti-entropy using Merkletrees on Dynamo: Merkle Tree a type of data structure that contains a tree of summary information about a larger piece of data http://en.wikipedia.org/wiki/Hash_tree
- 25. Anti-entropy using Merkletrees on Dynamo: Merkle Tree より大きなデータ（例えば ファイル）の要約結果を 格納する木構造の一種 http://ja.wikipedia.org/wiki/%E3%83%8F%E3%83%83%E3%82%B7%E3%83%A5%E6%9C%A8
- 26. Anti-entropy using Merkletrees on Dynamo: Merkle Tree • Leaf(葉)はデータブロックのhash • Nodeは子ノードのhash – Top hash = Hash(0,1) • ルートのhash valueの比較だけで 整合性の確認可能 Node Leaf
- 27. Anti-entropy using Merkletrees on Dynamo • 各ノードはKey rangeのデータをMerkle Treeで管理 • 定期的に同じKey rangeのMerkle Treeを複数ノードが比較 • 異なる場合、最新のデータへ更新 • ノードの追加等で多くのKey rangeが変更される場合、 Merkle Tree再計算で負荷が高くなる可能性がある
- 28. Restore on Voldemort •なぜAnti-entropyが実装されてないの？ – DynamoのAnti-entropyは高負荷 – Cassandraの実装は大規模Production環境で検証されてない 2010.3,4月時点 – パフォーマンスが解決できれば導入するかも • Voldemortの永続的障害復旧方法 – レプリカからすべてのデータをコピーする – その際コピーはpartition id単位で行われる – bin/voldemort-admin-tool.sh --restoreで実行可能
- 29.
- 30. Gossip protocol andFailure Detection on Dynamo • 噂が広がるメカニズムと一緒 – 定期的にランダムで他のノードと接続し噂話をする。 – A,B(C,Dの情報を知っている)が噂話をすることで AはBの情報取得時CとDの情報も取得 – ただ数万ノード規模では遅くなる • 失敗感知 – AとB(BはCと通信出来ても)で噂話が出来なければ AはBをhash ring(Aローカル)から外す – その後は定期的にBとの通信を試す – 通信できたらhash ringへBを追加する
- 31. Gossip protocol onVoldemort • 設定情報チェックに利用 – ランダムでノードを選択し、cluster.xmlとstores.xmlの情報を比較 – リモートノードの設定情報が最新の場合、ローカルノードの設定情報を更新 – リモートノードの設定情報が古い場合、リモートノードがゴシップを始めるよう にする(ローカルノードは何もせずに終了する) • デフォルトでは無効 – server.propertiesファイルのgossip.enable=true指定で利用可能 – 30秒間隔で設定情報のチェックは要らないと思う
- 32. Failure Detection onVoldemort • 失敗感知は主にクライアント側で行う – BannagePeriodFailureDetector(最初の実装) • 簡単な実装 • ノートとの通信が失敗したら言って時間banする(デフォ30秒) • 利用可能ノードも瞬断で一定時間使えない可用性低下の問題 – AsyncRecoveryFailureDetector • Project Voldemort Configurationページには書いてない • 10秒間隔でバックグラウンドで失敗感知したノードの生存確認をする – ThresholdFailureDetector(デフォルト失敗感知) • 一回で失敗判断は精度が低い • 一定時間(30秒)の間一定回数(30)以上のリクエスト中95%成功であれば生きていると判断 • ノード障害時は無駄な通信が発生するが、Hinted Handoffで吸収可能
- 33.