Paxos

株式会社プリファードインフラストラクチャー

2012 年 7 月 5 日

自己紹介

久保田展行 (@nobu_k) 製品開発部

Sedue/Bazil (Jubatus)

ブル 最近勉強してるもの

開発手法：要件定義・管理 本

Transactional Information Systems(@ ノーチラス )

– 約 1 年で念願のリカバリーまで到達・・・！ 分散 DB 本

2

今日の話

Paxos Consensus algorithm(protocol) の 1 つ ものすごく難しいことで有名 ( 主に元論文が )

流れ Consensus 問題設定 Paxos ( ちょびっとだけ )Multi-Paxos 参考文献紹介

日本語の文献が少なく、用語が怪しいですすいません

3

ConsensusPaxos の説明を始める前に

4

Consensus( 合意 ) とは

Consensus とは プロセスの集合が 1 つの値において合意を取ること 分散システムにおける重要な問題の 1 つ

5

どれか 1 つを選択

B

A

C D

E

つけ麺

ロンアール

ロンアール

ロンアール

Red Bull

「お昼どうする？」

Consensus algorithm はなぜ必要か

分散システムで高可用性 (High Availability) を実現するため 高可用性を実現する方法は「冗長化」ただ 1 つ

ハードウェア障害は防げない

6

状態を持つ (stateful な ) ソフトウェアを冗長化する 状態を持つソフトウェアを冗長化するには

レプリケーション State machine replication

命令の列を全レプリカに同じ順序で適用する

7

命令の列をすべてのレプリカに同じ順序で届ける

レプリカ毎に命令の順序が変わると、レプリカの状態も変わる i 番目の命令として何を採用するかに対して合意を取る

すべての i に対して合意を取る ここで Consensus が必要 しくじると状態の違う (inconsistent な ) レプリカができあがる

補足： Atomic broadcast 全順序付きのブロードキャスト すべてのプロセスが同じ順序でメッセージを受け取る メッセージはすべてのプロセスに到達するか、全く到達しないか

のどちらか

8

分散システムで合意を取るのはなぜ難しいのか

CC が使えないメールを利用して、集合場所を決めることを考える ただし、メールには到達保証がない ( 到達確認ができない ) 参加メンバーだけはわかっている 誰が取り仕切るかは決まっていない 他のメンバーが今何をしているのかはわからない

せっかくメール送ったのに返信が来ない・・・考えられる状況は メールは届いてない メールは届いてるけど仕事中で返信できない メールは返信されたけど、届く前に消えてしまった・・・

他のやっかいな問題 取り仕切り役が 2 人同時に、別々の集合場所を提案 音信不通の人が途中から復帰してくるけど議論に追いつけない

9

Consensus が必要とされるほかのところ

分散トランザクション トランザクションを Commit するか、 Abort するか 全員が同じ選択をしないと一貫性 (consistency) がオワコンに

メンバシップ管理 協調動作しているグループのメンバを管理する

メンバが追加されるとき、削除されるときに合意を取る 全員が常に同じメンバを見ている状態を維持

リーダー決定 リーダーは 1 プロセス (1 人 ) であるように決定する

人間的な問題 「お昼どこに行く？」、「明日どこに集合する？」 CC が使えないメールのみで合意を取れるか

10

問題設定

11

Consensus problem の設定

プロセス 合意を取りたいグループのメンバ (活動単位みたいなやつ )

主に Paxos における役割 (Role) Proposer

値を提案する Accepter

値を受理する Learner

ある値に関して合意が取れたことを確認する プロトコルによってはいない

1 プロセスがすべての役割を担ってもいい Proposer&accepter&learner兼任のプロセスだけでの構成も可

12

プロトコルが満たすべき性質

安全性 (safety) に関わる性質 ゆるふわバージョン Proposer が提案された値のみが選択される

誰も提案していない謎の値は選択されない ただ 1 つの値のみが選択される

正しく動作しているすべてのプロセスは同じ値を選ぶ 値が実際に使われるのは選択された後

先走り防止

その他の性質 (liveness) 停止保証 : 有限時間で値が選択されることを保証

13

問題があまりない状態での Consensus

想定する状況 メッセージは必ず届く メッセージは壊れない すべてのプロセスが同じ速度で処理を進める 障害は 100%検知できる 停止したプロセスは復活しない (fail-stop)

常にこの状態だと楽ちん

