SlideShare a Scribd company logo
1 of 33
Download to read offline
名前を言ってはいけないあの人
 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 &      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
データの割当
既存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の比較だけで
  整合性の確認可能

                            Node



                            Leaf
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?

More Related Content

What's hot

Wakame-vdc 開発苦労談
Wakame-vdc 開発苦労談Wakame-vdc 開発苦労談
Wakame-vdc 開発苦労談Masahito Yoshida
 
InfoTalk springbreak_2012
InfoTalk  springbreak_2012InfoTalk  springbreak_2012
InfoTalk springbreak_2012Hiroshi Bunya
 
20分でわかるHBase
20分でわかるHBase20分でわかるHBase
20分でわかるHBaseSho Shimauchi
 
スマートフォン向けサービスにおけるサーバサイド設計入門
スマートフォン向けサービスにおけるサーバサイド設計入門スマートフォン向けサービスにおけるサーバサイド設計入門
スマートフォン向けサービスにおけるサーバサイド設計入門Hisashi HATAKEYAMA
 
スケーラブルなシステムのためのHBaseスキーマ設計 #hcj13w
スケーラブルなシステムのためのHBaseスキーマ設計 #hcj13wスケーラブルなシステムのためのHBaseスキーマ設計 #hcj13w
スケーラブルなシステムのためのHBaseスキーマ設計 #hcj13wCloudera Japan
 
SSDとTokyoTyrantやMySQLの性能検証
SSDとTokyoTyrantやMySQLの性能検証SSDとTokyoTyrantやMySQLの性能検証
SSDとTokyoTyrantやMySQLの性能検証勲 國府田
 
OpenStack を 拡張する NetApp Unified Driver の使い方 Vol.001
OpenStack を 拡張する NetApp Unified Driver の使い方 Vol.001OpenStack を 拡張する NetApp Unified Driver の使い方 Vol.001
OpenStack を 拡張する NetApp Unified Driver の使い方 Vol.001Takeshi Kuramochi
 
cassandra 100 node cluster admin operation
cassandra 100 node cluster admin operationcassandra 100 node cluster admin operation
cassandra 100 node cluster admin operationoranie Narut
 
はじめるCassandra
はじめるCassandraはじめるCassandra
はじめるCassandraKakeru Iwanaga
 

What's hot (12)

Wakame-vdc 開発苦労談
Wakame-vdc 開発苦労談Wakame-vdc 開発苦労談
Wakame-vdc 開発苦労談
 
InfoTalk springbreak_2012
InfoTalk  springbreak_2012InfoTalk  springbreak_2012
InfoTalk springbreak_2012
 
20分でわかるHBase
20分でわかるHBase20分でわかるHBase
20分でわかるHBase
 
スマートフォン向けサービスにおけるサーバサイド設計入門
スマートフォン向けサービスにおけるサーバサイド設計入門スマートフォン向けサービスにおけるサーバサイド設計入門
スマートフォン向けサービスにおけるサーバサイド設計入門
 
Paxos
PaxosPaxos
Paxos
 
スケーラブルなシステムのためのHBaseスキーマ設計 #hcj13w
スケーラブルなシステムのためのHBaseスキーマ設計 #hcj13wスケーラブルなシステムのためのHBaseスキーマ設計 #hcj13w
スケーラブルなシステムのためのHBaseスキーマ設計 #hcj13w
 
Paxos
PaxosPaxos
Paxos
 
Osc2011 Do
Osc2011 DoOsc2011 Do
Osc2011 Do
 
SSDとTokyoTyrantやMySQLの性能検証
SSDとTokyoTyrantやMySQLの性能検証SSDとTokyoTyrantやMySQLの性能検証
SSDとTokyoTyrantやMySQLの性能検証
 
OpenStack を 拡張する NetApp Unified Driver の使い方 Vol.001
OpenStack を 拡張する NetApp Unified Driver の使い方 Vol.001OpenStack を 拡張する NetApp Unified Driver の使い方 Vol.001
OpenStack を 拡張する NetApp Unified Driver の使い方 Vol.001
 
cassandra 100 node cluster admin operation
cassandra 100 node cluster admin operationcassandra 100 node cluster admin operation
cassandra 100 node cluster admin operation
 
はじめるCassandra
はじめるCassandraはじめるCassandra
はじめるCassandra
 

Viewers also liked

MySQL 5.7が魅せる新しい運用の形
MySQL 5.7が魅せる新しい運用の形MySQL 5.7が魅せる新しい運用の形
MySQL 5.7が魅せる新しい運用の形yoku0825
 
