コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

CAP定理

出典: フリー百科事典『ウィキペディア(Wikipedia)』

CAP定理ブリュワーの定理とも呼ばれ、分散コンピュータシステムのマシン間の情報複製に関する定理。ウェブサービスを想定して作られた定理。

定義

[編集]

ノード間のデータ複製において、同時に次の3つの保証を提供することはできない[1][2]

  • 一貫性 (Consistency)
    すべてのデータ読み込みにおいて、最新の書き込みデータもしくはエラーのどちらかを受け取る。
  • 可用性 (Availability)
    ノード障害により生存ノードの機能性は損なわれない。つまり、ダウンしていないノードが常に応答を返す。単一障害点が存在しないことが必要。
  • 分断耐性 (Partition-tolerance)
    システムは任意の通信障害などによるメッセージ損失に対し、継続して動作を行う。通信可能なサーバーが複数のグループに分断されるケース(ネットワーク分断)を指し、1つのハブに全てのサーバーがつながっている場合は、これは発生しない。ただし、そのようなネットワーク設計は単一障害点をもつことになり、可用性が成立しない。RDBではそもそもデータベースを分割しないので、このような障害とは無縁である。

この定理によると、分散システムはこの3つの保証のうち、同時に2つの保証を満たすことはできるが、同時に全てを満たすことはできない[3]。単一障害点があれば、ネットワーク分断が発生した際にシステムがバラバラに分裂しても、そこを基準に一貫した応答ができる(分断耐性+一貫性)が、可用性が成立しなくなる。

個別例

[編集]

一貫性+可用性

[編集]

一般的な関係データベースLDAPNFS などは一貫性と可用性しか成立しない。2相コミットはこれに該当。ネットワーク分断が発生した際は、片方を切り捨てる。Amazon Relational Database Service の Multi-AZ 配備も該当。

可用性+分断耐性

[編集]

可用性+分断耐性のケースでも、一定時間以内に一貫性を成立させるシステム(結果整合性; eventually consistent)は構築可能である。Amazon SimpleDBApache Cassandra などがこの方式を採用している。DNS や HTTP キャッシュなども該当。3種の中ではこの方式が最も障害に強い。

一貫性+分断耐性

[編集]

Apache HBase などが採用している。HBase の場合、単一障害点がある上、ネットワーク分断に対して整合性をとる仕組みが不完全であるため、可用性が犠牲となっている。

歴史

[編集]

この定理は、インクトミの創業者でもあり、カリフォルニア大学バークレー校計算機科学教授でもあるエリック・ブリュワーが2000年の Symposium on Principles of Distributed Computing (PODC) で提案(数学的な用語では予想)したのが始まりである[4]

2002年にMITのSeth Gilbertとナンシー・リンチがブリュワーの予想の厳密な証明を提出し、定理として確立した[1]

参照

[編集]
  1. ^ a b Nancy Lynch and Seth Gilbert, conjecture and the feasibility of consistent, available, partition-tolerant web services”, ACM SIGACT News, Volume 33 Issue 2 (2002), pg. 51-59.
  2. ^ "Brewer's CAP Theorem", julianbrowne.com, Retrieved 02-Mar-2010
  3. ^ "Brewers CAP theorem on distributed systems", royans.net
  4. ^ Eric Brewer, "Towards Robust Distributed Systems"

関連項目

[編集]