Formalization and Proof of Distributed Systems (ja)

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

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

View Slide

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

View Slide

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

View Slide

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

View Slide

NAUTILUS 6
今日の「分散」
■何台かコンピュータがある
■ときどき黙ったりそのまま落ちたりするやつがある
■意見をまとめる方法
v = ?
v = 1
v = 0
v = 0
v = 1
“Consensus in Distributed Systems”

View Slide

NAUTILUS 7
分散システムの理論
■どこまで故障するか？
■どこまで故障したら、合意できなくなるか？
■故障はあるけど、合意はしたい
■「故障」と「合意」をフォーマルに定義して、その
理論限界を模索する

View Slide

NAUTILUS 8
おまけ：分散システムの実践
■そもそもその合意、必要ですか？
■目的とする合意を決める
■システムの動作環境から、一番厳しい故障条件を決める
■システムの動作環境を保証するための運用条件を決める
■理論的に合意できるプロトコルを決めて実装
■テストしてから本番投入
■障害からの復旧

View Slide

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

View Slide

NAUTILUS 10
なぜ耐故障性が重要なのか？
■コンピューターは壊れる
– フラッシュメモリの寿命
– SATAケーブルの不良
– GPU焼け落ち事件
– 宇宙線によるビットエラー
■ネットワークは信頼できる [5]
– ネットワーク機器も壊れる
– LANケーブルは切れる
– ネットワーク機器もコンピューター
■クラウドもデータセンターも壊れる
–
「データセンター火災」
–
「クラウド障害事例」

View Slide

NAUTILUS 11
ネットワークは信頼できる [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

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

View Slide

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

View Slide

NAUTILUS 14
分散システムの基礎理論
■合意とは何か
■故障の分類
■証明のパターン
■理論限界
■合意できるプロトコル

View Slide

NAUTILUS 15
各種用語
v = 1
v=0にしようよ
v = 1
■プロセス
■メッセージ
■故障
プロセス
メッセージ
故障（のひとつ）

View Slide

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

View Slide

NAUTILUS 17
合意に必要な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

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

View Slide

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

View Slide

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

View Slide

NAUTILUS 21
分散システムの証明のパターン
■背理法: (¬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

NAUTILUS 22
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

NAUTILUS 23
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

NAUTILUS 24
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

NAUTILUS 25
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

NAUTILUS 26
■つまり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

NAUTILUS 27
■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

NAUTILUS 28
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

NAUTILUS 29
分散システムでの実用的な合意アルゴリズム
■Paxos
– Chubby, SpannerとかSQL Serverで使っているやつ
■Zab
– ZooKeeperで使っているやつ
■Raft
– etcdで使っているやつ

View Slide

NAUTILUS 30
…の前に確認
■FLP Impossibility
– 非同期性と故障が両方ある世界 ASn,t
[Φ]では合意は不可能
■非同期性のない世界 Sn,t
■故障のない世界 ASn,0
[Φ]
■はどうか？

View Slide

NAUTILUS 31
同期的な世界では合意できるプロトコルを適当に作れる
■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

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

View Slide

NAUTILUS 33
非同期だけど故障のない世界
■ 非同期=遅延が有限で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

NAUTILUS 34
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の過半数がｖを返したらLearn

View Slide

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

View Slide

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

View Slide

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

View Slide

NAUTILUS 38
■ [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

NAUTILUS 39
■ [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

Formalization and Proof of Distributed Systems (ja)

Formalization and Proof of Distributed Systems (ja)

UENISHI Kota

More Decks by UENISHI Kota

Other Decks in Science

Featured

Transcript