SlideShare a Scribd company logo
1 of 64
Download to read offline
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
問題があまりない状態でのConsensus

l    想定する状況
      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 model

l    同期、⾮非同期、分散システムではちょっと意味が違う
      l  特に元々lock-freeとかしてた⼈人にとっては・・・w

      l  佐藤先⽣生つぶやきがtogetterにまとめられている

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


l  Synchronous system model
     l  先ほど「問題があまりない」と紹介した例例

     l  純粋にアルゴリズムを検証するのに便便利利なモデル

l  Asynchronous system model
     l  問題しかない、なにが起こってもおかしくない⽅方のモデル

      l    このモデルで正しく動けば、すべての状況で正しく動くんでは!


                                        16
補⾜足:FLP impossibility

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


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



l    注意
      l  100%合意に⾄至れないだけで、⼤大体のケースでは合意に⾄至れる

      l  「100%の確率率率で完了了するアルゴリズム」が存在しないことの証明




                        17
Paxos


18
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  うまくいくっぽくね!?           A1
l  詳細は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&Promise

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

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

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


l  Prepare(n)メッセージの導⼊入
     l  ⾃自分もうすぐ提案するので、今後IDがn未満の提案は無視して!

     l  これで少なくとも⾃自分より古くなる予定の提案は全部拒否できる

     l  Prepareを受け取ったaccepterは約束を必ず守ること!

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

                              35
Accept

l  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 Prepare

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

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

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




                         39
Paxos: フェーズ1 Promise

l    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 Accept

l  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 Accepted

l  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 proposer



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


l    リーダーの選び⽅方は・・・
      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の構成例例1

l  Accepterがlearnerにメッセージを送る
     l  もちろんメッセージは遅延したり、到達順序が前後したりする

     l  過半数超えを確認するためには提案の値ではなくIDを利利⽤用

l  ⽋欠点:メッセージ数がaccepterの数とlearnerの数の積に

                            A1                過半数超えたらOK	
           Accept(n, v)	
                                                      L1

      P1                    A2


                                                      L2

                            A3     Accepted(n, v)	

                            48
Learnerの構成2

l  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-Paxos


53
Paxosの最適化

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



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



l    Paxosの最適化⼿手法はいろいろある
       l  Cheap Paxos

       l  Fast Paxos



l    今⽇日はMulti-Paxosを紹介


                           54
Multi-Paxos

l  複数回連続してインスタンスを実⾏行行するような場合向けの最適化
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 simple

l    Paxosを実装しようとしたらどういう問題が起こるのか知りたい
       l  Paxos made live

l    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 simple

l    本⽇日の主な情報源
      l  Lamport先⽣生



l  いきなりこれを読み始めてもいいレベル!
l  10回くらい読み直したら理理解できた
l  メモ
     l  Proposal/valueという単語は適切切に使い分けている

            l    注意して読もう
      l    Chosenの対象を⾒見見極める
            l    選択されたのはproposal、それともvalue?
      l    細かいことが気になり始めたらPaxos made liveへ!


                                  59
Paxos made live

l    Googleの論論⽂文
       l  Paxosを実装したらこんな問題に突き当たりました集

       l  解決⽅方法ももちろん載ってる

       l  参考⽂文献も豊富で、しかも⾯面⽩白そうな論論⽂文が多い



l    例例
      l    マスター(distinguished proposer)の維持⽅方法
             l    マスターのリースによる管理理
      l    ディスク障害との向き合い⽅方
      l    スナップショットの維持⽅方法
             l    MongoDBのoplog too stale問題に近い話も
      l    テスト⽅方法!!すばらしかったので読むべき

                                     60
Chubby & ZooKeeper

l    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 Parliament

l    伝説の元論論⽂文
      l  最初に投稿されたのは1990年年?

      l  1998年年のACM Transactions on Computer Systems



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




                                 62
まとめ

l    Consensus
       l  そもそもどういう問題なのか

       l  どこで使われているのか

       l  満たすべき性質



