合意プロトコル(Consensus Protocol)についてまとめてみる 第1章 概要と背景知識について
この記事は何?
分散環境下において合意を取るためのプロトコルがいくつか存在するので、それらを簡単にまとめることとする。
※分散システムの勉強を兼ねて書いておりますので、間違い等ありましたらご指摘頂けると幸いです。
利用用途
分散合意プロトコルは、以下のようなシチュエーションで使われている:
- リーダ選出 (Leader election)
例. master-slaveモデルの分散システムにおいてmasterがダウンした際に、master eligible nodesから次なるmasterを選出する
- ログ複製の管理 (Replicated state machine)
例. masterが正しいログを保持し、複製を他のnodesに配る
そもそも合意って何?
"The distributed consensus problem deals with reaching agreement among a group of processes connected by an unreliable communications network"
プロセス系全体として一つの値を決定すること、だと解釈している。
例えば5人の人間A,B,C,D,Eが存在し、お昼ご飯について合意を取るとする。
A,B,Cがラーメンを食べる、Dがカレーを食べる、Eが寿司を食べるとなった時、多数決を取り「ラーメンを食べる」で系として合意を得るイメージ?
分散合意プロトコルの話に入る前に、前提となる背景知識について述べる。
背景知識
Byzantine Generals Problem (1982)
Byzantine Generals Problem(ビザンチン将軍問題)は "相互に通信しあう何らかのオブジェクト群において、通信および個々のオブジェクトが故障または故意によって偽の情報を伝達する可能性がある場合に、全体として正しい合意を形成できるかを問う問題" である。 (Wikipediaより)
例え話として、通信など無縁な時代において、小国A, B, C, D, Eの軍隊らが協力し、大国Fを攻めようと画策している状況を考える。
当然A-E単独で攻め込んだところで返り討ちに合うことは目に見えているため、協力して大国Fを攻め落とそうという話になった。
しかし、A-Eは地理的に離れているため、協力するためには攻撃の日を "合意" することで決定する必要がある。
ある小国ともう一方の小国における "通信" 手段は連絡兵を送り合うことのみであるが、小国間には危険な地域があるため、連絡兵がもう一方の小国へ無事に辿り着けない可能性がある。
さらには、A-Eのどれかの国が裏切りを図る可能性もある。
このような状況下でA-E全体として正しい合意を得られるか?を問う問題である。
同期システムの場合、特に弱ビザンチン将軍問題において 3t < n (n: ノード数, t: 障害数) であれば、合意をとることができる (逆にいうと the oral-messages model において3t ≧ n の場合に解決できないことが示されている)
the oral-messages modelは以下参照。
一方、非同期システムの場合、障害が発生した場合において有限時間内に合意を取る方法はない https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf ということがMichael J. Fischer, Nancy Lynch, and Mike Patersonらによって示されている。これをFLP impossibilityと呼び、後述する。
Two general's Problem
Byzantine Generals ProblemはTwo General's Problemを一般化したものである。
つまり、例え話のA-EがA,Bの2つになった問題と解釈してよい。(雑)
FLP impossibility (1985)
Byzantine Generals Problemで触れたFLP impossibilityの話。
非同期システムにおける分散合意の不可能性を説いた論文で、要約すると、
"どのようなプロトコルであっても、たった 1 つでも不完全なプロセスが含まれるのなら終了に達しない可能性を持つことを示している。"
つまり「落ちたか遅延しているかが不明なプロセスが発生した場合、有限時間内で合意に至るアルゴリズムはない」 とのこと。 (論文はまた後日読む)
※ただし前提条件として、故障検知が不可・プログラムが決定的を仮定している。
ちなみに同期システムにおける同問題はByzantine Generals Problemで、合意を取る方法は既にある。
A Brief Tour of FLP Impossibility
論文翻訳: Impossibility of Distributed Consensus with One Faulty Process - MOXBOX / HazMat
分散合意プロトコル
ここでは分散合意プロトコルの種類についてのみ述べる。
個々の内容に関しては非常にボリュームがあるため、次回以降まとめることとする。
- 2相コミット(2 Phase-Commit, 2PC)
PrepareフェーズとCommitフェーズという2段階のフェーズに分かれてトランザクションを実施する。
- 3相コミット(3 Phase-Commit, 3PC)
Voteフェーズ、Prepareフェーズ、Commitフェーズという3段階のフェーズに分かれてトランザクションを実施する。
- Paxos
今日の様々な分散システムの合意をとるために使われているプロトコル。
亜種が非常に多い、難しいことで有名?
Paxosの派生は沢山ある (というか元々のものを忠実に再現することが難しい) らしく、例えばChubbyやApache Zookeeper で採用されている(Zab)は派生の一例である。
- Raft
Diego Ongaro et al.,によって提案されたプロトコル。
Paxosよりも学習者にとって分かりやすいという点を売りにしている。
Paxosよりも制約が多いが、実用上は問題ないとのこと。
特徴として、強力なリーダ選出がある。
- Viewstamped Replication
Paxosに非常に似た手法らしい、あまり情報がなかったので論文を読みたい。
- Mencius
あんまり情報出てこなかった...
それぞれReferencesに参考文献を載せた
(余談) ブロックチェーン?
- Practical Byzantine Fault Tolerance (PBFT)
- Proof of Work (PoW) <- Bitcoinで使われてるやつ
- Proof of Stake (PoS)
次回
2PCからまとめていきます〜!
References
全般
Paxos
ざっくり理解するPaxos - 小野マトペの納豆ペペロンチーノ日記
Paxos, Raftなど分散合意プロトコルを概観する(1) - 備忘録 blog
Raft
Viewstamped Replication
Mencius
Mencius: Building Efficient Replicated State Machines for WANs