運用が楽になる分散データベース Riak
運用が楽になる分散データベース Riak運用が楽になる分散データベース Riak
運用が楽になる分散データベース RiakTakahiko Sato
 
MySQL 5.7 InnoDB 日本語全文検索
MySQL 5.7 InnoDB 日本語全文検索MySQL 5.7 InnoDB 日本語全文検索
MySQL 5.7 InnoDB 日本語全文検索yoyamasaki
 
MySQL5.6と5.7性能比較
MySQL5.6と5.7性能比較MySQL5.6と5.7性能比較
MySQL5.6と5.7性能比較hiroi10
 
MySQL5.7とMariaDB10.1の性能比較(簡易)
MySQL5.7とMariaDB10.1の性能比較(簡易)MySQL5.7とMariaDB10.1の性能比較(簡易)
MySQL5.7とMariaDB10.1の性能比較(簡易)hiroi10
 
dimSTATから見るベンチマーク
dimSTATから見るベンチマークdimSTATから見るベンチマーク
dimSTATから見るベンチマークhiroi10
 

Viewers also liked (6)

MySQL 5.7が魅せる新しい運用の形
MySQL 5.7が魅せる新しい運用の形MySQL 5.7が魅せる新しい運用の形
MySQL 5.7が魅せる新しい運用の形
 
運用が楽になる分散データベース Riak
運用が楽になる分散データベース Riak運用が楽になる分散データベース Riak
運用が楽になる分散データベース Riak
 
MySQL 5.7 InnoDB 日本語全文検索
MySQL 5.7 InnoDB 日本語全文検索MySQL 5.7 InnoDB 日本語全文検索
MySQL 5.7 InnoDB 日本語全文検索
 
MySQL5.6と5.7性能比較
MySQL5.6と5.7性能比較MySQL5.6と5.7性能比較
MySQL5.6と5.7性能比較
 
MySQL5.7とMariaDB10.1の性能比較(簡易)
MySQL5.7とMariaDB10.1の性能比較(簡易)MySQL5.7とMariaDB10.1の性能比較(簡易)
MySQL5.7とMariaDB10.1の性能比較(簡易)
 
dimSTATから見るベンチマーク
dimSTATから見るベンチマークdimSTATから見るベンチマーク
dimSTATから見るベンチマーク
 

Similar to voldemortの技術 - Dynamoとの比較

ソーシャルゲームにレコメンドエンジンを導入した話
ソーシャルゲームにレコメンドエンジンを導入した話ソーシャルゲームにレコメンドエンジンを導入した話
ソーシャルゲームにレコメンドエンジンを導入した話Tokoroten Nakayama
 
Kink: invokedynamic on a prototype-based language
Kink: invokedynamic on a prototype-based languageKink: invokedynamic on a prototype-based language
Kink: invokedynamic on a prototype-based languageTaku Miyakawa
 
Web本文抽出 using crf
Web本文抽出 using crfWeb本文抽出 using crf
Web本文抽出 using crfShuyo Nakatani
 
このべん第二回 ~「できない子ほどかわいくしたい!ConoHa補完計画」勉強会
このべん第二回 ~「できない子ほどかわいくしたい!ConoHa補完計画」勉強会このべん第二回 ~「できない子ほどかわいくしたい!ConoHa補完計画」勉強会
このべん第二回 ~「できない子ほどかわいくしたい!ConoHa補完計画」勉強会ConoHa, GMO INTERNET
 
Cloudera Manager4.0とNameNode-HAセミナー資料
Cloudera Manager4.0とNameNode-HAセミナー資料Cloudera Manager4.0とNameNode-HAセミナー資料
Cloudera Manager4.0とNameNode-HAセミナー資料Cloudera Japan
 
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェースモジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェースHajime Yanagawa
 
Awsデータレイク事例祭り dmm.com YUKI SASITO.pdf
Awsデータレイク事例祭り dmm.com YUKI SASITO.pdfAwsデータレイク事例祭り dmm.com YUKI SASITO.pdf
Awsデータレイク事例祭り dmm.com YUKI SASITO.pdfYUKI SAITO
 
C#で最も使われていない言語機能はこれだ!
C#で最も使われていない言語機能はこれだ!C#で最も使われていない言語機能はこれだ!
C#で最も使われていない言語機能はこれだ!和紀 大鷲
 
Windows Azure の中でも動いている InfiniBand って何?
Windows Azure の中でも動いている InfiniBand って何?Windows Azure の中でも動いている InfiniBand って何?
Windows Azure の中でも動いている InfiniBand って何?Sunao Tomita
 
