1. Paxos
株式会社プリファードインフラストラクチャー
2012年年 7⽉月 5⽇日

2. ⾃自⼰己紹介
l 久保⽥田展⾏行行(@nobu_k)
l 製品開発部
l Sedue/Bazil
l (Jubatus)
l ブル
l 最近勉強してるもの
l 開発⼿手法：要件定義・管理理
l 本
l Transactional Information Systems(@ノーチラス)
‒ 約1年年で念念願のリカバリーまで到達・・・！
l 分散DB本
2

3. 今⽇日の話
l Paxos
l Consensus algorithm(protocol)の1つ
l ものすごく難しいことで有名(主に元論論⽂文が)
l 流流れ
l Consensus
l 問題設定
l Paxos
l (ちょびっとだけ)Multi-Paxos
l 参考⽂文献紹介
l ⽇日本語の⽂文献が少なく、⽤用語が怪しいですすいません
3

4. Paxosの説明を始める前に
Consensus
4

5. Consensus(合意)とは
l Consensusとは
l プロセスの集合が1つの値において合意を取ること
l 分散システムにおける重要な問題の1つ
ロンアール
「お昼どうする？」
A
Red Bull ロンアール
B E
どれか1つを選択
ロンアール つけ麺
C D
5

6. Consensus algorithmはなぜ必要か
l 分散システムで⾼高可⽤用性(High Availability)を実現するため
l ⾼高可⽤用性を実現する⽅方法は「冗⻑⾧長化」ただ1つ
l ハードウェア障害は防げない
6

7. 状態を持つ(statefulな)ソフトウェアを冗⻑⾧長化する
l 状態を持つソフトウェアを冗⻑⾧長化するには
l レプリケーション
l State machine replication
l 命令令の列列を全レプリカに同じ順序で適⽤用する
7

8. 命令令の列列をすべてのレプリカに同じ順序で届ける
l レプリカ毎に命令令の順序が変わると、レプリカの状態も変わる
l i番⽬目の命令令として何を採⽤用するかに対して合意を取る
l すべてのiに対して合意を取る
l ここでConsensusが必要
l しくじると状態の違う(inconsistentな)レプリカができあがる
l 補⾜足：Atomic broadcast
l 全順序付きのブロードキャスト
l すべてのプロセスが同じ順序でメッセージを受け取る
l メッセージはすべてのプロセスに到達するか、全く到達しないか
のどちらか
8

9. 分散システムで合意を取るのはなぜ難しいのか
l CCが使えないメールを利利⽤用して、集合場所を決めることを考える
l ただし、メールには到達保証がない(到達確認ができない)
l 参加メンバーだけはわかっている
l 誰が取り仕切切るかは決まっていない
l 他のメンバーが今何をしているのかはわからない
l せっかくメール送ったのに返信が来ない・・・考えられる状況は
l メールは届いてない
l メールは届いてるけど仕事中で返信できない
l メールは返信されたけど、届く前に消えてしまった・・・
l 他のやっかいな問題
l 取り仕切切り役が2⼈人同時に、別々の集合場所を提案
l ⾳音信不不通の⼈人が途中から復復帰してくるけど議論論に追いつけない
9

10. Consensusが必要とされるほかのところ
l 分散トランザクション
l トランザクションをCommitするか、Abortするか
l 全員が同じ選択をしないと⼀一貫性(consistency)がオワコンに
l メンバシップ管理理
l 協調動作しているグループのメンバを管理理する
l メンバが追加されるとき、削除されるときに合意を取る
l 全員が常に同じメンバを⾒見見ている状態を維持
l リーダー決定
l リーダーは1プロセス(1⼈人)であるように決定する
l ⼈人間的な問題
l 「お昼どこに⾏行行く？」、「明⽇日どこに集合する？」
l CCが使えないメールのみで合意を取れるか
10

11. 問題設定
11

