地理分散DBについて

地理分散DBについて

1. 1. 地理分散DBについて 2017年4月28日 Database Lounge Tokyo ハッシュタグ #dbltokyo 発表者 熊崎宏樹 @kumagi
2. 2. トランザクションの基本 • トランザクションとは：CommitかAbortで終わる 複数の手続きの塊 – 例 [Read(x) Read(y) Write(y) Commit] • トランザクションマネージャとは：トランザクショ ンを複数並行して流し込んでも、何らかの順序 で一つずつ直列に流し込んだかのような結果を 生み出すシステム – トランザクションマネージャの中では主に並行制御 アルゴリズムが使われる
3. 3. 並行制御アルゴリズム • 2 Phase Lock・タイムスタン プ・グラフ・楽観的制御と 様々な亜種が考案されて きた – その系統を樹形図で表し たのが右図 – 2PLは有名だがその位置づ けは数ある手法の一角に 過ぎない Transactional Information Systems 176ページから抜粋
4. 4. 2 Phase Lock おさらい A「ロックを取って行った操作は論理的にはいつ実行され た事にして良いか？」 Q「ロックが保持されていた期間の中ならどこでも良い」 処理が実行されたと見なせる論理的な時間軸上の瞬間 を「Linearization Point」と呼ぶ 処理A 処理B Linearization Point
5. 5. 2 Phase Lock おさらい Q「2つ以上のオブジェクトのロックを握って行った 操作は論理的にはいつ実行された事にして良い か？」 A「全部のロックが確保された中の一瞬に全ての 操作が行えた事にしてよい」 処理A 3つのLinearization Pointが重なっている
6. 6. 2 Phase Lock おさらい • 複数のロックを握りっぱなしで行った操作は、複数の オブジェクトを一瞬で操作した事にしてよい • ACI(D)特性を実現する基盤となる考え方 • 他の並行制御アルゴリズムも2PLをベースに拡張した ものが多い • とはいえRead Onlyなクエリでもロックを取ってしまうの で実用上は性能が出にくく、現在の製品ではまず使わ れていない – 製品ではMVCCが使われる事が多い
7. 7. Multi-Version Concurrency Control • 商用DBで広く使われている並 行制御手法 • 内部は細かく分かれている – MV2PLの事だけをMVCCだと思い 込んでる人が多い Concurrency control protocols Single-version Concurrency control protocolsMulti-version Concurrency control protocols An Empirical Evaluation of In-Memory Multi-Version Concurrency Control から引用 OptimisticPessimistic Nonlocking Locking Locking MV2PLMVTO MVOCC
8. 8. Multi Version 2 Phase Lock おさらい • 基本は2 Phase Lockだが、書き込みは常にその値の新し いバージョンをタイムスタンプと共に生成する – Read Onlyトランザクションは古いバージョンを読み出す事が できる – 古いバージョンは消えないのでRead Onlyトランザクションが 絶対成功する 処理A 新しいバージョンが生成される
9. 9. ここまでのまとめ • DBのトランザクションマネージャの中で使われ る並行制御にはいろんな方法がある • MVCCの実現方法一つとってもいろんな方法が ある
10. 10. 地理分散DB モチベーション：データセンターが一つ吹き飛んで も気にせず使えるデータベースが欲しい 1台のマシンに入りきらないぐらい巨大なテーブル を扱えるようになると更にうれしい 複数のマシンの処理性能を生かしたクエリ性能 が出るともっとうれしい
11. 11. 分散トランザクション • 目的から逆算するとトランザクションの経過・結 果について複数台のマシンが同一の値を持つ 事が必須条件 – 分散合意：2 Phase Commit
12. 12. Phase 2 2 Phase Commit • 分散合意プロトコルの金字塔 – 誰が最初の発明者かも明白でないほど古い – 故障時の挙動に大量の亜種がある prepare ok commit ok coordinator worker worker Phase 1
13. 13. 2 Phase Commit • prepare完了前にworkerが故障したらabort – これはいい prepare ok abort ok coordinator worker worker
14. 14. 2 Phase Commit • Commit前にcoordinatorが故障したら prepare ok coordinator worker worker Phase 1
15. 15. Phase 2 2 Phase Commit • Commit前にcoordinatorが故障したら、それを検知した リカバリノードがabortを依頼してロールバック – 1つもcommitが成功していない事を調べる prepare ok recovery coordinator worker worker Phase 1 check abort
16. 16. Phase 2 2 Phase Commit • 死んだと思っていたcoordinatorが生きていたら？ – 食い違って死ぬ – 2 Phase Commitは基本的に死ぬ prepare ok coordinator worker worker Phase 1 abort commit committed aborted check
17. 17. Phase 2 2 Phase Commit • commit途中でcoordinatorが落ちたら prepare ok commit ok coordinator worker worker Phase 1
18. 18. Phase 2 2 Phase Commit • commit途中でcoordinatorが落ちたら回復ノードが表 れて一つでもcommitしていたら全部をcommitさせる prepare ok commit coordinator worker worker Phase 1 commitcheck ok
19. 19. Phase 2 2 Phase Commit • commit途中でcoordinatorが落ちたら一つでもcommit しているときリカバリノードが全部をcommitさせる – その途中で一部のworkerが落ちて後で復活したら？→死 prepare ok commit coordinator worker worker Phase 1 abortcheck ok committed aborted
20. 20. 2 Phase Commit • 2 Phase Commitは故障したり復活したりするとすぐ 壊れる • 回復中に壊れるパターンや回復ノードが壊れるパ ターンまで挙げだすと壊せるシナリオは山ほど出 てくる • 弱点を補強したという触れ込みの3 Phase Commit なんてものもあるけどやはり壊れている • GoogleのChubbyの開発者Mike Burrows「合意プロ トコルは一つしかない。Paxosだ」（≒他の合意プロト コルは全て合意不能） 覚えていただきたい事実：2 Phase Commitはそのまま では使えない
21. 21. Paxos • Lamport先生が「参加者の故障や復活がある場 合絶対に合意には至れない」ということを証明 しようとして逆に生み出してしまった合意プロト コル – 実は故障に耐える合意プロトコルは他にも viewstamped replicationとかstake replicationとかい ろいろあるが、きっちり証明されたのはPaxosが初だ から有名らしい 出典:http://lamport.azurewebsites.net/pubs/pubs.html#lamport-paxos
22. 22. Paxos • 複雑さに定評がある(とよく言われる) – 正常時の挙動やメッセージ数は2PCと同じ – prepare, proposeがバージョン番号を持つ prepare(n) ok(n, v) propose(n, v) accept(n) coordinator worker worker
23. 23. Paxos • Coordinator – prepare(n)に対して過半数からok(n,v)が貰えたらそ の中で最大のnに対するvを全workerに投げる • このvがnullなら自分自身のvを使う • nullでないならvは生死不明な他のCoordinatorのvである • Worker – 過去に見たprepare(n)のうち最大のnであればそれ にok(n,v)を返す。そうでなければng(n') • vは過去に一度も合意してない場合nullかも知れない 25行で説明するPaxos: http://nil.csail.mit.edu/6.824/2015/notes/paxos-code.html
24. 24. Paxos • 2PCだと死んだシナリオ – 蘇るcoordinator • 間に入った別のcoordinatorがバージョン番号を変えるので 間違った合意に至らなくなる prepare(n) ok(n,v) coordinator worker worker propose(n',v) propose(n) prepare(n') ng(n',v) ng(n',v)
25. 25. Paxos • 過半数にproposeが届いた時点でクラスタは合意した事になる – workerが復活してもok – 不完全な複製は後続のcoordinatorが複製し直してくれる prepare(n) ok(n, v) propose(n, v1) coordinator1 worker worker coordinator2 prepare(x) ok(x, v1) propose(x, v1)
26. 26. Paxos • あらゆる故障パターンを網羅して描いても良い けれどスライドに書くには手狭&退屈 • エッセンスだけ掻い摘むと – バージョン番号のお陰で古いcoordinatorやworker が場を乱そうとしても適切に無視される – 複数のcoordinatorがある意味リカバリノードを兼ね ている（合意した値が既に一部のworkerにあれば それを再度全体へ周知する） – 過半数が合意すればプロトコルが進行するように設 計されているためシンプル
27. 27. ここまでのまとめ • 2 Phase Commitは基本的に壊れている • 任意の通信遅延(つまりノードの復活)を含む分 散環境で合意するにはPaxosのような強固なプ ロトコルが必要
28. 28. Spanner • Googleが開発してOSDI 2012で発表した地理分 散データベース – 登場時は原子時計やGPSを使っている事ばかりが 話題にされたが実はそこは枝葉末節 • その実態はMV2PLと2Phase LockとPaxosを組み 合わせたオモシロ地理分散データベース
29. 29. Spanner • 巨大なDBでACIDかつ地理分散したい – テーブルをタブレットへ水平分割 ID 名前 住所ID スコア 1 佐藤 3 123 2 田中 2 3243 3 鈴木 3 54 4 山田 5 2 5 磐田 6 332 6 吉井 3 232 7 山下 5 332 8 熊谷 3 12 ID 名前 住所ID スコア 1 佐藤 3 123 2 田中 2 3243 ID 名前 住所ID スコア 3 鈴木 3 54 4 山田 5 2 5 磐田 6 332 ID 名前 住所ID スコア 7 山下 5 332 8 熊谷 3 12 ID 名前 住所ID スコア 1 佐藤 3 123 2 田中 2 3243 数 万 行 約 千 行
30. 30. Paxos Spanner • 障害に備えたい – 1タブレットを1 Paxos単位として地理分散 日本DC フランスDC 西海岸DC ID 名前 住所ID スコア 1 佐藤 3 123 2 田中 2 3243 ID 名前 住所ID スコア 1 佐藤 3 123 2 田中 2 3243 ID 名前 住所ID スコア 1 佐藤 3 123 2 田中 2 3243
31. 31. フランスDCシンガポールDC Spanner • データセンタ1つあたり100から数1000のサーバ • サーバ1台で100～1000個のタブレットを持つ 日本DC tablet tablet tablet tablet tablet tablet tablet tablet tablet tablet tablet tablet tablet tablet tablet tablet tablet tablet tablet tablet tablet tablet tablet tablet tablet tablet tablet tablet tablet tablet 100～数1000台 100～ 1000 タブレット ・・・ Paxos
32. 32. タブレット with Paxos • 1つのタブレットの操作はPaxosで調停する – Paxosは1つの値についてしか合意できないので、それを並 べて命令列を作り、合意できた命令から順に適用していく – 同じ命令列を同じ順序で実行したのだから同じ状態になる • Replicated State Machineという複製アプローチ x=10 x=10 x=10 1 y=3 y=3 y=3 2 z=2 z=2 z=2 3 a=8 a=8 a=8 4 b=5 5 c=9 6 未実行命令 実行済命令 Paxosの合意 1回分
33. 33. Spannerでの更新 • トランザクションの操作が1つのtabletの中で収 まるなら、TabletのPaxosを行うリーダーに命令 の実行を依頼する – tablet内は2 phase lockで並行制御 • 複数のtabletに跨るトランザクションは、複数の tabletの間で2 Phase Commitを行う – 2 Phase Commitは故障に弱いのでは？→Paxosが 参加者なので故障しないと仮定してよい – tabletを跨っても2 phase lockで並行制御
34. 34. Spannerでの更新 • paxosグループが参加者となって2phase commitを行う – paxos – 2PC paxos paxos prepare prepare ok commit ok
35. 35. Spannerでの参照 • 2 Phase Lockを使って更新しているのでトランザ クションとしてはこの上なく正しい • だがRead Onlyな操作であっても毎回2 Phase Lockを使うのはコストが高すぎる • よし、全部の値にタイムスタンプを振って追記す る形を取れば、過去の任意の時間の値に遡っ て一貫性のあるRead-Onlyトランザクションがで きるぞ！ – いわゆるMV2PL – (そのままでは)分散環境ではまともに動かない
36. 36. SpannerでのRead-Onlyトランザクション • まともに動かない理由：各サーバの時刻がズレて いるから write(x,10) write(y,10) read(x), read(y) x=10, y=10 期待する挙動
37. 37. SpannerでのRead-Onlyトランザクション • まともに動かない理由：各サーバの時刻がズレて いるから read(x), read(y) x=0, y=10 発生する挙動 write(x,10) write(y,10)
38. 38. Spannerが満たしたい一貫性 • External Consistency – あるトランザクションT1が終わった後に始まったトラ ンザクションT2のタイムスタンプは絶対にT1より後 – これを分散MV2PL環境下で実現したのがSpannerの Contribution • どうやって？ – やっと原子時計・GPSの出番
39. 39. True Time API • 正しい時刻がどの範囲にあるかわかるAPI – GPSでも原子時計でも一応ズレるので、その誤差範 囲を制限できる機能がある • システムに参加している全マシンの時刻の誤差 範囲を予測可能にする事が目的 – この範囲を超えて時間が狂うマシンはシステムから 除外される（地味に重要）
40. 40. Spannerのcontribution: Commit Wait • True Time APIを用いて – トランザクションで書く値にタイムスタンプを振る – タイムスタンプで振った時刻が「確実に過ぎた」と断言で きるまで、ロックを意図的に握ったままにする read(x), read(y) x=10, y=10 write(x,10) write(y,10) Commit Wait Commit Wait
41. 41. Commit Waitの証明 • External Consistencyを満たす証明は論文に書 いてあって複雑に見えるが実は簡単 – T1が振ったタイムスタンプが過ぎてからアンロック • s1 < T1(完了) – アンロックが済んだ後のデータをT2が読む • T1(完了) < T2(開始) – T2に振られる時刻はT2の開始より後(当然) • T2(開始) < s2 – よって s1 < s2 → External Consistencyは守られた
42. 42. 細かい議論 • Read Onlyトランザクションもタイムスタンプを振られ る – そのタイムスタンプより前の値しか読みだすことができ ない – そのタイムスタンプの値を読み出せたと断言するために はそのタイムスタンプの時刻が過ぎた後でないといけな い – なお、Tabletを跨らないRead Onlyは普通にMV2PLの範 疇で値を読んでかまわないから少し速い • googleのシステムでは時刻ズレは1桁ミリ秒の範囲 で収まっている様子。これによって比較的高速なト ランザクションができる – 単純に遅延が小さいことより、ジッタが少ない事が脅威
43. 43. ベンチマーク • Quizletというサービスが使い込んだベンチを公 開している • ノード数を増やすごとにスループットの限界が伸びている • 台数当たりの性能ではやはりMySQLに軍配 • アルゴリズムの割にレイテンシが引く程低い
44. 44. Spannerのまとめ • 基本的にMV2PLを分散環境に拡張しただけ • Commit Waitがcontributionだが愚直にやると 性能が残念になる • そこでTrue Time APIでCommit Waitを短縮した
45. 45. その他の地理分散DB • Spannerは主にその効率性の観点から批判が いくつかある – 一言で言うと「Paxos遅い」
46. 46. Spannerでの遅延 • paxosの通信は常に地理的に跨っている – 地理間通信に片道10ms掛かると仮定すると…？ paxos paxos prepare prepare ok commit ok 40ms • tabletを跨る2PCは最低でも160msかかる – 実際はもっと細かい高速化ができるが割愛
47. 47. Replicated Commitアプローチ • 2PCのログ結果を共有するのではなくコミット可能か否かを共 有する • Paxos on 2PCにすれば地理間通信が減るね 2PC 2PC prepareprepare(n) ok(n,v) commitpropose(n,v) ok(n,v) • この方式なら2往復で済む – 2PCの進行に掛かるログをPaxosで複製する(Log Replication)のではなく、コミット可能 か否かという情報をPaxosで複製する(Commit Replication) Hatem Mahmoud et al. Low-Latency Multi-Datacenter Databases using Replicated Commit(VLDB2013)
48. 48. Calvin • トランザクションリクエストそのものを複製すれば良いよね – 同じリクエストを同じ順序で実行したら同じDB状態になるし – 各DBはクエリを実行する順序だけ合意して、あとはFIFOに処理していくだけ – いわゆる並行処理制御でいうDeterministicアプローチ 2PC 2PC prepare(n) propose(n,v) ok(n,v)
49. 49. Spanner vs Calvin • 要旨：ほとんどのケースでCalvinはSpannerより優れている – DC間通信をしている間に値をロックし続ける必要が無いという点で速度 的に優位 • 試したい人はFaunaDBを使ってみてね https://fauna.com/blog/spanner-vs-calvin-distributed-consistency-at-scale
50. 50. まとめと所感 • 分散DBと違って地理分散DBはDC間の遅延が支配項に なりがちなので新しいプロトコルが考案される素地があ る • トランザクションの実行順序だけ合意するというアプロー チは良さそうに見えるがDBを大規模に水平分割する前 提で考えるとShared-Everything的になってスケーラビリ ティに限界が出るのでは？ – どのクエリがどの値に触るかを断定すればShared-Nothing になるがその断定に掛かるコストが今度は高くつきそう