CAP定理とは？分断時の一貫性と可用性を整理【DS検定】

まず結論

CAP定理とは、分散システムでネットワーク分断が起きたとき、一貫性（Consistency）と可用性（Availability）の両方を同時に完全には保証できないという原則です。

DS検定では、単に「3つから2つを選ぶ」と覚えるより、次のように判断します。

分断が起きたら、Cを優先するか、Aを優先するか

分散システムでは分断耐性Pを無視しにくいため、実際の議論は主にCPかAPかになります。

直感的な説明

複数サーバーに同じデータを保存している状況を考えます。

サーバー間の通信が切れたとき、片方のサーバーだけが更新を受け付けると、データが一時的に食い違う可能性があります。

このとき、設計には大きく2つの方向があります。

Cを優先：正しい最新データを確認できないなら、一部の処理を拒否する
Aを優先：多少の不一致を許してでも、各サーバーが応答を続ける

CAP定理は、通常時の性能比較ではなく、通信分断という異常時の選択を説明します。

定義・仕組み

要素	意味
Consistency	すべてのクライアントが同じ最新データを読めること
Availability	正常に動作しているノードへの各リクエストが応答を得ること
Partition tolerance	ノード間通信が分断されてもシステムが動作を続けること

CP型

分断時に一貫性を優先します。

最新状態を確認できないノードでは、更新や読み取りを拒否する場合があります。

AP型

分断時に可用性を優先します。

各ノードが応答を続ける代わりに、一時的なデータ不一致を許します。通信復旧後に同期し、最終的に整合させる設計がよく使われます。

CA型

一貫性と可用性を両立しますが、ネットワーク分断を前提にしません。単一ノードや分断を考えなくてよい環境では考えられますが、大規模な分散システムではPが重要です。

どんな場面で使う？

金融・在庫管理

残高や在庫の不一致が大きな問題になるため、分断時にCを優先する設計が選ばれやすくなります。

SNS・ログ収集

一時的な表示差よりサービス継続を重視する場合、Aを優先する設計が選ばれやすくなります。

ただし、金融なら必ずCP、SNSなら必ずAPという固定ルールではありません。機能ごとに要件が異なります。

NoSQL・分散データベース

CAP定理はNoSQL専用ではありませんが、NoSQL製品の設計思想を説明する場面でよく使われます。

よくある誤解・混同

常に3つから2つを選ぶ

単純化しすぎです。重要なのは、分断が起きたときにCとAを同時に完全保証できないことです。

Availability＝高速応答

異なります。CAPのAvailabilityは、各リクエストが応答を得る性質です。応答速度の速さそのものではありません。

CAPのConsistency＝ACIDのConsistency

異なります。

用語	意味
CAPのConsistency	複数ノードから同じ最新値が見える
ACIDのConsistency	トランザクション前後でDBの制約・整合性が保たれる

APは不整合を放置する

誤りです。AP型でも、通信回復後にデータを同期して最終的な整合性を目指します。

CPはシステム全体を必ず停止する

誤りです。一貫性を保証できない一部の操作やノードを利用不可にする場合があり、必ず全停止するとは限りません。

CAPとPACELC

CAPは分断時のCとAの選択を扱います。

PACELCはさらに、分断がない通常時でも、遅延（Latency）と一貫性（Consistency）のトレードオフがあると整理します。

Pが起きたらAかC
Else（通常時）はLかC

という考え方です。

まとめ（試験直前用）

CAP定理は分散システムの原則
分断時にCとAを同時に完全保証できない
CPは一貫性、APは可用性を優先
Availabilityは高速性ではなく応答を返す性質
CAPのConsistencyとACIDのConsistencyは意味が異なる
APでも最終的な同期を目指す
PACELCは通常時の遅延と一貫性も扱う

対応スキル項目（データエンジニアリング力シート）

データ蓄積
分散技術
分散システム設計のトレードオフを説明できる

🔗 関連記事

🏠 DS検定トップに戻る