← 分散システム 一覧

🎓 レベル：標準　|　重要度：B（重要）

📎 前提：レプリケーション方式（同期／非同期・リーダー／リーダーレス）　|　関連：CAP定理・クォーラム（R+W>N）

要点（BLUF）

• 分散データストアの設計とは、これまでの全章——一貫性（4章）・合意（5章）・レプリケーション/分割（6章）・信頼性（7章）——を、要件に合わせて1つに束ねること。
• 中心の判断は3つ：一貫性をどこまで強くするか（CP/AP・R/W）、どう分割するか（分割キー）、どう冗長化するか（リーダー/リーダーレス・複製数）。
• 万能解は無い。「このデータに何が必要か」を要件から逆算して選ぶ。具体的な実装（Cassandra・Spanner・Dynamo等）はこの選択の組合せの結晶。境界の先（Spark等の処理基盤）は データエンジニアリング へ。

問題設定 ── 全理論を1つの設計に

理論を個別に学んでも、実際の設計は「全部を同時に決める」作業です。残高を扱うのか、いいね数か。レンジ検索が要るか。何台落ちても動くべきか。これらの要件が、一貫性モデル・複製・分割・信頼性の選択を一意に縛っていきます。

設計フレーム ── 要件から逆算する

flowchart TB
    REQ["要件（正しさ/可用性/遅延/規模/アクセス型）"] --> C{"強整合が必須?"}
    C -->|"はい（残高・在庫・ロック）"| CP["CP・リーダー合意（Raft）・R+W>N"]
    C -->|"いいえ（SNS・計測・カート）"| AP["AP・リーダーレス・結果整合"]
    REQ --> PK["分割キー（同一トランザクションを1パーティションに収める）"]
    REQ --> REP["複製数・配置（地理・耐障害 f 台）"]

設計の直観 ── 代表3アーキの選択

• 強整合KV（etcd/Spanner系）：リーダー合意（Raft）でログを複製、線形化可能。設定・ロック・残高向き。CP・低スループット寄り。
• 高可用ワイドカラム（Cassandra/Dynamo系）：リーダーレス＋クォーラム（クォーラム（R+W>N））、一貫性ハッシュ（一貫性ハッシュ）、ゴシップ（ゴシップ・反エントロピー・故障検出（SWIM））。AP・高スループット・結果整合。
• 新SQL（Spanner/CockroachDB）：パーティション分割＋各シャードをRaft複製＋2PCで横断トランザクション。強整合と水平スケールの両立（代償はレイテンシ・複雑性）。

正しさの観点 ── 全体として破綻しないか

設計レビューの観点を、安全性/活性で整理します。

• 安全性：選んだ一貫性モデルが要件を満たすか（残高にAPを選んでいないか）。クォーラムは R+W>N か。またぎ更新の原子性/補償は正しいか。
• 活性：何台の故障まで読み/書きできるか（N−R・N−W、合意なら過半数生存）。分断の少数派はどう振る舞うか（CPなら停止・APなら縮退）。
• 運用の活性：再試行は冪等＋ジッタか（冪等性と再試行・バックオフ）。リバランスは局所的か（一貫性ハッシュ）。

なぜ分散だと難しいか（直観）

1台のRDBは ACID と単純さを無料でくれます。分散データストアは、スケールと可用性を買う代わりに、一貫性・トランザクション・運用の複雑さを自分で組む。だから「本当に分散が要るか」を最初に問い、要るなら「どのデータにどの強さが必要か」をデータ単位で割り当てる。理論はこの割り当てを誤らないための地図です。

⚠️ よくある誤解・落とし穴

• 「とりあえず強整合・全部レプリケーション」→ 過剰なコスト（遅延・可用性低下）。データごとに必要十分を選ぶ。
• 「1つのDBで全要件を満たす」→ 強整合と高可用は同じ製品で両立しにくい。ポリグロット永続化（用途別に使い分け）が現実解。
• 「分割キーは後で変えられる」→ 再シャーディングは極めて高コスト。アクセスパターンから最初に決める（パーティショニング／シャーディング）。
• 「処理基盤（Spark等）もここで設計」→ 分散処理の実装は データエンジニアリング の領域。ここはストアの理論設計まで。

対応ラボ

なし（総括回）。各構成要素のラボは クォーラム（R+W>N）・一貫性ハッシュ・ゴシップ・反エントロピー・故障検出（SWIM）・冪等性と再試行・バックオフ を参照。

関連

• 一貫性の選択は CAP定理
• 複製と分割の組合せは レプリケーション方式（同期／非同期・リーダー／リーダーレス）
• またぎ更新は 分散トランザクションとSaga

← 第7章 分散トランザクションと信頼性 目次