l    Paxos
       l  Paxos made simpleに従った紹介

       l  Multi-Paxosの紹介



l    参考⽂文献紹介




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


Copyright © 2006-2012
Preferred Infrastructure All Right Reserved.

More Related Content

What's hot

例外設計における大罪
例外設計における大罪例外設計における大罪
例外設計における大罪Takuto Wada
 
ネットワークでなぜ遅延が生じるのか
ネットワークでなぜ遅延が生じるのかネットワークでなぜ遅延が生じるのか
ネットワークでなぜ遅延が生じるのかJun Kato
 
地理分散DBについて
地理分散DBについて地理分散DBについて
地理分散DBについてKumazaki Hiroki
 
DockerとPodmanの比較
DockerとPodmanの比較DockerとPodmanの比較
DockerとPodmanの比較Akihiro Suda
 
Dockerfileを改善するためのBest Practice 2019年版
Dockerfileを改善するためのBest Practice 2019年版Dockerfileを改善するためのBest Practice 2019年版
Dockerfileを改善するためのBest Practice 2019年版Masahito Zembutsu
 
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話Koichiro Matsuoka
 
Where狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキーWhere狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキーyoku0825
 
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介AdvancedTechNight
 
並行実行制御の最適化手法
並行実行制御の最適化手法並行実行制御の最適化手法
並行実行制御の最適化手法Sho Nakazono
 
目grep入門 +解説
目grep入門 +解説目grep入門 +解説
目grep入門 +解説murachue
 
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方Yoshiyasu SAEKI
 
BuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルドBuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルドAkihiro Suda
 
Akkaとは。アクターモデル とは。
Akkaとは。アクターモデル とは。Akkaとは。アクターモデル とは。
Akkaとは。アクターモデル とは。Kenjiro Kubota
 
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjugYahoo!デベロッパーネットワーク
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!mosa siru
 
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)NTT DATA Technology & Innovation
 
Javaのログ出力: 道具と考え方
Javaのログ出力: 道具と考え方Javaのログ出力: 道具と考え方
Javaのログ出力: 道具と考え方Taku Miyakawa
 

What's hot (20)

At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajpAt least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
 
例外設計における大罪
例外設計における大罪例外設計における大罪
例外設計における大罪
 
Docker Compose 徹底解説
Docker Compose 徹底解説Docker Compose 徹底解説
Docker Compose 徹底解説
 
ネットワークでなぜ遅延が生じるのか
ネットワークでなぜ遅延が生じるのかネットワークでなぜ遅延が生じるのか
ネットワークでなぜ遅延が生じるのか
 
地理分散DBについて
地理分散DBについて地理分散DBについて
地理分散DBについて
 
DockerとPodmanの比較
DockerとPodmanの比較DockerとPodmanの比較
DockerとPodmanの比較
 
Dockerfileを改善するためのBest Practice 2019年版
Dockerfileを改善するためのBest Practice 2019年版Dockerfileを改善するためのBest Practice 2019年版
Dockerfileを改善するためのBest Practice 2019年版
 
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
 
Where狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキーWhere狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキー
 
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介
 
並行実行制御の最適化手法
並行実行制御の最適化手法並行実行制御の最適化手法
並行実行制御の最適化手法
 
目grep入門 +解説
目grep入門 +解説目grep入門 +解説
目grep入門 +解説
 
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
 
BuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルドBuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルド
 
Akkaとは。アクターモデル とは。
Akkaとは。アクターモデル とは。Akkaとは。アクターモデル とは。
Akkaとは。アクターモデル とは。
 
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
 
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
今こそ知りたいSpring Batch(Spring Fest 2020講演資料)
 
Javaのログ出力: 道具と考え方
Javaのログ出力: 道具と考え方Javaのログ出力: 道具と考え方
Javaのログ出力: 道具と考え方
 
Docker Tokyo
Docker TokyoDocker Tokyo
Docker Tokyo
 

Viewers also liked

