CAP定理と分散データベース

CAP定理とは

CAP定理は、複数のサーバーに分散したデータベースが次の3つを同時にすべて満たすことはできないという原則です。

C: Consistency(一貫性)— どのサーバーに聞いても常に最新の同じ値が返る
A: Availability(可用性)— 一部が壊れていても必ず応答を返す
P: Partition tolerance(分断耐性)— サーバー間の通信が途切れても動き続ける

ネットワークの分断はいつか必ず起きるため、分散システムでは P は捨てられません。したがって現実の選択は「分断が起きたとき、C と A のどちらを優先するか」という二択になります。

CP型とAP型

	CP型(一貫性優先)	AP型(可用性優先)
分断時の動き	最新か確認できない要求はエラーにする	古い値でもとにかく応答を返す
利用者から見ると	「今は使えません」と言われる	使えるが情報が少し古いことがある
向く用途	残高・在庫・決済	SNSのタイムライン、閲覧数、レコメンド

お金を扱うシステムで古い残高を返すのは致命的なので CP型を、多少古くても表示を止めたくないサービスでは AP型を選びます。[[NoSQL]] のデータベースにはどちらの方針の製品もあり、設定で切り替えられるものもあります。

結果整合性

AP型で使われる考え方が結果整合性(eventual consistency)です。書き込み直後は各サーバーの値がばらつくものの、時間が経てば最終的にすべて同じ値に収束することを保証します。

[[レプリケーション]] で複製を作る構成では、複製先への反映に遅れ(レプリケーションラグ)が生じます。「投稿した直後に自分のタイムラインに出てこない」といった現象は、この遅れが表に出たものです。

一方、[[トランザクションとACID]] が前提とする厳密な一貫性は「書いた瞬間から誰が読んでも同じ」を求めます。分散環境ではこの保証にコストがかかることを理解しておきましょう。

実務での受け止め方

CAP定理は「常に3つのうち2つしか選べない」ではなく、分断が起きている間の振る舞いの選択と理解するのが正確です
平常時は一貫性も可用性も両立できる。設計で決めるのは「異常時にどう振る舞うか」
[[シャーディングとパーティショニング]] でデータを分割する場合も、複数ノードにまたがる更新をどう扱うかで同じ悩みに突き当たります(アプリケーション側でつなぐ手段は [[分散トランザクションとSaga]])

初学者向けポイント

「銀行なら C、SNSなら A」で当たりをつけると覚えやすい
業務要件として「どのくらい古いデータなら許容できるか」を先に決めると設計が進む
可用性の確保は [[高可用性設計]] の一部でもある — 冗長化と整合性はセットで考える

関連技術とのつながり

[[NoSQL]] — CP型・AP型の方針の違いが製品選定の軸になる
[[レプリケーション]] — 複製の遅れが結果整合性として表面化する
[[シャーディングとパーティショニング]] — 分割されたデータをまたぐ更新で同じ課題が生じる
[[トランザクションとACID]] — 厳密な一貫性を求める従来型の考え方との対比
[[高可用性設計]] — 可用性を取る側の具体的な実現手段

Q: CAP定理の3要素の組み合わせとして正しいのはどれ?
- [x] 一貫性・可用性・分断耐性
- [ ] 容量・可用性・暗号化
- [ ] 一貫性・圧縮率・速度
解説: Consistency(一貫性)、Availability(可用性)、Partition tolerance(分断耐性)の3つです。

Q: 分散データベースで分断耐性(P)を捨てられないとされるのはなぜ?
- [ ] 法律で義務づけられているから
- [x] サーバー間のネットワーク分断はいつか必ず起きるから
- [ ] 性能が3倍になるから
解説: 分断は避けられない前提なので、現実の選択は分断時に C と A のどちらを優先するかになります。

Q: 結果整合性の説明として正しいのはどれ?
- [ ] 書き込みが完了した瞬間から全サーバーが必ず同じ値を返す
- [x] 一時的にばらつくが、時間が経てば最終的に同じ値に収束する
- [ ] データが二度と更新されない状態
解説: AP型で採られる考え方で、複製の反映遅れを許容しつつ最終的な一致を保証します。