CAP定理

menu icon

CAP定理

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

CAP定理の概要

低価格、短時間、高品質。いずれか2つをお選びください」の見出しで始まる、造園業者や塗装業者の広告を見たことがあるでしょうか。

CAP定理は、分散システムに同様の論理を適用します。 この定理では、分散システムは、望ましい3つの特性である、一貫性(Consistency、つまり「CAP」の「C」)、可用性(Availability、「CAP」の「A」)、分断耐性(Partition tolerance、「CAP」の「P」)のうち、いずれか2つしか提供できないことが示されています。

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

CAP定理は、「ブリュワーの定理(Brewer’s Theorem)」とも呼ばれます。これは、Eric A. Brewer教授が、 2000年に分散コンピューティングについての講演を行った際に、初めて提唱したためです。 その2年後、MITのSeth Gilbert教授とNancy Lynch教授が、「ブリュワーの推論」の証明を発表しました。

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

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

一貫性

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

可用性

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

分断耐性

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

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

NoSQL(非リレーショナル)データベースは、分散ネットワーク・アプリケーションにとって理想的なデータベースです。 NoSQLデータベースは、垂直方向にスケーラブルなSQL(リレーショナル)データベースとは異なり、水平方向にスケーラブルな分散型の設計です。つまり、複数の相互接続されたノードで構成された拡大するネットワークに素早く対応して、規模を拡張することが可能です(「SQLデータベースとNoSQL データベース:その相違点は?」を参照してください)。

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

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

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

CAP定理とMongoDB(CP)

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

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

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

CAP定理とCassandra(AP)

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

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

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

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

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

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

IBM CloudとCAP定理

IBMは、あらゆる種類のフルマネージド・データベース・サービスを提供しています。 IBM Cloud上では、リレーショナル・データベース管理システムの他に、MongoDBCloudant(同じくAP分散データ・ストア)、Elasticsearchetcdなど、さまざまなデータベース・ソリューションを実行できます。

IBMのデータベースのラインアップを閲覧するには、IBMidを登録し、IBM Cloudアカウントを作成してください(コミットメントは不要です)。