ブロックチェーン連続講義 第5回 分散システムのリテラシー
ブロックチェーン連続講義 第5回 分散システムのリテラシーブロックチェーン連続講義 第5回 分散システムのリテラシー
ブロックチェーン連続講義 第5回 分散システムのリテラシーKenji Saito
 
Ekmett勉強会発表資料
Ekmett勉強会発表資料Ekmett勉強会発表資料
Ekmett勉強会発表資料時響 逢坂
 
分散型台帳技術Orb DLTのご紹介とOracle Cloudにおける当該ソフトウェアの性能評価
分散型台帳技術Orb DLTのご紹介とOracle Cloudにおける当該ソフトウェアの性能評価分散型台帳技術Orb DLTのご紹介とOracle Cloudにおける当該ソフトウェアの性能評価
分散型台帳技術Orb DLTのご紹介とOracle Cloudにおける当該ソフトウェアの性能評価Orb, Inc.
 
Spannerに関する技術メモ
Spannerに関する技術メモSpannerに関する技術メモ
Spannerに関する技術メモEtsuji Nakai
 
[C16] インメモリ分散KVSの弱点。一貫性が崩れる原因と、それを克服する技術とは? by Taichi Umeda
[C16] インメモリ分散KVSの弱点。一貫性が崩れる原因と、それを克服する技術とは? by Taichi Umeda[C16] インメモリ分散KVSの弱点。一貫性が崩れる原因と、それを克服する技術とは? by Taichi Umeda
[C16] インメモリ分散KVSの弱点。一貫性が崩れる原因と、それを克服する技術とは? by Taichi UmedaInsight Technology, Inc.
 
分散型台帳技術Orb DLTの紹介
分散型台帳技術Orb DLTの紹介分散型台帳技術Orb DLTの紹介
分散型台帳技術Orb DLTの紹介Orb, Inc.
 

Viewers also liked (6)

ブロックチェーン連続講義 第5回 分散システムのリテラシー
ブロックチェーン連続講義 第5回 分散システムのリテラシーブロックチェーン連続講義 第5回 分散システムのリテラシー
ブロックチェーン連続講義 第5回 分散システムのリテラシー
 
Ekmett勉強会発表資料
Ekmett勉強会発表資料Ekmett勉強会発表資料
Ekmett勉強会発表資料
 
分散型台帳技術Orb DLTのご紹介とOracle Cloudにおける当該ソフトウェアの性能評価
分散型台帳技術Orb DLTのご紹介とOracle Cloudにおける当該ソフトウェアの性能評価分散型台帳技術Orb DLTのご紹介とOracle Cloudにおける当該ソフトウェアの性能評価
分散型台帳技術Orb DLTのご紹介とOracle Cloudにおける当該ソフトウェアの性能評価
 
Spannerに関する技術メモ
Spannerに関する技術メモSpannerに関する技術メモ
Spannerに関する技術メモ
 
[C16] インメモリ分散KVSの弱点。一貫性が崩れる原因と、それを克服する技術とは? by Taichi Umeda
[C16] インメモリ分散KVSの弱点。一貫性が崩れる原因と、それを克服する技術とは? by Taichi Umeda[C16] インメモリ分散KVSの弱点。一貫性が崩れる原因と、それを克服する技術とは? by Taichi Umeda
[C16] インメモリ分散KVSの弱点。一貫性が崩れる原因と、それを克服する技術とは? by Taichi Umeda
 
分散型台帳技術Orb DLTの紹介
分散型台帳技術Orb DLTの紹介分散型台帳技術Orb DLTの紹介
分散型台帳技術Orb DLTの紹介
 

More from Preferred Networks

Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3Preferred Networks
 
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...Preferred Networks
 
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55Preferred Networks
 
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2Preferred Networks
 
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2Preferred Networks
 
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2Preferred Networks
 
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演Preferred Networks
 
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)Preferred Networks
 
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)Preferred Networks
 
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)Preferred Networks
 
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語るKubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語るPreferred Networks
 
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張Preferred Networks
 
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2Preferred Networks
 
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...Preferred Networks
 
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...Preferred Networks
 
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...Preferred Networks
 