14

現実の問題

分散システム的な問題設定 処理に任意の時間がかかる、しかもプロセス毎に進行速度が違う 通信に任意の時間がかかる、メッセージが失われる可能性がある 停止したプロセスが、あとで復旧する可能性がある (fail-recover) しかし、メッセージが壊れた状態で到達しない (non-Byzantine)

15

A1働きたくないでござる (ゆっくり進行 )

メール返したくないでござるP1

これコミットしていいですか？

A2

A3

A4

メール届かない

一時間寝ます

補足： Synchronous/Asynchronous system model 同期、非同期、分散システムではちょっと意味が違う

特に元々 lock-free とかしてた人にとっては・・・ｗ 佐藤先生つぶやきが togetter にまとめられている

Google Spanner まとめ http://togetter.com/li/317139

Synchronous system model 先ほど「問題があまりない」と紹介した例 純粋にアルゴリズムを検証するのに便利なモデル

Asynchronous system model 問題しかない、なにが起こってもおかしくない方のモデル このモデルで正しく動けば、すべての状況で正しく動くんでは！

16

補足： FLP impossibility

分散システム界隈でよく見かける定理

非同期システムでは、たとえメッセージのロスがなくても、プロセスが 1台でも停止する可能性がある限り、 100% 合意に至れるConsensus アルゴリズムは存在しない Paxos も例外ではない！

注意 100% 合意に至れないだけで、大体のケースでは合意に至れる 「 100% の確率で完了するアルゴリズム」が存在しないことの証

明

17

Paxos

18

Paxos とは

非同期システム上での Consensus protocol の 1 つ 1989 年 ( 有名な論文が出たのは 1998 年 ) Lamport先生

分散アルゴリズムの神 名前はギリシャの Paxos島から

そこの議会の仕組み (fiction) が元ネタになってるらしい Chubby で一気に有名になった

相当やばい状態でも動く 2PC 、 3PC の問題を解決している

19

説明の流れ

Paxos made simple に従って話を進める Lamport先生の論文 ( というか記事？ ) 2001 年

まずは単純なモデルを構築 徐々に問題を解決しながら完成に近づけていく

1回の Paxos インスタンスに関する説明 1 つの値に対して合意を取る一連の処理をインスタンスと呼ぶ State machine replication は i 番目の命令毎にインスタンスを実

行して実現する

20

単純な方法

Proposer 1台、 accepter 1台 Proposer の提案が accepter に渡った段階で値が選択される

問題 Proposer 、 accepter どちらが停止してもプロトコルが停止する

解決策 Proposer 、 accepter が複数台いる構成にする まずは accepter が複数いる状況を考える 次に proposer が複数いる状況を考える

21

複数 accepter を使って合意を取る

手順 Proposer が複数の accepter に提案を送る Accepter は値を受理 (accept) してもいいし、しなくてもいい 十分に多く (以後”過半数” ) の accepter が受理した値を選択する

例：過半数、 Quorum Accepter 集合の部分集合の集合で、任意の 2 つの要素 ( 部分集

合 ) が 1 つ以上の共通する要素 ( プロセス ) を持つ Accepter が 1 つの提案しか受理しないようにすれば動く

問題 Accepter が全部の提案を拒否すると提案を選択できない

制約 P1. Accepter は最初に受け取った提案を受理しなければならな

い22

Proposer を複数用意する

複数台用意できれば、 1台停止しても怖くない しかし、メッセージロスが絶妙に積み重なった状況を考える

N台の accepter はすべて値を受理している 全体で M個の値が受理されている しかし、どの値も過半数の accpeter から受理されていない

23

A1

A2

A3 A4

A5

3 提案

複数 proposer での問題

問題 M=2 の状況でも 1台の accepter の障害でプロトコルが停止する

かも 解決策

Accepter が複数の提案を受理できるようにする 値の上書きを許す

2F+1台構成で F台までの障害は許容したい 今だと何台構成でも 1台の障害しか

許容できない状況 もちろんワーストケースの話

24

^o^

A2

A3 A4

A5

提案 ID(proposal number) の導入

Accepter が複数の提案を受理できるようにするために・・・ 提案に全順序付きの ID を付ける 混乱をなくすため、すべての提案がユニークな ID を持つようにす

る 値は同じでも、提案自体は違うことを識別したい

ID は単調増加する (連番である必要はない ) データの例

