現代の分散システムでは、トレードオフが重要です。パフォーマンス、信頼性、スケーラビリティ、一貫性は無料で得られるものではなく、常にどこかで代償を払うことになります。ここで CAP 定理が登場します。これは、分散設計における避けられない妥協を理解するための出発点です。  CAP 定理はなぜ正しいのでしょうか? 実際に何を説明するのでしょうか? そして最も重要なのは、それで十分なのでしょうか? この記事では、CAP 定理、その限界、直面した批判、そして PACELC などの新しいアイデアがどのように議論を前進させているかについて説明します。早速見ていきましょう。  CAP定理 CAP 定理の最初のバージョンは、  の論争として始まりました。しかし、時間が経つにつれて進化し、正式な証明を得て、今日知られている CAP 定理になりました。 ACID と BASE  CAP 定理は、 述べています。 分散システムが同時に満たすことができる特性は 3 つのうち最大 2 つであると 一貫性 可用性 パーティション耐性 この制限により、エンジニアはシステムの目標と分散環境の現実に応じて厳しいトレードオフを強いられます。 一貫性  CAP における一貫性は、  における一貫性とは異なります。CAP 定理では、これは または を指します。つまり、どのノードがリクエストを処理するかに関係なく 。つまり、どのノードにクエリを実行しても、すべての読み取り操作は最新の書き込みを反映します。 ACID トランザクション 線形化可能性 強い一貫性 、分散システム内のすべてのノードが常に単一の最新のデータ ビューを提示する必要があります  💡 一方、ACID における一貫性は、データベース スキーマで定義されたルールに従って、トランザクションがデータベースをある有効な状態から別の有効な状態に移行させることに重点を置いています。整合性制約 (外部キー、一意制約など) を適用し、クラッシュが発生してもデータベースが無効な状態にならないようにすることがより重要です。 可用性  CAP における可用性と ことを意味します。つまり、正常なノードが要求を受け取った場合、その要求を処理して応答する必要があります。ただし、CAP は ノードがサイレントに障害を起こさないことを保証するだけです (たとえば、  では、ノードは、可用性を確保するために、分割中に古いデータで応答する場合があります)。 は、ネットワークの分割に関係なく、障害のないすべてのノードが受信したすべての要求に対して応答を返す必要がある 応答が常に「正しい」または最新であることを保証するものではなく、 AP システム  💡 Eric Brewer (CAP の原作者) は当初、この特性を「ほぼすべてのクエリが応答を受け取る」ともう少し柔軟に説明していました。しかし、CAP の正式な証明では、可用性がさらに厳しくなり、「クエリを処理するノードが正常である限り、すべてのクエリが応答を受け取る」ことが求められました。 ただし、実際には、可用性は絶対的な保証ではありません。応答を待つ SLA (サービス レベル契約) の形成に重要な役割を果たします。詳細については、 をご覧ください。 時間の長さなど、システム固有の制約によって決まることがよくあります。実際のシステムでは、CAP 自体は遅延を直接考慮していませんが、応答時間 (またはタイムアウト) は こちらのブログ投稿 パーティション耐性 パーティション耐性は、ネットワーク障害を乗り切るためのものです。 パーティションは、パケットのドロップ、タイムアウト、またはネットワーク分割によりノードが通信できない場合に発生します。 ネットワーク分割 (パーティション) によりノードが通信できない場合でも、システムは設計上の選択に応じて一貫性または可用性の保証を満たす必要があります。 分散システムは、完璧なネットワークを備えたおとぎ話の世界に存在するわけではありません。パケットはドロップされ、タイムアウトが発生し、レイテンシの急増は避けられません。このため、 。パーティションは遅かれ早かれ発生するため、どんなに魅力的に思えてもそれを無視することを「選択」することはできません。 分散システムではパーティション耐性は譲れないものです  CAP では、パーティション耐性は、何も起こらなかったかのようにシステムが稼働し続けることを意味するわけではありません。パーティション発生時に、システムが可用性 (AP) と一貫性 (CP) のどちらを優先するかを決定する必要があることを意味します。パーティション耐性を無視すると、実質的に非分散型のモノリシック システムを構築することになります。  CAPの説明 CAP を理解する最も簡単な方法は、 (分散システムの 2 つの部分が相互に通信できない状況) について考えることです。このようなシナリオでは、システムは次の 3 つの結果に直面します。 ネットワーク パーティション 他の部分が分離されている場合、2 つの部分は不整合な状態になります。その結果、  が失われます。 システムの一部が更新を受け入れ、 C (一貫性) 、すべてのノード間で統一された状態を確保するために、パーティションの一方または両方の部分で更新をブロックする必要があります。これにより、一部の要求が拒否されるか無期限に遅延されるため、  が失われます。 システムが一貫性を維持することを選択した場合 A (可用性) 、そのシステムは真の意味で分散化されていません。この場合、ノードが対話して状態を調整する必要があり、分割中はそれが不可能になります。 システムが、分割 (P) を許容せずに、可用性 (A) と一貫性 (C) を維持することを選択した場合 したがって、 、システムは しか満たすことができません。分割が解決されると (つまり、ノードが再び相互作用すると)、システムは 3 つの特性すべてを回復できますが、 トレードオフは避けられません。 分割中は 3 つの特性 (C、A、または P) のうち 2 つ 分割中は 定理の意味 非同期システムの定理の結果として、一貫性、可用性、およびパーティション耐性の組み合わせは次の 3 つだけ可能になります。  AP (可用性 + パーティション耐性) このタイプのシステムはクエリに応答しますが、返されるデータは必ずしも最新ではない可能性があり、データの更新は遅くなりますが、「常に」利用可能です。このようなシステムの例としては、DNS、DynamoDB、Cassandra などがあります。  CP (一貫性 + パーティション耐性) このタイプのシステムは常に最新のデータを返しますが、パーティション分割されている場合、システム内の一部またはすべてのノードが応答しない可能性があります。アトミック更新が行われますが、タイムアウトが発生する可能性があります。Google BigTable、MongoDB、HBase、Redis などの NoSQL データベースはすべてこのタイプのシステムです。  CA (一貫性 + 可用性) このタイプのシステムは、パーティションがない場合には常に最新のデータを返します。最後の制限のため、通常、このようなシステムは 1 台のマシン内でのみ使用されます。例としては、従来のリレーショナル データベースがあります。 実際には、CA は基本的にパーティションのないモノリスであるため、CP と AP のどちらかを選択します。大規模システムの場合、設計者は P を放棄できないため、C と A の間で難しい選択を迫られます。  CAでは、ノード障害はサービスが完全に利用できなくなることを意味します。しかし、独立したモノリスを複製して負荷を分散できるため、スケーラビリティが無効になることはありません。  CAP定理の批判 CAP 定理は分散システムにおける基本的な概念ですが、限界がないわけではありません。トレードオフの考え方を明確に示しているにもかかわらず、CAP 定理は複雑な現実を過度に単純化し、誤解や誤った適用につながっていると批判されることがよくありました。  1. トレードオフは分割時にのみ適用される 最も一般的な批判の 1 つは、CAP 定理のトレードオフ と の選択) は、 実際に発生した場合にのみ適用されるというものです。通常の操作では、ネットワークが安定していて分割が存在しない場合、一貫性と可用性の間に本質的なトレードオフはありません。 (一貫性 (C) 可用性 (A) ネットワーク分割 (P) が さらに、これらのトレードオフはシステム全体に共通するものではありません。同じ分散システム内でも、 システムのさまざまな部分では、コンテキスト (ユーザーの場所、データの種類など) に基づいて、さまざまなトレードオフが発生する可能性があります。 特定の操作では一貫性を優先し、他の操作では可用性を優先する場合があります。 決定は、負荷、レイテンシ、ユーザー要件などの要因に応じて実行時に変わる可能性があります。 このニュアンスは、CAP に関する高レベルの議論では失われることが多く、システムが全体的に「CP」または「AP」として過度に単純化された分類につながることになります。  2. CAPはレイテンシを無視する もう 1 つの重要な批判は、レイテンシとパーティショニングは実際には深く関連しているにもかかわらず、CAP 定理では が考慮されていないことです。例: レイテンシ 低速ネットワーク (高レイテンシ) は、パーティションと区別がつかないように見える場合があります。 障害を検出するために使用されるタイムアウトは主観的であり、システム設計とネットワーク状態に大きく依存します。あるシステムで「パーティション」として定義されているものが、別のシステムでは単なる一時的な遅延である可能性があります。 実際の分散システムでは、パーティション分割や高レイテンシが発生すると、システムは 内に、おそらく古い結果を返して可用性を優先するか、より長く待機して（応答しない可能性もある）一貫性を優先するかを決定する必要があります。CAP のバイナリ ビューでは、これらの決定の複雑さは捉えられません。 タイムアウト期間  3. CAPプロパティはバイナリではない CAP 定理では、一貫性、可用性、および分断耐性は、2 つの特性、つまり、これらを備えているか備えていないかのどちらかであると説明されています。しかし、実際には、 。 これら 3 つの特性はすべてスペクトル上に存在します 、2 進の「オン/オフ」プロパティではなく、0% から 100% の範囲です。たとえば、システムは 99.99% の可用性を保証できますが、それでも短時間は利用できない状態が続きます。 可用性は 、結果的一貫性から因果的一貫性、強い一貫性まで、さまざまなレベルがあります。すべてのアプリケーションで完全な線形化が求められるわけではありません。 一貫性には 自体は明確なイベントではありません。パーティションが存在するかどうかについて、システム間で意見が一致しない場合があります (たとえば、1 つのノードではタイムアウトを障害と見なしますが、別のノードでは正常に動作を続けます)。 パーティション耐性 このプロパティの連続的な性質により、CAP は現代の分散システムの複雑さをモデル化するには過度に単純化されています。  PACELC定理 CAP は分散システムにおけるトレードオフの理解に革命をもたらしましたが、このテーマに関する最終的な結論ではありません。Daniel  分散システムの設計に対する代替アプローチと考えられています。これは CAP モデルに基づいていますが、一貫性、可用性、およびパーティション耐性に加えて、これらの概念の組み合わせ間のレイテンシと論理的排他性も含まれています。 J. Abadi が説明した PACELC 定理は、  PACELC は、分散システムに対して 2 つの異なる動作モードを導入します。 (   ): パーティションが発生した場合、システムはどのようなトレードオフを行うのでしょうか。ここでは、 と の間の従来の CAP トレードオフを再検討します。 パーティション モード PAC 可用性 (A) 一貫性 (C)   (   ): パーティションがなく、ネットワークが正常に機能している場合、システムはどのようなトレードオフを行うのでしょうか。このモードでは、システムは と の間で異なるトレードオフに直面します。  Else モード ELC レイテンシ (L) 一貫性 (C) レイテンシと一貫性のトレードオフ 分散システムではパーティションは避けられませんが、通常の運用中に発生する問題に比べると稀です。現代の分散システムでは、特にグローバル規模のアプリケーションでは、ネットワーク パーティションよりも ボトルネックになることがよくあります。PACELC 、パーティションなしでシステムが動作する場合のトレードオフに対処することで、この点に焦点を当てています。障害シナリオでの動作のみに焦点を当てる CAP とは異なり、PACELC は、 と のバランスをとるためにアーキテクトが毎日行う決定を重視しています。 レイテンシの方が は レイテンシ (L) 一貫性 (C) 実現するには、データの統一されたビューを維持するために、ノード間の調整と同期が必要です。このオーバーヘッドにより遅延が発生し、応答時間が遅くなります。 強力な一貫性を (最終的な一貫性を採用しているシステムなど) では、一貫性の保証を緩めて速度を優先します。これらのシステムは応答が速くなりますが、古くなったデータや一貫性のないデータが返されることがあります。 低レイテンシのシステム  PACELC は、会話をパーティションを超えて通常の操作にまで拡張することにより、分散システムの日常的なパフォーマンスが適切な重要性を持って扱われることを保証します。 まとめ CAP 定理の定式化はコミュニティにとって重要な出来事であり、分散システム設計への影響に関する研究では、分散システムの設計者はシステムを 2 つの特性に限定すべきではなく、それぞれの特定のケースで必要な保証を最大化するよう努めるべきであることが示されています。この目的のためには、システムをセグメントに分割し、各セグメントに独自の要件を持たせ、各セグメントの要件に基づいてシステムを設計するのが合理的です。  CAP 定理は、何十年にもわたって分散システムの考え方の礎となってきました。この定理は、一貫性、可用性、分断耐性の固有のトレードオフについて推論するためのフレームワークを提供しました。しかし、多くの点で、これは現実を単純化したものであって、二者択一を前提とし、レイテンシなどの重要な要素を無視しています。  PACELC は CAP を基盤として、次のことを認識しています。 パーティションが存在しない場合でもトレードオフは存在します。 。 遅延は分散システム設計における最重要事項です  CAP と PACELC はどちらも貴重なツールですが、どちらもシステムを構築するためのステップバイステップのレシピではありません。代わりに、トレードオフを評価し、分散アーキテクチャの限界を理解するための を提供します。 メンタルモデル 追加資料 CAP 12年後：「ルール」はどのように変化したか カサンドラ: 決定版ガイド   データベースを CP または AP と呼ぶのはやめてください。Martin Kleppmann による CAP 定理の批判 若い世代のための分散システムに関するメモ 読んでいただきありがとうございます！ 何か気になることや、共有したい考えはありますか? 以下にコメントを残してください。 をチェックするか、   、   、または で私をフォローしてください。 私のブログ LinkedIn Substack Telegram

Subscribe

Buy My Book

このオーディオは、ストーリーの元の言語で制作されています。

分散システムですべてを実現できない理由

About Author

コメント

ラベル

この記事は

Related Stories

クラウド移行を成功させるための完全ガイド: 戦略とベストプラクティス

タップして稼ぐ：テレグラムはソラナより先に次の100億人の暗号通貨ユーザーを獲得する可能性がある

ユニークなエコシステムを支えるビットコインUTXOのモデル

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

クラウド移行を成功させるための完全ガイド: 戦略とベストプラクティス

タップして稼ぐ：テレグラムはソラナより先に次の100億人の暗号通貨ユーザーを獲得する可能性がある

ユニークなエコシステムを支えるビットコインUTXOのモデル

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps