分散システムの限界について知ろう

分散システムの限界に
ついて知ろう
大村伸吾 @everpeace
2018/07/02 株式会社エフ・コード社内勉強会

大村伸吾
おおむらしんご
✘ Software Engineer at Preferred Networks
✘ Technical Consultant at f-code, ChatWork
✘ twitter/github: everpeace
✘ facebook: shingo.omura

ご注意
✘ 専門家が作った or 専門家向けの資料ではありません
✘ 私自身勉強を続けており、この勉強会に向けて論文を自分自身
で読解し作成しています
✘ 間違い等あるかもしれません。あれば是非コメント等いただけた
ら嬉しいです
✘ 最後の付録に参考文献を幾つか載せていますので適宜参照をお
願いします

本日の流れ
✘ 分散システムをなぜ作るのか
✘ 分散システムとはなにか
✘ 分散システムにおける不可能性
✗ FLP Impossibilities
✗ CAP Theorem
✘ CAPは今見直され始めている
✗ 現実に使うには単純化されすぎている
✗ 様々な整合性、その実現可能性が研究されている

Section 1. 　　　　　　
なぜ分散システムを作るのか

なぜ分散システムを作るのか
✘ スケーラビリティ (post moore’s lawと言われることも)
✗ 複数で並行処理を行うことでたくさん処理をしたい
✗ 全部一箇所でやるのではなくて分担作業したい
✘ 耐障害性
✗ 一箇所だと何処かが壊れたらおしまい
■ システムも使えなくなる
■ 最悪データがなくなったりする
✗ どこかは故障するけど全体は故障しない&データなくなって
ほしくない

Section 2. 　　　　　　
分散システムとはなにか

分散システムとはなにか
✘ 広義
✗ 複数のプロセスがネットワークを介して通信しながら
協調して何かを遂行するシステム
✘ 故障に注目した定義もある
✗ “分散システムとは自分が存在すら知らないコンピュータ上
の障害があなたのコンピュータを利用不可能してしまうような
システムだ” by Leslie Lamport (拙訳)
✗ “部分的な故障を許容するシステム” by @kumagi (*)
(*) “本当は恐ろしい分散システムの話” 熊崎宏樹 NTTデータテクノロジーカンファレンス2017

ふつうの3層Webアプリ(client, web-server, DB)はそうなの？
✘ 広義の意味ではそう
✘ DBにステートを閉じ込めている
✗ アプリはステートを持たないのが普通
✗ DBがSPOF(Single Point of Failure)/ボトルネックになりがち
✗ Key Value Store(Scalable) はかなりポピュラー
■ ACIDなトランザクションは未対応なもの多い
✗ 分散DB(ACID対応)も最近はいろいろ聞くようになった
(Spanner, Kudu, CockroachDB, Cosmos DB etc.)

必然的に分散システムでは
ステートを扱う話題が中心

Section 3. 　
　　分散システムにおける不可能性

分散システムおいてよく知られている不可能性
✘ Part 1. FLP Impossibility (分散合意における不可能性)
✘ Part 2. CAP 定理 (データの整合性における不可能性)

Section 3.　　　　　　
Part 1.　　　　　
FLP Impossibility
(耐障害性のある分散合意の不可能性)

合意、合意って
なぜ良く聞くの？

分散合意という問題が分散システムにおいて本質的である理由
✘ 「帰着(Reduction)」という概念の根っこにあるから
✗ 例: ソートが解ければ最大値は解ける
✘ 多くの重要な問題が「分散合意」を介して相互帰着可能
分散
合意
リーダ
選挙
アトミック
ブロードキャ
スト
State
Machine
Replication
「分散合意が解けない」は「他の問題も解けない」ことを意味する

