名前を言ってはいけないあの人 He-Who-Must-Not-Be-Named

Voldemort

Joongjin Bae

twitter: bae_j

http://baepiff.blogspot.com/

Index

• Voldemortの紹介

• Voldemortの実現技術

– Consistent Hashing and Replication

– Vector Clocking and Read Repair

– Sloppy Quorum and Hinted Handoff

– Gossip Protocol and Failure Detection

この方じゃなくて

名前を言ってはいけないあの人

Voldemort

• Horizontal Scalable

• High Available

• Distributed Key-Value Store

• Clone of Amazon Dynamo

DynamoとVoldemortの比較

問題 Dynamo Voldemort メリット

データの割当 Consistent Hashing Consistent Hashing Incremental Scalability

書込みの高可用性 Vector Clocks & Read Repair

Vector Clocks & Read Repair

一時的失敗 Sloppy Quorum & Hinted Handoff

Sloppy Quorum & Hinted Handoff

可用性と 耐久性

永続的失敗 Anti-entropy using Merkle trees

Restore from Replica node

耐久性

メンバーシップと 失敗感知

Gossip-based membership protocol & failure detection

Gossip-based membership protocol & failure detection

データの割当

既存Hashの問題

• シンプルな格納先決め

– Node id = key.hash % Nodes.size

• シンプルなレプリカ先決め

– For(i = 0; I < replica_num; i++)

add(node_id + i);

• 問題

– ノードの追加/削除発生時全データの移動が発生 この問題を解決するためConsistent Hashing！

Consistent Hashing on Dynamo

• 0～2^31-1の輪(hash ring)を用意

• その輪の中にハッシュ値(key)が 均等に分散されるようにノードを置く

• データをハッシュ値(key)を計算し 時計回りでノードを検索し格納する

• Cassandraも同じConsistent Hashing を使って割当を行う

• 図のようにキーKが(A,B)の範囲に 存在するのでマスターノードはB、レプリカノードは時計回りでC,Dになる

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変更はできない！

書込みの高可用性

Vector Clocks and Read Repair

• DynamoとVoldemortは

AP(Availability & Partition-tolerance)を優先したKVS

• そのためConsistency(整合性)は100%担保できない

• しかしDBとしては整合性も重要

• 書込みの可用性を犠牲しない

• 解決方法としてVector ClockとRead Repairを利用し

• 書込み時追加作業はほとんど発生しない

• 一貫性は読込時解決する

Vector Clocks

• 書き込んだ順序を持つ

• 書込/更新時バージョンを上げる [$nodeId, $version] 例)[C:1] -> [C:2]

• 分断が発生すると異なるバージョンが複数ノードに存在する

例) [C:45,B:1], [C:45,A:1]

• その場合バージョンで因果関係を決められる

• 整合性は読込時解決する – Read Repair

– アプリケーション実装

Vector Clocks: 初期

Vector Clocks:イベント発生

Vector Clocks:レプリカノードへ適用

Vector Clocks:分断発生

Vector Clocks:イベント発生

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]

一時的失敗

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へ格納されて書き込みは成功 高可用性保証

Hinted Handoff

• Hinted Handoffとは – 書き込むべきノードが一時的障害で繋がらない際、そのヒントを他のノード が持ち、後でそのヒントを本来データがあるべきノードへ送信し 復旧する仕組み

• Hinted Handoffの実際の流れ – C, Dへ書くべきデータのヒントをE, Fが保持

– C, Dが復活したらヒントを送信

– C, DがKey Kを持つ

– E, Fからヒントを削除

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回復旧を行う

永続的失敗

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

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

Anti-entropy using Merkle trees on Dynamo: Merkle Tree

• Leaf(葉)はデータブロックのhash

• Nodeは子ノードのhash – Top hash = Hash(0,1)

• ルートのhash valueの比較だけで 整合性の確認可能

Leaf

Node

Anti-entropy using Merkle trees on Dynamo

• 各ノードはKey rangeのデータをMerkle Treeで管理

• 定期的に同じKey rangeのMerkle Treeを複数ノードが比較

• 異なる場合、最新のデータへ更新

• ノードの追加等で多くのKey rangeが変更される場合、 Merkle Tree再計算で負荷が高くなる可能性がある

Restore on Voldemort

• なぜAnti-entropyが実装されてないの？ – DynamoのAnti-entropyは高負荷

– Cassandraの実装は大規模Production環境で検証されてない 2010.3,4月時点

– パフォーマンスが解決できれば導入するかも

• Voldemortの永続的障害復旧方法 – レプリカからすべてのデータをコピーする

– その際コピーはpartition id単位で行われる

– bin/voldemort-admin-tool.sh --restoreで実行可能

メンバーシップと失敗感知

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を追加する

Gossip protocol on Voldemort

• 設定情報チェックに利用 – ランダムでノードを選択し、cluster.xmlとstores.xmlの情報を比較

– リモートノードの設定情報が最新の場合、ローカルノードの設定情報を更新

– リモートノードの設定情報が古い場合、リモートノードがゴシップを始めるようにする(ローカルノードは何もせずに終了する)

• デフォルトでは無効 – server.propertiesファイルのgossip.enable=true指定で利用可能

– 30秒間隔で設定情報のチェックは要らないと思う

Failure Detection on Voldemort

• 失敗感知は主にクライアント側で行う – BannagePeriodFailureDetector(最初の実装)

• 簡単な実装

• ノートとの通信が失敗したら言って時間banする(デフォ30秒)

• 利用可能ノードも瞬断で一定時間使えない可用性低下の問題

– AsyncRecoveryFailureDetector • Project Voldemort Configurationページには書いてない

• 10秒間隔でバックグラウンドで失敗感知したノードの生存確認をする

– ThresholdFailureDetector(デフォルト失敗感知) • 一回で失敗判断は精度が低い

• 一定時間(30秒)の間一定回数(30)以上のリクエスト中95%成功であれば生きていると判断

• ノード障害時は無駄な通信が発生するが、Hinted Handoffで吸収可能

Question?