CAP 定理
分散データベースは一貫性(C)・可用性(A)・分断耐性(P)を同時に全て満たせない、という指針です。ネットワーク分断時に C と A のどちらを取るかを解説します。
- 1.CAP 定理＝分散システムは 一貫性(C)・可用性(A)・分断耐性(P) の3つを同時に全ては満たせない。
- 2.ネットワークは必ず分断(P)しうるので、分散DBは実質 P を前提に、分断中は C か A のどちらかを選ぶ。
- 3.CP は“正しさ優先で一部応答停止”、AP は“応答優先で一時的に古い値も許容”。用途で選ぶ。
CAP 定理とは
複数台のサーバーにデータを分散して持つシステムでは、次の3つの性質を 同時に全部 は保証できない、という指針が CAP 定理 です。
- 一貫性 (Consistency): どのサーバーに読みに行っても、常に最新の同じ値が返る。
- 可用性 (Availability): 生きているサーバーは、必ず（エラーで突き放さず）応答を返す。
- 分断耐性 (Partition tolerance): ネットワークが分断され、サーバー間の通信が一部途切れても動き続ける。
ここでの C は ACID の一貫性とは意味が異なり、「複製したデータが全ノードで一致して見える」ことを指す点に注意してください。
なぜ「3つ同時」が無理なのか
ポイントは 分断(P)は選べない ことです。物理的なネットワークである以上、ケーブル障害や遅延でサーバー間の通信が途切れる事態は必ず起こりえます。分散DBはこれに耐えるしかないので、Pは事実上の前提になります。
そのうえで、いざ分断が起きた瞬間に何が起こるか考えます。サーバー X と Y が通信できなくなったとき、X に届いた書き込みを Y は知りません。このとき選べるのは2つだけです。
- C を取る: Y は「正しい最新値を返せない」ので、エラーを返すか応答を止める → 可用性を犠牲。
- A を取る: Y は手元の（少し古いかもしれない）値を返す → 一貫性を犠牲。
つまり 分断中は C と A のどちらかを諦めるしかない――これが CAP 定理の実務的な核心です。
CP と AP
分断時にどちらを取るかで、分散システムは大きく2タイプに分かれます。
| 観点 | CP（一貫性優先） | AP（可用性優先） |
|---|---|---|
| 分断時の挙動 | 正しい値を返せないなら応答を止める | 古いかもしれない値でも応答する |
| 諦めるもの | 可用性（一部停止） | 一貫性（一時的にズレる） |
| 向く用途 | 残高・在庫など正しさが絶対 | SNS・カートなど止めたくない |
| 典型例 | 強整合な構成のDB | 結果整合性のDB |
「P を捨てて C と A を取る（CA）」は、分断が起きない単一ノードや障害ゼロの理想環境でしか成立しません。複数台に分散する以上、分断は避けられないので、現実の選択は事実上 CP か AP の二択になります。
結果整合性という落としどころ
AP 型でよく使われる考え方が 結果整合性 (eventual consistency) です。「今この瞬間は値がズレているかもしれないが、通信が回復すれば、いずれ全ノードで同じ値に揃う」という妥協です。
「投稿した直後、別の人にはまだ見えない」といった挙動はこれにあたります。多くのWebサービスは、可用性のためにこの“一瞬の古さ”を受け入れています。
実務での向き合い方
- CAP は「3つから2つを選ぶ」より「分断時に C と A のどちらに倒すか」という指針として捉えると実用的です。
- 1つのシステム内でも、処理ごとに方針を変えるのが現実的です（決済は CP 寄り、表示系は AP 寄り）。
分断が起きていない平常時は、C も A も満たせているように見えます。CAP が牙をむくのは障害の瞬間だけです。だからこそ「分断したときどう振る舞うか」を設計時に決めておくことが大切で、障害が起きてから慌てないための備えになります。
CAP 定理は万能の答えではなく、分散DBを選ぶ・設計するときの判断軸です。「このデータは止まっても正しさを守りたいか、多少古くても止めたくないか」を問い続けることが、適切な選択につながります。
データベース Article
CAP 定理を実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
CAP定理
比較で見る軸
難易度: intermediate / カテゴリ: データベース / タグ数: 4
導入後に効く点
ネットワークは必ず分断(P)しうるので、分散DBは実質 P を前提に、分断中は C か A のどちらかを選ぶ。
先に潰すリスク
用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。
- 難易度
- intermediate
- カテゴリ
- データベース
- タグ数
- 4
判断チェックリスト
- 自社の用途が「CAP定理 / 分散システム」に近いか確認する。
- 強みである「CAP 定理＝分散システムは 一貫性(C)・可用性(A)・分断耐性(P) の3つを同時に全ては満たせない。」が本当に評価軸になるか確認する。
- 注意点の「用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。