FLP Impossibility
✘ Fisher, Lynch, Patersonによって1983年に証明
非同期な分散システムにおいて
たった一つのプロセスが故障がした(Crash-Stop)だけでも
有限時間で分散合意に到るアルゴリズムは存在しない
✘ 「不可能である」ための主な前提
✗ 非同期な通信モデル
➔ プロセスの実行スピードやメッセージ遅延に保証がない
✗ 故障は検知できないこと
➔ 通信遅延と故障を区別できない
✗ アルゴリズムは決定性である

合意(Concensus) 問題
✘ 入力: Nプロセス (N ≧ 2) が与えられて、各々初期値を持っている
✘ タスク: 下記3つを満たすプロトコル(アルゴリズム)を設計しなさい
✗ Termination: 故障していない全プロセスがいつか値を決定する
✗ Agreement: 決定された値はすべて等しい
✗ Validity: 決定された値はどれかのプロセスの初期値
✘ 簡単のため提案値は 0, 1 の2値とする
(以降の議論は簡単に多値に拡張できる)

FLP が前提とするシステムモデル
✘ タイミングモデル => 非同期モデル
✗ メッセージの処理時間の上限がない
➔ 遅いだけなのか、停止しているのか区別不能
✘ リンク(通信路)モデル => 完全に信頼性のあるリンク
✗ 順序保証ない(順序バラバラ、遅延も任意)けどいつか絶対届く
✗ Unreliableなモデルでは同期モデルでもconcensusできない
✘ 故障モデル => Crash-Stopモデル
✗ 停止したら二度と戻ってこない

故障モデルの階層
Byzantine Failure
Crash-Recovery Failure
Omission Failure
Crash-Stop Failures
何でもあり(システムを騙すような挙動もあり )
故障停止するが、有限時間内に正常に戻る可能性あり
(これを繰り返す可能性も有る )
停止して二度と戻らない
メッセージを送らなかったり、受信しなかったりする
Introduction to Reliable and Secure Distributed Programming
難/広
易/狭

モデルをもうちょっと詳しく(定式化されたモデル)
✘ 各プロセス&通信
✗ 入力レジスタx, y (1bit)を持っている
■ yは出力用, 初期値はnil, 一度だけ書き込める
(書き込む=合意完了)
✗ 無限の通信バッファを持っている
■ send(p, m): pのバッファにmを書き込む
■ receive(p): pがメッセージを受信する
戻りは nilかもしれない、順番保証しない
(遅延や順序の乱れをモデル化している)

モデルをもうちょっと詳しく(定式化されたモデル)
✘ システム全体
✗ configuration:
■ 各プロセスの状態の集合(x, y, buffer)
■ initial configuration: 初期状態(x=?, y=nil, buffer=empty)
✗ step:
■ どれか一つのプロセスが動く
■ receive(p) → 内部計算(状態更新) → 有限個のメッセージを送信
✗ event:
■ pがメッセージm を受信した事実 ( (p,m)とtupleで表記 )
■ algorithmは決定的なのでinitial configurationとreceive(p)で戻るメッセージの列(p,
m)だけで再現可能
✗ schedule:
■ eventの列 (無限, 有限ok)
■ schedule を configurationに適用して生成されるstepの列をrunと呼ぶ
■ 重要: あるschedule σ1, σ2 がdisjoint (nodeが被ってない) なら可換

FLP Impossibility 証明の概要 (なぜ不可能なのか？)
✘ 弱い合意をするプロトコル P を考える
✗ 不可能性証明はこれで十分
✗ 故障していない幾つかのプロセスが内部的に合意状態に至れる
■ Configuration の decision value v をもつ ⇔ ∃ p, yp = v
■ 弱合意(このスライドだけの造語)
● どんな初期状態からもdecision valueが 1個だけになる
● どちらのdecision value(0, 1) に至る場合がある
✘ 大筋 ➔ 背理法:
✗ 1 process故障しても弱合意するプロトコル Pの存在を仮定して、
✗ プロトコル制御外のシステムの非決定性/故障によって合意に
至らない実行を生み出せてしまうことを示して矛盾を導く

