分散システムの問題

ネットワークは信頼できない

分散システムでは、ノード間の通信はいつでも失敗する可能性があります。 パケットの遅延・順序逆転・消失は例外ではなく常態であり、部分障害（partial failure） が起きることを前提に設計する必要があります。 『データ指向アプリケーションデザイン』第 8 章では、この「信頼できないネットワーク」のモデルを出発点としています。

クロックは信頼できない

各ノードのローカルクロックは微妙にずれており、クロックスキューが発生します。 NTP で同期しても数ミリ秒〜数百ミリ秒の誤差が残るため、「イベント A はイベント B より先に起きた」という判定にクロックを使うのは危険です。 分散環境で因果順序を正しく扱うには、論理クロック（Lamport タイムスタンプ、ベクタークロック） を使います。

ビザンチン障害

ビザンチン障害（Byzantine fault） は、ノードが任意の誤った動作（嘘のレスポンスを返す、データを改ざんするなど）をする障害モデルです。 通常のデータセンター環境ではビザンチン耐性は不要とされますが、ブロックチェーンのような信頼できない参加者がいるシステムでは必須です。 大多数のバックエンドシステムでは「クラッシュ障害モデル」（ノードは停止するか正しく動作する）を前提とします。

合意アルゴリズム

複数のノードがひとつの値に合意する問題を合意（consensus） と呼びます。 第 9 章では代表的なアルゴリズムとして以下が紹介されています。

2PC はコーディネータ障害時に参加者がブロックされるため、可用性が犠牲になります。 Raft や Paxos はリーダー障害時に自動で再選出を行うため、より耐障害性が高い構成です。

CAP 定理の限界

CAP 定理は「一貫性（Consistency）・可用性（Availability）・分断耐性（Partition tolerance）の 3 つすべてを同時に満たすことはできない」という命題です。 しかし実務では、ネットワーク分断は避けられないため実質「C か A を選ぶ」という 2 択になります。 現代の分散データベース設計では、CAP よりも「どのレベルの一貫性をどのレイテンシで提供するか」という連続的なトレードオフ（PACELC モデルなど）で議論されることが多くなっています。