Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Paxos株式会社プリファードインフラストラクチャー       2012年 7月 5日
自己紹介   久保田展行(@nobu_k)   製品開発部       Sedue/Bazil       (Jubatus)   ブル   最近勉強してるもの       開発手法:要件定義・管理       本       ...
今日の話   Paxos       Consensus algorithm(protocol)の1つ       ものすごく難しいことで有名(主に元論文が)   流れ       Consensus       問題設定    ...
Paxosの説明を始める前にConsensus4
Consensus(合意)とは   Consensusとは       プロセスの集合が1つの値において合意を取ること       分散システムにおける重要な問題の1つ                               ロンアー...
Consensus algorithmはなぜ必要か   分散システムで高可用性(High Availability)を実現するため   高可用性を実現する方法は「冗長化」ただ1つ       ハードウェア障害は防げない          ...
状態を持つ(statefulな)ソフトウェアを冗長化する   状態を持つソフトウェアを冗長化するには       レプリケーション       State machine replication            命令の列を全レプリ...
命令の列をすべてのレプリカに同じ順序で届ける   レプリカ毎に命令の順序が変わると、レプリカの状態も変わる   i番目の命令として何を採用するかに対して合意を取る       すべてのiに対して合意を取る       ここでConsen...
分散システムで合意を取るのはなぜ難しいのか   CCが使えないメールを利用して、集合場所を決めることを考える       ただし、メールには到達保証がない(到達確認ができない)       参加メンバーだけはわかっている       誰...
Consensusが必要とされるほかのところ   分散トランザクション       トランザクションをCommitするか、Abortするか       全員が同じ選択をしないと一貫性(consistency)がオワコンに   メンバシッ...
問題設定11
Consensus problemの設定   プロセス       合意を取りたいグループのメンバ(活動単位みたいなやつ)   主にPaxosにおける役割(Role)       Proposer            値を提案する ...
プロトコルが満たすべき性質   安全性(safety)に関わる性質 ゆるふわバージョン       Proposerが提案された値のみが選択される           誰も提案していない謎の値は選択されない       ただ1つの値のみ...
問題があまりない状態でのConsensus   想定する状況       メッセージは必ず届く       メッセージは壊れない       すべてのプロセスが同じ速度で処理を進める       障害は100%検知できる      ...
現実の問題   分散システム的な問題設定       処理に任意の時間がかかる、しかもプロセス毎に進行速度が違う       通信に任意の時間がかかる、メッセージが失われる可能性がある       停止したプロセスが、あとで復旧する可能...
補足:Synchronous/Asynchronous system model   同期、非同期、分散システムではちょっと意味が違う       特に元々lock-freeとかしてた人にとっては・・・w       佐藤先生つぶやきがt...
補足:FLP impossibility   分散システム界隈でよく見かける   非同期システムでは、たとえメッセージのロスがなくても、プロセ    スが1台でも停止する可能性がある限り、100%合意に至れる    Consensusアルゴ...
Paxos18
Paxosとは   非同期システム上でのConsensus protocolの1つ       1989年(有名な論文が出たのは1998年)       Lamport先生            分散アルゴリズムの神       名前...
説明の流れ   Paxos made simpleに従って話を進める       Lamport先生の論文(というか記事?)       2001年   まずは単純なモデルを構築   徐々に問題を解決しながら完成に近づけていく   ...
単純な方法   Proposer 1台、accepter 1台   Proposerの提案がaccepterに渡った段階で値が選択される   問題       Proposer、accepterどちらが停止してもプロトコルが停止する ...
複数accepter   手順       Proposerが複数のaccepterに提案を送る       Accepterは値を受理(accept)してもいいし、しなくてもいい       十分に多く(以後”過半数”)のaccept...
Proposerを複数用意する   複数台用意できれば、1台停止しても怖くない   しかし、メッセージロスが絶妙に積み重なった状況を考える       N台のaccepterはすべて値を受理している       全体でM個の値が受理され...
複数proposerでの問題   問題       M=2の状況でも1台のaccepterの障害でプロトコルが停止するかも   解決策       Accepterが複数の提案を受理できるようにする            値の上書きを...
提案ID(proposal number)の導入   Accepterが複数の提案を受理できるようにするために・・・       提案に全順序付きのIDを付ける       混乱をなくすため、すべての提案がユニークなIDを持つようにする ...
提案の選択と提案の上書きによる問題   「値vを持つ提案が選択された」とは       過半数のaccepterが値vを持つ提案を受理した場合、提案が選択さ        れたという       値が選択された後も、提案を送ることは可能 ...
もう1つの制約   P2. 一度値vを持つ提案が選択されたら、より大きなIDを持つ提案    が選択される場合、その提案の値はvでなければならない   これで、提案選択後に選択された提案の値以外で上書きされること    を防げる   具体...
P2の修正   提案が選択されるためには、最低でも1つのaccepterに受理されな    ければならない       これを考慮してP2を尐し修正   P2a. 値vを持つ提案が選択されたら、任意のaccepterに受理される    よ...
P1とP2aの問題   問題が起こる状況        提案が選択されている        しかし、まだ提案を1度も受け取っていないaccepterもいる        そのaccepterに違う値を持つ提案が送られる        ...
補足:現段階での疑問   いずれにせよ過半数は維持できているため大丈夫では?       この問題を放置すると今後の制約を洗練させる際の支障に・・・       具体的には、最も大きな提案IDを利用して選択済みでない値を提案       ...
P2aの修正   結局proposer側にも制約をかけるしかない   P2b. 値vを持つ提案が選択されたら、任意のproposerからリクエ    ストされる、より大きなIDを持つすべての提案の値はvでなければ    ならない   P2...
提案が選択されている状況を考える    ある提案が選択されていると言うことは・・・        その提案を受理したAccepter集合の部分集合Sが存在する        Sは過半数(※)のaccepterで構成される    というこ...
しょぼい説明   提案を行う前に、過半数のaccepterに対して現在受理している提案    を確認すればよくない?       もし提案が受理されてたら、とりあえずIDが一番大きな提案の値を        もう一度提案しとけばいいよね  ...
P2bの修正   P2c. 値vを持つIDがnの提案がproposerより出た場合、次のような    accepterの集合Sが存在しなければならない       Sには過半数のaccepterが含まれる       Sに含まれるどのac...
Prepare&Promise   自分の提案IDが提案時点で最大であることを保証したい       確認時点では無くて、自分が提案する時点で最大であることを保証       しかし未来を予測するのは難しい・・・           状...
Accept   Prepare(n)のレスポンスを過半数から受け取ったら提案を送る       過半数から受け取れないと正確に現状を判断できない   P2cに従って値を提案       Accept(n, v)           ...
最後の修正と制約のまとめ   P1a. Accepterはnより大きなPrepareリクエストを受理していない    とき、またそのときに限り、IDがnの提案を受理できる   P2c. 値vを持つIDがnの提案がproposerより出た場合...
Paxosできた?   なんかそれらしくなった気がする   今まで出てきた制約をまとめてみる   フェーズを2つに分けて考える       フェーズ1: Prepare&Promiseメッセージのやりとり       フェーズ2: A...
Paxos: フェーズ1 Prepare   ProposerはPrepare(n)メッセージを過半数のaccepterに送る       Nはこれから送ろうと思っている提案のID(proposal number)   Accepterか...
Paxos: フェーズ1 Promise   AccepterはPrepare(n)を受け取ったらPromiseレスポンスを返す       nがPromise済みの提案IDよりも大きかった場合は受理           提案を受理してい...
Paxos: フェーズ2に入る前に   次の状況になったらPrepareからやり直し       1台以上のaccepterに拒否された           拒否レスポンスの中から、最大の提案IDを選択           それより大き...
Paxos: フェーズ2 Accept   ProposerはaccepterにAccept(n, v)を送る       nはPrepareした提案のID       vは値       Acceptを送る対象のaccepterは、P...
Paxos: フェーズ2 Accepted   AccepterはAccept(n, v)を受け取る       nがPromiseした提案ID以上の値だったら受理       そうでなかったら拒否   Accepterはどのような状況...
停止保証   FLP impossibility! Paxosにも合意に至れないパスがある   Proposer 2台がより大きな値でPrepareし続けると・・・         Proposer1                 Acc...
停止しなくなる確率を下げる   解決策       Proposerのリーダーを1台選び、それだけが提案できるようにする       Distinguished proposer   現実的にはPaxosのフェーズ2回分を    独立し...
安全性に関して   Proposerが2台以上いると停止は保証されないことはわかった   しかし、リーダーが誤って2台以上同時出現することもある       Split brain       リーダーが1台しか出てこないようにすること...
提案(値)   提案を安全に選択する手段は確立できた   提案が選択されたことはどうやって確認する?       Learnerががんばる   Accepterは勝手に提案が選択されたと判断してはいけない       提案を上書きでき...
Learnerの構成例1   Accepterがlearnerにメッセージを送る       もちろんメッセージは遅延したり、到達順序が前後したりする       過半数超えを確認するためには提案の値ではなくIDを利用   欠点:メッセ...
Learnerの構成2   Distinguished learnerでメッセージ数を削減   non-Byzantineだから問題が簡単になってるそうです        Byzantine-failureが起こると、L1が間違った情報を...
Learnerその他   メッセージの損失を考慮       AccepterからのAcceptedメッセージは失われる可能性がある       そうすると提案が選択されたことに気づけない       Learnerが定期的にaccep...
現実的なlearnerの運用   Distinguished proposer&learnerを同じプロセスで動かす       いわゆるマスター   ProposerはAcceptedメッセージをaccepterから回収する     ...
Paxos要約   Paxosプロトコルの2フェーズ       Prepare&Promise       Accept&Accepted       ID付きの提案がポイント!   提案は過半数のaccepterに受理されたら合意...
Multi-Paxos53
Paxosの最適化   Paxosは1インスタンスあたりのメッセージ数が多い       最小で4回のやりとりが必要になる   メッセージ数を減らせないか?       仮定をおいたり、制約をかければ何とかなる   Paxosの最適化...
Multi-Paxos   複数回連続してインスタンスを実行するような場合向けの最適化   Distinguished proposerが割とstableであると仮定       マスターがあんまり変わらない   何回も連続してインスタ...
参考文献紹介56
俺たちの戦いはまだ始まったばかりだ!   Paxosというか分散システムは難しいのでいろんな説明を読もう   Consensus protocolの歴史と概要を知りたい       Paper trailのConsensus Protoc...
Paper TrailのConsensus Protocolsシリーズ   Henry Robinson(@HenryR)さんのブログ       http://the-paper-trail.org/       ZooKeeperのコ...
Paxos made simple   本日の主な情報源       Lamport先生   いきなりこれを読み始めてもいいレベル!   10回くらい読み直したら理解できた   メモ       Proposal/valueという単...
Paxos made live   Googleの論文       Paxosを実装したらこんな問題に突き当たりました集       解決方法ももちろん載ってる       参考文献も豊富で、しかも面白そうな論文が多い   例    ...
Chubby & ZooKeeper   Chubby       GoogleのPaxosを使ったもの            (特許関係がよくわかってない)       これがあると分散システムの設計がすごく楽に   ZooKeep...
The Part-Time Parliament   伝説の元論文       最初に投稿されたのは1990年?       1998年のACM Transactions on Computer Systems   証明も載ってる  ...
まとめ   Consensus       そもそもどういう問題なのか       どこで使われているのか       満たすべき性質   Paxos       Paxos made simpleに従った紹介       Mul...
ご清聴ありがとうございました!Copyright © 2006-2012Preferred Infrastructure All Right Reserved.
Upcoming SlideShare
Loading in …5
×

Paxos

2,613 views

Published on

  • DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT (Unlimited) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... Download Full EPUB Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ACCESS WEBSITE for All Ebooks ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... Download EPUB Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... Download doc Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT (Unlimited) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... Download Full EPUB Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ACCESS WEBSITE for All Ebooks ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... Download EPUB Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... Download doc Ebook here { https://tinyurl.com/yyxo9sk7 } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

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.

×