Topology Managerについて / Kubernetes Meetup Tokyo 50
Topology Managerについて / Kubernetes Meetup Tokyo 50Topology Managerについて / Kubernetes Meetup Tokyo 50
Topology Managerについて / Kubernetes Meetup Tokyo 50Preferred Networks
 
PFN Summer Internship 2021 / Kohei Shinohara: Charge Transfer Modeling in Neu...
PFN Summer Internship 2021 / Kohei Shinohara: Charge Transfer Modeling in Neu...PFN Summer Internship 2021 / Kohei Shinohara: Charge Transfer Modeling in Neu...
PFN Summer Internship 2021 / Kohei Shinohara: Charge Transfer Modeling in Neu...Preferred Networks
 
PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜
PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜
PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜Preferred Networks
 
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48Preferred Networks
 

More from Preferred Networks (20)

Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
Optunaを使ったHuman-in-the-loop最適化の紹介 - 2023/04/27 W&B 東京ミートアップ #3
 
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
深層学習の新しい応用と、 それを支える計算機の進化 - Preferred Networks CEO 西川徹 (SEMICON Japan 2022 Ke...
 
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
Kubernetes ControllerをScale-Outさせる方法 / Kubernetes Meetup Tokyo #55
 
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
Kaggle Happywhaleコンペ優勝解法でのOptuna使用事例 - 2022/12/10 Optuna Meetup #2
 
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
最新リリース:Optuna V3の全て - 2022/12/10 Optuna Meetup #2
 
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
Optuna Dashboardの紹介と設計解説 - 2022/12/10 Optuna Meetup #2
 
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
スタートアップが提案する2030年の材料開発 - 2022/11/11 QPARC講演
 
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
Deep Learningのための専用プロセッサ「MN-Core」の開発と活用(2022/10/19東大大学院「 融合情報学特別講義Ⅲ」)
 
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
PFNにおける研究開発(2022/10/19 東大大学院「融合情報学特別講義Ⅲ」)
 
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
自然言語処理を 役立てるのはなぜ難しいのか(2022/10/25東大大学院「自然言語処理応用」)
 
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語るKubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
Kubernetes にこれから入るかもしれない注目機能!(2022年11月版) / TechFeed Experts Night #7 〜 コンテナ技術を語る
 
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
Matlantis™のニューラルネットワークポテンシャルPFPの適用範囲拡張
 
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
続・PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜 #2
 
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Co...
 
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
KubeCon + CloudNativeCon Europe 2022 Recap / Kubernetes Meetup Tokyo #51 / #k...
 
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
KubeCon + CloudNativeCon Europe 2022 Recap - Batch/HPCの潮流とScheduler拡張事例 / Kub...
 
Topology Managerについて / Kubernetes Meetup Tokyo 50
Topology Managerについて / Kubernetes Meetup Tokyo 50Topology Managerについて / Kubernetes Meetup Tokyo 50
Topology Managerについて / Kubernetes Meetup Tokyo 50
 
PFN Summer Internship 2021 / Kohei Shinohara: Charge Transfer Modeling in Neu...
PFN Summer Internship 2021 / Kohei Shinohara: Charge Transfer Modeling in Neu...PFN Summer Internship 2021 / Kohei Shinohara: Charge Transfer Modeling in Neu...
PFN Summer Internship 2021 / Kohei Shinohara: Charge Transfer Modeling in Neu...
 
PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜
PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜
PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜
 
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
 

Recently uploaded

持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見Shumpei Kishi
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor arts yokohama
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~arts yokohama
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦Sadao Tokuyama
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-LoopへTetsuya Nihonmatsu
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdfAyachika Kitazaki
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)ssuser539845
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfMatsushita Laboratory
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法ssuser370dd7
 

Recently uploaded (12)

持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor
 
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf
 
2024 03 CTEA
2024 03 CTEA2024 03 CTEA
2024 03 CTEA
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
 
2024 04 minnanoito
2024 04 minnanoito2024 04 minnanoito
2024 04 minnanoito
 
What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?
 

Paxos

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