More Related Content Similar to voldemortの技術 - Dynamoとの比較 (20) More from Joongjin Bae (10) voldemortの技術 - Dynamoとの比較2. Index
• Voldemortの紹介
• Voldemortの実現技術
– Consistent Hashing and Replication
– Vector Clocking and Read Repair
– Sloppy Quorum and Hinted Handoff
– Gossip Protocol and Failure Detection
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
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変更はできない!
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]
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回復旧を行う
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で実行可能
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で吸収可能