【データベース】分散システムの限界を示す！CAP定理（CAP Theorem）とは

分散データベースやNoSQLの選定・設計において、避けて通れない非常に重要な理論が「CAP定理（CAP Theorem）」である。
（※一般に「CPA」ではなく「CAP」と呼ばれることが多い概念だ）

CAP定理とは、「分散システムにおいて『一貫性』『可用性』『分断耐性』の3つの性質を、同時にすべて（3つとも）満たすことはできない」というトレードオフの定理を指す。

1. CAP定理の3つの構成要素

分散システムが備えるべき3つの評価軸の定義は以下の通りである。

C：Consistency（一貫性）
システムにあるオペレーションを行った後、どのノード（サーバー）にアクセスしても常に最新で同じデータ（一貫性）が保たれている性質。
分散システムで一貫性を担保するためには、あるノードでデータ更新（Update）が発生した場合、他のすべてのノードにもその結果を即座に同期・反映しなければならない。
A：Availability（可用性）
システムを構成するノードの一部が故障（ダウン）しても、システム全体としてはレスポンスを返し続け、正常に稼働し続けなければならない性質。
エラーを返さず、常にすべての正常なノードが読み書きの要求に応答できることが求められる。
P：Partition Tolerance（分断耐性）
ノード間を結ぶネットワークが障害等で分断され、通信が一時的に不通・切断されても、システムとしては停止せずに稼働し続けなければならない性質。

2. なぜ3つ同時に満たせないのか？

ネットワーク分断（P）が発生した状況を想像してみよう。ノードAとノードBの間で通信ができない状態である。

このとき、ノードAに書き込みリクエストが届いた場合、選択肢は2つしかない。

選択肢①：一貫性（C）を優先する ➔ ノードBへデータ更新を同期できないため、エラーを返して書き込みを拒否する。（可用性 A が犠牲になる）
選択肢②：可用性（A）を優先する ➔ ノードAだけで書き込みを完了させ、応答を返す。しかしノードBのデータは古いままになる。（一貫性 C が犠牲になる）

このように、現実の分散環境において「分断（P）」の発生を完全に回避することは不可能なため、実質的に分散システムは「CP型」か「AP型」のどちらかを選択（トレードオフ）せざるを得ないのである。

3. NoSQLにおけるCAPによる分類

近代のNoSQLデータベースは、この3つのうち「どれを重視し、どれを妥協するか」という設計思想（トレードオフ）によって、大きく3つのタイプに分類することができる。

【CAP特性によるデータベース分類】

■ CP型（一貫性 ＋ 分断耐性）

・特徴：ネットワーク分断時はエラーを返してでもデータ不整合を防ぐ。

・代表例：HBase, MongoDB, Redis, Accumulo

・用途：金融決済や在庫管理など、絶対的なデータ整合性が求められるシステム。

■ AP型（可用性 ＋ 分断耐性）

・特徴：データ整合性が一時的に崩れても、止まらずに読み書きに応答する（※結果的一貫性を重視）。

・代表例：Apache Cassandra, Amazon DynamoDB, CouchDB

・用途：SNSのタイムラインやアクセスログの収集など、止まらないことが最優先のシステム。

■ CA型（一貫性 ＋ 可用性）

・特徴：ネットワーク分断が発生しない単一ノード（非分散環境）を前提とするモデル。

・代表例：従来の単一構成RDBMS（PostgreSQL, MySQL, Oracle DB など）

・注意：分散環境においてはネットワーク障害（P）の回避が困難なため、実質の選択肢としては「CP」か「AP」の2択となる。

4. まとめ

「すべての面で完璧なデータベース」は存在しない。システム要件に応じて、「一貫性（C）」を絶対に譲れないのか、あるいは「高可用性（A）」を取って一時的な不整合（Eventual Consistency：結果的一貫性）を許容するのかを見極めることが、適切なDB選定の第一歩となる。

【CAP定理から考えるデータベース選定の要点】

✔ 金融・決済・アカウント管理など、1円・1件のズレも許されない ➔ CP型（または伝統的RDBMS）

✔ ログ収集・SNS・カートの一時保持など、止まらないことが最優先 ➔ AP型

✔ AP型を採用する場合は「結果的一貫性（最終的にデータが合えばOK）」の思想を許容できるか確認する