分散システムでは、すべての機能や特性を完全に満たすことは不可能で、必ずトレードオフが発生するとされています。
CAP定理は、そのトレードオフとなる3つの特性を表す言葉です。
どんなに優れたシステムでも、3つのうち2つを選択することしかできないことを示しています。
今回はこのCAP定理についてまとめていきます。
CAP定理の概要
CAP定理(またはBrewerの定理)は、2000年にいコンピュータ科学者エリック・ブリューワーによって提唱された概念です。
分散システムにおける3つの重要な特性の間のトレードオフを示しています。
重要な特性とは、
- 一貫性(Consistency)
- 可用性(Availability)
- 分断耐性(Partition Tolerance)
のことを指します。
分散システムはどんなに頑張ってもこれらを、
「完全同時に満たすことは出来ない」
という事を表しているのがCAP定理です。
CAP定理の詳細
一貫性(Consistency)
一貫性は、システム内のすべてのノード(≒状態)が同じ時点で同じデータを持っていることを保証しています。
具体的には、あるクライアントがデータの書き込みを行った場合、その後に他のクライアントがデータを読み込むと、必ず最新データが返されます。
これは、銀行のトランザクションや在庫管理システムなど、正確なデータが求められるアプリケーションで重要です。
可用性(Availability)
可用性は、すべてのリクエストに対して常にレスポンスを返すことを保証します。
システムが高い可用性を持つ場合、ユーザーはいつでもサービスにアクセスでき、ダウンタイムが発生しません。
これは、オンラインショッピングサイトやSNSなど、サービスの継続的な提供が要求されるアプリケーションにとって重要です。
分断耐性(Partition Taleran)
分断耐性は、ネットワークが分断されてもシステムが動作し続ける能力を指します。
ネットワークの分断は、データセンター間の通信障害やインターネットの一部が利用不可になる場合などに発生します。
分断耐性が高いシステムは、これらの障害が発生してもデータの整合性やサービスの継続性を維持します。
CAP定理の役割
CAP定理は、分散システムの設計と実装において重要なガイドラインを提供します。
システムアーキテクトや開発者はCAP定理を理解することで、システム設計時にどの特性を優先させるべきかを判断しています。
以下に、CAP定理の役割とその影響について記載します。
システム設計のトレードオフ
CAP定理の3つの特性のうち、どの2つを優先させるかでどういったシステムになるか決まってきます。
CA(一貫性と可用性)
一貫性と可用性を優先すると、ネットワーク分断が発生した場合にシステムが停止する可能性があります。
これは、銀行のトランザクションシステムなど、正確なデータが最優先されるアプリケーションに適しています。
CP(一貫性と分断耐性)
一貫性と分断耐性を優先させると、システムは常に最新のデータを提供しますが、一部のリクエストに対して応答しない場合があります。
これは、分散データベースや金融取引システムなどに適しています。
AP(可用性と分断耐性)
可用性と分断耐性を優先すると、システムは常にレスポンスを返しますが、最新のデータでない場合があります。
これは、SNSやオンラインショッピングサイトなど、サービスの継続性が重要なアプリケーションに適しています。
現代の分散システム
CAP定理は、現代の分散システム設計に大きな影響を与えています。
例えばNoSQLデータベースは、一般的にAPモデルを採用しており、一貫性を若干犠牲にして成り立っています。
一方で、GoogleのSpanner(Googleが開発した分散データベースシステム)のようなシステムは、分断耐性を維持しながら高い一貫性を提供することを目指しています。
しかし、これには高度な技術と複雑な設計が必要です。
CAP定理のまとめ
CAP定理は分断システム設計において重要な役割を果たします。
開発者はCAP定理を理解することで、要件に合わせた最適なアーキテクチャを選択することができます。
CAP定理と近い存在にACID特性というものがあります。
ACID特性について知りたい方はこちら。