証明の概要
✘ 証明のステップ
✗ 弱合意値が決定できない初期状態(bivalent initial configurations)が
存在する
■ 豆知識: -valent とは化学でよく出てくる-価とかの英語らしい。configurationが 1-価、2-価という感じ。bi-valent = 2-
価。このアルゴリズム的にいうと、まだシステム全体として合意状態(0, 1)が確定していない状態。
✗ bivalent configurationで受信されるべきメッセージが遅延すると別の
bivalent configuration に至る実行が存在する
✘ 注意:

簡単に説明すると(bivalentな状態がずっと続きうる)
“分散システムについて語らせてくれ” 熊崎宏樹 NTTデータテクノロジーカンファレンス2017 #2

✘ bivalentな状態 C とは
✗ 状態 = プロセスの内部状態(通信バッファ含む)の集合
✗ C から Pを走らせて、弱合意に至る値の種類が2個存在する
■ 故障や遅延によって合意結果が異なる(決まってない)
✘ uni-valent => 弱合意値が1種類だけ存在する(絶対特定の値に合意可能な状態)
✗ ポイント: 合意に至る前に必ずuni-valentな状態を経由する！
✘ x-valent => その値がx
Pには bivalent な初期状態が必ず存在する
Pを実行
1
1
に合意するパターンと
に合意するパターンが
存在する

証明の概要
✘ 証明のステップ
✗ 弱合意値が決定できない初期状態(bivalent initial
configurations)が存在する
✗ bivalent configurationで受信されるべきメッセージが遅延する
と別のbivalent configuration に至る実行が存在する
✗ 合意に至るにはいつかunivalentな状態に至ることが必須
✗ bivalentが続いてしまうと永遠に合意に至れない

Pには bivalent な初期状態が必ず存在する　cont.
✘ bivalentな初期状態(提案値のみ、通信バッファ空)が無いと仮定する
✘ すべての初期状態は0-valent, 1-valentに分類できる
✘ 1 プロセスだけ状態が異なる初期状態を隣接していると呼ぶ
✘ 0-valentと1-valentは絶対どこかで隣接している
✗ n進数に見立てて一列に並べればどこかに絶対境目があってそれは隣接
✘ 隣接しているC0, C1 で内部状態が異なるプロセスをp として
pが全く動作しない(遅延or故障)実行σを考える
✘ C0, C1 はpを除くと初期状態は全く等しい。実行σはpに全く関与しないのでC0, C1
からスタートさせることができて、その時C0, C1 は同じ弱合意値を持つ状態に至る
はず。
✘ でも定義によるとC0, C1 はそれぞれ0-valent, 1-valent。矛盾。

bivalent configurationで特定のメッセージが遅延すると
別のbivalent configuration に至る実行が存在する
✘ 準備
✗ C = bivalentな状態
✗ e = (p,m) = Cの状態で発生(適用)可能な
「プロセス p でメッセージ m が受信される」event
✗ C = Cからeが発生せず到達可能な全状態
✗ D = C の最後にeを適用した全状態(eが遅延したとみなす)
✘ 示したい結果
✗ D は bivalentな状態を含む
✘ 方針: 背理法。D にbivalentな状態が含まれない(つまり全部univalent)だ
と仮定して矛盾を導く

E0 ∉ C
C
別のbivalent configuration に至る実行が存在する cont.
✘ D にbivalentな状態が存在しないと仮定する
✗ つまりuni-valent
✗ つまりD に至ったら必ず弱合意に至る
と仮定する
✘ この時D には0-valent, 1-valent 両方が
存在する
✗ C は bivalentだからいつか0-valent,
1-valentの状態(E0, E1)に遷移する
✗ E0 を0-valentとする
✗ E0 ∈ C の場合
➔ e を受信後D0∈D は0-valentなはず
✗ E0∉ C の場合, E0に至るまでにe が受
信されているはずで、それをD0
とするとDはunivalentなのでそれは
0-valentなはず
C
E0
E0 ∈ C
D0
D
E0
D0
?
e e

