CAP 定理

分散システムで一貫性、可用性、分断耐性の 3 つを同時に満たすことはできないという定理

分散システムデータベース

CAP 定理とは

CAP 定理は、Eric Brewer が 2000 年に提唱した定理で、分散システムはネットワーク分断 (Partition) が発生した場合、一貫性 (Consistency) と可用性 (Availability) を同時に満たすことができないとする。

3 つの特性

3 つの特性を以下にまとめる。

特性説明
Consistency (一貫性)全ノードが同じデータを返す
Availability (可用性)全リクエストに応答する
Partition Tolerance (分断耐性)ネットワーク分断に耐える

ネットワーク分断時の選択

ネットワーク分断が発生すると、CP システムは一貫性を優先して書き込みを拒否し、AP システムは可用性を優先して古いデータでも応答を返す。どちらを選ぶかはアプリケーションの要件次第で、金融系は CP、SNS のタイムラインは AP を選ぶことが多い。

ノード A ←×→ ノード B  (ネットワーク分断)

CP (一貫性 + 分断耐性):
  ノード A: 書き込みを拒否 (一貫性を優先)
  → 可用性を犠牲

AP (可用性 + 分断耐性):
  ノード A: 古いデータでも応答 (可用性を優先)
  → 一貫性を犠牲

AWS サービスの分類

AWS サービスの分類を以下に示す。

サービス分類説明
DynamoDB (デフォルト)AP結果整合性、高可用性
DynamoDB (ConsistentRead)CP強い整合性
AuroraCP同期レプリケーション
ElastiCache (Redis)AP非同期レプリケーション
S3AP結果整合性 (2020 年以降は強い整合性)

DynamoDB の整合性モデル

DynamoDB の整合性モデルのコード例を示す。

// AP: 結果整合性 (デフォルト、高速)
const item = await db.get({
  TableName: 'users',
  Key: { id: '123' },
});

// CP: 強い整合性 (やや遅い)
const item = await db.get({
  TableName: 'users',
  Key: { id: '123' },
  ConsistentRead: true,
});

PACELC 定理 (CAP の拡張)

PACELC 定理 (CAP の拡張) を図で示す。

ネットワーク分断時 (P):
  A (可用性) or C (一貫性) を選択

正常時 (E = Else):
  L (レイテンシ) or C (一貫性) を選択

DynamoDB は PA/EL (分断時は可用性、正常時はレイテンシを優先)。

実務での判断

実務での判断を以下にまとめる。

ケース推奨
EC サイトの商品表示AP (古いデータでも表示)
在庫の減算CP (正確な在庫数が必要)
ユーザーのプロフィールAP (結果整合性で十分)
金融取引CP (強い整合性が必須)

CAP 定理を扱う関連書籍も多い。

この記事は役に立ちましたか?

関連用語

関連する記事