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 強い整合性
Aurora CP 同期レプリケーション
ElastiCache (Redis) AP 非同期レプリケーション
S3 AP 結果整合性 (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 定理を扱う関連書籍も多い。

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

関連用語

関連する記事