CAP定理(シーエーピーていり)とは | 意味や読み方など丁寧でわかりやすい用語解説

CAP定理は、分散システムを設計する上で非常に重要な概念であり、システムの特性を理解し、適切な選択を行うための指針となる。これは、分散コンピューティング環境において、同時に達成することが困難な三つの主要な特性、「一貫性（Consistency）」、「可用性（Availability）」、「分断耐性（Partition tolerance）」の頭文字を取ったもので、これらのうち最大で二つしか同時に満たすことができないという原理を示す。

まず、各特性について詳しく説明する。一貫性（Consistency）とは、分散システム内にある全てのデータレプリカが常に同じ状態を保つことを指す。つまり、あるデータを更新した場合、システム内のどのノードにアクセスしても、その最新のデータが取得できる状態である。銀行の口座残高のように、常に正確な情報が求められる場合に重要となる特性だ。例えば、ある口座からお金を引き出した直後には、どの支店のATMから残高を確認しても、引き出し後の残高が表示されるべきである。

次に、可用性（Availability）とは、システムが常に稼働しており、ユーザーからのリクエストに対して確実に応答を返す能力を指す。これは、システムの一部に障害が発生したとしても、残りの部分でサービスを継続し、ユーザーがいつアクセスしても情報が得られる、あるいは処理を実行できる状態を意味する。Webサイトやオンラインサービスでは、システムがダウンせず、常にアクセス可能であることが非常に重視される。

最後に、分断耐性（Partition tolerance）とは、ネットワークの分断が発生した場合でも、システムが全体として機能し続けられる能力を指す。分散システムでは、複数のノードがネットワークで接続されているが、そのネットワークに障害が発生し、一部のノード間での通信が不可能になることがある。この状況がネットワーク分断（Partition）であり、分断耐性があるシステムは、このような状況下でも停止せずに動作を続けることができる。現代の地理的に分散したシステムでは、ネットワーク障害は避けられないため、この分断耐性は必須の特性とされることが多い。

CAP定理の核心は、この三つの特性のうち、分散システムは「最大で二つしか同時に満たせない」という点にある。特に、ネットワーク分断（P）が発生した場合に、残る一貫性（C）と可用性（A）のどちらかを犠牲にしなければならないというトレードオフを強調する。

具体的に見ていこう。もしシステムが分断耐性（P）を持つことを前提とするならば、ネットワーク分断が発生した際に、システムは一貫性（C）と可用性（A）のどちらかを選択する必要がある。

一つ目の選択肢は、一貫性（C）を優先し、可用性（A）を犠牲にする場合である。これを「CPシステム」と呼ぶ。ネットワーク分断が発生した際、データの一貫性を保つために、システムは一部のノードへのアクセスを拒否したり、書き込み操作を停止したりすることがある。例えば、一部のノードが最新のデータを持っていない可能性がある場合、そのノードからの読み取りを一時的に禁止したり、データの更新を中断したりすることで、不整合なデータがユーザーに提供されるのを防ぐ。この結果、システム全体としてはサービスを継続しているが、一部のユーザーからのリクエストには応答できない状態、つまり可用性が低下する状況が発生する。金融システムなど、データの整合性が最も重視される場面でこのような設計が採用されることが多い。

二つ目の選択肢は、可用性（A）を優先し、一貫性（C）を犠牲にする場合である。これを「APシステム」と呼ぶ。ネットワーク分断が発生しても、システムは可能な限りサービスを提供し続け、ユーザーからのリクエストに応答する。たとえ一部のノードが最新のデータを持っていない可能性があっても、利用可能な情報を提供しようとする。この場合、分断が解消されるまでの間、一時的にシステム内でデータの一貫性が失われる可能性がある。例えば、SNSのタイムラインやオンラインショッピングサイトの在庫表示など、一時的なデータの不整合が許容され、サービスが停止するよりも常に利用可能であることが優先される場面で採用されることが多い。分断解消後にデータの同期が行われ、最終的には一貫性が保たれる「結果整合性（Eventual Consistency）」と呼ばれる考え方と密接に関連している。

では、分断耐性（P）を犠牲にして、一貫性（C）と可用性（A）を両立させる「CAシステム」は可能だろうか。理論上は可能だが、現実の分散システムにおいてネットワーク分断は避けられないため、Pを完全に放棄することは非現実的である。単一のサーバーや密結合されたクラスタであればCとAを両立できるが、広域に分散されたシステムではネットワーク障害のリスクが常に存在する。そのため、今日の分散システム設計においては、Pはほぼ必須の要件と認識されている。

CAP定理は、システム設計者がどのような特性を優先すべきかを明確にするための非常に有用なフレームワークである。完璧な分散システムというものは存在せず、それぞれのビジネス要件やアプリケーションの性質に応じて、CとAのどちらに重きを置くかを慎重に選択する必要がある。この選択によって、データベースの種類（例えば、厳密な一貫性を持つリレーショナルデータベースか、可用性やスケールアウトに優れたNoSQLデータベースか）や、データ同期の方式、エラー発生時の振る舞いなどが大きく異なってくる。システムエンジニアは、このCAP定理を理解することで、分散システムの限界と特性を把握し、より堅牢で目的に合ったシステムを設計できるようになる。