提案 : ( 提案 ID, 値 ) 提案 ID: (数値 , プロセスの ID)

プロセスの ID はユニークなものを採用 その他

複数の ID が異なる提案が同じ値を持つことはある 同じ ID の提案は、同じ値しか持たない

25

提案の選択と提案の上書きによる問題

「値 v を持つ提案が選択された」とは 過半数の accepter が値 v を持つ提案を受理した場合、提案が選択

されたという 値が選択された後も、提案を送ることは可能

N/2+1台の accepter にだけ受理された状態で accepter が 1台

停止するとよくわからないことになるため

受理した提案を上書きすることによる問題 一度選択された (過半数の accepter から受理された ) 値を変更で

きる “ただ 1 つの値のみが選択される”という性質に違反する もう 1 つ制約が必要

26

もう 1 つの制約

P2. 一度値 v を持つ提案が選択されたら、より大きな ID を持つ提案が選択される場合、その提案の値は v でなければならない

これで、提案選択後に選択された提案の値以外で上書きされることを防げる

具体的にどうやってこの制約を実現するのか 少なくとも accepter には制約が必要 このことを考慮して P2 を少し修正する

27

P2 の修正

提案が選択されるためには、最低でも 1 つの accepter に受理されなければならない これを考慮して P2 を少し修正

P2a. 値 v を持つ提案が選択されたら、任意の accepter に受理されるより大きな ID を持つ提案の値は v でなければならない

しかし、このままでは P1 を満たせない・・・ P1. Accepter は最初に受け取った提案を受理しなければならない

28

P1 と P2a の問題

問題が起こる状況 提案が選択されている しかし、まだ提案を 1度も受け取っていない accepter もいる その accepter に違う値を持つ提案が送られる P1 により、その accepter は提案を受理しなければならない

29

A1

A2

A3 A4

A5

最初の提案は受理するんだろオラァ

やめて＼ (^o^)／

補足：現段階での疑問

いずれにせよ過半数は維持できているため大丈夫では？ この問題を放置すると今後の制約を洗練させる際の支障に・・・ 具体的には、最も大きな提案 ID を利用して選択済みでない値を提

案できるのが問題 今は、とりあえずこうしないと無理と思って続ける

30

A1

A2

A3 A4

A5

／ (^o^)＼

P2a の修正

結局 proposer側にも制約をかけるしかない

P2b. 値 v を持つ提案が選択されたら、任意の proposer からリクエストされる、より大きな ID を持つすべての提案の値は v でなければならない

P2b を満たせば P2a を満たし、 P2a を満たせば元々の P2 を満たす

Proposer は選択されている値しか提案できないため P1 を維持可能

では P2b をどうやって満たすか

31

提案が選択されている状況を考える

ある提案が選択されていると言うことは・・・ その提案を受理した Accepter 集合の部分集合 S が存在する S は過半数 (※) の accepter で構成される

ということを元に、本当はかっこよく帰納的に説明するんですが！

32

A1

A2

A3 A4

A5

※特定の性質を満たせば 過半数である必要は無い

しょぼい説明

提案を行う前に、過半数の accepter に対して現在受理している提案を確認すればよくない？ もし提案が受理されてたら、とりあえず ID が一番大きな提案の値

をもう一度提案しとけばいいよね 提案が選択された後でも大丈夫そう！？ うまくいくっぽくね！？

詳細は Paxos made live を参照

33

A1

A2

A3 A4

A5ほんとは を提案したいけど今一番新しい提案は だから を提案しておこう・・・

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

Prepare&Promise

自分の提案 ID が提案時点で最大であることを保証したい 確認時点では無くて、自分が提案する時点で最大であることを保

証 しかし未来を予測するのは難しい・・・

状況を確認してから提案するまでに状態が変わったらどうしよう

Prepare(n) メッセージの導入 自分もうすぐ提案するので、今後 ID が n未満の提案は無視して！ これで少なくとも自分より古くなる予定の提案は全部拒否できる Prepare を受け取った accepter は約束を必ず守ること！

Promise Accepter の Prepare に対する返信、受理するか拒否するか 自分が現在受理している提案を返す (ID と値 )

35

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

最後の修正と制約のまとめ

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

Paxos できた？

なんかそれらしくなった気がする 今まで出てきた制約をまとめてみる フェーズを 2 つに分けて考える

