$30 off During Our Annual Pro Sale. View Details »

Formalization and Proof of Distributed Systems (ja)

UENISHI Kota
January 20, 2017

Formalization and Proof of Distributed Systems (ja)

分散システムの形式化と証明について @情報システム特別講義D 2016年度筑波大学

UENISHI Kota

January 20, 2017
Tweet

More Decks by UENISHI Kota

Other Decks in Science

Transcript

  1. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    Proprietary & Confidential
    NAUTILUS
    Formalization and Proof of
    Distributed Systems
    分散システムの形式化と証明について
    2017/1/20 上西康太
    株式会社ノーチラス・テクノロジーズ
    http://www.nautilus-technologies.com/
    mailto:[email protected]
    Tel: 03-6712-0636 Fax: 03-6712-0664

    View Slide

  2. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 2
    Proprietary & Confidential
    誰?
    ■上西康太
    ■NTT研究所
    – 分散データベースの開発
    – オンライン分散機械学習 Jubatus
    ■Basho Technologies, Inc.
    – Riak CS
    ■ノーチラス・テクノロジーズ
    – Retz (on Apache Mesos)

    View Slide

  3. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 3
    Proprietary & Confidential
    ノーチラス・テクノロジーズ
    ■Asakusa Frameworkという業務バッチ向けのDSLコンパイラをOSSで
    開発・提供しています
    ■Retzという汎用ジョブキューをOSSで開発・提供しています
    ■コンパイラに詳しい人、データベースに詳しい人、分散システムに詳しい
    人、業務に詳しい人、Javaに詳しい人などがいます

    View Slide

  4. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 4
    Proprietary & Confidential
    三行で
    ■時代は分散処理なので、コンピュータを沢山並べます
    ■沢山並べると故障するやつが必ず出てきます
    ■部分的な故障があっても、クラスタ全体が目的の動作を
    するようにシステムを「正しく」設計します
    See https://goo.gl/yiZPXp for resume and refs, https://goo.gl/ahKX14 for slides

    View Slide

  5. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 5
    Proprietary & Confidential
    「分散」という言葉の意味はいろいろある
    ■クライアントとサーバーで責務を分ける中央集権システム
    – ホストコンピュータ
    ■ひとつの計算を複数ノードで分担することで全体を高速化
    – MPICH
    – Spark
    – いわゆるHPC
    ■信頼性の低い(経済性の高い)コンピュータを束ねて信頼性を高める
    – P2Pファイル共有派(BitTorrentなど [6]
    – P2P通信派(Skypeなど
    – 分散ストレージ派
    – 分散KVS派
    ■The インターネット

    View Slide

  6. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 6
    Proprietary & Confidential
    今日の「分散」
    ■何台かコンピュータがある
    ■ときどき黙ったりそのまま落ちたりするやつがある
    ■意見をまとめる方法
    v = ?
    v = 1
    v = 0
    v = 0
    v = 1
    “Consensus in Distributed Systems”

    View Slide

  7. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 7
    Proprietary & Confidential
    分散システムの理論
    ■どこまで故障するか?
    ■どこまで故障したら、合意できなくなるか?
    ■故障はあるけど、合意はしたい
    ■「故障」と「合意」をフォーマルに定義して、その
    理論限界を模索する

    View Slide

  8. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 8
    Proprietary & Confidential
    おまけ: 分散システムの実践
    ■そもそもその合意、必要ですか?
    ■目的とする合意を決める
    ■システムの動作環境から、一番厳しい故障条件を決める
    ■システムの動作環境を保証するための運用条件を決める
    ■理論的に合意できるプロトコルを決めて実装
    ■テストしてから本番投入
    ■障害からの復旧

    View Slide

  9. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 9
    Proprietary & Confidential
    そもそもその合意、必要ですか?
    ■コンセンサスシステムは、設計、実装、構築、運用、全てが難しい
    – なくてもよいならやるべきではない
    ■システム全体で強く一貫したオブジェクト(ロックとか、銀行口座とか、
    CASとか)が必要な場合
    ■データの整合性よりもパフォーマンスや経済性が優先される場合
    ■CDNやDNSなど、いろいろなユースケースで、合意は不要
    – 楽観的レプリケーション [9][10]
    ■実際、20世紀までは研究のための研究が多く、「使えない」コンピュータ
    技術の分野のひとつだと思われていた
    ■21世紀になってそれを変えたのがGoogleとAmazon

    View Slide

  10. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 10
    Proprietary & Confidential
    なぜ耐故障性が重要なのか?
    ■コンピューターは壊れる
    – フラッシュメモリの寿命
    – SATAケーブルの不良
    – GPU焼け落ち事件
    – 宇宙線によるビットエラー
    ■ネットワークは信頼できる [5]
    – ネットワーク機器も壊れる
    – LANケーブルは切れる
    – ネットワーク機器もコンピューター
    ■クラウドもデータセンターも壊れる

    「データセンター 火災」

    「クラウド 障害 事例」

    View Slide

  11. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 11
    Proprietary & Confidential
    ネットワークは信頼できる [5]
    ■ MSのデータセンターでは
    – an average failure rate of 5.2 devices/day and 40.8 links/day, 復旧まで中央値5分、最大1週間
    – 中央値 1/59000 パケロス
    ■ Google
    – a typical first year for a new Google cluster involves:
    ■ Five racks going wonky (40-80 machines seeing 50 percent packet loss).
    ■ Eight network maintenance events (four of which might cause ~30-minute random connectivity losses).
    ■ Three router failures (resulting in the need to pull traffic immediately for an hour).
    ■ Fog creek
    – ネットワークループとゲートウェイ制御からネットワーク分断 →2時間のサービス停止
    ■ GitHub
    – スイッチの設定ミス→リンク一つ切ったら障害検知で全リンクが切れる→18分のダウンタイム
    – スイッチのキャッシュを正しく更新できないファームのバグ→ほぼ全てのパケットを全インターフェースにブロードキャスト
    – 90秒のネットワーク分断がPacemakerとDRBDで冗長化されたファイルサーバーの両方をマスターにしてしまった→お互いにKillメ
    ッセージを送信→ネットワーク復旧後にそれが届いて両方死ぬ
    – 分断中に双方のマスターに書かれたデータをマニュアル復旧するのに数時間かかり、GitHubサービスの一部がダウン
    – MySQLのPrimary-Secondaryが頻繁に切り替わる問題→Pacemakerをマニュアル操作に切り替え→Pacemakerが
    Segmentation Fault→Primary/Secondary不一致→ Privateレポジトリが他人に見えてしまう
    ■ AWS
    – MongoDB on EC2: EC2のネットワーク切断により、2時間分Mongoに書いたデータがネットワーク復旧後に消滅
    – Isolated Redis Primary on EC2: Twilio API call caused the billing system to recharge customer credit cards
    automatically, resulting in 1.1 percent of customers being overbilled over a period of 40 minutes
    ■ スイッチやルーターのファームウェアのバグや設定ミス、メンテナンスはやっぱり起きる
    ■ アプリケーションがSplit brainに対応していないケース

    View Slide

  12. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 12
    Proprietary & Confidential
    コンセンサスは重要
    ■データベースの重要な要素技術のひとつは並行制御
    – ロックやアトミック命令で構成される ←CPUやメモリが提供する機能
    – 分散するところでは、そういったプリミティブは存在しない
    – 分散トランザクションでの「コミットするよ?するよ?」問題
    ■ストレージの要素技術のひとつはレプリケーション
    – あるデータが一致しているかどうかを定義する
    ■現代のクラウドの巨大なシステムでは、各種メタデータや状態だけを保存
    するデータベースが必要
    Chubby [4] BigTable, MegaStore, Borg
    ZooKeeper Spark, HBase, HDFS, YARN, Mesos, Kafka
    etcd Kubernetes, CoreOS, Docker Swarm

    View Slide

  13. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 13
    Proprietary & Confidential
    なぜ形式化が重要なのか?
    ■カーネルのデバッグやったことある人?
    ■マルチスレッドで共有変数があるプログラムのデバッグ?
    – printfを入れると…
    ■分散システムのプログラミングはタイヘン
    – チューリングマシンやラムダ計算とは違うパラダイム
    ■ いちおうπ計算というパラダイムはあるが
    ■ 現実に再現性がない
    – 通信まわりを含んで複雑化しがち
    ■短いサイクルで作ってテストしながらアルゴリズムを改善するのは難しい
    ■とんでもないタイミングのバグが絡み合っていたりする
    – The Discovery of Apache ZooKeeper’s Poison Packet
    ■正しいアルゴリズムを先に作ってから実装する
    – アルゴリズムの正しさが自明ではない
    – ひとりや二人がコードやドキュメントをレビューして検証できるレベルではない

    View Slide

  14. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 14
    Proprietary & Confidential
    分散システムの基礎理論
    ■合意とは何か
    ■故障の分類
    ■証明のパターン
    ■理論限界
    ■合意できるプロトコル

    View Slide

  15. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 15
    Proprietary & Confidential
    各種用語
    v = 1
    v=0にしようよ
    v = 1
    ■プロセス
    ■メッセージ
    ■故障
    プロセス
    メッセージ
    故障(のひとつ)

    View Slide

  16. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 16
    Proprietary & Confidential
    コンセンサスの流れ
    ■各プロセスが同じように動作して、いろいろ通信をする
    ■ときどき黙ったりそのまま落ちたりするやつがある
    ■ある条件を満たすと、意見がまとまったとして決定
    v = 1
    v = 0
    v = 0
    v = 1
    v = 1
    v = 1
    v = 1
    v = 1
    v = 1
    ■ Input
    – 各プロセスはどういう動作をするか?
    – どういう故障が起きうるか?
    – どういう通信が可能か?
    ■ Output
    – 合意できる? [y/n]

    View Slide

  17. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 17
    Proprietary & Confidential
    合意に必要な3つの条件
    ■Validity
    – クラスタを構成する誰かが提案した値であること
    – e.g. 国会議員でない者は法案を提出できない
    ■Termination
    – 有限ステップまたは有限時間内に合意が得られること
    – e.g. 議論がどんなに紛糾しても、議論にならなくても強行採決
    ■Agreement
    – (故障していない)全員が同じ値を決定すること
    – e.g. 法案は可決 or 否決
    ■(Liveness)
    – 合意の結果をいつでも正しく得られること
    © 参議院 http://www.sangiin.go.jp/japanese/ugoki/h28/la161209-1.html

    View Slide

  18. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 18
    Proprietary & Confidential
    故障 is 何
    ■Crash Failure
    – プロセスがいきなり停止、沈黙
    ■Omission Failure
    – メッセージが届かない、送れない、欠落
    ■Arbitrary Failure
    – プロセスがアルゴリズム(プログラム)で定義していない異常動作をする
    – Byzantine Failure とも言う
    – ウソをつく
    ■故障ではないけど
    – プログラムの進行が、プロセスによって異なる e.g., Stop the world GC
    – “Processes can be Arbitrarily Slow”
    – メッセージを100個無視したあといきなり動き始める場合も

    View Slide

  19. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 19
    Proprietary & Confidential
    通信モデル
    ■メッセージの配送保証のレベル、条件など
    ■遅延
    – 同期的: メッセージは有限時間内に到着する
    – 非同期的: メッセージは有限時間内に到着するが、上限がない
    ■欠落
    – メッセージは無限時間内に届く(それって…)
    ■順番
    – メッセージは送った順番と同じ順番で届く
    ■Fairness
    – ある種のメッセージだけが優先されないこと

    View Slide

  20. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 20
    Proprietary & Confidential
    分散システムの有名な理論限界
    ■FLP Impossibility
    – 通信モデルが非同期、かつ、1台でも故障が起きるシステム
    では合意は不可能
    ■CAP Theorem
    – Omission Failureがあるシステム (Partition) では、
    Agreement (Consistency) か Liveness
    (Availability) の両方を満たすことはできない
    ■Failure Detector
    – 完璧な故障検知は実現不可能

    View Slide

  21. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 21
    Proprietary & Confidential
    分散システムの証明のパターン
    ■背理法: (¬P⇒⊥)⇒P
    – 〜〜を満たすアルゴリズムAがあるとする→矛盾
    – 入れ子になる場合もある (¬P⇒(¬Q⇒⊥)⇒Q⇒⊥)
    – プログラムの停止性問題
    ■同定
    – Aを満たすプロセス(値)はただひとつである
    – ∀x∀x’ (x = x’)
    ■帰納法
    – ラウンド1で~~が成立する
    – ラウンドrで~~が成立したとすると、 ラウンド r+1 でも成立
    – P(1)∧( P(n)⇒P(n+1) ) ⇒ ∀n, n>0 P(n)

    View Slide

  22. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 22
    Proprietary & Confidential
    CAP Theorem
    ■Originally "Brewer's Conjecture” [1]
    ■前提
    – プロセス間の通信は非同期
    – プロセス内の時計の進行は一定ではない
    ■このとき、以下は両立しない
    1. いつでもある値を読み書きできる(待たされない)
    2. ある値の読み書きはLinearizableである
    v = 0
    v = 0
    v = 0
    v = 0
    v = 1
    v = 0
    v = 0
    v = 1
    Linearizable:
    Write: v => 1
    の後は
    Read: v => 1
    でなければならない

    View Slide

  23. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 23
    Proprietary & Confidential
    Proof Sketch of CAP Theorem
    ■仮定: あるアルゴリズムAは、性質 1, 2 を満たすとする
    ■全プロセスは v0 という初期値を持っている
    ■{G1, G2} のグループに全プロセスが分断されたシナリオでは
    – G1 <=> G2 間の通信は永遠に届かない
    ■あるExecution α1={w(G1, v1)} が実⾏された場合
    – 1. (Liveness)から、どのようなプロトコルであっても、すぐに成功は
    返る
    ■あるExecution α2={r(G2)} が実⾏されたとする (E2)
    – 1. (Liveness)から、どのようなプロトコルであっても、すぐに結果 v0
    が返る(G2はv1を知り得ない)
    ■あるExecution α={α1, α2} が対して実⾏されたとする (E3)
    – 2. から、AはLinearizableであり、Aが α2={r(G2)} で返す値は v1
    – G2からみると、E2とE3で起きたことは区別がつかないので、同じ値を
    返さなければならない
    – E2ではv0が返る
    ■→⽭盾→仮定が間違っている→ 性質1,2を満たすAはない

    View Slide

  24. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 24
    Proprietary & Confidential
    FLP Impossibility [2][23]
    ■前提
    – 非同期通信(メッセージ遅延は無限)
    – 1台だけ故障する (ただのFail stop)
    ■これで合意できるプロトコルは実在しない
    ■“No consensus protocol is totally correct in spite of one fault”
    – Totally correct in spite of one fault :=
    ■ It is partially correct, and
    – Partially correct
    ■ No accessible configuration has more than one decision value, and
    ■ For each v {0, 1}, some accessible configuration has decision value v
    ■ Every admissible run is a deciding run
    – Admissible
    ■ At most one process is faulty, and
    ■ All message to nonfaulty processes are eventually received
    ■ Nonfaulty=it takes infinitely many steps

    View Slide

  25. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 25
    Proprietary & Confidential
    FLP Impossibility Proof Sketch 1/3
    ■プロセスは2つの状態がある
    – 初期/遷移状態({0, 1} の初期値を持つ)と決定状態(値を決定済)
    ■まず、全てのメッセージと処理を直列に表記する
    – Send(m, p) … メッセージバッファに (m, p) を積む
    – Recv(p) … メッセージバッファから p または Φ が出てくる
    ■プロセスの状態Cと e=(m, p) の並びから決定論的に状態遷移する
    ■背理法: Totally correctなプロトコルPがあるとする
    – Lemma 2: Pはbivalentな初期状態を持つ
    – Lemma 3: Pのbivalentな初期状態Cに e=(p,m) を施せるとして、e以外
    の操作を使ってReachableな状態の集合をCとすると、Cにeを施した状態の
    集合Dもまたbivalentである(C, Dは論文では筆記体)
    – Lemma 3より、 C からReachableなbivalentな状態C’が必ずある
    – C→C’→C‘’→C‘’’→… 決定不可能なので⊥

    View Slide

  26. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 26
    Proprietary & Confidential
    FLP Impossibility Proof Sketch 2/3
    ■つまりLemma 3が肝
    ■証明は背理法
    – 仮定: bivalentな状態Cから任意の遷移を経て最後にeを施すとunivalent
    な状態にしかならない(本当はbivalentなの状態がある)
    ■e = (p, m)
    ■e’ = (p’, m’)
    ■Ci: bivalent state (i=0,1) in C
    ■Di = e(Ci) な i-valent state
    ■Ei: univalent state reachable from Ci
    ■ p≠pのとき、Lemma 1より eとe’は可換
    ■ D1 = e(e’(C0)) = e’(D0)
    ■ D0 は 0-valent であることと矛盾
    •p≠p’のとき

    View Slide

  27. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 27
    Proprietary & Confidential
    FLP Impossibility Proof Sketch 3/3
    ■p=p’のとき
    – σ = schedule(eを含まない)
    – A = σ(C0) で、0か1のどちらかに決まるunivalentな状態
    – Ei: univalent state reachable from Ci
    ■左側
    – E0 = σ(D0) = σ(e(C0))
    – Lemma 1より
    – → E0 = e(A) = e(σ(C0))
    ■右側
    – E1 = σ(D1) = σ(e(e’(C0))
    – Lemma 1より
    – E1 = e(e’(A))
    ■∴AからE0もE1も到達できる
    – ⇒Aはbivalent
    •p=p’のとき

    View Slide

  28. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 28
    Proprietary & Confidential
    FLP Impossibility Proof / Lemma 1
    ■ある状態Cから、適当なスケジュールσ1を
    走らせるとC1になるとする
    ■C1 = σ1(C)
    ■σ1 で何のステップもしなかったプロセス
    (disjoint set of processes) が動作す
    る適当なスケジュールを σ2 で、C2を定義
    ■C2 = σ2(C)
    ■このとき、 σ1とσ2は可換
    – どちらのスケジュールもあり得る
    ■ PROOF. The result follows at once from the
    system definition, since σ1 and σ2 do not
    interact. □

    View Slide

  29. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 29
    Proprietary & Confidential
    分散システムでの実用的な合意アルゴリズム
    ■Paxos
    – Chubby, SpannerとかSQL Serverで使っているやつ
    ■Zab
    – ZooKeeperで使っているやつ
    ■Raft
    – etcdで使っているやつ

    View Slide

  30. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 30
    Proprietary & Confidential
    …の前に確認
    ■FLP Impossibility
    – 非同期性と故障が両方ある世界 ASn,t
    [Φ]では合意は不可能
    ■非同期性のない世界 Sn,t
    ■故障のない世界 ASn,0
    [Φ]
    ■はどうか?

    View Slide

  31. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 31
    Proprietary & Confidential
    同期的な世界では合意できるプロトコルを適当に作れる
    ■Sn,t
    な世界でのナイーブで適当な合意プロトコル:
    – プロセスPi
    は、ベクトル vi
    = [vi0
    , vi1
    , …, vii
    , … vin
    ]を持つ
    – vi
    の初期値は [⊥, ⊥, …, xi
    , … ⊥]
    – ラウンドrでは:
    ■ Foreach(i, j), Pi
    がPj
    にvi
    を送って、受け取ると、 ⊥ のところを vjx
    = vix
    にする
    – r > t になったら decide(min(vi
    ))
    ■ラウンド:
    – メッセージが確実に送信できる期間、順番
    – 同期的な世界ではメッセージ遅延がboundedだから
    ■合意できない要素:
    – Partial sendがあると自分の値が全員に伝わらない可能性がある
    – Partial sendが起きなくなるまでラウンドを回す
    ■ tラウンド経ったら本来死ぬべき人は確実に死んでいる→以降Partial sendは起きない

    View Slide

  32. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 32
    Proprietary & Confidential
    同期的な世界で合意できるプロトコルを適当に証明
    ■Proof Sketch
    – Validity: 提案された値しか使わないので自明
    – Termination: t+1 ラウンド経ったら確実に終わる
    – Agreement: tラウンド経ったらメッセージは確実に浸透しているので
    ■ ∀i ∀j で vi
    = vj
    であり、 min(v) も一致

    View Slide

  33. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 33
    Proprietary & Confidential
    非同期だけど故障のない世界
    ■ 非同期=遅延が有限でunbounded(遅延が無限=故障)
    ■ 遅延が有限なので、メッセージを無限回送れば必ず届く
    – Ackのあるプロトコルの場合、無限回送っていればいつか返信が来る
    ■ Asn,0
    [Φ]な世界でのナイーブで適当な合意プロトコル:
    – プロセスPiは、ベクトル vi
    = [vi0
    , vi1
    , …, vii
    , … vin
    ]を持つ
    – Vi
    の初期値は [⊥, ⊥, …, xi
    , … ⊥]
    – Foreach(i, j), Pi
    がPj
    に提案値を「送って」、Ackを受け取ると、 vji
    = xi
    – 全員から xi
    とAckが来たら decide(min(vi
    ))
    ■ Proof:
    – Validity: OK
    – Termination: ループもない、遅延が有限なのでいつか必ず返事が来る
    – Agreement:
    ■ 故障がないので Partial send は起きない
    ■ メッセージが届くまで周り続けるので ∀i ∀j で vi
    = vj
    であり、 min(v) も一致

    View Slide

  34. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 34
    Proprietary & Confidential
    Paxos [3][4]
    ■ 歴史が古く、もっともよく使われている分散合意プロトコル
    – Hoge Paxosみたいなのが沢山ある
    ■ 分散トランザクションでいう2PCの一般型 [7]
    ■ 前提
    – プロセスは任意のスピードで動く(止まる、再起動する、etc)
    – メッセージは冗送、欠送、無限遅延があるが、壊れたり改竄はされない
    ■ 証明
    – 思ったより長い
    – いくつかある(Part-time parliament [18], Fast Paxos [19][20] など)
    – プログラムでの証明も (TLA+, IronFleet [15] )
    •Phase 1:
    •Proposerは Prepare(n) を全員に送る(nはいくら増やしてもよいが、ユニークでなければならない)
    •Acceptorは Prepare(n) を受け取ると、 最大の n であれば記憶。Accept済の場合は v を返信
    •Proposerは v を返された場合、 自分の提案する値をナシにして v で更新する
    •Phase 2:
    •ProposerはPrepare(n)に対して、過半数のプロセスから返事をもらった場合、 Accept(n, v) を全員に送信
    •AcceptorはAccept(n,v)を受け取ると、既知の n であればAccept。そうでなければ無視
    •Learn:
    •LearnerはAcceptorの過半数がvを返したらLearn

    View Slide

  35. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 35
    Proprietary & Confidential
    Zab / Raft
    ■Zab [13][14]
    – ZooKeeper で使われているアトミックブロードキャストプロトコル
    – 順番保証と配送保証のあるプロトコル(TCP)が前提
    – 証明のスタイル
    ■ 定義を列挙
    ■ Invariantを列挙
    ■ プロトコルが満たすべき性質(Properties)を列挙
    ■ 補題とInvariantから、Propertiesが満たされていることを証明
    ■ 補題の定理とその証明を列挙
    ■Raft [22]
    – etcd, Kudu で使われている
    – お手軽に実装できる
    – 証明はTLA+で

    View Slide

  36. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 36
    Proprietary & Confidential
    まとめ
    ■耐故障性、一貫性に関する分散システムはクラ
    ウドを支える基礎技術、基礎理論
    ■証明怖くないよ
    ■非同期性と故障が両方あると合意はできない
    ■制約つきで合意できるプロトコルがいくつかあり、
    理論的に証明できる

    View Slide

  37. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 37
    Proprietary & Confidential
    FAQ
    ■Q. 証明されているプロトコルを実装すれば絶対安全なのでは?
    ■A. アルゴリズムが正しくても実装が正しいとは限らない
    –いまのところ分散プログラムについては、実装の正しさを検証する方法はない
    –モデル検査とか証明の試みはある (TLA+など
    –Fault injection testing (Jepsen, Molly, Chaos Monkey
    –IronFleet
    ■Q. 要約とか参考文献
    ■A. レジュメ→ https://goo.gl/ioE3rX

    View Slide

  38. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 38
    Proprietary & Confidential
    ■ [1] Seth Gilbert and Nancy Lynch. 2002. Brewer's conjecture and the feasibility of consistent, available,
    partition-tolerant web services. SIGACT News 33, 2 (June 2002), 51-59. DOI:
    https://doi.org/10.1145/564585.564601
    ■ [2] Michael J. Fischer, Nancy A. Lynch, and Michael S. Paterson. 1985. Impossibility of distributed consensus
    with one faulty process. J. ACM 32, 2 (April 1985), 374-382. DOI=http://dx.doi.org/10.1145/3149.214121
    ■ [3] Leslie Lamport, Paxos Made Simple, 2001 http://research.microsoft.com/en-
    us/um/people/lamport/pubs/paxos-simple.pdf
    ■ [4] Tushar D. Chandra, Robert Griesemer, and Joshua Redstone. 2007. Paxos made live: an engineering
    perspective. In Proceedings of the twenty-sixth annual ACM symposium on Principles of distributed
    computing (PODC '07). ACM, New York, NY, USA, 398-407.
    DOI=http://dx.doi.org/10.1145/1281100.1281103
    ■ [5] Peter Bailis and Kyle Kingsbury. 2014. The Network is Reliable. Queue 12, 7, pages 20 (July 2014), 13
    pages. DOI: http://dx.doi.org/10.1145/2639988.2639988 -> http://queue.acm.org/detail.cfm?id=2655736
    ■ [6] グリッドを支えるP2P技術http://www.shudo.net/publications/jpgrid-20050218/shudo-jpgrid-20050218-P2P-
    Grid.pdf
    ■ [7] Jim Gray and Leslie Lamport. 2006. Consensus on transaction commit. ACM Trans. Database Syst. 31, 1
    (March 2006), 133-160. DOI=http://dx.doi.org/10.1145/1132863.1132867
    ■ [8] Leslie Lamport, How to Write a 21st Century Proof, 2011 http://research.microsoft.com/en-
    us/um/people/lamport/pubs/proof.pdf
    ■ [9] Yasushi Saito and Marc Shapiro. 2005. Optimistic replication. ACM Comput. Surv. 37, 1 (March 2005),
    42-81. DOI=http://dx.doi.org/10.1145/1057977.1057980
    ■ [10] Bernadette Charron-Bost, Fernando Pedone, and André Schiper (Eds.). 2010. Replication: Theory and
    Practice. Springer-Verlag, Berlin, Heidelberg.
    ■ [11] Miguel Castro and Barbara Liskov. 1999. Practical Byzantine fault tolerance. In Proceedings of the third
    symposium on Operating systems design and implementation (OSDI '99). USENIX Association, Berkeley, CA,
    USA, 173-186.
    ■ [12] M. Castro and B. Liskov. 1999. A Correctness Proof for a Practical Byzantine-Fault-Tolerant Replication
    Algorithm. Technical Report. Massachusetts Institute of Technology, Cambridge, MA, USA

    View Slide

  39. Copyright © 2017 Nautilus Technologies, Inc. All rights reserved.
    NAUTILUS 39
    Proprietary & Confidential
    ■ [13] Flavio P. Junqueira, Benjamin C. Reed, and Marco Serafini. 2011. Zab: High-performance broadcast for
    primary-backup systems. In Proceedings of the 2011 IEEE/IFIP 41st International Conference on Dependable
    Systems&Networks (DSN '11). IEEE Computer Society, Washington, DC, USA, 245-256.
    DOI=http://dx.doi.org/10.1109/DSN.2011.5958223
    ■ [14] Flavio Junqueira, Benjamin Reed, and Marco Serafini, 2010. Dissecting ZAB. Yahoo! Labs Tech Report,
    YL-2010-0007.
    ■ [15] Chris Hawblitzel, Jon Howell, Manos Kapritsos, Jacob R. Lorch, Bryan Parno, Michael L. Roberts, Srinath
    Setty, and Brian Zill. 2015. IronFleet: proving practical distributed systems correct. In Proceedings of the
    25th Symposium on Operating Systems Principles (SOSP '15). ACM, New York, NY, USA, 1-17. DOI:
    http://dx.doi.org/10.1145/2815400.2815428
    ■ [16] Micheal Raynal, Communication and Agreement Abstractions for Fault-Tolerant Asynchronous
    Distributed Systems.
    ■ [17] Micheal Raynal, Fault-Tolerant Agreement in Synchronous Message-Passing Systems.
    ■ [18] Leslie Lamport. 1998. The part-time parliament. ACM Trans. Comput. Syst. 16, 2 (May 1998), 133-169.
    DOI=http://dx.doi.org/10.1145/279227.279229
    ■ [19] Lamport, L. Fast Paxos. Distrib. Comput. (2006) 19: 79. doi:10.1007/s00446-006-0005-x
    ■ [20] Correctness proofs of classic Paxos and Fast Paxos
    ■ [21] Diego Ongaro and John Ousterhout. 2014. In search of an understandable consensus algorithm. In
    Proceedings of the 2014 USENIX conference on USENIX Annual Technical Conference (USENIX ATC'14),
    Garth Gibson and Nickolai Zeldovich (Eds.). USENIX Association, Berkeley, CA, USA, 305-320.
    ■ [22] TLA+ spec of Raft, https://github.com/ongardie/raft.tla
    ■ [23] A Brief Tour of FLP Impossibility

    View Slide