CAP定理とは？画像多めで解説！

CAP定理は、分散システムでよく出てくる考え方だよ。
簡単に言うと、

分散システムでは、C・A・Pの3つを同時に完璧には満たせない

という考え方。

それぞれ、こういう意味だよ。

ひとつずつ見ていこうね。

分散システムは、複数のコンピュータが協力して1つのサービスを動かす仕組みだよ。

そう。
たとえば、ネットショップやSNSみたいな大きなサービスは、1台だけで動かすと大変だよね。

だから、複数のサーバーで役割を分けたり、同じデータを複数の場所に持ったりする。

サーバーA
サーバーB
サーバーC
↓
みんなで1つのサービスを動かす

それじゃあ一つ一つ見ていこうか。まずCの一貫性だね。

一貫性は、簡単に言うと、
どのサーバーを見ても同じ最新データが見えることだよ。

そう。
たとえば、銀行口座の残高で考えると分かりやすい。

たとえば残高が10,000円あって、5,000円引き出したら、残高は5,000円になるよね。

更新前：10,000円
更新後：5,000円

一貫性が高いシステムでは、どのサーバーに問い合わせても、ちゃんと5,000円と表示される。

そう。それを防ぐのが一貫性。

可用性は、簡単に言うと、
いつでもちゃんと応答してくれることだよ。

近いね。
ユーザーがリクエストしたときに、

「今は無理です」

ではなく、何らかの返事を返せる状態。

そう。
可用性が高いシステムは、多少トラブルがあってもサービスを続けようとする。

分断耐性は、
分断耐性は、サーバー同士の通信が切れる可能性を前提にして、その状態でもシステムとして破綻しないように設計する考え方だよ。

たとえば、東京のサーバーと大阪のサーバーがあるとする。

東京サーバー  ←通信→  大阪サーバー

でも、ネットワーク障害で一時的に通信できなくなることがある。

東京サーバー  ×通信不可×  大阪サーバー

この状態が ネットワーク分断。

そう。
このときにもシステムをどう動かすか、という話がCAP定理で重要になる。

混乱しやすいところだね。
ざっくり言うと、こう違うよ。

Aは「ユーザーに返事できるか」の話。
Pは「サーバー同士の通信が切れる前提で考えているか」の話。
だから、AとPはどちらも障害に関係するけど、見ている場所が違うよ。

CAP定理は、

ネットワーク分断が起きたとき、C（一貫性）とA（可用性）の両方を完全には守れない

という話だよ。

そう。ここが大事。
P、つまり分断耐性は、分散システムでは現実的に避けられない。
ネットワークはいつか切れる可能性があるからね。

そうそう。それでいいよ。

例で考えよう。

東京サーバーと大阪サーバーがあって、同じ在庫データを持っているとする。

東京サーバー：在庫 1個
大阪サーバー：在庫 1個

ここでネットワーク障害が起きて、東京と大阪が通信できなくなった。

東京サーバー  ×通信不可×  大阪サーバー

そう。
この状態で、東京にも大阪にも注文が来たらどうする？

一貫性を重視するなら、

データが正しいと確認できるまで、一部の処理を止める

という判断になる。

そう。
東京と大阪が通信できず、在庫が本当にあるか確認できないなら、

「今は注文を受け付けられません」

とする。

そう。
これが Cを優先してAを犠牲にする 考え方。

可用性を重視するなら、

多少データがズレる可能性があっても、リクエストには応答する

という判断になる。

そう。
東京サーバーも大阪サーバーも、それぞれ自分が持っている情報をもとに注文を受ける。

東京サーバー：注文OK
大阪サーバー：注文OK

その通り。
サービスは止まりにくいけど、あとでデータのズレを直す必要がある。

よくそう説明されるね。
ただ、もう少し正確に言うと、

ネットワーク分断が起きたとき、一貫性と可用性のどちらを優先するか選ぶ必要がある

という考え方。

そう。
現実の分散システムでは、ネットワーク分断の可能性を無視しにくい。
だから多くの場合、Pを前提にして、C寄りにするかA寄りにするかを考える。

優先するものの組み合わせだよ。

そうそう、いい感じ。

CP型は、データの正しさを重視する。

たとえば、

銀行の残高
在庫数が厳密なシステム
予約管理

みたいに、データのズレが大きな問題になる場合は、Cを重視したい。

そう。
だから、通信が怪しいときは処理を止めてでも、正しさを守る。

AP型は、サービスを止めないことを重視する。

たとえば、

SNSのタイムライン
いいね数
アクセスログ
おすすめ表示

みたいに、少し古い情報が見えても致命的ではない場合。

そう。
その場合は、多少ズレても表示を続けて、あとでデータを合わせる方が向いている。

理論上は出てくるけど、分散システムではあまり現実的ではない。

ネットワーク分断が起きない前提になってしまうから。
でも現実のネットワークでは、通信障害は起こり得る。

そう。
だから実務では、分断が起きたときにCP寄りにするかAP寄りにするかを考えることが多い。

じゃあ、友達グループでイベントの出欠管理をする例で考えよう。

AグループとBグループで、同じイベントの出欠リストを管理しているとする。

Aグループのリスト
Bグループのリスト

でも、スマホの通信障害で、AグループとBグループが連絡を取り合えなくなった。

C、一貫性を優先するなら、

連絡が復旧するまで、出欠の変更受付を止める

A、可用性を優先するなら、

各グループで出欠変更を受け付け続ける
あとで情報を合わせる

そう。
これがCAP定理の感覚に近い。

システム設計で、何を優先するかを考えるときに使う。

たとえば、

多少止まっても、データの正しさを守りたいのか
多少ズレても、サービスを止めたくないのか

を決める。

そう。
銀行とSNSでは、優先すべきものが違う。

厳密には、ネットワーク分断が起きたときの話。
通常時はCもAも満たしているように見えるシステムもある。

それも少し違う。
実際には「どちら寄りに設計するか」という話。
完全に0か100かではないよ。

そう。
たとえばAP寄りでも、あとからデータを整える仕組みを持つことが多い。

こう覚えるといいよ。

C：Consistency
→ どこで見ても同じデータ

A：Availability
→ いつでも返事が返ってくる

P：Partition Tolerance
→ 通信が切れても耐える

これでいい。

C：正しさ
A：止まらなさ
P：通信切れへの強さ

試験とかで気にするといいポイントを紹介するね。

CAP定理とは、分散システムで、

一貫性・可用性・分断耐性の3つを、ネットワーク分断時に同時に完全には満たせない

という考え方。

そうそう。
初心者向けに一言でまとめるなら、

CAP定理は、分散システムで「正しさ」と「止まらなさ」のどちらを優先するか考えるためのルール

だね。