分散システムの基本となるCAP定理について、具体例を交えて自分なりにまとめてみる
CAP定理とは
CAP定理とは、Consistency （一貫性）・Availability （可用性）・Partition-tolerance (（ネットワークの）分断耐性）の頭文字をとったもの
これら全ての特性を満たすシステムを構築するのは不可能であり、必ずトレードオフが発生するという定理。
一般的に分散システムでネットワーク障害が起こらないという前提をおくのは危険で、ネットワークの分断耐性は必須条件となる。つまり、P(分断耐性)＋A(可用性)か、P(分断耐性)＋C(一貫性)のどちらかを選択することが求められる。
身近なサイトでの例
例えば 「アーティストのチケット予約サイト」 で考えてみる。
1. Consistency(一貫性)
いつでもどこからアクセスしても必ず最新の正しいデータが見えるという性質。
例えば、ある席の最後の一枚が売れた瞬間、東京のサーバーにアクセスしても、大阪のサーバーにアクセスしても誰が見ても「売り切れ」と表示されていなければならない。
もしもこれが、東京サーバーに接続してるユーザーはまだ「在庫有り」なのに、大阪サーバーに接続しているユーザーからは「在庫なし」と表示されたとしたらそれは一貫性が崩れていると言える。
2.Availability(可用性)
いつでもシステムが正常に応答を返してくれるという性質。
例えるなら、チケット予約サイトにアクセスしたときに、タイムアウトしたり、「サーバーが混み合っています」というエラー画面が出たりせずに必ず「在庫あり」や「売り切れ」といったなんらかのページが表示される状態
3.Partition-Tolerance(分断耐性)
システム内の一部の通信が途切れてもシステム全体としては動き続けるという性質。
例えるなら、東京大阪のサーバーを繋ぐネットワークに障害が発生し、お互いに通信できなくなってしまったとした時に、チケットサイトがサービスを完全に停止せずに動き続けるかどうか。
もしこの分断耐性がないとしたら、東京大阪のネットワークが切れたら全てのシステムが止まるということを意味する。
CかAどっちを取るか？
これは作成するアプリケーションの要件による。
Cをとるケース
上のチケットサイトの例に倣うと「ダブルブッキングダメ！ゼッタイ！」と考えるのがこの一貫性にあたる。
つまり、もし、東京大阪間などでネットワークが分断されるとするなら、どちらとも更新させてはいけないのでシステムは予約処理を一時停止する。つまりA(可用性)が失われることになる。
一貫性が何よりも優先される銀行システムなどにも適応される
Aをとるケース
絶対にサイトを止めることだけは阻止したい！と考えるのがこの可用性
もし、ネットワークが分断されるとしたらそれぞれのサーバでの一時的な整合性は失われるが、アプリケーションは動き続ける。あとから帳尻を合わせていくことを「結果整合性」と呼んだりもする
まとめ
CAP定理では、基本的にCPかAPのどちらかを取ることが現代では求められているのだと知った。
もっと身近なサービスでどちらが取られているのか考える時間を作りたい！