CAP定理で言及される、分散システムの3つの特性について詳しく説明します。

一貫性

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

可用性

可用性とは、1つ以上のノードがダウンしている場合でも、データの要求を行うクライアントが応答を受け取ることを意味します。 すなわち、分散システム内のすべての作業ノードが、どんな要求に対しても、常に有効な応答を返すということです。

分断耐性

分断は、分散システム内の通信障害です。2つのノード間の接続が失われたか、一時的に遅延している状態です。 分断耐性とは、システム内のノード間でさまざまな通信障害が発生した場合に、クラスターが引き続き機能できることを意味します。

NoSQL（非リレーショナル）データベースは分散型ネットワーク・アプリケーションに最適です。 NoSQLデータベースは、垂直方向にスケーラブルなSQL（リレーショナル）データベースとは異なり、水平方向にスケーラブルな分散型の設計です。つまり、複数の相互接続されたノードで構成された拡大するネットワークに素早く対応して、規模を拡張することが可能です。 （詳細については、「SQL vs. NoSQL Databases: What's the Difference?」をご覧ください。）

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

• CPデータベース： 可用性を犠牲にして、一貫性と分断耐性を提供します。 2つのノード間で分断が発生した場合、システムは、分断が解消されるまで、整合しなくなったノードをシャットダウンする（使用不可にする）必要があります。
• APデータベース： APデータベースは、一貫性を犠牲にして、可用性と分断耐性を提供します。 このタイプでは、分断が発生しても、すべてのノードを使用できます。しかし、分断されて損なわれた側にあるノードは、他のノードより古いバージョンのデータを返すことがあります。 （分断が解決すると、APデータベースは通常、ノードを再同期して、システム内のすべての不整合を修復します。）
• CAデータベース： CAデータベースは、すべてのノードで一貫性と可用性を提供します。 しかし、システム内の2つのノード間に分断が発生すると、一貫性と可用性を提供することはできなくなります。したがって、このタイプのデータベースでは、フォールト・トレランスは提供されません。

このタイプを最後に挙げた理由は、分散システムでは分断を回避できないためです。 つまり、CA分散データベースについては、理論上の検討を行うことはできても、実際的には存在しないと言えます。 しかし、ご使用の分散アプリケーションでCAデータベースを必要とする場合に、このタイプのデータベースを使用できないということではありません。 PostgreSQLに代表される多くのリレーショナル・データベースは、一貫性と可用性を備えており、複製を用いて複数のノードに展開することができます。

MongoDBは、データをBSON（バイナリーJSON）文書として保管する、一般的なNoSQLデータベース管理システムです。 複数の異なる場所で実行されるビッグデータやリアルタイム・アプリケーションによく使用されます。 CAP定理による分類では、MongoDBはCPデータ・ストアです。つまり、可用性を犠牲にしますが、一貫性を維持してネットワークの分断を解消します。

MongoDBはシングル・マスターのシステムであり、各レプリカセット （ibm.com外部のリンク）には、すべての書き込み操作を受ける1次ノードが1つしかありません。 同じレプリカ・セット内のほかのすべてのノードは2次ノードです。2次ノードは、1次ノードの操作ログを複製して自身のデータ・セットに適用します。 デフォルトでは、クライアントは読み取りも1次ノードで行いますが、2次ノードからの読み取りを可能にするように読み取りの優先 （外部へのリンク）を指定することもできます。

1次ノードが使用不可になると、最新の操作ログを持つ2次ノードが新しい1次ノードとして選出されます。 ほかのすべての2次ノードが新しいマスターと整合すると、そのクラスターは再び使用可能になります。 それまでの間は、クライアントは書き込み要求を行うことができないため、ネットワーク全体でのデータの整合性が保たれます。

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

CAP定理による分類では、CassandraはAPデータベースです。可用性と分断耐性を提供しますが、一貫性を常に提供することはできません。 Cassandraにはマスター・ノードがなく、すべてのノードが常に使用可能な状態でなければならないためです。 しかし、Cassandraは、クライアントがいつでも任意のノードに書き込みを行えるようにし、不整合をできるだけ迅速に調整することで、結果整合性を提供します。

ネットワークの分断が発生した場合にのみ、データは不整合になりますが、この不整合は迅速に解消されます。そのために、Cassandraでは「修理」機能 を提供して、ノードの整合性の回復を支援しています。 Cassandraを使用すると、安定した可用性を得られるため、システムのパフォーマンスは向上します。そのため、多くの場合、この一時的に不整合が生じるというデメリットは許容されます。

マイクロサービスは、個々にデプロイ可能な、疎結合のアプリケーション・コンポーネントです。独自のスタック（独自のデータベースとデータベース・モデルを含む）が組み込まれており、ネットワークを介して相互に通信します。 マイクロサービスは、クラウド・サーバーとオンプレミス・データセンターのどちらでも実行可能です。そのため、ハイブリッドおよびマルチクラウド・アプリケーションで、非常に高い人気を得ています。

CAP定理を理解すると、複数の場所で実行されるマイクロサービス・ベースのアプリケーションを設計する際に、最適なデータベースを選択できます。 例えば、ご使用のアプリケーションで、データ・モデルの迅速な反復処理と水平スケーリングの機能が不可欠である一方、（厳密とは反対の）結果整合性を許容できるという場合は、CassandraやApache CouchDBのようなAPデータベースが要件を満たすため、デプロイメントが簡素化します。 一方、e-コマース・アプリケーションや決済サービスのように、アプリケーションがデータの整合性に大きく依存している場合は、PostgreSQLなどのリレーショナル・データベースを選択できます。

IBMは、あらゆる種類のフル・マネージド・データベース・サービスを提供しています。 IBM Cloud上では、リレーショナル・データベース管理システムと以下を実行できます。

• Cloudant（AP分散型データ保存）
• DataStax Enterprise（Cassandraをベースにした、ハイブリッドクラウド向けのデータベース）
• MongoDB、Elasticsearch、etcd、およびその他のデータベース・ソリューション。

IBMのデータベース・セレクション全体を見るには、IBMidにサインアップし、IBM Cloudアカウントを作成してください。