高速な暗号実装のためにしてきたこと
高速な暗号実装のためにしてきたこと高速な暗号実装のためにしてきたこと
高速な暗号実装のためにしてきたことMITSUNARI Shigeo
 
Guide to Cassandra for Production Deployments
Guide to Cassandra for Production DeploymentsGuide to Cassandra for Production Deployments
Guide to Cassandra for Production Deploymentssmdkk
 
お金をかけないDBチューニング
お金をかけないDBチューニングお金をかけないDBチューニング
お金をかけないDBチューニングKazuya Sato
 
Cost of ovs receiving process
Cost of ovs receiving processCost of ovs receiving process
Cost of ovs receiving processTakuya ASADA
 
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計Yoshinori Matsunobu
 
Databasedesignforsocialgames 110115195940-phpapp02
Databasedesignforsocialgames 110115195940-phpapp02Databasedesignforsocialgames 110115195940-phpapp02
Databasedesignforsocialgames 110115195940-phpapp02hideki hasegawa
 
Mobage を支える Ruby の技術 ~ 複数DB編 ~
Mobage を支える Ruby の技術 ~ 複数DB編 ~Mobage を支える Ruby の技術 ~ 複数DB編 ~
Mobage を支える Ruby の技術 ~ 複数DB編 ~Naotoshi Seo
 
実録!Railsのはまりポイント10選
実録!Railsのはまりポイント10選実録!Railsのはまりポイント10選
実録!Railsのはまりポイント10選Drecom Co., Ltd.
 

Similar to voldemortの技術 - Dynamoとの比較 (20)

ソーシャルゲームにレコメンドエンジンを導入した話
ソーシャルゲームにレコメンドエンジンを導入した話ソーシャルゲームにレコメンドエンジンを導入した話
ソーシャルゲームにレコメンドエンジンを導入した話
 
Kink: invokedynamic on a prototype-based language
Kink: invokedynamic on a prototype-based languageKink: invokedynamic on a prototype-based language
Kink: invokedynamic on a prototype-based language
 
Web本文抽出 using crf
Web本文抽出 using crfWeb本文抽出 using crf
Web本文抽出 using crf
 
このべん第二回 ~「できない子ほどかわいくしたい!ConoHa補完計画」勉強会
このべん第二回 ~「できない子ほどかわいくしたい!ConoHa補完計画」勉強会このべん第二回 ~「できない子ほどかわいくしたい!ConoHa補完計画」勉強会
このべん第二回 ~「できない子ほどかわいくしたい!ConoHa補完計画」勉強会
 
Flume
FlumeFlume
Flume
 
Cloudera Manager4.0とNameNode-HAセミナー資料
Cloudera Manager4.0とNameNode-HAセミナー資料Cloudera Manager4.0とNameNode-HAセミナー資料
Cloudera Manager4.0とNameNode-HAセミナー資料
 
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェースモジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェース
 
Awsデータレイク事例祭り dmm.com YUKI SASITO.pdf
Awsデータレイク事例祭り dmm.com YUKI SASITO.pdfAwsデータレイク事例祭り dmm.com YUKI SASITO.pdf
Awsデータレイク事例祭り dmm.com YUKI SASITO.pdf
 
C#で最も使われていない言語機能はこれだ!
C#で最も使われていない言語機能はこれだ!C#で最も使われていない言語機能はこれだ!
C#で最も使われていない言語機能はこれだ!
 
Windows Azure の中でも動いている InfiniBand って何?
Windows Azure の中でも動いている InfiniBand って何?Windows Azure の中でも動いている InfiniBand って何?
Windows Azure の中でも動いている InfiniBand って何?
 
高速な暗号実装のためにしてきたこと
高速な暗号実装のためにしてきたこと高速な暗号実装のためにしてきたこと
高速な暗号実装のためにしてきたこと
 
Guide to Cassandra for Production Deployments
Guide to Cassandra for Production DeploymentsGuide to Cassandra for Production Deployments
Guide to Cassandra for Production Deployments
 
HBase at LINE
HBase at LINEHBase at LINE
HBase at LINE
 
HBase at LINE
HBase at LINEHBase at LINE
HBase at LINE
 
お金をかけないDBチューニング
お金をかけないDBチューニングお金をかけないDBチューニング
お金をかけないDBチューニング
 
Cost of ovs receiving process
Cost of ovs receiving processCost of ovs receiving process
Cost of ovs receiving process
 
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
 