12. Consensus problemの設定
l プロセス
l 合意を取りたいグループのメンバ(活動単位みたいなやつ)
l 主にPaxosにおける役割(Role)
l Proposer
l 値を提案する
l Accepter
l 値を受理理する
l Learner
l ある値に関して合意が取れたことを確認する
l プロトコルによってはいない
l 1プロセスがすべての役割を担ってもいい
l Proposer&accepter&learner兼任のプロセスだけでの構成も可
12

13. プロトコルが満たすべき性質
l 安全性(safety)に関わる性質 ゆるふわバージョン
l Proposerが提案された値のみが選択される
l 誰も提案していない謎の値は選択されない
l ただ1つの値のみが選択される
l 正しく動作しているすべてのプロセスは同じ値を選ぶ
l 値が実際に使われるのは選択された後
l 先⾛走り防⽌止
l その他の性質(liveness)
l 停⽌止保証: 有限時間で値が選択されることを保証
13

14. 問題があまりない状態でのConsensus
l 想定する状況
l メッセージは必ず届く
l メッセージは壊れない
l すべてのプロセスが同じ速度度で処理理を進める
l 障害は100%検知できる
l 停⽌止したプロセスは復復活しない(fail-stop)
l 常にこの状態だと楽ちん
14

15. 現実の問題
l 分散システム的な問題設定
l 処理理に任意の時間がかかる、しかもプロセス毎に進⾏行行速度度が違う
l 通信に任意の時間がかかる、メッセージが失われる可能性がある
l 停⽌止したプロセスが、あとで復復旧する可能性がある(fail-recover)
l しかし、メッセージが壊れた状態で到達しない(non-Byzantine)
A1 働きたくないでござる(ゆっくり進行)
A2 メール返したくないでござる
P1
A3 メール届かない
これコミットしていいですか？
A4 一時間寝ます
15

16. 補⾜足：Synchronous/Asynchronous system model
l 同期、⾮非同期、分散システムではちょっと意味が違う
l 特に元々lock-freeとかしてた⼈人にとっては・・・ｗ
l 佐藤先⽣生つぶやきがtogetterにまとめられている
l Google Spannerまとめ http://togetter.com/li/317139
l Synchronous system model
l 先ほど「問題があまりない」と紹介した例例
l 純粋にアルゴリズムを検証するのに便便利利なモデル
l Asynchronous system model
l 問題しかない、なにが起こってもおかしくない⽅方のモデル
l このモデルで正しく動けば、すべての状況で正しく動くんでは！
16

17. 補⾜足：FLP impossibility
l 分散システム界隈でよく⾒見見かける定理
l ⾮非同期システムでは、たとえメッセージのロスがなくても、プロ
セスが1台でも停⽌止する可能性がある限り、100%合意に⾄至れる
Consensusアルゴリズムは存在しない
l Paxosも例例外ではない！
l 注意
l 100%合意に⾄至れないだけで、⼤大体のケースでは合意に⾄至れる
l 「100%の確率率率で完了了するアルゴリズム」が存在しないことの証明
17

18. Paxos
18

19. Paxosとは
l ⾮非同期システム上でのConsensus protocolの1つ
l 1989年年(有名な論論⽂文が出たのは1998年年)
l Lamport先⽣生
l 分散アルゴリズムの神
l 名前はギリシャのPaxos島から
l そこの議会の仕組み(fiction)が元ネタになってるらしい
l Chubbyで⼀一気に有名になった
l 相当やばい状態でも動く
l 2PC、3PCの問題を解決している
19

20. 説明の流流れ
l Paxos made simpleに従って話を進める
l Lamport先⽣生の論論⽂文(というか記事？)
l 2001年年
l まずは単純なモデルを構築
l 徐々に問題を解決しながら完成に近づけていく
l 1回のPaxosインスタンスに関する説明
l 1つの値に対して合意を取る⼀一連の処理理をインスタンスと呼ぶ
l State machine replicationはi番⽬目の命令令毎にインスタンスを実
⾏行行して実現する
20

21. 単純な⽅方法
l Proposer 1台、accepter 1台
l Proposerの提案がaccepterに渡った段階で値が選択される
l 問題
l Proposer、accepterどちらが停⽌止してもプロトコルが停⽌止する
l 解決策
l Proposer、accepterが複数台いる構成にする
l まずはaccepterが複数いる状況を考える
l 次にproposerが複数いる状況を考える
21

