【ITニュース解説】CAP Theorem in Distributed Systems : Beyond the ‘Pick Two’ Myth

現代のITシステムの多くは、複数のコンピュータがネットワークを介して連携し合う「分散システム」として構築されている。この分散システムを設計する上で、避けては通れない基本原則が「CAP定理」である。CAP定理は、分散システムが持つべき3つの重要な特性、すなわち「一貫性（Consistency）」「可用性（Availability）」「分断耐性（Partition Tolerance）」の関係性を示したもので、これら3つを同時に完全に満たすことはできないとされている。

まず、それぞれの要素を理解する必要がある。銀行のATMネットワークを例に考えてみよう。このネットワークでは、銀行の中央サーバーが全ての口座情報の原本を管理し、各地のATMがそのサーバーと通信して取引を行う分散システムと見なせる。

「一貫性（C）」とは、システムのどの部分にアクセスしても、常に最新の正しいデータが得られることを保証する性質である。ATMの例で言えば、あるATMで預金した直後に、別の地域のATMで残高照会をしても、預金が反映された最新の残高が表示される状態が一貫性が保たれている状態だ。システム内の全てのデータが常に同期されていることを意味する。

次に「可用性（A）」は、システムにアクセスした際に、必ず何らかの応答が返ってくることを保証する性質である。つまり、システムが常に稼働し、ユーザーのリクエストを処理できる状態を指す。ATMが故障中やメンテナンス中でない限り、いつでもお金の引き出しや預け入れができる状態が可用性が高い状態だ。

最後に「分断耐性（P）」は、システムを構成するコンピュータ間の通信に障害が発生し、ネットワークが分断された状態になっても、システム全体が動作を継続できる能力を指す。例えば、ある地域のATMが、ネットワーク障害によって銀行のサーバーと通信できなくなったとしても、システムが停止しない性質が分断耐性である。

CAP定理はよく「C、A、Pのうち2つしか選べない」と単純化して説明されるが、これは実態を正確に表していない。現代の大規模な分散システムにおいて、ネットワーク障害による「分断」は稀な例外ではなく、いつか必ず発生する事象として扱わなければならない。そのため、分断耐性（P）は選択の対象ではなく、設計上必須の要件となる。したがって、現実のシステム設計におけるトレードオフは、ネットワークが分断された状況で、「一貫性（C）」と「可用性（A）」のどちらを優先するかという選択になる。

ここで、2つの設計方針が考えられる。一つは「CPシステム」で、分断耐性（P）を確保した上で、一貫性（C）を優先する。この場合、可用性（A）が犠牲になる。ATMの例に戻ると、ネットワーク障害でATMがサーバーと通信できなくなったとする。CPシステムでは、最新の口座残高を確認できない以上、誤った取引（残高以上の引き出しなど）を防ぐために、一切の取引を拒否する。ユーザーはATMを使えなくなるが、口座データの正確性は守られる。

もう一つは「APシステム」で、分断耐性（P）を確保し、可用性（A）を優先する。この場合は、一貫性（C）が犠牲になる可能性がある。同じくATMがサーバーと通信できない状況で、APシステムはユーザーの利便性を重視し、取引を許可する。これにより、ユーザーはサービスを継続して利用できるが、サーバーとの同期が取れないため、一時的に口座残高が不正確になるリスクが生じる。例えば、通信が復旧した際に、残高がマイナスになってしまうといった事態が起こり得る。

しかし、実際のシステム設計は、このように単純にCPかAPかを選ぶ二者択一ではない。多くの場合、両者の特性を組み合わせた、より柔軟なアプローチが取られる。これを「部分的可用性」や「部分的整合性」と考えることができる。例えば、先ほどのATMの例で、ネットワークが分断された際に、リスクの高い「出金」は停止するが、リスクの低い「入金」は受け付けるといった設計が考えられる。これは、システムを完全に停止させるのではなく、一部の機能を提供し続けることで部分的に可用性を維持しつつ、データの不整合が致命的な問題とならないように制御する手法だ。また、一時的なデータの不整合を許容し、ネットワークが復旧した後に時間をかけてデータの辻褄を合わせる「結果整合性」という考え方もある。これは、常に完璧な一貫性を求めるのではなく、最終的にデータが正しくなれば良いというアプローチで、多くのWebサービスで採用されている。

結論として、CAP定理は分散システム設計における絶対的な法則というよりは、障害発生時にどのようなトレードオフが存在するかを理解するための重要な指針である。システムエンジニアは、「2つを選ぶ」という神話にとらわれるのではなく、システムの特性やビジネス要件に応じて、ネットワーク分断時に一貫性と可用性のバランスをどのように取るかを熟慮する必要がある。完全にどちらかを捨てるのではなく、状況に応じて機能を制限したり、一時的な不整合を許容したりすることで、堅牢で実用的なシステムを構築することが求められるのだ。