はじめに
データベース周りの記事を読んでいるとたまに出てくる「CAP定理」。
数学用語感がありますが、実際は分散アプリケーションに関する用語です。
この用語を腹の底から理解すべく、自分なりにエッセンスを記載してみました。
CAP定理ってなに？
分散システムで望ましい3つの特性のうち、2つしか満たせないよね～という話が「CAP定理」です。この全部を満たせないよねっていうニュアンスは物理学でいう不確定性原理に近いものがあります。
さて、分散システムで望ましい特性とは
- 一貫性（Consistency、「CAP」の「C」）
- 可用性（Availability、「CAP」の「A」）
- 分断耐性（Partition tolerance、「CAP」の「P」）
の３つ。特に最後のPは分散システム用語。
このうち、いずれか2つしか提供できないよね～という趣旨がCAP定理です。
深掘り
C,A,Pがそれぞれ何を示しているのかはっきりさせます。
Cは一貫性で、どのサーバに接続したクライアントも同じデータが見えること。 これを実現するためには、データが1つのノードに書き込まれるたびに、そのデータがシステム内の他のすべてのノードに即時に転送または複製される必要があります。グローバルコピーのような考え方ですね。
続いてAの可用性で、1つ以上のサーバがダウンしている場合でもきちんと応答すること。これはよくある話。
最後のPは分断耐性で、分散システム内の通信障害が起きても遅延している状態でも全体として機能する・・ということ。これは可用性に近い気がしますが、分散特有でサーバがデータセンターまたぎをしているケースなどの想定でしょうか。
CAPの何を取るかという選択
なぜ3つを満たせないのかは置いておいて、CAPのうち２つを選んだ場合はどうなるのか。
- CPデータベース：可用性を犠牲にして一貫性と分断耐性を提供。 2つのノード間で分断が発生した場合、整合しなくなったノードをシャットダウン。
- APデータベース：一貫性を犠牲にして、可用性と分断耐性を提供。 分断が起きると古い情報を返すかも。
- CAデータベース：分断が発生すると、一貫性と可用性を提供ができなくなる
という選択を迫られるわけですね。自分のシステムがどれを捨てているのかという見方ができるとおもしろいですね。
