🎓 レベル:標準 | 重要度:A(必須)
📎 前提:CAP定理 | 関連:クォーラム(R+W>N)・Raft
要点(BLUF)
- レプリケーション=同じデータを複数ノードに複製。目的は可用性(1台死んでも継続)と読み性能(複数から読む)と地理近接。
- 2つの設計軸:同期 vs 非同期(書き込みをいつ「成功」とするか)と、リーダー型 vs リーダーレス型(書き込みの受け口を1つに絞るか)。
- トレードオフは常に一貫性 vs 可用性/レイテンシ。同期&リーダーは一貫性寄り(Raft)、非同期&リーダーレスは可用性寄り(Dynamo系、クォーラム(R+W>N))。
問題設定 ── いつ「書けた」と言うか
書き込みを全複製に反映するには時間がかかる。「いくつの複製に届いたら成功と返すか」で一貫性と可用性が決まります。これが同期/非同期の軸。さらに「誰が書き込みを受け付けるか」で順序付けの難しさが変わる——これがリーダー/リーダーレスの軸です。
モデル ── 2軸の4象限
flowchart TB
L["リーダー型(プライマリが順序を決める)"] --> LS["同期:過半数に届くまで待つ(強一貫・遅い)"]
L --> LA["非同期:リーダーが返してから複製(速い・ロスト窓)"]
LL["リーダーレス型(どの複製にも書ける)"] --> LLQ["クォーラム:W個に書きR個から読む(R+W>N)"]
LL --> LLG["ゴシップで反エントロピー収束(結果整合)"]
| 象限 | 一貫性 | 可用性/遅延 | 例 |
|---|---|---|---|
| リーダー+同期 | 強い(線形化可) | 遅い・少数派で停止 | Raft/Paxos系、同期レプリカ |
| リーダー+非同期 | 弱め(複製遅延でラグ) | 速い・障害時にロスト窓 | MySQL非同期レプリカ |
| リーダーレス+クォーラム | R/Wで調整可 | 高可用 | Dynamo, Cassandra |
| リーダーレス+ゴシップ | 結果整合 | 最高可用 | ゴシップ・反エントロピー・故障検出(SWIM) |
仕組み ── リーダー型 vs リーダーレス型
リーダー型:すべての書き込みを1人のリーダー(プライマリ)が受け、順序を決めて follower に流す。順序が自然に1本になるので一貫性を保ちやすい。リーダー障害時は選出(リーダー選出(Bully・Ring)・Raft)が要る。
リーダーレス型:どの複製にも書ける。順序を決める中心が無いので、並行書き込みの衝突が起きる。検出にはベクトル時計/版数ベクトル、解決には LWW・マージ・CRDT(PACELC・結果整合性)。読み修復とヒンテッドハンドオフで欠損を埋める。
状態機械レプリケーション(SMR):リーダー型の理論的核。全複製を決定的な状態機械とみなし、同じ操作列を同じ順で適用すれば全複製は同じ状態になる。だから「操作列の順序に合意する」=合意問題(Raft)に帰着します。
正しさの観点 ── 同期/非同期の保証差
- 同期(過半数):書き込み成功=過半数に永続化済み。リーダーが落ちても確定データは生き残る(耐久性)。代償は遅延と、少数派分断での停止(CP)。
- 非同期:リーダーが自分に書いた時点で成功を返し、複製は後追い。速いが、複製前にリーダーが落ちると書き込みが消える(ロスト窓)。
fsync前の応答ならさらに危うい。
なぜ分散だと難しいか(直観)
複製は「1つに見せる」(複製透過性、透過性とスケーラビリティ)が目標だが、コピー間は光速以下でしか同期できない。速さを取れば古い値・ロスト窓、正しさを取れば遅延・停止。リーダーレスにすると受け口は増えるが、今度は順序という単一マシンでは無料だったものを自前で作る羽目になる。どこに難しさを寄せるかの選択です。
⚠️ よくある誤解・落とし穴
- 「複製すれば一貫性は自動」→ 複製は一貫性を難しくする。揃える機構(合意/クォーラム/反エントロピー)が別途要る。
- 「非同期レプリカから読めば速くて正確」→ 複製ラグで古い値。read-your-writes が壊れる(自分の書き込みが見えない)。
- 「リーダーレスは順序を気にしなくてよい」→ 並行衝突の検出・解決が必須。むしろ順序の難しさが顕在化。
- 「同期=全複製待ち」→ 通常は過半数待ち(全部待つと1台の遅延で全体が止まる)。
対応ラボ
なし(概念回)。クォーラムの重なりは クォーラム(R+W>N)、収束は ゴシップ・反エントロピー・故障検出(SWIM) のラボで実証します。
関連
- 重なりで一貫性を作るのが クォーラム(R+W>N)
- リーダー型の合意が Raft
- 衝突解決の理論は PACELC・結果整合性