← 分散システム 一覧

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

📎 前提：分散システムとは・なぜ難しいか　|　関連：パーティショニング／シャーディング・CAP定理

要点（BLUF）

• 透過性（transparency）＝分散していることを利用者・開発者から隠す設計目標。アクセス・位置・複製・故障など複数の種類がある。
• スケーラビリティ＝負荷・規模・地理が増えても性能/可用性を保てる性質。垂直（1台を強く）には上限があり、分散の主役は水平（台数を増やす）。
• 両者は緊張する：完全な透過性（特に「故障を完全に隠す」）はコストが高く、CAP（CAP定理）の制約で隠しきれない。だから「どこを見せ、どこを隠すか」を選ぶ。

問題設定 ── 隠すべきか、見せるべきか

分散システムの設計目標は大きく2つ：**複雑さを隠す（透過性）**と、規模を伸ばす（スケーラビリティ）。理想は「ユーザは1台に見え、裏は何千台」。だが隠しすぎると、遅延や部分故障という現実が漏れたとき対処できません。

モデル ── 透過性の種類

van Steen/Tanenbaum の分類が定番です。実務で特に効くものを挙げます。

仕組みの直観 ── なぜ「故障透過性」は完全には無理か

「故障を完全に隠す」とは、壊れても利用者が一切気づかない、ということ。だが 分散システムとは・なぜ難しいか の通り、「遅い」と「死んだ」は区別できない。完全に隠そうとすると、無限に待つ（活性を失う）か、誤って生きたノードを切り離す（安全性を損なう）。CAP（CAP定理）はこの限界の定式化です。だから現実には「ほぼ隠す＋たまに見せる（縮退運転・エラー）」に落ち着きます。

モデル ── スケーラビリティの2軸とボトルネック

flowchart LR
    V["垂直スケール（1台を強化）"] -->|"上限・高コスト・SPOF"| LIMIT["頭打ち"]
    H["水平スケール（台数を足す）"] -->|"理論上は線形に近い"| GROW["伸びる"]
    H -.->|"ただし阻害要因あり"| B["ボトルネック"]

水平スケールを阻む典型は3つ：

• 集中点：単一の調整役（中央ロック・単一マスタ）が詰まる → 分散調整・パーティショニング／シャーディング。
• 共有状態の同期コスト：全台で強一貫を保つと調整が増え、台数を増やすほど遅くなる（CAP定理 の C 側）。
• 通信の集中（ファンイン/アウト）：1ノードに全員が問い合わせる設計 → ゴシップ（ゴシップ・反エントロピー・故障検出（SWIM））で分散。

スケール則の直観として、逐次的・集中的な部分が残るほど台数効果は頭打ちになります（アムダール的限界。単一マシン版は 性能の評価とアムダールの法則（コンピュータ基礎）参照）。

正しさ/トレードオフの観点

• 透過性を上げる ↔ 性能・可観測性が下がる（隠れた遅延・隠れた再送）。
• 強一貫の複製透過性 ↔ 可用性・レイテンシ（PACELC・結果整合性）。
• 水平スケール ↔ 一貫性・トランザクション境界（分散トランザクションとSaga）。

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

• 「透過性は高いほど良い」→ 漏れる抽象（leaky abstraction）。隠れた遠隔呼び出しが遅延を爆発させる。遠隔は遠隔と分かる設計が安全なことも。
• 「水平スケールすれば無限に伸びる」→ 集中点・共有状態が1つでもあると、そこが律速。
• 「スケーラブル＝高性能」→ 別物。スケーラブルは「増やせば対応できる」であって、1台の速さではない。
• 「複製透過性があれば一貫性も自動」→ コピーが複数ある事実を隠せても、コピー間のズレ（PACELC・結果整合性）は別途設計が要る。

対応ラボ

なし（概念回）。スケールの要となる再配置最小化は 一貫性ハッシュ のラボで実証します。

関連

• 隠せない限界の定式化が CAP定理
• 水平スケールの実装が パーティショニング／シャーディング
• リモート呼び出しの透過性が RPCとRMI

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