CAP定理
cloud leadspace
CAP定理の概要とは何ですか?

ここでは、CAP定理について解説します。さらに、分散アプリケーションを設計する際に、NoSQLデータ・ストアまたはリレーショナル・データ・ストアを選択する場面で、この定理がどのように関係するのかについても見ていきます。

「安い、速い、よい、から2つ選んでください」という見出しで始まる造園業者、塗装業者、または他の業者の広告を見たことがありますか。

CAPの定理は、似た論理を分散システムに適用したもので、分散システムは3つの望ましい特性のうち2つしか実現できないというものです。一貫性可用性および分断耐性です。CAPの「C」「A」、および「P」です。

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

このCAP定理は、2000年にEric A. Brewer教授が分散コンピューティングに関する講演で初めて提唱したことから、Brewerの定理とも呼ばれています。 その2年後、MITのSeth Gilbert教授とNancy Lynch教授が、「Brewerの推論」の証明を発表しました。

 

注目の製品

Cloudant

DataStax

IBM Cloud Databases for MongoDB


CAP定理の「CAP」が意味するもの

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

一貫性

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

可用性

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

分断耐性

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


CAP定理におけるNoSQLデータベースの分類

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に代表される多くのリレーショナル・データベースは、一貫性と可用性を備えており、複製を用いて複数のノードに展開することができます。


CAP定理とMongoDB(CP)

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

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

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


CAP定理とCassandra(AP)

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

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

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


マイクロサービスでの活用

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

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


IBM CloudとCAP定理

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

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

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


関連ソリューション

IBM Cloud上のクラウド・データベース

基幹業務ワークロードからモバイル・アプリケーションやWebアプリケーション、分析に至るまで、さまざまなユース・ケースに対応するIBMの多様なクラウド・データベースをご検討ください。


IBM Cloudant

IBM Cloudantは、Apache CouchDBに基づくスケーラブルな分散クラウド・データベースで、Webアプリケーション、モバイル・アプリケーション、IoTアプリケーション、サーバーレス・アプリケーションに使用されます。


DataStax Enterprise with IBM

Apache Cassandraをベースに構築されたスケーラブルで可用性の高いクラウド・ネイティブなNoSQLデータベースの、購入、導入、およびサポートを一元的に提供するIBMから取得してください。


IBM Cloud Databases for MongoDB

IBM Cloudにネイティブ統合され、エンタープライズ対応に構築された、サービスとしてのMongoDBです。


IBM Cloud Databases for Elasticsearch

全文検索エンジンとJSONドキュメント・データベースのインデックス機能を備えた、豊富なデータのための強力なツールであるDatabases for Elasticsearchの詳細を説明します。


IBM Cloud Databases for etcd

サーバー・クラスターを管理するためのデータを保持する、エンタープライズ対応のフルマネージド型キー値ストアを提供するIBM Cloud Databases for etcdの詳細をご覧ください。