22. 複数accepterを使って合意を取る
l ⼿手順
l Proposerが複数のaccepterに提案を送る
l Accepterは値を受理理(accept)してもいいし、しなくてもいい
l ⼗十分に多く(以後”過半数”)のaccepterが受理理した値を選択する
l 例例：過半数、Quorum
l Accepter集合の部分集合の集合で、任意の2つの要素(部分集合)が
1つ以上の共通する要素(プロセス)を持つ
l Accepterが1つの提案しか受理理しないようにすれば動く
l 問題
l Accepterが全部の提案を拒否すると提案を選択できない
l 制約
l P1. Accepterは最初に受け取った提案を受理理しなければならない
22

23. Proposerを複数⽤用意する
l 複数台⽤用意できれば、1台停⽌止しても怖くない
l しかし、メッセージロスが絶妙に積み重なった状況を考える
l N台のaccepterはすべて値を受理理している
l 全体でM個の値が受理理されている
l しかし、どの値も過半数のaccpeterから受理理されていない
A1
3提案
A2 A5
A3 A4
23

24. 複数proposerでの問題
l 問題
l M=2の状況でも1台のaccepterの障害でプロトコルが停⽌止するかも
l 解決策
l Accepterが複数の提案を受理理できるようにする
l 値の上書きを許す
^o^
l 2F+1台構成でF台までの障害は許容したい
l 今だと何台構成でも1台の障害しか
A2 A5
許容できない状況
l もちろんワーストケースの話
A3 A4
24

25. 提案ID(proposal number)の導⼊入
l Accepterが複数の提案を受理理できるようにするために・・・
l 提案に全順序付きのIDを付ける
l 混乱をなくすため、すべての提案がユニークなIDを持つようにする
l 値は同じでも、提案⾃自体は違うことを識識別したい
l IDは単調増加する(連番である必要はない)
l データの例例
l 提案: (提案ID, 値)
l 提案ID: (数値, プロセスのID)
l プロセスのIDはユニークなものを採⽤用
l その他
l 複数のIDが異異なる提案が同じ値を持つことはある
l 同じIDの提案は、同じ値しか持たない
25

26. 提案の選択と提案の上書きによる問題
l 「値vを持つ提案が選択された」とは
l 過半数のaccepterが値vを持つ提案を受理理した場合、提案が選択
されたという
l 値が選択された後も、提案を送ることは可能
l N/2+1台のaccepterにだけ受理理された状態でaccepterが1台停⽌止
するとよくわからないことになるため
l 受理理した提案を上書きすることによる問題
l ⼀一度度選択された(過半数のaccepterから受理理された)値を変更できる
l “ただ1つの値のみが選択される”という性質に違反する
l もう1つ制約が必要
26

27. もう1つの制約
l P2. ⼀一度度値vを持つ提案が選択されたら、より⼤大きなIDを持つ提
案が選択される場合、その提案の値はvでなければならない
l これで、提案選択後に選択された提案の値以外で上書きされるこ
とを防げる
l 具体的にどうやってこの制約を実現するのか
l 少なくともaccepterには制約が必要
l このことを考慮してP2を少し修正する
27

28. P2の修正
l 提案が選択されるためには、最低でも1つのaccepterに受理理され
なければならない
l これを考慮してP2を少し修正
l P2a. 値vを持つ提案が選択されたら、任意のaccepterに受理理され
るより⼤大きなIDを持つ提案の値はvでなければならない
l しかし、このままではP1を満たせない・・・
l P1. Accepterは最初に受け取った提案を受理理しなければならない
28

29. P1とP2aの問題
l 問題が起こる状況
l 提案が選択されている
l しかし、まだ提案を1度度も受け取っていないaccepterもいる
l そのaccepterに違う値を持つ提案が送られる
l P1により、そのaccepterは提案を受理理しなければならない
A1
やめて＼(^o^)／
A2 A5
最初の提案は受理するんだろオラァ
A3 A4
29

