分散システムの最前線 — 世界規模の設計へ

データセンター1棟の中の分散から、地球全体に広がる分散へ。光速という絶対の壁、合意なしで必ず収束するデータ構造 CRDT、ユーザのそばで応答するエッジ。世界規模のシステムを支える考え方を動かして体感します。

1. 光速という物理限界 — 世界規模のレプリケーション

大陸をまたぐレプリケーションの遅延は、ソフトウェアの工夫では消せません。光ファイバ中の光は約 20万 km/s（真空中の約2/3）でしか進めないため、東京–欧州 約9,400km なら往復 約94ms が理論下限。実測は経路の遠回りや中継機器でさらに 1.5〜2倍 になります。世界に複製を置いて強い一貫性（同期レプリケーション）を求めるほど、この往復が書き込みのたびに応答時間へ直撃します。

下のデモは東京からの書き込みが各大陸へ実距離比の時間で飛ぶ様子です（スローモーション表示）。「多数決で確定」と「全ノードで確定」でコミットまでの時間がどう変わるかを見てください。

3大陸レプリケーション — 書き込みの粒は光速より速く飛べない
距離は大円距離、時間は光ファイバ速度（約20万km/s）から計算した理論下限。多数決（東京自身＋最寄り1台のACK）なら約94ms、全ノード確定なら約109msでコミット。地図上の線は模式図で、実際の最短経路（大円）は太平洋・北極側を通ります。
RTTmin = 2d ⁄ v　（v ≈ 2×105 km/s） d＝大円距離。東京–フランクフルト 9,360km → 往復 約94ms。これはハードウェアの進歩では縮まない物理限界
POINT — 光速は「設計の第一制約」 世界規模の設計は、機能ではなく地理とRTTの表から始まる。強い一貫性を求めるほど大陸間往復の回数が増え、遅延は倍々に効く。だから最前線のシステムは「どのデータをどの地域に置き、どこまでの一貫性で我慢するか」をデータごとに選ぶ。6章の一貫性モデル、8章のCAPの選択が、ここで地球サイズの現実になる。

2. 合意なしで収束する — CRDT（G-Counter）

大陸間で毎回合意（9章のRaftのような多数決）を取れば一貫性は保てますが、書き込みのたびに約100msを支払うことになります。逆転の発想が CRDT（Conflict-free Replicated Data Type）。「マージ操作が可換・結合的・冪等」になるようデータ構造そのものを設計し、各ノードがローカルで即座に更新→あとで交換すれば必ず同じ状態に収束することを数学的に保証します。

最小の例が G-Counter（増加専用カウンタ）。各ノードは「自分の分」だけを増やし、値は全ノード分の和。マージは成分ごとの max なので、どの順で何回混ぜても結果は同じです。

G-Counter — 並行に増やしても、混ぜれば必ず同じ値になる
同期せずに両ノードで +1 を重ねると値は一時的にズレますが、「同期」で互いの状態を交換し成分ごとの max を取ると、どちらも必ず同じ合計値になります。自動デモをONにするとランダムな更新と同期を繰り返します。
value = Σi ci　／　merge(x, y)i = max(xi, yi) ノード i は自分の成分 ci だけを増やす。max は可換・結合的・冪等 → 交換の順序や重複によらず同じ状態へ収束する
POINT — 強い結果整合性（Strong Eventual Consistency） CRDTの保証は「同じ更新の集合を受け取った複製は、受け取った順序や回数によらず同じ状態になる」こと。6章の結果整合性が「いつかは揃う（揃い方は実装次第）」だったのに対し、CRDTは揃うことが構造から証明されている。合意も調整も待たずにローカル更新できるのが最大の武器。

3. 追加と削除が競合したら — CRDTセット

カウンタの次は集合。買い物カゴを2拠点で複製していて、Aが🍎を削除、同時にBが🍎を追加したら、マージ後はどうなるべきでしょうか。単純な「追加集合と削除集合」（2P-Set）では一度削除した要素は二度と戻せません。OR-Set は追加のたびに一意なタグを付け、削除は「その時点で見えていたタグ」だけに墓石を立てます。並行して行われた追加は削除側から見えていないタグを持つため、マージ後も生き残る — 追加が勝つ（add-wins）という一貫したルールで矛盾なく収束します。

OR-Set — 並行の追加と削除がマージで矛盾なく収束する
試してみよう: ①同期 → ②Aで削除・Bで追加（同期せずに両方）→ ③同期。Bの追加タグはAの削除から「見えていなかった」ので生き残り、両ノードとも🍎あり（add-wins）に収束します。タグ＝追加ごとの一意な印、打ち消し線＝墓石。
注意 — CRDTは「何でも解決する魔法」ではない CRDTが保証するのは収束だけで、アプリの不変条件は守ってくれない。「在庫を負にしない」「ユーザ名は一意」のような全体の制約は、並行更新を無条件に受け入れるCRDTでは原理的に保証できず、そこは合意（9章）やトランザクション（10章）の出番。カウンタ・集合・共同編集テキストのように「衝突をそもそも起きない構造に落とせる」データにこそ効く道具である。

4. ユーザのそばで処理する — エッジコンピューティング

光速の壁を「越える」ことはできませんが、「近づく」ことはできます。中央のデータセンター1か所にすべてを置く代わりに、世界中の拠点（エッジ）に処理とデータを分散すれば、各ユーザの往復距離が縮まり、応答時間の分布全体が改善します。CDNの静的配信から始まったこの流れは、いまやエッジでのコード実行・エッジDB・そしてCRDTと組み合わせた書き込み可能なエッジへと進んでいます。

中央一極 vs エッジ分散 — 世界のユーザの応答時間ヒストグラム
点＝世界各地のユーザ（緑<60ms／橙<150ms／赤≥150ms）。エッジ分散に切り替えると遠方ユーザの往復距離が縮み、ヒストグラムの山が左（速い側）へ寄って中央値・p95が改善します。3つ目のボタンは本カテゴリ12章の概念関係マップです。

5. まとめ — 分散システム12章の地図

一歩先へ — 誤差保証付き時計と local-first グローバル分散DBの一部は、原子時計とGPSで「現在時刻の誤差幅」を保証し、その幅だけ待ってからコミットすることで世界規模の直列化可能性（外部一貫性）を実現している — 5章の「時計はずれる」問題への物理側からの回答だ。もう一方の潮流が local-first ソフトウェア: CRDTを端末側に置き、オフラインでも即座に編集→ネット復帰時に自動マージする設計で、共同編集ツールやメモアプリで実用化が進む。中央集権とエッジ・端末分散のあいだで、データの置き場所は今も動き続けている。