Paxos

2,267 views

Published on

0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,267
On SlideShare
0
From Embeds
0
Number of Embeds
49
Actions
Shares
0
Downloads
35
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide

Paxos

  1. 1. Paxos株式会社プリファードインフラストラクチャー 2012年 7月 5日
  2. 2. 自己紹介 久保田展行(@nobu_k) 製品開発部  Sedue/Bazil  (Jubatus) ブル 最近勉強してるもの  開発手法:要件定義・管理  本  Transactional Information Systems(@ノーチラス) – 約1年で念願のリカバリーまで到達・・・!  分散DB本 2
  3. 3. 今日の話 Paxos  Consensus algorithm(protocol)の1つ  ものすごく難しいことで有名(主に元論文が) 流れ  Consensus  問題設定  Paxos  (ちょびっとだけ)Multi-Paxos  参考文献紹介 日本語の文献が尐なく、用語が怪しいですすいません 3
  4. 4. Paxosの説明を始める前にConsensus4
  5. 5. Consensus(合意)とは Consensusとは  プロセスの集合が1つの値において合意を取ること  分散システムにおける重要な問題の1つ ロンアール 「お昼どうする?」 A Red Bull ロンアール B E どれか1つを選択 ロンアール つけ麺 C D 5
  6. 6. Consensus algorithmはなぜ必要か 分散システムで高可用性(High Availability)を実現するため 高可用性を実現する方法は「冗長化」ただ1つ  ハードウェア障害は防げない 6
  7. 7. 状態を持つ(statefulな)ソフトウェアを冗長化する 状態を持つソフトウェアを冗長化するには  レプリケーション  State machine replication  命令の列を全レプリカに同じ順序で適用する 7
  8. 8. 命令の列をすべてのレプリカに同じ順序で届ける レプリカ毎に命令の順序が変わると、レプリカの状態も変わる i番目の命令として何を採用するかに対して合意を取る  すべてのiに対して合意を取る  ここでConsensusが必要  しくじると状態の違う(inconsistentな)レプリカができあがる 補足:Atomic broadcast  全順序付きのブロードキャスト  すべてのプロセスが同じ順序でメッセージを受け取る  メッセージはすべてのプロセスに到達するか、全く到達しないかの どちらか 8
  9. 9. 分散システムで合意を取るのはなぜ難しいのか CCが使えないメールを利用して、集合場所を決めることを考える  ただし、メールには到達保証がない(到達確認ができない)  参加メンバーだけはわかっている  誰が取り仕切るかは決まっていない  他のメンバーが今何をしているのかはわからない せっかくメール送ったのに返信が来ない・・・考えられる状況は  メールは届いてない  メールは届いてるけど仕事中で返信できない  メールは返信されたけど、届く前に消えてしまった・・・ 他のやっかいな問題  取り仕切り役が2人同時に、別々の集合場所を提案  音信不通の人が途中から復帰してくるけど議論に追いつけない 9
  10. 10. Consensusが必要とされるほかのところ 分散トランザクション  トランザクションをCommitするか、Abortするか  全員が同じ選択をしないと一貫性(consistency)がオワコンに メンバシップ管理  協調動作しているグループのメンバを管理する  メンバが追加されるとき、削除されるときに合意を取る  全員が常に同じメンバを見ている状態を維持 リーダー決定  リーダーは1プロセス(1人)であるように決定する 人間的な問題  「お昼どこに行く?」、「明日どこに集合する?」  CCが使えないメールのみで合意を取れるか 10
  11. 11. 問題設定11
  12. 12. Consensus problemの設定 プロセス  合意を取りたいグループのメンバ(活動単位みたいなやつ) 主にPaxosにおける役割(Role)  Proposer  値を提案する  Accepter  値を受理する  Learner  ある値に関して合意が取れたことを確認する  プロトコルによってはいない 1プロセスがすべての役割を担ってもいい  Proposer&accepter&learner兼任のプロセスだけでの構成も可 12
  13. 13. プロトコルが満たすべき性質 安全性(safety)に関わる性質 ゆるふわバージョン  Proposerが提案された値のみが選択される  誰も提案していない謎の値は選択されない  ただ1つの値のみが選択される  正しく動作しているすべてのプロセスは同じ値を選ぶ  値が実際に使われるのは選択された後  先走り防止 その他の性質(liveness)  停止保証: 有限時間で値が選択されることを保証 13
  14. 14. 問題があまりない状態でのConsensus 想定する状況  メッセージは必ず届く  メッセージは壊れない  すべてのプロセスが同じ速度で処理を進める  障害は100%検知できる  停止したプロセスは復活しない(fail-stop) 常にこの状態だと楽ちん 14
  15. 15. 現実の問題 分散システム的な問題設定  処理に任意の時間がかかる、しかもプロセス毎に進行速度が違う  通信に任意の時間がかかる、メッセージが失われる可能性がある  停止したプロセスが、あとで復旧する可能性がある(fail-recover)  しかし、メッセージが壊れた状態で到達しない(non-Byzantine) A1 働きたくないでござる(ゆっくり進行) A2 メール返したくないでござる P1 A3 メール届かない これコミットしていいですか? A4 一時間寝ます 15
  16. 16. 補足:Synchronous/Asynchronous system model 同期、非同期、分散システムではちょっと意味が違う  特に元々lock-freeとかしてた人にとっては・・・w  佐藤先生つぶやきがtogetterにまとめられている  Google Spannerまとめ http://togetter.com/li/317139 Synchronous system model  先ほど「問題があまりない」と紹介した例  純粋にアルゴリズムを検証するのに便利なモデル Asynchronous system model  問題しかない、なにが起こってもおかしくない方のモデル  このモデルで正しく動けば、すべての状況で正しく動くんでは! 16
  17. 17. 補足:FLP impossibility 分散システム界隈でよく見かける 非同期システムでは、たとえメッセージのロスがなくても、プロセ スが1台でも停止する可能性がある限り、100%合意に至れる Consensusアルゴリズムは存在しない  Paxosも例外ではない! 注意  100%合意に至れないだけで、大体のケースでは合意に至れる  「100%の確率で完了するアルゴリズム」が存在しないことの証明 17
  18. 18. Paxos18
  19. 19. Paxosとは 非同期システム上でのConsensus protocolの1つ  1989年(有名な論文が出たのは1998年)  Lamport先生  分散アルゴリズムの神  名前はギリシャのPaxos島から  そこの議会の仕組み(fiction)が元ネタになってるらしい  Chubbyで一気に有名になった 相当やばい状態でも動く  2PC、3PCの問題を解決している 19
  20. 20. 説明の流れ Paxos made simpleに従って話を進める  Lamport先生の論文(というか記事?)  2001年 まずは単純なモデルを構築 徐々に問題を解決しながら完成に近づけていく 1回のPaxosインスタンスに関する説明  1つの値に対して合意を取る一連の処理をインスタンスと呼ぶ  State machine replicationはi番目の命令毎にインスタンスを実行し て実現する 20
  21. 21. 単純な方法 Proposer 1台、accepter 1台 Proposerの提案がaccepterに渡った段階で値が選択される 問題  Proposer、accepterどちらが停止してもプロトコルが停止する 解決策  Proposer、accepterが複数台いる構成にする  まずはaccepterが複数いる状況を考える  次にproposerが複数いる状況を考える 21
  22. 22. 複数accepter 手順  Proposerが複数のaccepterに提案を送る  Accepterは値を受理(accept)してもいいし、しなくてもいい  十分に多く(以後”過半数”)のaccepterが受理した値を選択する  例:過半数、Quorum  Accepter集合の部分集合の集合で、任意の2つの要素(部分集合)が1 つ以上の共通する要素(プロセス)を持つ  Accepterが1つの提案しか受理しないようにすれば動く 問題  Accepterが全部の提案を拒否すると提案を選択できない 制約  P1. Accepterは最初に受け取った提案を受理しなければならない 22
  23. 23. Proposerを複数用意する 複数台用意できれば、1台停止しても怖くない しかし、メッセージロスが絶妙に積み重なった状況を考える  N台のaccepterはすべて値を受理している  全体でM個の値が受理されている  しかし、どの値も過半数のaccpeterから受理されていない A1 3提案 A2 A5 A3 A4 23
  24. 24. 複数proposerでの問題 問題  M=2の状況でも1台のaccepterの障害でプロトコルが停止するかも 解決策  Accepterが複数の提案を受理できるようにする  値の上書きを許す ^o^ 2F+1台構成でF台までの障害は許容したい  今だと何台構成でも1台の障害しか A2 A5 許容できない状況  もちろんワーストケースの話 A3 A4 24
  25. 25. 提案ID(proposal number)の導入 Accepterが複数の提案を受理できるようにするために・・・  提案に全順序付きのIDを付ける  混乱をなくすため、すべての提案がユニークなIDを持つようにする  値は同じでも、提案自体は違うことを識別したい  IDは単調増加する(連番である必要はない) データの例  提案: (提案ID, 値)  提案ID: (数値, プロセスのID)  プロセスのIDはユニークなものを採用  複数のIDが異なる提案が同じ値を持つことはある  同じIDの提案は、同じ値しか持たない 25
  26. 26. 提案の選択と提案の上書きによる問題 「値vを持つ提案が選択された」とは  過半数のaccepterが値vを持つ提案を受理した場合、提案が選択さ れたという  値が選択された後も、提案を送ることは可能  N/2+1台のaccepterにだけ受理された状態でaccepterが1台停止する とよくわからないことになるため 受理した提案を上書きすることによる問題  一度選択された(過半数のaccepterから受理された)値 る  “ただ1つの値のみが選択される”という性質に違反する  もう1つ制約が必要 26
  27. 27. もう1つの制約 P2. 一度値vを持つ提案が選択されたら、より大きなIDを持つ提案 が選択される場合、その提案の値はvでなければならない これで、提案選択後に選択された提案の値以外で上書きされること を防げる 具体的にどうやってこの制約を実現するのか  尐なくともaccepterには制約が必要  このことを考慮してP2を尐し修正する 27
  28. 28. P2の修正 提案が選択されるためには、最低でも1つのaccepterに受理されな ければならない  これを考慮してP2を尐し修正 P2a. 値vを持つ提案が選択されたら、任意のaccepterに受理される より大きなIDを持つ提案の値はvでなければならない しかし、このままではP1を満たせない・・・  P1. Accepterは最初に受け取った提案を受理しなければならない 28
  29. 29. P1とP2aの問題 問題が起こる状況  提案が選択されている  しかし、まだ提案を1度も受け取っていないaccepterもいる  そのaccepterに違う値を持つ提案が送られる  P1により、そのaccepterは提案を受理しなければならない A1 やめて\(^o^)/ A2 A5 最初の提案は受理するんだろオラァ A3 A4 29
  30. 30. 補足:現段階での疑問 いずれにせよ過半数は維持できているため大丈夫では?  この問題を放置すると今後の制約を洗練させる際の支障に・・・  具体的には、最も大きな提案IDを利用して選択済みでない値を提案 できるのが問題 今は、とりあえずこうしないと無理と思って続ける A1 /(^o^)\ A2 A5 A3 A4 30
  31. 31. P2aの修正 結局proposer側にも制約をかけるしかない P2b. 値vを持つ提案が選択されたら、任意のproposerからリクエ ストされる、より大きなIDを持つすべての提案の値はvでなければ ならない P2bを満たせばP2aを満たし、P2aを満たせば元々のP2を満たす Proposerは選択されている値しか提案できないためP1を維持可能 ではP2bをどうやって満たすか 31
  32. 32. 提案が選択されている状況を考える  ある提案が選択されていると言うことは・・・  その提案を受理したAccepter集合の部分集合Sが存在する  Sは過半数(※)のaccepterで構成される  ということを元に、本当はかっこよく帰納的に説明するんですが! A1 A2 A5 A3 A4※特定の性質を満たせば 過半数である必要は無い 32
  33. 33. しょぼい説明 提案を行う前に、過半数のaccepterに対して現在受理している提案 を確認すればよくない?  もし提案が受理されてたら、とりあえずIDが一番大きな提案の値を もう一度提案しとけばいいよね  提案が選択された後でも大丈夫そう!?  うまくいくっぽくね!? A1 詳細はPaxos made liveを参照 A2 A5 ほんとは を提案したいけど 今一番新しい提案は だから を提案しておこう・・・ A3 A4 33
  34. 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. 35. Prepare&Promise 自分の提案IDが提案時点で最大であることを保証したい  確認時点では無くて、自分が提案する時点で最大であることを保証  しかし未来を予測するのは難しい・・・  状況を確認してから提案するまでに状態が変わったらどうしよう Prepare(n)メッセージの導入  自分もうすぐ提案するので、今後IDがn未満の提案は無視して!  これで尐なくとも自分より古くなる予定の提案は全部拒否できる  Prepareを受け取ったaccepterは約束を必ず守ること! Promise  AccepterのPrepareに対する返信、受理するか拒否するか  自分が現在受理している提案を返す(IDと値) 35
  36. 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. 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. 38. Paxosできた? なんかそれらしくなった気がする 今まで出てきた制約をまとめてみる フェーズを2つに分けて考える  フェーズ1: Prepare&Promiseメッセージのやりとり  フェーズ2: Accept&Acceptedメッセージのやりとり PromiseやAcceptedで返す情報を増やすことにより若干最適化可 Learnerはもうちょっと後で出てくる 38
  39. 39. Paxos: フェーズ1 Prepare ProposerはPrepare(n)メッセージを過半数のaccepterに送る  Nはこれから送ろうと思っている提案のID(proposal number) AccepterからPromiseメッセージが返ってくるのを待つ  補足:非同期なので、適当にタイムアウトを設定して待つ  適当な時間が経過したらもう一度リクエストを投げればいい 39
  40. 40. Paxos: フェーズ1 Promise AccepterはPrepare(n)を受け取ったらPromiseレスポンスを返す  nがPromise済みの提案IDよりも大きかった場合は受理  提案を受理していた場合は、その提案(IDと値を含む)を返す  提案を受理していなかった場合はnilっぽいものを返す  そうでない場合は拒否  拒否した場合は、現在受理している提案IDを返す 40
  41. 41. Paxos: フェーズ2に入る前に 次の状況になったらPrepareからやり直し  1台以上のaccepterに拒否された  拒否レスポンスの中から、最大の提案IDを選択  それより大きなIDでPrepareし直し  拒否はされなかったが、過半数のレスポンスを回収できなかった  安全な判断ができないのでやり直し A1 A2 A5 が過半数かどうかわからないからやり直そう A3 A4 41
  42. 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. 43. Paxos: フェーズ2 Accepted AccepterはAccept(n, v)を受け取る  nがPromiseした提案ID以上の値だったら受理  そうでなかったら拒否 Accepterはどのような状況下でPrepareやAcceptを受け取ってもそ れらを無視していい  「無視していい」とは  メッセージが失われてもいい  障害が起こったりしてリクエストに応えられなくてもいい  レスポンスが返ってこないからといって死亡判定する必要も無い  安全!! 43
  44. 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. 45. 停止しなくなる確率を下げる 解決策  Proposerのリーダーを1台選び、それだけが提案できるようにする  Distinguished proposer 現実的にはPaxosのフェーズ2回分を 独立して実行するのに十分な時間、 1台のproposer OK リーダーの選び方は・・・  また別の機会に 45
  46. 46. 安全性に関して Proposerが2台以上いると停止は保証されないことはわかった しかし、リーダーが誤って2台以上同時出現することもある  Split brain  リーダーが1台しか出てこないようにすることはたぶん不可能! Paxosはリーダーが複数台いても安全性は守られる  停止保証がなくなるだけ  2つ以上の提案が選択されることはない  謎の提案が選択されることもない 46
  47. 47. 提案(値) 提案を安全に選択する手段は確立できた 提案が選択されたことはどうやって確認する?  Learnerががんばる Accepterは勝手に提案が選択されたと判断してはいけない  提案を上書きできなくなる  Accepterが1台停止しただけでも合意に至れなくなる可能性がでる 過半数のaccepterに提案が受理されたことをlearnerに確認させる 47
  48. 48. Learnerの構成例1 Accepterがlearnerにメッセージを送る  もちろんメッセージは遅延したり、到達順序が前後したりする  過半数超えを確認するためには提案の値ではなくIDを利用 欠点:メッセージ数がaccepterの数とlearnerの数の積に A1 過半数超えたらOK Accept(n, v) L1 P1 A2 L2 A3 Accepted(n, v) 48
  49. 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. 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. 51. 現実的なlearnerの運用 Distinguished proposer&learnerを同じプロセスで動かす  いわゆるマスター ProposerはAcceptedメッセージをaccepterから回収する  Learnerの役割も果たせる Acceptedメッセージが失われて過半数の確認ができない場合は?  もう1度Paxosインスタンスを実行すればいい 51
  52. 52. Paxos要約 Paxosプロトコルの2フェーズ  Prepare&Promise  Accept&Accepted  ID付きの提案がポイント! 提案は過半数のaccepterに受理されたら合意を取れたといえる 過半数に受理されたのを確認するのはlearnerの役目 Proposer、accepter、learnerは複数台いても大丈夫  Proposerは、活発なのが複数台いると停止しなくなる場合がある  Accepterは沢山いても大丈夫  Learnerは沢山いすぎると送らないといけないメッセージが増える 補足:Accepterもlearnerも多ければいいってものじゃないよ! 52
  53. 53. Multi-Paxos53
  54. 54. Paxosの最適化 Paxosは1インスタンスあたりのメッセージ数が多い  最小で4回のやりとりが必要になる メッセージ数を減らせないか?  仮定をおいたり、制約をかければ何とかなる Paxosの最適化手法はいろいろある  Cheap Paxos  Fast Paxos 今日はMulti-Paxosを紹介 54
  55. 55. Multi-Paxos 複数回連続してインスタンスを実行するような場合向けの最適化 Distinguished proposerが割とstableであると仮定  マスターがあんまり変わらない 何回も連続してインスタンスを実行する場合を考える  1回目にPrepare&Promiseを実行してAcceptedまでこぎ着けた  2回目以降は、Prepare&Promiseを省略できないか  前回のインスタンスとproposerが同じである場合はいきなりAccept 飛ばしていいんじゃない?  途中で他のproposerがPrepareで割り込めるし、安全性にも問題な いよね? ざっくりですが、こんな雰囲気! 55
  56. 56. 参考文献紹介56
  57. 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. 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. 59. Paxos made simple 本日の主な情報源  Lamport先生 いきなりこれを読み始めてもいいレベル! 10回くらい読み直したら理解できた メモ  Proposal/valueという単語は適切に使い分けている  注意して読もう  Chosenの対象を見極める  選択されたのはproposal、それともvalue?  細かいことが気になり始めたらPaxos made liveへ! 59
  60. 60. Paxos made live Googleの論文  Paxosを実装したらこんな問題に突き当たりました集  解決方法ももちろん載ってる  参考文献も豊富で、しかも面白そうな論文が多い 例  マスター(distinguished proposer)の維持方法  マスターのリースによる管理  ディスク障害との向き合い方  スナップショットの維持方法  MongoDBのoplog too stale問題に近い話も  テスト方法!!すばらしかったので読むべき 60
  61. 61. Chubby & ZooKeeper Chubby  GoogleのPaxosを使ったもの  (特許関係がよくわかってない)  これがあると分散システムの設計がすごく楽に ZooKeeper  Chubbyクローン(Paxos使ってない)  ZAB(ZooKeeper Atomic Broadcast)  Atomic Broadcastも面白い概念  Consensusと近い(というか同じ?)問題 61
  62. 62. The Part-Time Parliament 伝説の元論文  最初に投稿されたのは1990年?  1998年のACM Transactions on Computer Systems 証明も載ってる 難しい 一人で読んでると心が折れそうなので一緒に読む人募集 62
  63. 63. まとめ Consensus  そもそもどういう問題なのか  どこで使われているのか  満たすべき性質 Paxos  Paxos made simpleに従った紹介  Multi-Paxosの紹介 参考文献紹介 63
  64. 64. ご清聴ありがとうございました!Copyright © 2006-2012Preferred Infrastructure All Right Reserved.

×