フェーズ 1: Prepare&Promise メッセージのやりとり フェーズ 2: Accept&Accepted メッセージのやりとり

Promise や Accepted で返す情報を増やすことにより若干最適化可

Learner はもうちょっと後で出てくる

38

Paxos: フェーズ 1 Prepare

Proposer は Prepare(n) メッセージを過半数の accepter に送る N はこれから送ろうと思っている提案の ID(proposal number)

Accepter から Promise メッセージが返ってくるのを待つ 補足：非同期なので、適当にタイムアウトを設定して待つ

適当な時間が経過したらもう一度リクエストを投げればいい

39

Paxos: フェーズ 1 Promise

Accepter は Prepare(n) を受け取ったら Promise レスポンスを返す n が Promise済みの提案 IDよりも大きかった場合は受理

提案を受理していた場合は、その提案 (ID と値を含む ) を返す 提案を受理していなかった場合は nil っぽいものを返す

そうでない場合は拒否 拒否した場合は、現在受理している提案 ID を返す

40

Paxos: フェーズ 2 に入る前に

次の状況になったら Prepare からやり直し 1台以上の accepter に拒否された

拒否レスポンスの中から、最大の提案 ID を選択 それより大きな ID で Prepare し直し

拒否はされなかったが、過半数のレスポンスを回収できなかった 安全な判断ができないのでやり直し

41

A1

A2

A3 A4

A5

が過半数かどうかわからないからやり直そう

Paxos: フェーズ 2 Accept

Proposer は accepter に Accept(n, v) を送る n は Prepare した提案の ID v は値 Accept を送る対象の accepter は、 Promise を受け取ったもので

なくてもいい v は次のように決める

提案を受理していた accepter がいた場合は、返ってきたレスポン

スのうち最も大きな ID を持つ提案の値を v として採用 どの accepter も値を受理していなかった場合は、自分の好きな値

を v として採用 P2c の話

42

Paxos: フェーズ 2 Accepted

Accepter は Accept(n, v) を受け取る n が Promise した提案 ID以上の値だったら受理 そうでなかったら拒否

Accepter はどのような状況下で Prepare や Accept を受け取ってもそれらを無視していい 「無視していい」とは

メッセージが失われてもいい 障害が起こったりしてリクエストに応えられなくてもいい

レスポンスが返ってこないからといって死亡判定する必要も無い 安全！！

43

停止保証

FLP impossibility! Paxos にも合意に至れないパスがある Proposer 2台がより大きな値で Prepare し続けると・・・

この問題をなくすことは不可能 発生率を減らすにはどうすればいいか

44

Proposer1 Accepter Proposer2

Prepare(n)Prepare(n+1)

Prepare(n+2)Prepare(n+3)

Prepare(n+4)…

Accept できない

