CAP定理 — 分断のとき、一貫性か可用性か

データを複数のサーバー（レプリカ）にコピーして持つと、1台壊れても大丈夫…のはずですが、サーバー同士をつなぐ回線が切れたらどうなるでしょう。これをネットワーク分断（Partition）と呼びます。分散システムでは、分断は「いつか必ず起きる」ものとして扱います。

そのとき、あなたは究極の二択を迫られます。「古いかもしれないが応答を返す（可用性）」か、「正しさを守るため応答を拒否する（一貫性）」か。分断中は両方は取れない——これが CAP定理です。下の図1で、回線を切ってから書き込んでみてください。

分断が起きて初めて、選択を迫られる

回線がつながっている平常時は、CもAも両立できます。問題は分断中です。図1で CP（一貫性優先）のまま分断して書き込むと、もう片方に複製できないので書き込みを拒否します。データは決して食い違いませんが、その間サービスは「使えない」状態になります（可用性を犠牲）。銀行残高のように、間違った値を見せるくらいなら止まるべき、という場面向きです。

一方 AP（可用性優先）で分断中に書き込むと、各レプリカは自分だけで受け付けます。サービスは止まりませんが、A と B の値が食い違います（一貫性を犠牲）。そして回線が復旧すると、お互いの更新をすり合わせて最終的に同じ値へ収束します。これが結果整合性（Eventual Consistency）です。「いいね数」が一瞬ズレても、しばらくすれば揃えばよい——SNSやカートのような場面に向きます。図1で AP のまま分断→両方に別々の書き込み→再接続、と進めて収束を確かめてください。

まとめ

CAP定理は、「ネットワーク分断が起きたら、一貫性(C)と可用性(A)のどちらかしか選べない」という分散システムの宿命です。図1で見たように、CPは正しさのために止まり、APは止まらない代わりに値が食い違い、後で結果整合性で揃えます。どちらが正解かはアプリ次第——「間違った答え」と「答えないこと」、どちらがマシかで決めるのです。