分散システムのCAP定理とBASE理論

[[386799]]

この記事はWeChatの公開アカウント「Coder's Private Talk」から転載したもので、著者はGoQengです。この記事を転載する場合は、Coder Private Talk の公開アカウントにご連絡ください。

最近、インタビューの前にテンセントテンペイ登録センターの知識ポイントをまとめていました。しかし、書いていくうちに、基礎的な理論的な準備が必要な機能的なポイントがたくさんあることに気づきました。そこで、面接試験のポイントを理解しやすくするために、まずは分散システムでよく使われる理論をまとめることにしました。

CAPとは何ですか?

分散システムの基本理論である CAP 理論は、分散システムを次の 3 つの特性で説明します。

一貫性
可用性
パーティション耐性

下の図に示すように、最大で 2 つの特性を満たすことができます。分散システムは CA、CP、または AP のいずれかを満たすことができますが、CAP を同時に満たすことはできません。

パーティション耐性: 分散システム内のノードまたはネットワークパーティションに障害が発生した場合でも、システム全体は一貫性と可用性を満たすサービスを引き続き提供できます。つまり、部分的な障害は全体的な使用には影響しません。

可用性: システムは常に読み取りおよび書き込み操作を正常に実行できます。簡単に言えば、クライアントは常にシステムにアクセスして、システムから通常の応答を受け取ることができます。ユーザーの観点からは、システム動作障害やアクセスタイムアウトなどの問題は発生しません。

一貫性: 分散システムが書き込み操作を完了すると、すべての読み取り操作は書き込み操作によって書き込まれた最新の値を取得する必要があります。これは、分散システム内の各ノードが常にデータの一貫性を維持することを要求するのと同じです。

CAP を理解するには?

まず、パーティションのフォールトトレランスを確保するという前提の下、ノードに障害が発生しても、ユーザーは引き続きアクセスできます。ただし、現時点では、次の図に示すように、ユーザーのアクセスプロセス中に一貫性と可用性を同時に満たすことはできません。

シナリオ 1:

分散システムに S0 と S1 という 2 つのノードがあるとします。ノード内の変数の初期値は v0 です。ここで、クライアントは新しい値 v1 をシステムに書き込みます。ここでは、値がノード S0 に直接書き込まれると想定します。書き込み後、クライアントは再度値を読み取りますが、今回はノード S1 から値を読み取ります。

S1 ノードは S0 ノードとの通信を失っているため、S0 ノードのデータは S1 ノードにまだ同期されておらず、クライアントは古い値 v0 を読み取ります。その結果、一貫性違反が発生します。つまり、可用性は満たされますが、一貫性は失われます。

シナリオ2:

同様に、システムが強力な一貫性を保証する場合、クライアントが S0 ノードにデータを書き込んだ後、S0 から S1 ノードへのデータの同期に問題が発生します。このとき、クライアントが S1 ノードから再度データを読み取ると、システム内の各ノードのデータが同期されていないため、クライアントは待機状態になります。使用するには、同期が完了するまで待つ必要があります。つまり、一貫性は満たされますが、可用性は失われます。

シナリオ3:

複数のクライアントがデータにアクセスする場合、一貫性と可用性は次のように理解できます。クライアント 1 が S0 の値を変更したときに書き込み操作がまだ完了しておらず、クライアント 2 が値の読み取り操作を開始して S1 ノードの値を読み取るとします。この時点で、一貫性が満たされるには、クライアント 1 を一時的に使用不可にする必要があります。クライアント 2 が使用可能である場合、取得されたデータは最新ではなく、システムは一貫性を満たしていません。

CAP: 3つすべてを手に入れることはできないので、どうやって選ぶのですか?

CA: 一貫性と可用性を優先し、パーティション耐性を放棄します。これはシステムのスケーラビリティを放棄するということでもあり、システムは分散されなくなり、当初の設計意図に反することになります。

