voldemortの技術 - Dynamoとの比較
•
7 likes•3,672 views
Amazon DynamoのクローンであるVoldemortで使われる技術をDynamoと比較しながら説明した資料です。
Recommended
More Related Content
What's hot
Viewers also liked
Similar to voldemortの技術 - Dynamoとの比較
Similar to voldemortの技術 - Dynamoとの比較 (20)
More from Joongjin Bae
More from Joongjin Bae (10)
Recently uploaded
Recently uploaded (11)
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 on Dynamo • 0～2^31-1の輪(hash ring)を用意 • その輪の中にハッシュ値(key)が 均等に分散されるようにノードを置く • データをハッシュ値(key)を計算し 時計回りでノードを検索し格納する • Cassandraも同じConsistent Hashing を使って割当を行う • 図のようにキーKが(A,B)の範囲に 存在するのでマスターノードはB、レプリカノードは時計回りでC,Dに なる
- 9. Consistent Hashing on Voldemort • 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 and Read 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 – アプリケーション実装
- 18. 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]
- 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 • Hinted Handoffとは – 書き込むべきノードが一時的障害で繋がらない際、そのヒントを他のノード が持ち、後でそのヒントを本来データがあるべきノードへ送信し 復旧する仕組み • Hinted Handoffの実際の流れ – C, Dへ書くべきデータのヒントをE, Fが保持 – C, Dが復活したらヒントを送信 – C, DがKey Kを持つ – E, Fからヒントを削除
- 22. 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回復旧を行う
- 23. 永続的失敗
- 24. Anti-entropy using Merkle trees 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 Merkle trees 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 Merkle trees on Dynamo: Merkle Tree • Leaf(葉)はデータブロックのhash • Nodeは子ノードのhash – Top hash = Hash(0,1) • ルートのhash valueの比較だけで 整合性の確認可能 Node Leaf
- 27. Anti-entropy using Merkle trees 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 and Failure 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 on Voldemort • 設定情報チェックに利用 – ランダムでノードを選択し、cluster.xmlとstores.xmlの情報を比較 – リモートノードの設定情報が最新の場合、ローカルノードの設定情報を更新 – リモートノードの設定情報が古い場合、リモートノードがゴシップを始めるよう にする(ローカルノードは何もせずに終了する) • デフォルトでは無効 – server.propertiesファイルのgossip.enable=true指定で利用可能 – 30秒間隔で設定情報のチェックは要らないと思う
- 32. Failure Detection on Voldemort • 失敗感知は主にクライアント側で行う – BannagePeriodFailureDetector(最初の実装) • 簡単な実装 • ノートとの通信が失敗したら言って時間banする(デフォ30秒) • 利用可能ノードも瞬断で一定時間使えない可用性低下の問題 – AsyncRecoveryFailureDetector • Project Voldemort Configurationページには書いてない • 10秒間隔でバックグラウンドで失敗感知したノードの生存確認をする – ThresholdFailureDetector(デフォルト失敗感知) • 一回で失敗判断は精度が低い • 一定時間(30秒)の間一定回数(30)以上のリクエスト中95%成功であれば生きていると判断 • ノード障害時は無駄な通信が発生するが、Hinted Handoffで吸収可能
- 33. Question?