✘ すると次のような状態 C0, C1 が C に存在する
✗ C0, C1 は neighbor (受信イベント e’ = (p’, m’) を適用可能)
✗ C0, C1 に e = (p, m) を適用すると
0-valent, 1-valentな状態 D0, D1 になる
D
C
C0
C1
e’=(p’, m’)
C
D0
D1
0に弱合意
1に弱合意
e=(p, m)
e=(p, m)

✘ p’ = p, p’ ≠ p の二通りが考えられるが、どの場合も矛盾が生じてしまう
✘ p’ ≠ p の場合( m’, m が違うノードで受信されるメッセージの場合)
✗ D0 で e’ が起きるとD1
になるはず
✗ e’ はpと関係ないから
✗ でも0-valentから1-valent
に遷移できるはずない
✗ 矛盾。
D
C
C0
C1
e’=(p’, m’)
C
D0
D1
e=(p, m)
e=(p, m)
e’=(p’, m’)

✘ p’ = p の場合 (m, m’ が同じプロセスの受信メッセージの場合)
✗ つまりe’ が遅れるだけでvalencyが変わる
✘ σ を pが動作しない状態で弱合意されたAへの実行とする
✘ pが関与しないので, Aの後に e, e’ を適用できる(遅れてpが受信する)
✘ すると A は弱合意した状態なのに、bivalentであることになってしまう
✘ 矛盾。D には必ず bivalentな状態が存在する
D
C
C0
C1
e’=(p, m’)
C
D0
D1
e=(p, m)
e=(p, m)
A
σ
E0
σ
E1
e
e’
e
σ

やっと２つ証明完了
✘ P には bivalentな initial configuratinがある
✘ Bivalentなconfiguration C において
適用(受信)可能な e = (p, m) が遅延したとすると
遅延したメッセージを受信した後のconfiguration集合 D の中
には bivalent configurationが必ず存在する
✗ 注: 合意するためにはいつか univalentなconfigurationに遷
移する必要があるがそれが永遠にできない

組み合わせるとbivalentな状態の無限ループが構成できる
✘ C0 を initial bivalent configurationとする
✘ C0 で受信されるメッセージ(nullable)イベントを e とすると
✘ そのeventが遅延して到着した後やはり bivalentであるような実行
(最後がe)が必ず存在する
“分散システムについて語らせてくれ” 熊崎宏樹 NTTデータテクノロジーカンファレンス2017 #2

1台の停止故障でも有限時間で
分散合意をする決定性プロトコルは
存在できない

分散合意が耐障害性を持てないということは
✘ 相互に帰着可能な下記も耐障害性を持つことはできない
分散
合意
リーダ
選挙
アトミック
ブロードキャ
スト
State
Machine
Replication
「分散合意が解けない」は「他の問題も解けない」ことを意味する

でもZookeeperとかetcd(Raft)とか
Chubby(Paxos)とかってできているの
では？

FLP Impossibilityの語ること
✘ 有限時間で100%の確率で合意に到ることが不可能と
言っているだけ
✘ 現実的にはほとんどの場合回避できる
✘ コーナーケースとして絶対に存在することを肝に銘じる
✘ Zookeeper, Paxos, Raftも完全な合意はできていない。故障ノード
が発生したりして合意が停止しない場合があり得る。
✘ 現実的にはtimeoutを設けたりして諦めて、別の合意プロセスと
してやり直す(最初のはエラーになるけど、保存されている状態
は破壊されない)

Part 2.　　
CAP Theorem
(データ整合性についての限界)

CAP 定理の概要
✘ 2000年にEric Brewerによって予想され、2004年にGilbert, Lynchが証明
✘ 分散システムではこれら３つを同時に満たすシステムは存在しない
✗ Consistency(一貫性):
■ 読めるデータはいつでも最新(もしくはエラー)
✗ Availability(可用性):
■ いつでもどこかのプロセスから読み書きできる
✗ Partition Tolerance(分断耐性):
■ ネットワークが分断しても耐えられる
Wikipedia: CAP定理

