「分散システムを作るってどういうことだろう？」
「CAP定理ってよく聞いたことはあるけれど、どう意識すればいいのか分からない」
と感じたことはありませんか？
プログラミング未経験者や駆け出しエンジニアにとって、分散システムの設計やその背後にある理論は、非常に難解で混乱を招きやすいものです。特に、CAP定理という言葉に触れるとき、どのトレードオフ（妥協）が必要なのか、具体的にどのような選択肢を取るべきなのかを理解することが求められます。
このCAP定理という概念を理解することで、システムの安定性、スケーラビリティ、そしてパフォーマンスの最適化に繋がります。本記事では、初心者にも分かりやすいように具体例を交え、CAP定理を解説します。
CAP定理の基本概念
CAP定理（Consistency, Availability, Partition tolerance）は、分散システムの設計における三つの重要な特性を表した理論です。これを提唱したのは、コンピュータサイエンティストのEric Brewer氏で、2000年に彼のプレゼンテーションで紹介されました。
CAP定理の以下の三つの特性を持ちます。
- 一貫性（Consistency）
- 可用性（Availability）
- 分断耐性（Partition Tolerance)
一貫性(Consistency)
一貫性は、システム内のすべてのノード（コンピュータの一部）が常に同じ時点で同じデータを持っていることを保証します。
具体的には、あるクライアントがデータを更新した場合、その変更が他のすべてのクライアントに即座に反映され、常に最新のデータが返されることを意味します。これにより、システム全体でデータの整合性を保つことができます。
例えば、銀行のトランザクションシステムでは、一貫性が特に重要視されています。もし顧客が自分の口座にお金を振り込んだ場合、どの端末で照会してもその振込が反映されていることが確実でなければなりません。
可用性(Availability)
可用性は、システムが常に応答し続け、ユーザーからのリクエストに対して必ず何らかのレスポンスを返す能力を指します。
システムが高い可用性を持っている場合、ユーザーは24時間いつでもサービスにアクセスでき、ダウンタイムを最小限に抑えることができます。
例えば、オンラインショッピングサイトやSNSでは、サービスの提供が常に必要です。アクセス障害があれば、ユーザーの信頼を失いかねません。
分断耐性(Partition Taleran)
分断耐性は、システムがネットワークの一部が障害を起こしても引き続き機能し続ける能力を指します。
ネットワーク分断は、データセンター間の通信障害や一部のサーバーがダウンした場合など、さまざまな原因で発生します。分断耐性が高いシステムは、これらの障害に直面しても、データの整合性やサービスの継続性を維持し、システム全体がダウンすることを防ぎます。
CAP定理が示すトレードオフ
CAP定理の要点は、これらの3つの特性のすべてを同時に完璧に満たすことはできないということです。
分散システムを設計する際には、必ずトレードオフが生じてしまいます。つまり、システムは次の3つの特性のうち、どれか2つを優先する形になります。
一貫性と可用性（CA）
一貫性と可用性を最優先する場合、システムは常に最新のデータを提供し、リクエストに対して確実にレスポンスを返します。しかし、ネットワーク分断が発生した場合、システムが動作を停止する可能性があります。これにより、分断が発生しても処理を続けることができるが、最新データの提供を犠牲にすることになります。
適用例：銀行のトランザクションシステムや在庫管理システムなどでは、データの正確性が最優先であり、ネットワークが分断されたとしてもトランザクションが正確に行われることが求められます。
一貫性と分断耐性（CP）
一貫性と分断耐性を優先すると、システムは常に最新データを保持し、ネットワークが途切れても動作し続けます。しかし、リクエストに対してレスポンスしない場合が出てきます。つまり、システムは「データの一貫性」を保つために一部のリクエストを犠牲にする形になります。
適用例：分散データベースや金融取引システムでは、正確なデータの提供が最も重要であり、ネットワーク分断時には一時的にサービスを停止する選択がされることもあります。
可用性と分断耐性（AP）
可用性と分断耐性を優先すると、システムは常にレスポンスを返し続け、ネットワークの障害にも耐えることができます。しかし、この場合、システムは必ずしも最新のデータを返すわけではなく、最新の状態でないデータを提供することがあります。
適用例：SNSやオンラインショッピングサイトでは、サービスの継続的な提供が最優先されます。データの一貫性が一時的に犠牲になることがあっても、サービスが止まらないことが重要です。
現代の分散システムにおけるCAP定理
CAP定理は、特にNoSQLデータベースなどで重要な役割を果たしています。NoSQLデータベースは、多くの場合、APモデル（可用性と分断耐性）を採用しており、一貫性をある程度犠牲にして、スケーラビリティとサービスの継続性を重視しています。
例えば、CassandraやCouchDBなどのNoSQLデータベースは、分散システムとしての可用性と分断耐性を優先し、リーダブルなデータの整合性を犠牲にしています。
一方で、GoogleのSpannerなど、Googleが開発した一部の分散データベースは、分断耐性を維持しながらも高い一貫性を提供することを目指しており、これには高度な技術と複雑なアーキテクチャが必要です。
CAP定理は分散システム設計において不可欠な概念であり、システムの要件に合わせて適切な特性を選択することが求められます。しかし、近年では、CAP定理に加えて、
- ACID特性（Atomicity, Consistency, Isolation, Durability）
- BASE特性（Basically Available, Soft state, Eventually consistent）
を考慮することも重要とされています。
これらを適切に組み合わせることで、より堅牢でスケーラブルなシステムを構築することが可能になります。
CAP定理のまとめ
CAP定理は、分散システム設計における重要な指針となります。
開発者やシステムアーキテクトは、CAP定理の理解とどの特性を優先するかの判断が求められます。それぞれのアーキテクチャには、固有の利点と欠点があるため、システムの要求に合わせて最適な選択をすることが最も重要です。
分散システムを設計する際には、今回紹介したCAP定理を思い出してみてください。