分散ストレージシステムの理論的指針をCAPからPACELCに移行する時期が来ている

CAP 理論は、分散ストレージ システムの現在の設計に対する理論的ガイドラインであり、PACELC 理論は CAP 理論の拡張です。分散ストレージ システムの設計の理論的基礎を CAP 理論から PACELC 理論に拡張する時期が来ています。

WikiにおけるPACELCの定義は

「分散コンピュータ システムでネットワーク分割 (P) が発生した場合、CAP 定理に従って可用性 (A) と一貫性 (C) のどちらかを選択する必要があるが、それ以外の場合 (E) は、分割が行われずにシステムが正常に動作している場合でも、レイテンシ (L) と一貫性 (C) のどちらかを選択する必要がある」と述べています。

簡単に言えば、これは次のことを意味します。「パーティション (P) がある場合、システムは可用性と一貫性 (A と C) のバランスを取る必要があります。そうでない場合 (E)、システムがパーティションなしで実行されている場合、システムはレイテンシ (L) と一貫性 (C) のバランスを取る必要があります。」

[[232158]]

CAP 理論では、次の 3 つを同時に満たすことはできないとされています。

1) 一貫性: すべてのノードが同時にまったく同じデータを持ちます。

2) 可用性: ノード障害はシステムの IO に影響を与えません。

3) パーティション耐性: システムはネットワーク パーティション (ネットワーク接続障害) をサポートし、パーティション間のメッセージが失われた場合でも正常に動作します。

ビジネス シナリオに応じて、さまざまな分散ストレージ システムが、独自のビジネス ニーズに基づいて 3 つの CAP 要素間でトレードオフを行います。 CAP 理論の重要性は、3 つの要素のうち 2 つを選択するのではなく、分散ストレージ システムを設計するときに考慮する必要がある要素にあります。また、CAP 理論ではレイテンシについては触れられていませんが、レイテンシは非常に重要な可用性指標です。

CAP はシステムのレイテンシ要因を考慮していないため、次の図に示すように、レイテンシを追加した新しいモデル PACELC が定義されます。

現在の分散ストレージ システム設計ガイダンス理論では、次の理由により、CAP 理論ではなく PACELC 理論を使用する必要があります。

1) PACELC は、実際の運用における分散ストレージ作業シナリオをより適切に満たすことができ、より優れたエンジニアリング実装戦略です。

2) パーティション (P) が存在する場合、可用性と一貫性 (A と C) の間でトレードオフを行う必要があります。実際、分散システムではほとんどの場合パーティション (P) は存在しないため、レイテンシ (L) と一貫性 (C) の間でトレードオフを行う必要があります。

3) 可用性は、パーティション (P) がない場合にはレイテンシと関連付けられ、パーティション (P) がある場合には信頼性と関連付けられます。

4) PACELC はレイテンシと一貫性のバランスを実現できます。

5) CAP 定理は、一貫性とレイテンシの間のトレードオフを無視します。

PACELC は CAP の上に構築されており、どちらも一貫性、可用性、パーティション耐性の間の制限とトレードオフを記述しています。 PACELC はさらに、パーティションがない場合でも、レイテンシと一貫性の間にトレードオフがあることを説明しており、分散システムの一貫性モデルのより完全な理論的根拠を提供しています。

システムの高可用性を確保するには、データを複製する必要があります。ただし、データのレプリケーションでは、一貫性とレイテンシの間でトレードオフが必要になります。

以下に示す PACELC アプリケーション シナリオの例を見てみましょう。

1. 強力な一貫性レプリケーション シナリオでは、クライアントに OK を返す前に、3 つのレプリカすべてをディスクに保存する必要があります。マスターはデータをスレーブにコピーし、レイテンシ制限は 20 ミリ秒です。場合によっては、スレーブ 2 のハードディスクまたはネットワークに障害が発生し、マスターがスレーブにデータをコピーする際の遅延が 20 ミリ秒を超えることがあります。このとき、スレーブ 2 が結果を返すまで待ってからクライアントに通知すると、パフォーマンスとレイテンシのジッタが発生し、このジッタは頻繁に発生するロングテール効果です。

2. PACELC 理論によれば、一貫性とレイテンシの間でトレードオフを行うことができます。たとえば、スレーブ 2 ノードのレイテンシが 20 ミリ秒を超える場合、スレーブ 2 が戻るのを待たずに、マスターとスレーブ 1 が結果をクライアントに返すことができます。スレーブ 2 が 5 回以上タイムアウトした場合、このノードに障害がある可能性があるとみなされ、後続の処理のために障害ラベルが追加されます。