CAP定理 - 不可能な選択

「安い、早い、良い、2つ選んでください」？

CAP 定理: ケーキを食べて、それをまた手に入れることはできません。

• 一貫性: ケーキはいつも同じ味です。
• 入手可能性: ケーキはいつでも食べることができます。
• パーティション許容度: パイを分割して共有できます。

CAP 定理は同様の論理を分散システムに拡張します。具体的には、分散システムは、一貫性、可用性、および分断耐性 (CAP の文字「C」、「A」、「P」) という 3 つの望ましい特性のうち 2 つしか提供できないと述べています。

実際のコンピュータか仮想コンピュータかに関係なく、複数のノードに同時にデータを保存するネットワークは、分散システムと呼ばれます。

クラウド アプリケーションを開発する場合、すべてのクラウド アプリケーションは分散システムであるため、CAP 定理を理解することが重要です。

CAPの基本概念

分散システムの 3 つの特性に関する CAP 定理の概念を詳しく見てみましょう。

一貫性

クライアントがどのノードに接続しても、常に同じデータが同時に表示されます。これが一貫性です。

これを実現するには、データが 1 つのノードに書き込まれるたびに、書き込みが「正常に完了」したと見なされる前に、そのデータがシステム内の他のすべてのノードに直ちに送信または複製される必要があります。

可用性

ネットワーク内の 1 つ以上のノードが利用できない場合でも、データを要求するすべてのクライアントは応答を受け取ります。それが可用性です。

言い換えれば、分散システム内で実行中のすべてのノードは、例外なくすべての要求に対して正当な回答を提供します。

パーティション耐性

分散システム内での通信の中断はパーティションと呼ばれます。これは、システム内の 2 つのノード間の接続の損失または一時的な遅延として見られます。

「パーティション耐性」という用語は、システムを構成するさまざまなノード間の通信に何回障害が発生しても、クラスターの機能が維持される必要があることを意味します。

さまざまな NoSQL データベースの CAP 原則

画像

NoSQL データベースは、分散ネットワーク上で実行されるアプリケーションに最適です。垂直方向にスケーラブルな SQL (リレーショナル) データベースと比較すると、NoSQL データベースは水平方向にスケーラブルで、設計上分散されています。つまり、複数のリンクされたノードの拡大するネットワーク全体に迅速に拡張できるということです。

現在、NoSQL データベースは、次の 2 つの CAP 原則に基づいて分類されています。

CP データベースは、可用性を犠牲にして一貫性とパーティション耐性を提供します。 2 つのノード間でパーティションが発生した場合、システムはパーティションが解決されるまで、不整合のあるノードを停止する (つまり、アクセスできない状態にする) 必要があります。

AP データベースはデータの一貫性を犠牲にしますが、可用性とパーティション耐性を提供します。パーティションが発生すると、ネットワーク内のすべてのノードはアクセス可能なままですが、パーティションの先頭または末尾に近いノードは、他のノードよりも古いバージョンのデータを提供する場合があります。 (パーティションが解決されると、通常、AP データベースはノードを再同期して、システムに導入された可能性のある不整合を修正します。)

CA データベースは、システム内のすべてのノード間でデータの一貫性とアクセス可能性が維持されることを保証します。ただし、システム内の 2 つのノード間にパーティションがある場合はこのタスクを実行できず、フォールト トレランスを提供できません。

分散システムではパーティションが避けられないため、CA データベース タイプを意図的にリストの最後に配置します。したがって、CA 分散データベースの概念を理論的に議論することはできますが、実際には、そのようなデータベースは存在しません。ただし、分散アプリケーションに CA データベースが必要だと感じる場合でも、そのようなデータベースを使用できないわけではありません。

PostgreSQL を含むさまざまなリレーショナル データベースは、一貫性と可用性を提供し、分散展開のために複数のノードに複製できます。

CAP定理とMongoDB

MongoDB はデータを BSON (バイナリ JSON) ドキュメントとして保存するため、一般的な NoSQL データベース管理システムになります。大規模、リアルタイム、分散アプリケーションで広く使用されています。

MongoDB は、CAP 定理で説明されているように、可用性を犠牲にしてデータの一貫性を維持しながらネットワーク パーティションを解決できるため、CP データ ストアです。

MongoDB では、レプリカ セットにはすべての書き込み操作を処理するプライマリ ノードが 1 つだけ存在します。レプリケーション セット内のセカンダリ ノードは、プライマリ ノードのトランザクション ログをコピーし、それを使用して独自のデータのコピーを更新します。デフォルトではクライアントはマスターからデータを読み取りますが、読み取り設定を行うことでこの動作を変更できます。

元のノードに障害が発生した場合、最新の操作ログを持つセカンダリ ノードがプライマリ ノードに昇格されます。すべてのスレーブが新しい​​マスターに追いつくとすぐに、クラスターは再びアクセス可能になります。この間、クライアントは書き込み要求を送信できないため、データはネットワーク全体で同期されます。

CAP定理（AP）とカサンドラ

Apache Software Foundation は、無料のオープンソース NoSQL データベースである Cassandra を開発および配布しています。ワイドカラムデータベース形式で分散データストレージを実行します。 Cassandra はマスターレス設計のため、MongoDB のような単一障害点がありません。

Cassandra は、一貫性、可用性、パーティション耐性 (CAP) の要件の一部を満たしていますが、すべてを満たしているわけではないため、AP データベースです。マスター ノードがないため、Cassandra クラスター内のすべてのノードが常に稼働していることが重要です。一方、Cassandra は、クライアントがいつでも任意のノードにデータを書き込むことができ、不整合を迅速に解決できるようにすることで、最終的な一貫性を実現します。

Cassandra には、ネットワークが分割された場合にのみデータの不整合が発生し、その不整合がすぐに修正されるため、ノードがピアに追いつくのに役立つ「修復」機能があります。ただし、継続的な可用性により、高性能なシステムが実現され、場合によっては価格に見合う価値があるかもしれません。

結論は

マイクロサービスに基づく分散プロジェクトを作成する場合、CAP 定理を理解すると適切なデータベースを選択するのに役立ちます。たとえば、最終的な一貫性（厳密な一貫性ではない）は受け入れられるが、データ モデルを迅速に反復処理して水平方向に拡張する必要がある場合、Cassandra や Apache CouchDB などの AP データベースがニーズを満たし、展開を簡素化する可能性があります。

一方、電子商取引や決済サービスなど、アプリケーションの成功がデータの信頼性に依存する場合は、PostgreSQL などのリレーショナル データベースが最適な選択肢となる可能性があります。