Brewer氏の想定したシステムとCAP予想
✘ 一貫性
✗ 多くのWebサービスは ACID が必要とされている
■ 課金情報、商取引等は強い一貫性が必要なのは自明
✘ 可用性
✗ 同様に可用性も期待されている
✗ クライアントからのリクエストは常に成功し応答されるべき
✗ ネットワークがつながっている限りサービスを提供し続けることが目標
✘ 分断耐性
✗ 高度に分散したネットワーク上では、ある程度の障害耐性を提供することが望
ましい
■ 一つのノードがクラッシュしたり、一つの通信リンクが故障した場合でも、
サービス自体は期待通りに動作を続ける
✗ 望ましい障害耐性性質は、ネットワーク分断により、複数のコンポーネント群に
分断された場合でも生き残る能力
■ ノードクラッシュ、は分断の一種とモデル化できる

Gilbert, Lynchが行ったC, A, Pの形式化(Formalization)
一貫性(Consistency)
✘ 「一貫性のあるサービス」= アトミックデータオブジェクト
✗ アトミック(ないし線形化可能性)一貫性は、今日の大半のWebサービ
スに期待される条件
✘ アトミック一貫性(= lineraizability):
✗ 全操作(i.e., クライアントから発行されたリクエスト群)に全順序を定めら
れる
✗ その順序は、各操作の実時間順序を反映している
■ 外部からは「単一ノードでリクエスト群が処理されている」ような挙動と
して観測可能
■ (e.g., 直前にwriteされた値がreadされる)
✗ サービスを利用するユーザが最も理解しやすいモデル

可用性(Availability)
✘ 分散システムが継続的に利用可能(可用性がある)と言えるためには、
✗ 故障していないノードに対するリクエストには、応答が返されるべき
✗ つまりアルゴリズムは最終的には完了(terminate)しなければならない
✘ ある面では可用性の弱い定義と見なせる:
✗ 終了までの上限が定められていないから
✘ 別の面では可用性の強い定義ともみなせる:
✗ (分断耐性という条件が課された場合)
✗ 深刻なネットワーク障害が発生した場合でも、全てのリクエスト
は終了しなければならないから

分断耐性(Partition-Tolerance)
✘ "分断" =「コンポーネントを跨いで送信されたメッセージの消失」
✗ ネットワークが複数のコンポーネント群に分断された場合、
ある側に属するノードから、別の側のノードに送られた全メッセージ
が消失する
✗ 任意のメッセージの消失は「一時的な分断」としてモデル化可能
✘ アトミック性および可用性は「任意のメッセージが消失する」ような
ケースでも達成される必要がある
✗ ネットワーク全体の故障時を除いて、システムが不適切な応答を
返すことを許さない
✗ 単一ノードでも生存しているなら、それは正しい応答を返さなければ
ならない

Gilbert, Lynchが証明した不可能性
非同期ネットワークモデル
✘ FLP Impossibilityと同じ
✗ ネットワークの遅延は上限がない
✗ メッセージ処理時間は有限
✗ いわゆる時計は存在しない(お互いにせーの！で時間が測
れたりはしない)
■ 論理的な時計の存在は想定

非同期ネットワークモデルにおける不可能性とその証明
✘ 以下を保証する読み書きデータオブジェクトの実現は不可能
✗ 可用性
✗ アトミック一貫性
✘ メッセージ消失が生じ得る全てのフェアな実行において、
上記が成り立つ
✗ "フェア" = 「特定のノードの処理だけが永遠に実行される」
といった不公平がない

