分散システムの知識共有: CAP定理の正しい理解

序文

私は CAP に関する同僚の本やブログをたくさん読んできました。基本的に、人によって理解は異なりますが、ブリューワー教授の定義は具体的な説明やシナリオケースの分析がなく、単純すぎます。そこで、いくつかの情報を参考にして整理した記事を皆さんと共有したいと思います。

タイトルは正しい理解を反映しています。完全に正しくなかったり、曖昧な点もあるかもしれませんが、皆さんと共有し、議論した後、最終的な正解にたどり着けることを願っています。

導入

CAP 定理はブリューワーの定理とも呼ばれ、2000 年にエリック ブリューワー教授によって提唱された仮説です。分散システムでは、次の 3 つの点を同時に満たすことは不可能であると指摘しています。

一貫性: すべてのノードが同時に同じデータを参照します。

可用性: すべてのリクエストが成功したか失敗したかの応答を受け取ることを保証します。

パーティション耐性: システムの一部が失われたり故障したりしても、システムは動作を継続します。

多くの書籍や記事では、2014 年 8 月に Robert Greiner が書いたブログ投稿 (http://robertgreiner.com/2014/08/cap-theorem-revisited/) が引用されています。ブリューワー教授のわかりにくい定義に比べると、ロバート・グライナーの定義は理解しやすいです。

[[233434]]

意味

元のテキスト: 分散システム (データを共有する相互接続されたノードの集合) では、書き込み/読み取りペア全体で、一貫性、可用性、およびパーティション耐性の 3 つの保証のうち 2 つしか実現できません。そのうちの 1 つを犠牲にする必要があります。

翻訳: 分散システム (相互に接続され、データを共有するノードの集合) では、読み取りおよび書き込み操作に関しては、一貫性、可用性、およびパーティション耐性の 3 つのうち 2 つだけが保証され、残りの 1 つは犠牲にする必要があります。

キーワード: 相互接続されたノード、共有データ、書き込み/読み取りペア

上記の段落から、いくつかあります。つまり、CAP 定理について話すときは、データの読み取りと書き込み、データの共有、ノードの相互接続を前提として、上記の 3 つのうち 2 つを選択します。また、これら 3 つを同時に満たすために時間とエネルギーを費やすべきではないことも示唆しています。

たとえば、Web クラスターや memcached クラスターは説明に含まれていません。

Web クラスターは、リソースをコピーして、異なるノードに配布するだけです。ただし、ノード間の相互接続はなく、データの共有 (セッション ID、メモリ キャッシュ) もありません。

Memcached クラスター データ ストレージはクライアントを通じてハッシュの一貫性を実現しますが、クラスター ノードは相互接続されておらず、データの共有は行われません。

一般に、CAP 定理は分散システムのすべての機能について議論するものではありません。

一貫性

元のテキスト: 読み取りでは、特定のクライアントの最新の書き込みが返されることが保証されます。

翻訳: 特定のクライアントの場合、読み取り操作は最適な書き込み操作結果を返すことが保証されます。

キーワード: 特定のクライアント。

ここでの一貫性は、私たちが通常理解している ACID 一貫性とは少し異なります。 ACID 一貫性は、データベースのデータ整合性に重点を置いています。

上記の定義では、すべてのノードが同時に一貫したデータを持つ必要があるとは指定されていませんが、クライアントに焦点が当てられています。 ATM（クライアント）で銀行カードに500元を入金し、ATMで残高照会を開始するとすぐに、500元追加後の残高が表示され、その後500元を引き出すこともできるというシナリオがあるとします。バランスクエリの読み取り操作は、書き込み直後にマスターデータベースを読み取ることも、書き込み後一定時間経過後にスレーブデータベースを読み取ることもできます（途中の書き込みはありません）。

可用性

元のテキスト: 障害のないノードは、妥当な時間内に妥当な応答を返します (エラーやタイムアウトはありません)。

翻訳: 障害のないノードは、妥当な時間内に妥当な応答 (エラーやタイムアウトではない) を返します。

キーワード: 障害のないノード、適切な応答

ここでの可用性は、私たちが通常理解している高可用性とは少し異なります。高可用性とは、システムが中断することなく機能を実行できる能力を指します。

要求の結果がエラーまたはタイムアウトになったため、失敗したノードは使用できません。適切な応答では成功または失敗は指定されませんが、応答には成功または失敗の正確な説明が含まれている必要があります。たとえば、SQL Server クラスター内のスレーブ データベースを読み取る場合、同期に時間がかかり、読み取られるデータは最新のデータではない可能性がありますが、これは妥当な応答です。

パーティション耐性

元のテキスト: ネットワークパーティションが発生しても、システムは機能し続けます。

翻訳: ネットワークパーティションが発生しても、システムは正常に動作し続けます

キーワード: 機能を継続する（通常動作を継続する）

マスター 1 台とスレーブ 2 台で Redis クラスターを作成し、ある日ネットワーク障害によりスレーブ ノードの 1 台が使用できなくなったが、他のマスター 1 台とスレーブ 1 台が正常に動作できる場合、パーティション フォールト トレランスが備わっていると考えられます。

CAはパーティション耐性を犠牲にする

分散システムなので、パーティションは必ず発生する（2年に1回50分とか、1年に3回10分とか？）ので、CAPの議論はPが成立するという前提で行われることが多いと思われます。 P を犠牲にし、ネットワーク障害によりパーティションが発生し、ノードが使用できなくなるとします。この時点で、リクエストはエラーまたはタイムアウトで応答し、可用性の定義と矛盾します。

しかし、ほとんどの場合、パーティションが存在しないと仮定すると、単一ノードの読み取り/書き込みでは、C と A の間でトレードオフを行う必要はありません。しかし、パーティションが常に発生すると言うのは矛盾していませんか?それはまだトレードオフです。 1 年間のうち 99.99% の時間が正常で、利用できない時間が 0.01% (52.56 分) の場合、この時間が業務の許容範囲内である場合、または特定の地域 (華南、華北、華中など) にのみ影響がある場合は、CA を選択することもできます。

PC - 使いやすさを犠牲にする

最も一般的なケースは、RDBMS クラスターと Redis クラスターです。どちらも、マスターとスレーブのレプリケーションを使用して読み取りと書き込みの分離を実現します。両者が 1 つのマスターと複数のスレーブでクラスターを構築し、マスター ノードにデータを書き込む場合、後続の読み取り操作で最新のデータ (一貫性) を取得することを保証するために、この読み取り操作は依然としてマスター ノードに要求します (読み取りと書き込みの分離の複雑さは、スレーブ データベースを時間内に同期できないと業務異常につながることです。業務の正常性を保証するために、書き込み後の読み取りはマスター データベースに要求します)。スレーブ ノードがハングアップした場合でも、マスター ノードと他のスレーブ ノードが正常に動作している限り、パーティションのフォールト トレランスは満たされます。ただし、ある日、ネットワーク障害によりマスター ノードの書き込み操作でエラーまたはタイムアウトが発生すると、システムは使用できなくなります (可用性が犠牲になります)。

この時点で、Redis センチネル モードやフェイルオーバー機能など、タスクを完了するための他の機能やメカニズムを導入できます。

PA - 一貫性を犠牲にする

最も典型的なケースは、Cassanda クラスターと Riak クラスターです。このタイプの分散データベースは、任意のノードに書き込み、任意のノードから読み取りが可能です。クラスターとして表示される場合、どのノードに書き込まれたかに関係なく、そのノードのデータは他のノードに同期されます。この同期方法のため、データを読み取るときは 1 つのノードにアクセスすれば十分です (任意にアクセスできます) が、他のノードのデータ同期の理由により、データが完全でない可能性があります (一貫性が犠牲になります)。ネットワーク異常によるパーティションにより、現在のノードが使用不可（読み取り/書き込みに関係なく）になった場合、アクセスノードを転送できます（可用性）。

さらに、ここで一貫性を犠牲にするということは、一貫性を放棄することを意味するものではありません。 PA は最終的な一貫性を選択します (システム内のすべてのデータ コピーは、同期期間の後に最終的に一貫した状態に到達できます)。

要約する

上で述べた「犠牲」という言葉は、どちらか一方を選択することを意味するものではありません。サブシステムやモジュール（PA と PC、CA と PC など）の設計に応じて組み合わせることができます。

この記事では、CAP 定理の簡単な要約と説明を、いくつかの書籍や記事を参考にしながら私自身の理解を加えて、皆さんと共有したいと考えています。記事の説明に誤りがある場合など、異なる提案や意見がある場合は、以下にコメントしてください。適時に修正いたします。