(#^ω^) ﾋﾞｷﾋﾞｷ

停止しなくなる確率を下げる

解決策 Proposer のリーダーを 1台選び、それだけが提案できるようにす

る Distinguished proposer

現実的には Paxos のフェーズ 2回分を独立して実行するのに十分な時間、1台の proposer だけが動けば OK

リーダーの選び方は・・・ また別の機会に

45

安全性に関して

Proposer が 2台以上いると停止は保証されないことはわかった しかし、リーダーが誤って 2台以上同時出現することもある

Split brain リーダーが 1台しか出てこないようにすることはたぶん不可能！

Paxos はリーダーが複数台いても安全性は守られる 停止保証がなくなるだけ 2 つ以上の提案が選択されることはない 謎の提案が選択されることもない

46

提案 ( 値 ) が選択されたことの確認

提案を安全に選択する手段は確立できた 提案が選択されたことはどうやって確認する？

Learner ががんばる

Accepter は勝手に提案が選択されたと判断してはいけない 提案を上書きできなくなる Accepter が 1台停止しただけでも合意に至れなくなる可能性がで

る

過半数の accepter に提案が受理されたことを learner に確認させる

47

Learner の構成例 1

Accepter が learner にメッセージを送る もちろんメッセージは遅延したり、到達順序が前後したりする 過半数超えを確認するためには提案の値ではなく ID を利用

欠点：メッセージ数が accepter の数と learner の数の積に

48

P1

A1

A2

A3

L1

L2

過半数超えたら OKAccept(n, v)

Accepted(n, v)

Learner の構成 2

Distinguished learner でメッセージ数を削減 non-Byzantine だから問題が簡単になってるそうです

Byzantine-failure が起こると、 L1 が間違った情報をまき散らす

かも

49

P1

A1

A2

A3

L1

Accept(n, v)

Accepted(n, v)

L2

L3

L4

Accepted(n, v)

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

現実的な learner の運用

Distinguished proposer&learner を同じプロセスで動かす いわゆるマスター

Proposer は Accepted メッセージを accepter から回収する Learner の役割も果たせる

Accepted メッセージが失われて過半数の確認ができない場合は？ もう 1度 Paxos インスタンスを実行すればいい

51

Paxos 要約

Paxos プロトコルの 2 フェーズ Prepare&Promise Accept&Accepted ID 付きの提案がポイント！

提案は過半数の accepter に受理されたら合意を取れたといえる 過半数に受理されたのを確認するのは learner の役目

Proposer 、 accepter 、 learner は複数台いても大丈夫 Proposer は、活発なのが複数台いると停止しなくなる場合がある Accepter は沢山いても大丈夫 Learner は沢山いすぎると送らないといけないメッセージが増え

る 補足： Accepter も learner も多ければいいってものじゃないよ！

52

Multi-Paxos

53

Paxos の最適化

Paxos は 1 インスタンスあたりのメッセージ数が多い 最小で 4回のやりとりが必要になる

メッセージ数を減らせないか？ 仮定をおいたり、制約をかければ何とかなる

Paxos の最適化手法はいろいろある Cheap Paxos Fast Paxos

今日は Multi-Paxos を紹介

54

Multi-Paxos

複数回連続してインスタンスを実行するような場合向けの最適化 Distinguished proposer が割と stable であると仮定

マスターがあんまり変わらない

何回も連続してインスタンスを実行する場合を考える 1回目に Prepare&Promise を実行して Accepted までこぎ着け

た 2回目以降は、 Prepare&Promise を省略できないか 前回のインスタンスと proposer が同じである場合はいきなり

Accept飛ばしていいんじゃない？ 途中で他の proposer が Prepare で割り込めるし、安全性にも問

題ないよね？ ざっくりですが、こんな雰囲気！

55

参考文献紹介

56

俺たちの戦いはまだ始まったばかりだ！

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

Paper Trail の Consensus Protocols シリーズ

Henry Robinson(@HenryR) さんのブログ http://the-paper-trail.org/ ZooKeeper のコミッタ Cloudera の方

Consensus Protocols で検索 2PC→3PC→Paxos という順で話が進んでいく かなりわかりやすいのでおすすめ！

Paxos の説明のところが Paxos made simple とちょっと違う

58

Paxos made simple

本日の主な情報源 Lamport先生

いきなりこれを読み始めてもいいレベル！ 10回くらい読み直したら理解できた メモ

Proposal/value という単語は適切に使い分けている 注意して読もう

Chosen の対象を見極める 選択されたのは proposal 、それとも value ？

細かいことが気になり始めたら Paxos made liveへ！

59

Paxos made live

Google の論文 Paxos を実装したらこんな問題に突き当たりました集 解決方法ももちろん載ってる 参考文献も豊富で、しかも面白そうな論文が多い

例 マスター (distinguished proposer) の維持方法

マスターのリースによる管理 ディスク障害との向き合い方 スナップショットの維持方法

MongoDB の oplog too stale 問題に近い話も テスト方法！！すばらしかったので読むべき

60

Chubby & ZooKeeper

Chubby Google の Paxos を使ったもの

(特許関係がよくわかってない ) これがあると分散システムの設計がすごく楽に

ZooKeeper Chubby クローン (Paxos 使ってない ) ZAB(ZooKeeper Atomic Broadcast) Atomic Broadcast も面白い概念

Consensus と近い ( というか同じ？ ) 問題

61

The Part-Time Parliament

伝説の元論文 最初に投稿されたのは 1990 年？ 1998 年の ACM Transactions on Computer Systems

証明も載ってる 難しい 一人で読んでると心が折れそうなので一緒に読む人募集

62

まとめ

Consensus そもそもどういう問題なのか どこで使われているのか 満たすべき性質

Paxos Paxos made simple に従った紹介 Multi-Paxos の紹介

参考文献紹介

63

Copyright © 2006-2012

Preferred Infrastructure All Right Reserved.

ご清聴ありがとうございました！