【ITニュース解説】Mastering the CAP Theorem: A Simple Guide for System Design Interviews

システムエンジニアとして分散システムを設計する際、避けて通れない重要な概念がCAP定理である。これは、スケーラブルで障害に強いシステムを構築する上で、どのようなトレードオフが存在するのかを理解するための基礎となる。

CAP定理は、分散システムにおいて同時に保証できる特性が、次の三つのうち二つに限られると述べている。一つ目は一貫性（Consistency）、二つ目は可用性（Availability）、そして三つ目は分断耐性（Partition Tolerance）である。

まず、一貫性（Consistency）とは、すべての読み取り操作が最新の書き込みデータを返すことを意味する。つまり、システム内のどのノードにアクセスしても、常に同じ最新のデータが見える状態である。例えば、ユーザーが表示名を更新した場合、その直後にどのサーバーにアクセスしても、新しい表示名が即座に反映されていることが一貫性の保証された状態である。

次に、可用性（Availability）とは、システムが停止していないノードへのすべてのリクエストに対して、必ず応答を返すことを指す。この応答が必ずしも最新のデータを含んでいるとは限らないが、システムは沈黙することなく何らかの形で動作を継続する。例えば、あるサーバーがデータ同期に遅れをとっていたとしても、そのサーバーは利用可能な範囲でデータを提供し、リクエストに対して応答を返す。

最後に、分断耐性（Partition Tolerance）とは、ネットワークの一部が分断され、システムの一部が互いに通信できなくなったとしても、システム全体として動作を継続できる能力を意味する。現実世界の分散システムでは、サーバーの故障、ネットワークパケットの損失、データセンター間の接続断など、ネットワーク分断は避けられない事態である。例えば、アメリカとヨーロッパに配置されたサーバー間の通信が途絶えたとしても、両方のサーバーがそれぞれの地域のユーザーに対してサービスを提供し続けられる状態が分断耐性である。

重要な洞察として、現実の分散システムではネットワーク分断が必ず発生するという事実がある。これは、分断耐性（P）がシステム設計において必須の要件であることを意味する。そのため、CAP定理が示す本当のトレードオフは、「3つのうちどれか2つを選ぶ」のではなく、「ネットワーク分断が発生したときに、一貫性（C）と可用性（A）のどちらを優先するか」という選択になる。

このトレードオフを具体的な例で考えてみよう。例えば、二つのサーバー（アメリカとヨーロッパ）を持つウェブサイトで、ユーザーが自分のプロフィール（表示名）を更新するケースを想定する。

通常運用時は、アメリカのサーバーでユーザーAが表示名を更新すると、その更新がヨーロッパのサーバーにも複製され、ヨーロッパのユーザーBがユーザーAのプロフィールを閲覧すると、最新の表示名が見える。これは基本的なデータ同期が機能している状態である。

しかし、もしアメリカとヨーロッパのサーバー間のネットワーク接続が途絶える、つまりネットワーク分断が発生した場合、我々は判断を迫られる。 一つ目の選択肢は、一貫性を優先する方法である。この場合、サーバー間でデータの同期が保証できない限り、ユーザーBにはプロフィールの表示を拒否する。ユーザーBはエラーメッセージを受け取り、データが最新ではない可能性を排除する。 二つ目の選択肢は、可用性を優先する方法である。この場合、たとえデータが古い可能性があったとしても、ヨーロッパのサーバーが持つ既存のデータを使ってユーザーBにプロフィールを表示する。

このプロフィールの例では、古い表示名を見せることは、完全にデータが表示されないよりははるかに良い。一時的な不整合は許容範囲であり、ネットワークが復旧すればデータは後で同期される。このような設計は可用性と分断耐性（AP）を優先し、結果的に「最終的に一貫性を持つ」（Eventual Consistency）システムとなる。

しかし、すべてのシステムで可用性が優先されるわけではない。一貫性を絶対に優先しなければならないケースも存在する。 例えば、チケット予約システムを考えてみよう。もしネットワーク分断中にユーザーAとユーザーBが同じフライトの同じ座席を予約できてしまったら、それは壊滅的な問題となる。このような場合、システムは一貫性を確保するために、予約リクエストを拒否してでも二重予約を防がなければならない。 また、Eコマースサイトの在庫管理や、金融システムの株取引プラットフォームなども、データの一貫性がビジネスの信頼性と直結するため、一貫性が非常に重要視される。もしAmazonで残り1つの商品がネットワーク分断中に複数人に販売されてしまえば、顧客満足度を著しく損ねる。

一方で、多くのシステムでは、一時的な不整合がある程度許容され、可用性を優先する方が良い結果を生む。このようなシステムでは、最終的に一貫性が取れれば十分である。 例えば、ソーシャルメディアでは、ユーザーがプロフィール画像を更新した際に、他のユーザーが数分間古い画像を見たとしても、それが壊滅的な問題になることは稀である。 Netflixのようなコンテンツプラットフォームで映画の説明文が一時的に古くても、ユーザーはそれよりも動画が安定して視聴できることを望む。 レストランのレビューサイトで営業時間情報が一時的に古くても、情報が全く表示されないよりはマシである。

一貫性と可用性のどちらを優先すべきか判断する際の指針となる問いは、「ユーザーが一時的に不整合なデータを見た場合に、それは壊滅的な事態を引き起こすか？」である。もし答えが「はい」ならば一貫性を優先し、もし「いいえ」ならば可用性を優先するのが適切である。

現代の複雑な分散システムでは、一貫性と可用性の選択が単純な二者択一ではないことも多い。実際には、システム内の機能やデータによって、異なる一貫性モデルを採用することが一般的である。

例えば、BookMyShowのような映画やイベントのチケット予約システムでは、異なる部分で異なるアプローチが取られている。 座席の予約フローでは、強力な一貫性が求められる。二人のユーザーが同時に同じ座席を予約できないよう、ネットワーク分断時でも二重予約が発生しないことを保証する必要がある。この場合、予約リクエストが拒否される可能性があったとしても、一貫性を最優先する。 一方で、映画やイベントの詳細を閲覧する機能では、可用性が優先される。映画の説明や上映時間が一時的に古くても、それがユーザーにとって壊滅的な問題になることはない。ユーザーは、エラーで情報が見られないよりも、多少古い情報でも表示されることを望むだろう。 このように、同じシステム内でも「予約フローでは座席の衝突を防ぐために一貫性を優先し、映画の詳細やレビューの閲覧のような重要性の低い機能では可用性を最適化する」といった判断がなされる。

CAP定理を理解することは、システム設計において、どのような制約があり、どのようなトレードオフを考慮すべきかを明確にする上で不可欠である。特に分散システムを扱う際には、この原理が設計の重要な指針となる。