Paxos
Upcoming SlideShare
Loading in...5
×
 
  • 6,830 views

 

Statistics

Views

Total Views
6,830
Views on SlideShare
5,970
Embed Views
860

Actions

Likes
31
Downloads
95
Comments
0

8 Embeds 860

http://open-groove.net 757
https://twitter.com 91
https://si0.twimg.com 5
https://twimg0-a.akamaihd.net 2
https://www.google.co.jp 2
http://us-w1.rockmelt.com 1
https://abs.twimg.com 1
http://www.google.co.jp 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Paxos Paxos Presentation Transcript

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