← 分散システム 一覧

🎓 レベル：基礎　|　重要度：A（必須）

📎 前提：なし（ここが入口）　|　関連：障害モデル（クラッシュ・オミッション・ビザンチン）・CAP定理

要点（BLUF）

• 分散システムとは、独立して故障する複数のコンピュータが、ネットワーク越しに協調して、利用者には1つの一貫したシステムに見えるようにしたもの。
• 単一マシンと決定的に違うのは 「部分故障（partial failure）」：全体が止まるのでなく、一部だけ・しかもどこが壊れたか分からないまま動き続ける。
• だから難しさの本質は3つ：部分故障・通信遅延（と喪失）・大域状態を誰も即時に知り得ないこと。本章以降のすべてはこの3つへの対処です。

問題設定 ── なぜ1台で済まさないのか

1台のサーバには上限があります。性能（CPU・メモリ・I/O）、可用性（壊れたら全停止）、地理（遠いユーザは遅い）。これを超えるために台数を増やすと、3つの利得と引き換えに難しさを買うことになります。

仕組み ── 「1つに見せる」ための層

分散システムは、バラバラのノードの上にミドルウェアを挟み、命名・通信・一貫性・故障処理を肩代わりして「1つのシステム」に見せます。

flowchart TB
    U["利用者（1つのシステムに見える）"] --> M["分散ミドルウェア（命名・通信・一貫性・故障処理）"]
    M --> N1["ノードA（独立に故障する）"]
    M --> N2["ノードB（独立に故障する）"]
    M --> N3["ノードC（独立に故障する）"]
    N1 -.->|"遅延・喪失あり"| N2
    N2 -.->|"遅延・喪失あり"| N3

要するに何か：上の層が「透過性」（透過性とスケーラビリティ）で複雑さを隠し、下では各ノードが勝手に落ちうる。この「隠す」と「勝手に落ちる」の緊張が、分散の難しさそのものです。

仕組み ── 難しさの正体：部分故障

単一マシンのプログラムは「動くか、全部止まるか」のどちらか。分散では第3の状態があります。Bへ送ったリクエストの返事が来ないとき、起きうるのは次のどれかで、送り手には区別がつきません。

sequenceDiagram
    participant A as ノードA
    participant B as ノードB
    A->>B: リクエスト
    Note over A,B: 返事が来ない…原因は4通り
    Note right of B: (1) Bが処理前にクラッシュ
    Note right of B: (2) Bは処理したが応答が喪失
    Note right of B: (3) Bは生きてるが遅いだけ
    Note left of A: (4) 要求自体が届かず喪失

「処理されたのか、されなかったのか」が分からない。これが冪等性（配送保証（at-most-once・at-least-once・exactly-once））や合意（合意問題とFLP不可能性）がいる根本理由です。

正しさの観点 ── 安全性と活性

分散アルゴリズムの正しさは、必ず2つに分けて語ります。本サイトでは全アルゴリズムでこの2軸を明示します。

• 安全性（safety）：「悪いことが決して起きない」。例：2つのノードが同時にリーダーを名乗らない、確定した値が後で覆らない。
• 活性（liveness）：「良いことがいつか起きる」。例：いつかはリーダーが決まる、要求はいつか応答される。

部分故障と非同期性のせいで、両方を同時に完全保証することは一般に不可能（合意問題とFLP不可能性 のFLP）。どちらをどこまで諦めるか、の設計学が分散システムです。

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

• 大域時刻が無い：各ノードの時計はずれる（物理時計とクロック同期（NTP））。「どっちが先に起きたか」すら自明でない（論理時計（Lamportタイムスタンプ））。
• 大域状態を即時に知れない：観測には通信が要り、その間に状態は変わる。スナップショットすら工夫がいる（グローバルスナップショット（Chandy-Lamport））。
• 故障を確実に検知できない：「遅い」と「死んだ」は原理的に区別できない（ゴシップ・反エントロピー・故障検出（SWIM））。

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

• 「ネットワークはたまにしか落ちないから無視できる」→ 分散コンピューティングの誤謬（8つの誤謬） の第一の誤謬。分断は仕様として織り込む。
• 「分散にすれば速くなる」→ 協調・整合のオーバーヘッドで遅くなることも多い。台数は可用性・容量のための投資。
• 「タイムアウトすれば死んだと分かる」→ 分かるのは「一定時間応答が無い」だけ。生きていて遅いだけかもしれない（誤検知）。
• 「強い一貫性はデフォルトで付いてくる」→ 一貫性は一貫性モデルの地図の連続体で、可用性・レイテンシと取引して選ぶもの。

対応ラボ

なし（概念回）。以降の章で論理時計・合意・クォーラムを最小シミュで実証します。

関連

• 踏みやすい前提ミスは 分散コンピューティングの誤謬（8つの誤謬）
• 故障を型で整理するのが 障害モデル（クラッシュ・オミッション・ビザンチン）
• 難しさが一貫性 vs 可用性として定式化されるのが CAP定理

← 第1章 分散システムの基礎 目次