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

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

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

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

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

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

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

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

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

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

11. 問題設定
11

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

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

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

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

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

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

18. Paxos
18

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

53. Multi-Paxos
53

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

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

56. 参考文献紹介
56

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

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

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

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

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

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

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

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