1. 概要

このチュートリアルでは、CAP定理を紹介して説明します。 また、配電システムの設計についても理解します。 最後に、提案された定理の問題を調べ、現在利用可能な代替案を見ていきます。

2. CAP定理

2.1. 歴史

CAP仮説は2000年にEricBrewerによって最初に導入されました。 ただし、この仮説の正式な証明は、他のコンピューター科学者によって2002年まで提案されませんでした。 その導入から、CAP定理(またはブリューワーの定理)として知られています。 当初、ブリューワーは、分散システムの侵害について社会が議論を始めることを望んでいました。

2.2. 基本的な定義

CAP は、Consistency、Availability、およびPartitionToleranceの略語です。 これらの3つの概念を簡単な言葉で説明しましょう。

  • 一貫性とは、すべての読み取り操作で最新のレコードが取得されることを意味します。 すべての情報は最新であることが保証されています。
  • 可用性は、分散システムが常に利用可能であることを示すプロパティです。 このようなシステムの1つ以上のノードがオフになる場合があります。 ただし、システムには他のノードからアクセスできます。
  • パーティション許容値は、システムをパーティション化する能力を表します。 したがって、すべてのノードが他のノードから独立して動作できることを意味します。

2.3. 定理

CAP定理によると、分散システムは3つのプロパティのうち2つしか満たすことができません。したがって、 CA AP 、またはCPのみが存在する可能性があります。 ]システム。 他の2つのプロパティはすでに保証されていますが、3番目のプロパティが達成されることを保証することはできません。 したがって、CAP分散システムは存在しません。 次のセクションでは、さまざまなタイプのシステムの例を見ていきます。

3. データベースとCAP

データベースの違いをより簡単に理解するための重要な定義を紹介しましょう。

3.1. レプリケーション

レプリケーションはデータベーススケーリング手法の1つです。この手法は、1つのデータベースサーバーからのデータを1つ以上の他のサーバー(レプリカと呼ばれる)に継続的に(複製)コピーできるという考えに基づいています。 アプリケーションが複数のサーバーを使用してすべての要求を処理することが可能になります。 したがって、1台のサーバーから複数のサーバーに負荷を分散することが可能になります。

通常、メインノードはマスターと呼ばれます。 すべてのレプリカはスレーブと呼ばれます。 マスターは、データベースに変更を加えるための書き込み操作のみをサポートする場合があります。 その後、変更は読み取り操作のためにすべてのスレーブのレプリカに配布されます。 これは、データベースの一貫性を維持するのに役立ちます。 このようなレプリケーションは、マスタースレーブレプリケーションと呼ばれます。

ただし、マスターとマスターのレプリケーションも存在し、マスターとすべてのレプリカが読み取り操作と書き込み操作の両方を実行できるようになっています。

3.2. データベースの比較

最も一般的なデータベースのいくつかがタイプに従って分類されている三角形を見てみましょう。

ご覧のとおり、さまざまなタイプのデータベースは、 CA AP 、またはCPシステムとして厳密に分類されています。

CAシステムは、一貫性と可用性を保証します。ほとんどのリレーショナルデータベースは、CAシステムの例です。 たとえば、PostgreSQLでは、マスタースレーブレプリケーションと2フェーズトランザクションコミットアプローチで整合性が達成されます。 レプリカとマスターの同期は同期または非同期のいずれかであり、システムは強力に利用可能です。 問題はパーティショニング時に始まります。 PostgreSQLでパーティショニングを使用しようとしても、一貫性が保証されることはありません。

APシステムは、可用性とパーティションの許容範囲に関するものです。したがって、常に一貫しているとは限りません。 AP システムの例は、NoSQLデータベースがCassandraです。 これは、実際にはAPシステム定義に準拠するマスターマスターレプリケーションを使用します。 Cassandraへのパーティショニングを簡単に実行できます。 すべてのノードは独立したユニットになります。 したがって、少なくとも1つのノードが機能していれば、システムは使用可能になります。 ただし、パーティション化されたノード間の同期により、一貫性が低下する可能性があります。

CPシステムは一貫性があり、パーティションに耐性があります。 たとえば、MongoDBはNoSQLデータベースであり、 CP システム。 書き込み操作に単一のマスターノードを使用することで、強い一貫性が得られます。 MongoDBは、一貫性を失うことなくパーティション化できます。 ただし、パーティション分割すると、使用できなくなる場合があります。 すべての操作が安全に保存されることを確認するまで、システムは書き込み要求を受け入れません。

4. 単純な分散システム設計の例

このセクションでは、独自の分散システムの設計を試みます。 単一のノードから始めましょう。 ロギングサービスを提供するコールセンターで働いているとしましょう。 一部のアクティビティ(書き込み操作)の登録が必要なお客様からの電話があります。 彼らはまた、彼らが以前に私たちに言ったことを覚えておくように頼むために電話をかけることができるでしょう(操作を読んでください)。 すべての情報を1つのノートブックに書き込むことにしました。

すべてが正常に機能しますが、顧客の数は毎日増え始めています。 大きな列に並ぶ必要がありますが、電話に出るまで何時間も待てないお客様を失うことは承知しております。