非同期ネットワークモデルにおける不可能性とその証明 cont.
✘ 背理法による証明:
✗ CAPすべて満たすアルゴリズムの存在を仮定
✗ 不整合が生じる応答を返すような実行を構築して矛盾を導く
✘ 準備
✗ システムはNノード(N ≧ 2)で構成される
✗ G1, G2 というお互いに疎な非空のネットワークに分断
■ G1 <-> G2 のメッセージは全部消失する
■ 簡単のために2ノードとする
G1 G2

非同期ネットワークモデルにおける不可能性とその証明 cont.
✘ アトミックデータオブジェクトVの初期値をv0 とする
✘ 実行α0: G1 で V に v1 の書込が行われた実行
✗ 可用性があるので書き込み処理は完了してv1になる
✘ 実行 α1: G2 で V の読込が行われた実行
✗ 可用性があるので読み込みは完了してv0が返る
✘ 実行α = α0 + α1 を考える
✗ G1 -> G2 は全く通信できない
➔ G2 側では αと α2を区別不可能
➔ 実行αでも G2 は v0が返る
✗ アトミック性に反している。矛盾。
v1 v0
G1 G2

CAP定理の元で取れる戦略３つ
✘ 一貫性(C) + 可用性(A): 分断耐性がない
✗ 分断が起きたら片方を切り捨てる (Amazon RDSのMulti-AZに
よるHA等)
✘ 可用性(A) + 分断耐性(P): 一貫性がない
✗ 常に読み書きできて、分断しても耐えられるけど、データが
最新じゃない可能性有(Cassandra等)
✗ Eventual Consistency(結果整合性)があるものが多い
✘ 一貫性(C) + 分断耐性(P): 可用性がない
✗ 分断しても耐えられるけれど、分断中はデータは利用不可
(Apache HBase等)

CAP定理は今見直されている
(12年後の反省と現代における再解釈)

近年見直され始めたCAP定理
✘ CAP定理は確立された後、その単純明快さゆえに、
実際に多くの分散システムでのトレードオフを判断するために
活用(乱用)されてきた
✘ 近年、提唱者Eric Brewer自身も、
✗ CAP定理は現代にはそのまま適用するのは単純すぎて危険
✗ ３つのうち２つというのはミスリーディングだった
■ インターネットではPは取らざるを得ないことがほとんど
■ Aには度合いがある。Cにも実は度合いがある
● CAPが想定しているのはものすごく強いLineralizability
■ システムがモードを切り替えながら動くこともある
■ etc.
として2012年に見直しを行っている

近年見直され始めたCAP定理
✘ Please stop calling databases CP or AP — Martin Kleppmann's blog
✗ CAPの定義はあまり現実に即していない
■ Linearizabilityは必要な場合が少ない
(Eventual Consistencyで十分な場合が多い)
■ 可用性の定義が甘い
(レスポンスを返すだけでは甘い)
■ Partition-Toleranceは実際は取らざるを得ない
✗ CAP定理が対象にしているシステムは狭い
■ 対象は単一のデータオブジェクト
■ 考慮されている故障がネットワーク分断のみ
■ 現実的に問題となるLatency(Performance)には言及がない

近年見直され始めたCAP定理 cont.
✗ データベース全体でCP/APとカテゴライズするのは誤り
■ 一つのソフトウェアの中にも様々な一貫性がある
■ CAP定理の元では C も A もないPのみのシステムもあるのに
多く使われているものも在る(例: Zookeeper)
● Zookeeperは使い方によってCPにもAPにもなる
■ Eric BrewerですらCAPという分類は単純すぎた
と認めている

近年見直され始めたCAP定理 cont.
✗ これまで多くのデータベース設計に示唆を与えてきた
CAP定理の分類が使えないのならどうすれば？
✗ 自分で考えられるようになりましょう。
多くの先人達も同じ課題について考えています。
■ Doug Terryの論文が最初のおすすめ
● Replicated Data Consistency Explained Through Baseball
(野球の例を使って整合性の様々な異なるレベルを説明)
■ Highly Available Transactions: Virtues and Limitations (full)
● 整合性レベルの階層とトランザクション分離、可用性に
ついての考察
■ Designing Data Intensive Applications を読む
■ etc.

