voldemortの技術 - Dynamoとの比較

3,905 views

Published on

Amazon DynamoのクローンであるVoldemortで使われる技術をDynamoと比較しながら説明した資料です。

Published in: Technology
0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,905
On SlideShare
0
From Embeds
0
Number of Embeds
26
Actions
Shares
0
Downloads
17
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide

voldemortの技術 - Dynamoとの比較

  1. 1. 名前を言ってはいけないあの人 He-Who-Must-Not-Be-Named Voldemort Joongjin Bae twitter: bae_j http://baepiff.blogspot.com/
  2. 2. Index• Voldemortの紹介• Voldemortの実現技術 – Consistent Hashing and Replication – Vector Clocking and Read Repair – Sloppy Quorum and Hinted Handoff – Gossip Protocol and Failure Detection
  3. 3. 名前を言ってはいけないあの人 この方じゃなくて
  4. 4. Voldemort• Horizontal Scalable• High Available• Distributed Key-Value Store• Clone of Amazon Dynamo
  5. 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. 6. データの割当
  7. 7. 既存Hashの問題• シンプルな格納先決め – Node id = key.hash % Nodes.size• シンプルなレプリカ先決め – For(i = 0; I < replica_num; i++) add(node_id + i);• 問題 – ノードの追加/削除発生時全データの移動が発生 この問題を解決するためConsistent Hashing!
  8. 8. Consistent Hashing on Dynamo• 0~2^31-1の輪(hash ring)を用意• その輪の中にハッシュ値(key)が 均等に分散されるようにノードを置く• データをハッシュ値(key)を計算し 時計回りでノードを検索し格納する• Cassandraも同じConsistent Hashing を使って割当を行う• 図のようにキーKが(A,B)の範囲に 存在するのでマスターノードはB、レプリカノードは時計回りでC,Dに なる
  9. 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. 10. 書込みの高可用性
  11. 11. Vector Clocks and Read Repair• DynamoとVoldemortは AP(Availability & Partition-tolerance)を優先したKVS• そのためConsistency(整合性)は100%担保できない• しかしDBとしては整合性も重要• 書込みの可用性を犠牲しない• 解決方法としてVector ClockとRead Repairを利用し• 書込み時追加作業はほとんど発生しない• 一貫性は読込時解決する
  12. 12. Vector Clocks• 書き込んだ順序を持つ• 書込/更新時バージョンを上げる [$nodeId, $version] 例)[C:1] -> [C:2]• 分断が発生すると異なるバージョンが複数ノードに存在する 例) [C:45,B:1], [C:45,A:1]• その場合バージョンで因果関係を決められる• 整合性は読込時解決する – Read Repair – アプリケーション実装
  13. 13. Vector Clocks: 初期
  14. 14. Vector Clocks:イベント発生
  15. 15. Vector Clocks:レプリカノードへ適用
  16. 16. Vector Clocks:分断発生
  17. 17. Vector Clocks:イベント発生
  18. 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. 19. 一時的失敗
  20. 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. 21. Hinted Handoff• Hinted Handoffとは – 書き込むべきノードが一時的障害で繋がらない際、そのヒントを他のノード が持ち、後でそのヒントを本来データがあるべきノードへ送信し 復旧する仕組み• Hinted Handoffの実際の流れ – C, Dへ書くべきデータのヒントをE, Fが保持 – C, Dが復活したらヒントを送信 – C, DがKey Kを持つ – E, Fからヒントを削除
  22. 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. 23. 永続的失敗
  24. 24. Anti-entropy using Merkle trees on Dynamo: Merkle Treea type of datastructure that containsa tree of summaryinformation about a largerpiece of datahttp://en.wikipedia.org/wiki/Hash_tree
  25. 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. 26. Anti-entropy using Merkle trees on Dynamo: Merkle Tree• Leaf(葉)はデータブロックのhash• Nodeは子ノードのhash – Top hash = Hash(0,1)• ルートのhash valueの比較だけで 整合性の確認可能 Node Leaf
  27. 27. Anti-entropy using Merkle trees on Dynamo• 各ノードはKey rangeのデータをMerkle Treeで管理• 定期的に同じKey rangeのMerkle Treeを複数ノードが比較• 異なる場合、最新のデータへ更新• ノードの追加等で多くのKey rangeが変更される場合、 Merkle Tree再計算で負荷が高くなる可能性がある
  28. 28. Restore on Voldemort• なぜAnti-entropyが実装されてないの? – DynamoのAnti-entropyは高負荷 – Cassandraの実装は大規模Production環境で検証されてない 2010.3,4月時点 – パフォーマンスが解決できれば導入するかも• Voldemortの永続的障害復旧方法 – レプリカからすべてのデータをコピーする – その際コピーはpartition id単位で行われる – bin/voldemort-admin-tool.sh --restoreで実行可能
  29. 29. メンバーシップと失敗感知
  30. 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. 31. Gossip protocol on Voldemort• 設定情報チェックに利用 – ランダムでノードを選択し、cluster.xmlとstores.xmlの情報を比較 – リモートノードの設定情報が最新の場合、ローカルノードの設定情報を更新 – リモートノードの設定情報が古い場合、リモートノードがゴシップを始めるよう にする(ローカルノードは何もせずに終了する)• デフォルトでは無効 – server.propertiesファイルのgossip.enable=true指定で利用可能 – 30秒間隔で設定情報のチェックは要らないと思う
  32. 32. Failure Detection on Voldemort• 失敗感知は主にクライアント側で行う – BannagePeriodFailureDetector(最初の実装) • 簡単な実装 • ノートとの通信が失敗したら言って時間banする(デフォ30秒) • 利用可能ノードも瞬断で一定時間使えない可用性低下の問題 – AsyncRecoveryFailureDetector • Project Voldemort Configurationページには書いてない • 10秒間隔でバックグラウンドで失敗感知したノードの生存確認をする – ThresholdFailureDetector(デフォルト失敗感知) • 一回で失敗判断は精度が低い • 一定時間(30秒)の間一定回数(30)以上のリクエスト中95%成功であれば生きていると判断 • ノード障害時は無駄な通信が発生するが、Hinted Handoffで吸収可能
  33. 33. Question?

×