友人をロギングサービスに招待することにしました。 彼はまた電話に出て、彼自身のノートから要求を書いたり読んだりします。 これで、2つの異なるノートブックがあることに注意してください。 問題が発生するまで、しばらくの間、すべてがはるかに良くなります。

4.1. APシステム

妻の誕生日を書き留めてほしいというお客様からの電話がありました。 数ヶ月後、妻の誕生日が近づいていることを知っていたため、彼は電話をかけ直しましたが、日付を思い出せませんでした。 今回は友達が電話に出ました。 私たちがそれを共有しなかったので、彼は彼のノートに誕生日に関する情報を持っていませんでした。 顧客は怒った:

上の画像では、電話は顧客を表しています。 とは、ロギングサービスの2つのノード、私たちと私たちの友人です。

上記の状況は不整合と呼ばれます。現在のところ、システムはAPシステムであり、使用可能であり、パーティションに耐性があります。

4.2. CPシステム

今、私たちは矛盾に対処することにしました。 お客様から私たちまたは私たちの友人に電話をかけるたびに、私たちはすべてをノートに書き込み、次にお互いに電話して情報を同期します。 そのため、顧客は常にサービスから真の情報を得ることができます。

また、病気になって1日以上働けなくなる場合もあります。 そのような場合、私たちの友人はまず、ノートブックを同期するために私たちに電話をかけることができるかどうかを確認します。 私たちが利用できない場合、彼は私たちに電子メールを送ります。 仕事に戻ったら、まずメールをチェックして、ノートブックに不足しているデータを入力します。

その結果、顧客はサービスからの回答を待つ必要があります。 ノートブックを更新するには、お互いに電話をかけたり、メールの情報を書き留めたりするのに時間を費やす必要があります。 サービスが少し利用できなくなります。 これは現在CPシステムです。

4.3. CAシステム

今、私たちの友人は辞めることにしましたが、ロギングサービスは引き続き機能します。 当初と同じように、電話とノートブックは1つだけです。 お気づきかもしれませんが、システムはまだ利用可能です。 引き続き電話に応答し、ノートブックにログインします。

したがって、私たちのシステムは一貫しています。 一貫性は、単一のソース、1つのノートブックを持つことによって達成されます。 友達のノートブックと同期する必要はもうありません。 ただし、ロギングサービスの単一ノードであるため、システムはパーティション化されていません。 これはCAシステムです。顧客数が多いために別の友人を引き受ける場合は、可用性または一貫性のいずれかを再度選択する必要があります。

4.4. 結果

この例からの結論は、システムプロパティから常に選択する必要があるということです。 完璧なシステムは存在しません。 要件、タイプ、および操作の頻度に応じて、常にシステムを構築する必要があります。 アイデアは、 C A 、およびPのバランスを見つけることです。

5. 問題と代替案

5.1. CAPの問題

現在、CAP定理は厳密には使用されていません。 いくつかの大きな誤解とあいまいな定義があり、実際のアプリケーションからはほど遠いものです。

CAPの可用性には2つの問題があります。 その1つは、部分的に使用可能なシステムの定義がないことです。たとえば、何らかの問題のためにノードの半分がオフになっているため、システムは50%で使用可能である可能性があります。 このシステムは引き続きお客様にご利用いただけます。 ただし、CAPでは使用できません。

2番目の問題は、 CAPの可用性が応答時間(遅延)をカバーしていないことです。 これは、読み取り要求の1時間後または1日後に応答するシステムが利用可能であることを意味します。

多くのシステムは、Pシステムである可能性があります。 マスタースレーブレプリケーション技術を使用したシステムを想像してみてください。 このようなシステムに、1つのマスターノード、1つのスレーブ、および顧客が含まれているとします。 顧客はスレーブから読み取り、マスターノードにのみ書き込むことができます。 マスターへの接続がすぐに失われると、顧客は可用性を失います。 私たちのシステムはCPになります。

別の状況を想像してみてください。 顧客はマスターへの書き込み操作を実行します。 次に、スレーブからの読み取りを試み、誤ったデータを取得します。 これは、システムに同期のための十分な時間がなかったために発生する可能性があります。 一貫性が失われました。 これで、可能であれば、システムはPになります。

5.2. PACELC

PACELC定理は、CAP定理の拡張および代替です。 PACELCのルールは、実際の分散システムにより適しています。 定理は一種の公式です。「システムがPの場合、AまたはC、それ以外の場合はCまたはL。」

簡単に言うと、システムがパーティショントレラントである場合は、その可用性または一貫性のどちらかを選択する必要があります。 システムをパーティション化して正常に動作させることができない場合は、一貫性のあるシステムを構築するか、低遅延(平均応答時間)のシステムを構築するかを選択します。

6. 結論

この記事では、BrewerのCAP定理とその代替案について学びました。 私たちは、システムが同時に利用可能で、パーティション化され、一貫性があり、低レイテンシーであることができないことを発見しました。 したがって、システム特性の選択は、アプリケーションと要件によって異なります。 システムが他のプロパティを満足させるには、いくつかのプロパティを犠牲にする必要があることを覚えておく必要があります。