Doug Terry氏による複製データの整合性分類
Replicated Data Consistency Explained Through Baseball

Peter Bailis et.al. による整合性モデルの半順序構造
✘ 中身あまり理解できていない
✘ 近いうちにちゃんと時間を取って
読む予定(積読中)
✘ Partitionやlatencyが存在する世界で
Highly AvailableなTransactionとは？
✘ どういう整合性モデルが存在
するのか？
✘ それらの強さの関係は？
✘ クライアントから見て”sticky”
= 同じreplicaを操作しているように
見える
が可能かどうか？
✘ みたいな分類と実現可能性の
研究らしい？
Highly Available Transactions: Virtues and Limitations

まとめ
✘ 分散システムの研究成果の二本柱である
✗ FLP Impossibility
✗ CAP 定理
について証明概要を交えて説明した
✘ CAP定理は多くの分散データベース (KVS含)に影響を与えたが、現実と前提がそぐ
わないレベルまで単純化されているので、この定理を現実にそのまま適用するの
は危険、といった警笛が鳴らされていることも紹介した
✘ Doug Terry氏, Peter Bailis氏らによる細かい整合性分類について触れ、「整合性」と
いっても様々なレベルがあり CAPは実際に適用するには強すぎることにも触れた

THANKS!
Any questions?
You can find me at
✘ twitter/github: everpeace
✘ facebook: shingo.omura

付録: 参考文献 (FLP編)
✘ 分散システムについて語るときに我々の語ること― 分散システム... - POSTD
✗ 分散システムにまつわる概念をいろいろ解説。
✗ 入門的に読むととても良い。
✘ Impossibility of Distributed Consensus with One Faulty Process
✗ 原典。FLPの言わんとする所について何かに詰まったら必ず戻る場所。
✘ A Brief Tour of FLP Impossibility
✗ FLP証明の解説
✗ Zookeeperのcommitterでcloudera所属の@HenryR さんのブログThe Paper Trail より
✗ とてもわかり易いブログ満載。興味の在る方は他の記事も必読。
✘ Introduction to Reliable and Secure Distributed Programming
✗ 良書。分散システムを理論からしっかり学びたい人におすすめ。
✘ Stumbling over consensus research: Misunderstandings and issues
✗ concensusにまつわる誤解をFLPが前提としているシステムモデルを確認しながら解説
してくれる論文
✘ 分散システムについて語らせてくれ, 本当は恐ろしい分散システムの話
✗ NTTの熊崎さんによる分散システムについての解説

付録: 参考文献 (CAP定理編)
✘ Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services
✗ 原典。証明されていることはすべてここに。
✗ 日本語訳あり
✘ Perspectives on the CAP Theorem - Research
✗ 証明者(Gilbert, Lynch)によって12年後に書かれた CAP Theormの現代における解釈と現実的に取られている
解法について
✘ CAP Twelve Years Later: How the ''Rules'' Have Changed
✗ Eric Brewer自身が12年を振り返り、CAP定理への反省と現代における再解釈について考察した記事
✗ データベースをCP/APと分類するのは雑すぎる、現実的でないと唱えた記事
✗ Designing Data-Intensive Applicationの著者のMartin Kleppmanさんの記事
✘ Designing Data-Intensive Application
✗ とっても良書。分散システムの基礎概念がとてもよくまとまっている
✗ CAPへの批判も入っている
✘ Replicated Data Consistency Explained Through Baseball
✗ 整合性の様々な分類について述べられた論文
✗ Azure Cosmos DBが提供する整合性の元になっていると思われる

分散システムの限界について知ろう

Recommended

More Related Content

What's hot (20)

Similar to 分散システムの限界について知ろう (11)

分散システムの限界について知ろう