9.4.3 耐障害性を持つ合意

Transcript

1. データ指向 アプリケーションデザイン 9.4.3 耐障害性を持つ合意
2. 合意アルゴリズムが満たすべき性質 - 一様合意 ２つのノードが異なる決定をしないこと - 整合性 ２回決定しているノードがないこと - 妥当性 ノードが値vを決定したら、vを提案しているノードがあること - 終了性 クラッシュしていない全てのノードは、最終的に何らかの値を決定すること
3. 終了性 = 耐障害性の概念を形式化したもの 終了性を満たすことを諦めれば、一様合意、整合性、妥当性は容易に満たせる - 方法１： あるノードを「独裁者」として、全ての決定をそのノードが行う - そのノードがクラッシュすると全ノードは決定できなくなる - 方法２： 何も決定しない ２相コミットでは終了性を満たすことはできない - 一度クラッシュしたノードは二度と戻ってこない 終了性を満たすための、耐えられる障害の数には限度がある - クラッシュしていたり到達不能になっているノードが半数未満
4. 耐障害性を持つ合意アルゴリズム - ViewStamped Replication (VSR) ユーザ: ? - Paxos ユーザ: Hadoop - Raft ユーザ: etcd（k8sなどで使われている） - Zab (ZooKeeper Atomic Broadcast) ユーザ: ZooKeeper
5. シングルリーダーレプリケーションと合意 シングルリーダーレプリケーションではリーダーが予め決まっている - リーダーがクラッシュすると人間がリーダーを再起動/変更する必要がある - 終了性を満たしていない
6. エポック番号とクオラム スプリットブレインを防ぐために、「リーダーが誰か」についても合意が必要 合意アルゴリズムは各エポック内でリーダーがユニークであることを保証する - エポックの別名: Paxosではballot,Raftではterm,VSRではview 現在のリーダーがクラッシュしたと考えられるたびにエポック番号をインクリメントし、新し いリーダーを決める投票を開始する 大きいエポック番号をもつリーダーを優先する
7. エポック番号とクオラム（２） リーダーはある決定をする際、投票を行い過半数の票を得る必要がある - 自身がリーダーであると考えていても、そうとは限らない - エポック番号が他のノードより小さければ票を得られない 過半数の票が必要なので、２つの決定には１台以上の重複したノードがある - これによってリーダーは安全に決定をすることが出来る
8. 合意の限界 リーダーが決定をする際に投票する仕組みは同期レプリケーション - 非同期レプリケーションに比べてパフォーマンスが低い 過半数の投票が必要なので、１つの障害に耐えるには３台必要 クラスタへのノードの追加・削除が困難 - 動的なメンバーシップの仕組みを追加することで解決出来る 信頼性の低いネットワークではうまく動かないことがある