voldemortの技術 - Dynamoとの比較
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

voldemortの技術 - Dynamoとの比較

on

  • 2,683 views

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

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

Statistics

Views

Total Views
2,683
Views on SlideShare
2,677
Embed Views
6

Actions

Likes
6
Downloads
9
Comments
0

2 Embeds 6

https://twitter.com 4
http://s.deeeki.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

voldemortの技術 - Dynamoとの比較 Presentation Transcript

  • 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 – アプリケーション実装
  • 13. Vector Clocks: 初期
  • 14. Vector Clocks:イベント発生
  • 15. Vector Clocks:レプリカノードへ適用
  • 16. Vector Clocks:分断発生
  • 17. Vector Clocks:イベント発生
  • 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 Treea type of datastructure that containsa tree of summaryinformation about a largerpiece of datahttp://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?