「安い、早い、良い：2 つ選んでください」という見出しで始まる造園業者、住宅塗装業者、またはその他の業者の広告を見たことはありますか?

分散システムは、一貫性、可用性 、および 分割耐性（CAPの「C」、「A」、「P」）という3つの望ましい特性のうち、2つだけを提供することができるというものです。。

分散システムとは、複数のノード（物理 マシン または 仮想マシン ）に同時にデータを保存する ネットワークの ことです。すべてのクラウド アプリケーションは分散システムであるため、アプリケーションが最も必要とする特性を実現するデータ管理システムを選択できるように、クラウド アプリケーションを設計する際には 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は シングルマスターシステムで 、 各レプリカセット（リンクはibm.comの外部に存在する）には、すべての書き込み操作を受け取るプライマリノードが1つしかありません。同じレプリカ セット内の他のすべてのノードは、プライマリ ノードの操作ログを複製し、それを独自のデータ セットに適用するセカンダリ ノードです。デフォルトでは、クライアントはプライマリ・ノードからも読み込むが、セカンダリ・ノードから 読み込むための優先読み込み（リンクはibm.com外に存在）を指定することもできる。

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

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

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

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

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

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