30. 補⾜足：現段階での疑問
l いずれにせよ過半数は維持できているため⼤大丈夫では？
l この問題を放置すると今後の制約を洗練させる際の⽀支障に・・・
l 具体的には、最も⼤大きな提案IDを利利⽤用して選択済みでない値を提
案できるのが問題
l 今は、とりあえずこうしないと無理理と思って続ける
A1
／(^o^)＼
A2 A5
A3 A4
30

31. P2aの修正
l 結局proposer側にも制約をかけるしかない
l P2b. 値vを持つ提案が選択されたら、任意のproposerからリク
エストされる、より⼤大きなIDを持つすべての提案の値はvでなけ
ればならない
l P2bを満たせばP2aを満たし、P2aを満たせば元々のP2を満たす
l Proposerは選択されている値しか提案できないためP1を維持可能
l ではP2bをどうやって満たすか
31

32. 提案が選択されている状況を考える
l ある提案が選択されていると⾔言うことは・・・
l その提案を受理理したAccepter集合の部分集合Sが存在する
l Sは過半数(※)のaccepterで構成される
l ということを元に、本当はかっこよく帰納的に説明するんですが！
A1
A2 A5
A3 A4
※特定の性質を満たせば
過半数である必要は無い
32

33. しょぼい説明
l 提案を⾏行行う前に、過半数のaccepterに対して現在受理理している提
案を確認すればよくない？
l もし提案が受理理されてたら、とりあえずIDが⼀一番⼤大きな提案の値
をもう⼀一度度提案しとけばいいよね
l 提案が選択された後でも⼤大丈夫そう！？
l うまくいくっぽくね！？ A1
l 詳細はPaxos made liveを参照
A2 A5
ほんとは を提案したいけど
今一番新しい提案は だから
を提案しておこう・・・
A3 A4
33

34. P2bの修正
l P2c. 値vを持つIDがnの提案がproposerより出た場合、次のような
accepterの集合Sが存在しなければならない
l Sには過半数のaccepterが含まれる
l Sに含まれるどのaccepterもまだIDがn未満の提案を受理理していな
い(proposerが好きな値を提案できる状況)
l Sに含まれるaccepterが受理理したIDがn未満の提案のうち、⼀一番
⼤大きなIDを持つ提案の値はvである
l まだまだ問題はある！
l 確認した中で⼀一番⼤大きな提案のIDはmだった。
l ID n(>m)で提案を⾏行行ったが、その途中でID m’(<nかつ>m)の提
案が割り込んだ。しかもm’の提案は⾃自分とは違う値を持っていた。
l そしてm’の提案が選択されてしまっていた・・・！
34

35. Prepare&Promise
l ⾃自分の提案IDが提案時点で最⼤大であることを保証したい
l 確認時点では無くて、⾃自分が提案する時点で最⼤大であることを保証
l しかし未来を予測するのは難しい・・・
l 状況を確認してから提案するまでに状態が変わったらどうしよう
l Prepare(n)メッセージの導⼊入
l ⾃自分もうすぐ提案するので、今後IDがn未満の提案は無視して！
l これで少なくとも⾃自分より古くなる予定の提案は全部拒否できる
l Prepareを受け取ったaccepterは約束を必ず守ること！
l Promise
l AccepterのPrepareに対する返信、受理理するか拒否するか
l ⾃自分が現在受理理している提案を返す(IDと値)
35

36. Accept
l Prepare(n)のレスポンスを過半数から受け取ったら提案を送る
l 過半数から受け取れないと正確に現状を判断できない
l P2cに従って値を提案
l Accept(n, v)
l nはPrepareした提案ID
l vは値
l Accepterはどう対応すべきか
l nよりも⼤大きなIDでPrepareされていたらAcceptを拒否
l PrepareされていたIDの場合は受理理しAcceptedメッセージを返信
l Acceptに渡されたIDが、現在Prepareで受理理したIDよりも⼤大きい
場合もAcceptしちゃって問題ない
l 過半数はPrepareを受理理しているはずなので、制約は崩れない
36

