CAP定理

今日の朝会で、ミドルウェア選定をする際に大切な考え方で「CAP定理」というものがあることを教えて頂きました。

分散処理システムをで考えるのに必要なことです！！

Eric Brewerさんが考えたんですって。

CAPとは、

• Consistency（一貫性）
• Availability（可用性）
• Partition-tolerance（分断耐性）

を指します。

同時に3つの保証を提供することはできないので、このうち２つを選ぶという考え方です。

例をいくつかあげると、
一貫性と可用性　：MySQL等のRDBMS、LDAP、NFS
可用性と分断耐性：Cassandra、DNS
一貫性と分断耐性：Hbase、MongoDB

構築するサービスの用途に応じて選定してあげましょうってことですね。

・・・ところがどっこい

Eric Brewerさんが 「シンプルなCAPを主張する時代は完全に終わっています。 3のうち2つ”という公式はミスリーディングでした。というのは、この公式は3つの属性の緊張関係を過度に単純化してしまうからです。過度の単純化は問題です。 現在のCAPの目的は特定のアプリケーションが必要とする一貫性と可用性を最適化することでしょう。」

って訂正しちゃった（笑）

わかりやすく解説してくれた記事があるのでご紹介します。

CAPの本質はネットワーク分断によって処理のタイムアウトが発生したときに表れる、と書いています。 つまり、ネットワーク分断が発生するとシステム内の一貫性（C）が確認できなくなってしまうため、処理を止めてでも一貫性が失われないようにするのか、それとも一貫性はなくてもいいから処理を止めずに可用性（A）を優先させるのか、選択によってシステムの性格が大きくことなるためです。

CAPのPはネットワーク分断（Partiton）のPですが、そもそもネットワークが分断したという判断をシステムが完璧に行うことはできないと、Brewer氏は指摘しています。システムの一部だけがネットワーク分断を検知したときの動作や、分断していないかもしれないけれど遅延した状態がある程度続いたらどこかで分断と見なす、などの動作があるわけです。

www.publickey1.jp

サービスの性質に応じて、対応していかないといけないってことですね。 大変だ・・・