CAP定理とは何ですか?

CAP定理によると、分散システムでは、
一貫性（consistency） 、 可用性（availability） 、 分断耐性（partition tolerance） （CAPの「 C 」、「 A 」、「 P 」）という3つの望ましい特性のうち実現できるのは2つだけ、としています。

「安い、早い、良い：2つ選んでください」という見出しで始まる造園業者や住宅塗装業者のような業者の広告を見たことはありますか？CAP定理では、これと同種のロジックを分散システムに適用します。

分散システムとは、複数のノード（物理マシンまたは仮想マシン ）に同時にデータを保存するネットワークのことです。すべてのクラウド・アプリケーションは分散システムであるため、アプリケーションが最も必要とする特性を実現するデータ管理システムを選択できるようにクラウド・アプリケーションを設計する際には、 CAP 定理を理解することが不可欠です。

CAP 定理は、Eric A. Brewer 教授が 2000 年に分散コンピューティングに関する講演で初めて提唱したため、Brewer の定理とも呼ばれます。2年後、MITのセス・ギルバート教授とナンシー・リンチ教授は「ブリューワー予想」の証明を発表しました。

CAP 定理が言及する 3 つの分散システムの特性を詳しく見てみましょう。

一貫性

一貫性とは、どのノードに接続しても、すべてのクライアントが同時に同じデータを参照できることを意味します。これを実現するには、データが 1 つのノードに書き込まれるたびに、書き込みが「成功」とみなされる前に、そのデータがシステム内の他のすべてのノードに即座に転送または複製される必要があります。

可用性

可用性とは、1 つ以上のノードがダウンしている場合でも、データを要求するすべてのクライアントが応答を受け取ることを意味します。これを別の言い方で言えば、分散システム内のすべての動作ノードは、例外なく、あらゆるリクエストに対して有効な応答を返します。

パーティション許容度

パーティションとは、分散システム内の通信の中断、つまり 2 つのノード間の接続が失われたり、一時的に遅延したりすることです。パーティション耐性とは、システム内のノード間の通信障害が何度発生してもクラスターが動作し続ける必要があることを意味します。

NoSQLデータベースは分散ネットワーク・アプリケーションに最適です。垂直方向の拡張が容易なSQL（リレーショナル）データベースとは異なり、NoSQLデータベースは水平方向に拡張可能で、意図的に分散するように設計されています。相互接続された複数のノードからなるネットワーク全体の成長に合わせて迅速に拡張できます。（詳しくは"SQL vs. NoSQL Databases: What's the Difference?" をご覧ください。）

現在、NoSQL データベースは、サポートされている 2 つの CAP 特性に基づいて分類されています。

• CP データベース：CP データベースは、可用性を犠牲にして一貫性とパーティション耐性を提供します。任意の 2 つのノード間でパーティションが発生すると、システムはパーティションが解決されるまで、一貫性のないノードをシャットダウンする (つまり、使用不可にする) 必要があります。
  
  
• AP データベース：AP データベースは、一貫性を犠牲にして可用性とパーティション耐性を提供します。パーティションが発生すると、すべてのノードは利用可能なままになりますが、パーティションの間違った端にあるノードは、他のノードよりも古いバージョンのデータを返す可能性があります。(パーティションが解決されると、AP データベースは通常、ノードを再同期して、システム内のすべての不整合を修復します。)
  
  
• CA データベース：CA データベースは、すべてのノードにわたって一貫性と可用性を実現します。ただし、システム内の 2 つのノード間にパーティションがある場合はこれを行うことができないため、フォールト・トレランス（障害耐性）を提供できません。

CA データベース・タイプを最後にリストしたのには理由があります。分散システムではパーティションを避けることができません。したがって、理論的には CA 分散データベースについて議論することはできますが、実際のあらゆる目的において CA 分散データベースは存在できません。これは、分散アプリケーション用の CA データベースが必要な場合にそれを持てないという意味ではありません。PostgreSQLの ような多くの リレーショナルデータベースは、一貫性と可用性を提供し、レプリケーションを使用して複数のノードに展開することができます。

MongoDBは、データをBSON（バイナリJSON）ドキュメントとして保存する定番のNoSQLデータベース管理システムです。これは、複数の異なる場所で実行されるビッグデータやリアルタイム・アプリケーション用によく使用されます。CAP 定理と比較すると、MongoDB は CP データ・ストアであり、可用性を犠牲にしながら一貫性を維持することで、ネットワーク・パーティションを解決します。

MongoDBはシングルマスター・システムなので、レプリカセット1つにつき、すべての書き込み操作を受け取るプライマリ・ノードが1つしかありません。同じレプリカセットにある他のノードはすべてセカンダリ・ノードであり、プライマリ・ノードの操作ログを複製して独自のデータセットに適用するものです。デフォルトでは、クライアントはプライマリ・ノードからも読み取りますが、セカンダリ・ノードからの読み取りを可能にする優先読み取り設定を指定することもできます。

プライマリ ノードが使用できなくなった場合、最新の操作ログを持つセカンダリ ノードが新しいプライマリ ノードとして選択されます。他のすべてのセカンダリ ノードが新しいマスターに追いつくと、クラスターは再び使用可能になります。この期間中、クライアントは書き込みリクエストを行うことができないため、データはネットワーク全体で一貫したままになります。

Apache Cassandra は、Apache Software Foundation によって管理されているオープン ソースの NoSQL データベースです。これは、分散ネットワーク上にデータを保存できるワイドカラム データベースです。ただし、MongoDB とは異なり、Cassandra はマスターレス アーキテクチャを採用しているため、単一の障害点ではなく複数の障害点が存在します。

CAP 定理と比較すると、Cassandra は AP データベースです。可用性とパーティション耐性を提供しますが、一貫性を常に提供できるわけではありません。Cassandra にはマスター・ノードがないため、すべてのノードが継続的に利用可能である必要があります。ただし、Cassandra は、クライアントがいつでも任意のノードに書き込むことができ、不整合をできるだけ早く調整できるようにすることで、最終的な整合性を提供します。

データの一貫性が失われるのはネットワーク・パーティションの場合のみであり、不整合はすぐに解決されるため、Cassandraはノードがピアに追いつくのに役立つ「修復」機能を提供します。ただし、常に可用性を維持すると、多くの場合、トレードオフの価値がある高いパフォーマンスのシステムとなります。

マイクロサービスは、疎結合で独立してデプロイ可能なアプリケーション・コンポーネントであり、独自のデータベースやデータベース・モデルを含む独自のスタックを組み込み、ネットワークを介して相互に通信します。マイクロサービスはクラウドサーバーとオンプレミスのデータセンターの両方で実行できるため、ハイブリッドやマルチクラウドのアプリケーション向けとして高い人気を集めています。

CAP 定理を理解すると、複数の場所から実行されるマイクロサービス・ベースのアプリケーションを設計する際に、最適なデータベースを選択するのに役立ちます。例えば、アプリケーションにはデータモデルを素早く反復し水平方向に拡張させる能力が不可欠ではあるものの、厳密ではなく最終的な一貫性を許容できる場合、CassandraやApache CouchDBのようなAPデータベースは要件を満たし、デプロイメントを簡素化できます。一方、eコマース・アプリケーションや支払いサービスなど、アプリケーションがデータの一貫性に大きく依存している場合は、PostgreSQLのようなリレーショナル・データベースを選択することもできます。