Databasedesignforsocialgames 110115195940-phpapp02
Databasedesignforsocialgames 110115195940-phpapp02Databasedesignforsocialgames 110115195940-phpapp02
Databasedesignforsocialgames 110115195940-phpapp02
 
Mobage を支える Ruby の技術 ~ 複数DB編 ~
Mobage を支える Ruby の技術 ~ 複数DB編 ~Mobage を支える Ruby の技術 ~ 複数DB編 ~
Mobage を支える Ruby の技術 ~ 複数DB編 ~
 
実録!Railsのはまりポイント10選
実録!Railsのはまりポイント10選実録!Railsのはまりポイント10選
実録!Railsのはまりポイント10選
 

More from Joongjin Bae

The secret to building good development teams
The secret to building good development teamsThe secret to building good development teams
The secret to building good development teamsJoongjin Bae
 
Reactive summit 2018
Reactive summit 2018Reactive summit 2018
Reactive summit 2018Joongjin Bae
 
[LT] Continuous Delivery
[LT] Continuous Delivery [LT] Continuous Delivery
[LT] Continuous Delivery Joongjin Bae
 
SEDA – Staged Event-Driven Architecture
SEDA – Staged Event-Driven ArchitectureSEDA – Staged Event-Driven Architecture
SEDA – Staged Event-Driven ArchitectureJoongjin Bae
 
理想の開発論-LT用
理想の開発論-LT用理想の開発論-LT用
理想の開発論-LT用Joongjin Bae
 
Aerospike紹介-LT用
Aerospike紹介-LT用Aerospike紹介-LT用
Aerospike紹介-LT用Joongjin Bae
 
Chapter 8 : Evaluation in Information Retrieval
Chapter 8 : Evaluation in Information RetrievalChapter 8 : Evaluation in Information Retrieval
Chapter 8 : Evaluation in Information RetrievalJoongjin Bae
 
Programming in Scala Chapter 17 Collections
Programming in Scala Chapter 17 CollectionsProgramming in Scala Chapter 17 Collections
Programming in Scala Chapter 17 CollectionsJoongjin Bae
 
Cpuの速度向上はいかに実現されたのか
Cpuの速度向上はいかに実現されたのかCpuの速度向上はいかに実現されたのか
Cpuの速度向上はいかに実現されたのかJoongjin Bae
 

More from Joongjin Bae (10)

The secret to building good development teams
The secret to building good development teamsThe secret to building good development teams
The secret to building good development teams
 
Reactive summit 2018
Reactive summit 2018Reactive summit 2018
Reactive summit 2018
 
[LT] Continuous Delivery
[LT] Continuous Delivery [LT] Continuous Delivery
[LT] Continuous Delivery
 
SEDA – Staged Event-Driven Architecture
SEDA – Staged Event-Driven ArchitectureSEDA – Staged Event-Driven Architecture
SEDA – Staged Event-Driven Architecture
 
理想の開発論-LT用
理想の開発論-LT用理想の開発論-LT用
理想の開発論-LT用
 
Aerospike紹介-LT用
Aerospike紹介-LT用Aerospike紹介-LT用
Aerospike紹介-LT用
 
Chapter 8 : Evaluation in Information Retrieval
Chapter 8 : Evaluation in Information RetrievalChapter 8 : Evaluation in Information Retrieval
Chapter 8 : Evaluation in Information Retrieval
 
Programming in Scala Chapter 17 Collections
Programming in Scala Chapter 17 CollectionsProgramming in Scala Chapter 17 Collections
Programming in Scala Chapter 17 Collections
 
Cpuの速度向上はいかに実現されたのか
Cpuの速度向上はいかに実現されたのかCpuの速度向上はいかに実現されたのか
Cpuの速度向上はいかに実現されたのか
 
MapReduce基礎
MapReduce基礎MapReduce基礎
MapReduce基礎
 

Recently uploaded

IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)ssuser539845
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法ssuser370dd7
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~arts yokohama
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見Shumpei Kishi
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfMatsushita Laboratory
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdfAyachika Kitazaki
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦Sadao Tokuyama
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-LoopへTetsuya Nihonmatsu
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor arts yokohama
 

Recently uploaded (12)

IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
 
2024 03 CTEA
2024 03 CTEA2024 03 CTEA
2024 03 CTEA
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
 
2024 04 minnanoito
2024 04 minnanoito2024 04 minnanoito
2024 04 minnanoito
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor
 
What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?
 

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
  • 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で吸収可能