37. 最後の修正と制約のまとめ
l P1a. Accepterはnより⼤大きなPrepareリクエストを受理理していな
いとき、またそのときに限り、IDがnの提案を受理理できる
l P2c. 値vを持つIDがnの提案がproposerより出た場合、次のような
accepterの集合Sが存在しなければならない
l Sには過半数のaccepterが含まれる
l Sに含まれるどのaccepterもまだIDがn未満の提案を受理理していな
い
l Sに含まれるaccepterが受理理したIDがn未満の提案のうち、⼀一番
⼤大きなIDを持つ提案の値はvである
37

38. Paxosできた？
l なんかそれらしくなった気がする
l 今まで出てきた制約をまとめてみる
l フェーズを2つに分けて考える
l フェーズ1: Prepare&Promiseメッセージのやりとり
l フェーズ2: Accept&Acceptedメッセージのやりとり
l PromiseやAcceptedで返す情報を増やすことにより若若⼲干最適化可
l Learnerはもうちょっと後で出てくる
38

39. Paxos: フェーズ1 Prepare
l ProposerはPrepare(n)メッセージを過半数のaccepterに送る
l Nはこれから送ろうと思っている提案のID(proposal number)
l AccepterからPromiseメッセージが返ってくるのを待つ
l 補⾜足：⾮非同期なので、適当にタイムアウトを設定して待つ
l 適当な時間が経過したらもう⼀一度度リクエストを投げればいい
39

40. Paxos: フェーズ1 Promise
l AccepterはPrepare(n)を受け取ったらPromiseレスポンスを返す
l nがPromise済みの提案IDよりも⼤大きかった場合は受理理
l 提案を受理理していた場合は、その提案(IDと値を含む)を返す
l 提案を受理理していなかった場合はnilっぽいものを返す
l そうでない場合は拒否
l 拒否した場合は、現在受理理している提案IDを返す
40

41. Paxos: フェーズ2に⼊入る前に
l 次の状況になったらPrepareからやり直し
l 1台以上のaccepterに拒否された
l 拒否レスポンスの中から、最⼤大の提案IDを選択
l それより⼤大きなIDでPrepareし直し
l 拒否はされなかったが、過半数のレスポンスを回収できなかった
l 安全な判断ができないのでやり直し
A1
A2 A5
が過半数かどうか
わからないからやり直そう
A3 A4
41

42. Paxos: フェーズ2 Accept
l ProposerはaccepterにAccept(n, v)を送る
l nはPrepareした提案のID
l vは値
l Acceptを送る対象のaccepterは、Promiseを受け取ったものでな
くてもいい
l vは次のように決める
l 提案を受理理していたaccepterがいた場合は、返ってきたレスポン
スのうち最も⼤大きなIDを持つ提案の値をvとして採⽤用
l どのaccepterも値を受理理していなかった場合は、⾃自分の好きな値を
vとして採⽤用
l P2cの話
42

43. Paxos: フェーズ2 Accepted
l AccepterはAccept(n, v)を受け取る
l nがPromiseした提案ID以上の値だったら受理理
l そうでなかったら拒否
l Accepterはどのような状況下でPrepareやAcceptを受け取っても
それらを無視していい
l 「無視していい」とは
l メッセージが失われてもいい
l 障害が起こったりしてリクエストに応えられなくてもいい
l レスポンスが返ってこないからといって死亡判定する必要も無い
l 安全！！
43