CP: 一貫性とパーティション耐性を優先し、可用性を犠牲にします。 Zookeeper や Hbase など、データの一貫性要件が比較的高い状況では、これは一般的な方法です。ネットワーク障害やメッセージの損失が発生すると、ユーザーエクスペリエンスが犠牲になり、回復後にユーザーは徐々にアクセスできるようになります。

AP: 可用性とパーティション耐性を優先し、一貫性を放棄します。 Spring Cloud システムで使用される Eureka レジストリはこのタイプのアーキテクチャですが、一貫性を放棄することは、強い一貫性を放棄し、結果的一貫性を確保することだけを意味します。

BASE理論とは何ですか?

BASE は、Basically Available、Soft State、Eventually Consistent の 3 つのフレーズの略語であり、eBay のアーキテクトによって提案されました。

ベース理論は、CAP における一貫性と可用性のトレードオフの結果です。これは、大規模なインターネット分散実践の要約から生まれ、CAP 定理に基づいて徐々に進化してきました。

基本的な考え方は、強力な一貫性は実現できないため、各アプリケーションは独自のビジネス特性に基づいて、システムが最終的な一貫性を実現できるように適切な方法を採用できるというものです。

基本的に利用可能

基本的な可用性とは、システムのモジュールで予期しない障害が発生した場合でも、他のモジュールは引き続き利用可能であることを意味します。たとえば、ショッピングモールのダブルイレブンイベント中にコメントモジュールが失敗しても、トランザクションや製品などのコアモジュールのプロセス使用には影響しません。

ソフトステート

ソフト状態とは、システム内のデータが中間状態で存在することが許可され、この状態がシステム全体の可用性に影響を与えないと見なされることを意味します。つまり、システムでは、複数の異なるノード上のデータコピーでデータの遅延が許容されます。

ユーザーがモールで注文すると、ネットワークタイムアウトなどの要因により、注文は「支払い中」の状態になります。最終的にデータの整合性が確保されると、状態は「クローズ」または「成功」に変わります。

最終的に一貫性

上述のソフトな状態は永遠にソフトな状態のままではいられない。時間制限があるはずです。期限後は、すべてのレプリカがデータの一貫性を維持し、最終的なデータの一貫性を実現することが保証される必要があります。これにより、システムデータにアクセスするすべてのクライアントが最終的に最新の値を取得できるようになります。この時間制限は、ネットワークの遅延、システムの負荷、データ複製スキームなどの要因によって異なります。

CAP の一貫性を保つには、いつでもクエリを実行したときに各ノードのデータが一貫している必要があります。強力な一貫性を重視し、最終的な一貫性では、一定期間内に各ノードのデータが不一致であってもかまいませんが、一定期間が経過すると、各ノードのデータは一貫している必要があります。最終データの一貫性を重視します。

実際のシナリオでは、最終的な一貫性には 5 つの種類があります。

1. 因果関係の一貫性

ノード A が特定のデータを更新した後にノード B に通知すると、ノード B のその後のデータへのアクセスと変更は、更新された A の値に基づいて行われます。ただし、ノード A と因果関係のないノード C へのデータアクセスには、このような制限はありません。

2. 書いたものを読む

ノード A がデータを更新した後、古い値を参照することなく、ノード A 自身が更新した最新の値に常にアクセスできます。

3. セッションの一貫性

セッションの一貫性により、セッション内のシステムデータへのアクセスプロセスが制限されます。システムでは、同じ有効なセッション内で「書き込んだ内容を読み取る」という一貫性を確保できます。つまり、更新操作を実行した後、クライアントは常に同じセッション内でデータ項目の最新の値を読み取ることができます。

4. 読み取り一貫性

単調な読み取り一貫性とは、ノードがシステムからデータ項目の値を読み取る場合、システムはノードへの後続のデータアクセスに対して古い値を返さないことを意味します。

5. 一貫性のある書き方

これは、システムが同じノードからの書き込み操作が順番に実行されることを保証できる必要があることを意味します。

実際のシステムでは、上記 5 種類の結果整合性を組み合わせて、結果整合性を備えた分散システムを構築することが多いです。