CAP定理とPACELC定理

1. ネットワーク分断（Partition Tolerance）とは

分散システムでは、複数の物理サーバーがネットワークのスイッチやケーブルを介して相互に通信し合っています。しかし、通信機器の故障、ノードの急な再起動、ネットワークスイッチの輻輳などにより、一部のノード同士が一時的に通信できなくなる現象が発生します。これをネットワーク分断（Partition）と呼びます。

どれほど高価なインフラを構築しても、長時間の稼働を前提とすればネットワーク分断の発生確率をゼロにすることは物理的に不可能です。そのため、分散システムを設計する際には、最初から「分断は発生するもの」として前提を置かなければなりません（これが分断耐性: P です）。

2. 古典的な限界定理：CAP定理

2000年にエリック・ブリュワーが提唱したCAP定理（Brewer's CAP Theorem）は、分散システムにおいて次の3つの特性のうち、同時に満たすことができるのは最大でも2つまでであるという定理です。

• 一貫性（Consistency: C）：
  すべてのクライアントが、どのノードからデータを読み出しても、常に「最も新しく書き込まれたデータ」を同時に受け取れる特性。
• 可用性（Availability: A）：
  クラッシュしていない任意のノードが、クライアントからの読み書き要求に対してエラーを返さず、必ず正常なレスポンスを返す特性（古いデータを返しても構わない）。
• 分断耐性（Partition tolerance: P）：
  一部のネットワーク分断（ノード間の通信遮断）が発生しても、システム全体が動作を維持する特性。

前述の通り、現実世界のシステムでは「分断（P）」の発生を避けることはできません。したがって、実質的な選択肢は「CP（分断時の一貫性重視）」か「AP（分断時の可用性重視）」のどちらか一方を選択することになります。

3. 現代的な拡張：PACELC定理

CAP定理は分散システムの設計に多大な影響を与えましたが、「ネットワークが分断（P）されている特殊な状況下」のことしか説明していないという限界がありました。 そこで2012年、ダニエル・アバディによって提唱されたのがPACELC定理（パセルク定理）です。

PACELC定理は、システムを次のようにモデル化してトレードオフを記述します。

If P (Partition) ➔ choose A or C
Else (平常時) ➔ choose L (Latency) or C (Consistency)

つまり、「もしネットワークがP（分断）されたら、A（可用性）とC（一貫性）のどちらを取るか。Else（そうでない平常時）は、応答時間（Latency）とデータの一貫性（Consistency）のどちらを優先するか」という二重のトレードオフを示しています。

この分類により、分散データベースは以下の4つの象限に分類されます。

タイプ	分断時 (P)	平常時 (E)	データベースの傾向と代表例
PC / EC	一貫性 (C)	一貫性 (C)	平常時も複数ノードの同期を待つため遅いが、データは常に正確。金融系。RDB、Bigtableなど。
PA / EL	可用性 (A)	レイテンシ (L)	分断時も動き、平常時も同期を待たず即答する極めて高速な設計。DynamoDB、Cassandraなど。
PC / EL	一貫性 (C)	レイテンシ (L)	分断時はエラーを吐くが、平常時は高速。MongoDBなど。
PA / EC	可用性 (A)	一貫性 (C)	（理論的には可能だが、この設定を取る実用的なデータベースは稀）。

このように、データベースを評価する際、「平常時のレスポンス時間とデータの同期度合い」という実稼働に即した尺度を導入することで、システムの設計思想をより深く理解することが可能になります。

次節では、一貫性（C）の厳しさのレベルの定義と、複数のノードでデータを同期するレプリケーションの様々な仕組みについて学びます。