44. 停⽌止保証
l FLP impossibility! Paxosにも合意に⾄至れないパスがある
l Proposer 2台がより⼤大きな値でPrepareし続けると・・・
Proposer1
Accepter
Proposer2
Prepare(n)
Prepare(n+1)
Prepare(n+2)
Prepare(n+3)
Acceptできない
Prepare(n+4)
…
(#^ω^)ﾋﾞｷﾋﾞｷ
l この問題をなくすことは不不可能
l 発⽣生率率率を減らすにはどうすればいいか
44

45. 停⽌止しなくなる確率率率を下げる
l 解決策
l Proposerのリーダーを1台選び、それだけが提案できるようにする
l Distinguished proposer
l 現実的にはPaxosのフェーズ2回分を
独⽴立立して実⾏行行するのに⼗十分な時間、
1台のproposerだけが動けばOK
l リーダーの選び⽅方は・・・
l また別の機会に
45

46. 安全性に関して
l Proposerが2台以上いると停⽌止は保証されないことはわかった
l しかし、リーダーが誤って2台以上同時出現することもある
l Split brain
l リーダーが1台しか出てこないようにすることはたぶん不不可能！
l Paxosはリーダーが複数台いても安全性は守られる
l 停⽌止保証がなくなるだけ
l 2つ以上の提案が選択されることはない
l 謎の提案が選択されることもない
46

47. 提案(値)が選択されたことの確認
l 提案を安全に選択する⼿手段は確⽴立立できた
l 提案が選択されたことはどうやって確認する？
l Learnerががんばる
l Accepterは勝⼿手に提案が選択されたと判断してはいけない
l 提案を上書きできなくなる
l Accepterが1台停⽌止しただけでも合意に⾄至れなくなる可能性がでる
l 過半数のAccepterに提案が受理理されたことをLearnerに確認させる
47

48. Learnerの構成例例1
l Accepterがlearnerにメッセージを送る
l もちろんメッセージは遅延したり、到達順序が前後したりする
l 過半数超えを確認するためには提案の値ではなくIDを利利⽤用
l ⽋欠点：メッセージ数がaccepterの数とlearnerの数の積に
A1 過半数超えたらOK
Accept(n, v)
L1
P1 A2
L2
A3 Accepted(n, v)
48

49. Learnerの構成2
l Distinguished learnerでメッセージ数を削減
l non-Byzantineだから問題が簡単になってるそうです
l Byzantine-failureが起こると、L1が間違った情報をまき散らすかも
A1 Accepted(n, v)
L2
Accept(n, v)
P1 A2 L1 L3
A3 L4
Accepted(n, v)
49

50. Learnerその他
l メッセージの損失を考慮
l AccepterからのAcceptedメッセージは失われる可能性がある
l そうすると提案が選択されたことに気づけない
l Learnerが定期的にaccepterに聞きに⾏行行けば解決か？
l Accepterが停⽌止していると厳しい
l Proposerにもう⼀一度度提案してもらう必要がある
l Distinguished learnerの冗⻑⾧長化
l Distinguished learnerが1台だけだとSPOFになる
l 冗⻑⾧長化は簡単
l メッセージ数(accepter数+learner数)*distinguished learner数
l A:5、L:5構成では25メッセージ必要
l A:5、DL:2、L:3では(5+3)*2で16メッセージ
50

51. 現実的なlearnerの運⽤用
l Distinguished proposer&learnerを同じプロセスで動かす
l いわゆるマスター
l ProposerはAcceptedメッセージをaccepterから回収する
l Learnerの役割も果たせる
l Acceptedメッセージが失われて過半数の確認ができない場合は？
l もう1度度Paxosインスタンスを実⾏行行すればいい
51

52. Paxos要約
l Paxosプロトコルの2フェーズ
l Prepare&Promise
l Accept&Accepted
l ID付きの提案がポイント！
l 提案は過半数のaccepterに受理理されたら合意を取れたといえる
l 過半数に受理理されたのを確認するのはlearnerの役⽬目
l Proposer、accepter、learnerは複数台いても⼤大丈夫
l Proposerは、活発なのが複数台いると停⽌止しなくなる場合がある
l Accepterは沢⼭山いても⼤大丈夫
l Learnerは沢⼭山いすぎると送らないといけないメッセージが増える
l 補⾜足：AccepterもLearnerも多ければいいってものじゃないよ！
52

53. Multi-Paxos
53

54. Paxosの最適化
l Paxosは1インスタンスあたりのメッセージ数が多い
l 最⼩小で4回のやりとりが必要になる
l メッセージ数を減らせないか？
l 仮定をおいたり、制約をかければ何とかなる
l Paxosの最適化⼿手法はいろいろある
l Cheap Paxos
l Fast Paxos
l 今⽇日はMulti-Paxosを紹介
54

55. Multi-Paxos
l 複数回連続してインスタンスを実⾏行行するような場合向けの最適化
l Distinguished proposerが割とstableであると仮定
l マスターがあんまり変わらない
l 何回も連続してインスタンスを実⾏行行する場合を考える
l 1回⽬目にPrepare&Promiseを実⾏行行してAcceptedまでこぎ着けた
l 2回⽬目以降降は、Prepare&Promiseを省省略略できないか
l 前回のインスタンスとproposerが同じである場合はいきなり
Accept⾶飛ばしていいんじゃない？
l 途中で他のproposerがPrepareで割り込めるし、安全性にも問題
ないよね？
l ざっくりですが、こんな雰囲気！
55

56. 参考⽂文献紹介
56

57. 俺たちの戦いはまだ始まったばかりだ！
l Paxosというか分散システムは難しいのでいろんな説明を読もう
l Consensus protocolの歴史と概要を知りたい
l Paper trailのConsensus Protocolsシリーズ
l Paxosのわかりやすいところだけ知りたい
l Paxos made simple
l Paxosを実装しようとしたらどういう問題が起こるのか知りたい
l Paxos made live
l Paxosを使ってるプロダクトの話を知りたい
l Chubby
l PaxosではないけどZooKeeperも！
l Paxosを極めたい
l The Part-time Parliament
57

58. Paper TrailのConsensus Protocolsシリーズ
l Henry Robinson(@HenryR)さんのブログ
l http://the-paper-trail.org/
l ZooKeeperのコミッタ
l Clouderaの⽅方
l Consensus Protocolsで検索索
l 2PC→3PC→Paxosという順で話が進んでいく
l かなりわかりやすいのでおすすめ！
l Paxosの説明のところがPaxos made simpleとちょっと違う
58

59. Paxos made simple
l 本⽇日の主な情報源
l Lamport先⽣生
l いきなりこれを読み始めてもいいレベル！
l 10回くらい読み直したら理理解できた
l メモ
l Proposal/valueという単語は適切切に使い分けている
l 注意して読もう
l Chosenの対象を⾒見見極める
l 選択されたのはproposal、それともvalue？
l 細かいことが気になり始めたらPaxos made liveへ！
59

60. Paxos made live
l Googleの論論⽂文
l Paxosを実装したらこんな問題に突き当たりました集
l 解決⽅方法ももちろん載ってる
l 参考⽂文献も豊富で、しかも⾯面⽩白そうな論論⽂文が多い
l 例例
l マスター(distinguished proposer)の維持⽅方法
l マスターのリースによる管理理
l ディスク障害との向き合い⽅方
l スナップショットの維持⽅方法
l MongoDBのoplog too stale問題に近い話も
l テスト⽅方法！！すばらしかったので読むべき
60

61. Chubby & ZooKeeper
l Chubby
l GoogleのPaxosを使ったもの
l (特許関係がよくわかってない)
l これがあると分散システムの設計がすごく楽に
l ZooKeeper
l Chubbyクローン(Paxos使ってない)
l ZAB(ZooKeeper Atomic Broadcast)
l Atomic Broadcastも⾯面⽩白い概念念
l Consensusと近い(というか同じ？)問題
61

62. The Part-Time Parliament
l 伝説の元論論⽂文
l 最初に投稿されたのは1990年年？
l 1998年年のACM Transactions on Computer Systems
l 証明も載ってる
l 難しい
l ⼀一⼈人で読んでると⼼心が折れそうなので⼀一緒に読む⼈人募集
62

63. まとめ
l Consensus
l そもそもどういう問題なのか
l どこで使われているのか
l 満たすべき性質
l Paxos
l Paxos made simpleに従った紹介
l Multi-Paxosの紹介
l 参考⽂文献紹介
63

64. ご清聴ありがとうございました！
Copyright © 2006-2012
Preferred Infrastructure All Right Reserved.