Englishから翻訳 • 原文を読む 私たちが生きる世界は決して完璧ではありません。私たちは常にジレンマ、時にはトリレンマに陥り、トレードオフを迫られます。買い物をする際、私たちは「安い」「速い」「良い」の二つしか選べません。経済学において、政府は「主権金融政策」、「固定為替レート」、「自由資本の流れ」を同時に享受することはできません。政府は三つ目を放棄することで、そのうち二つしか達成できません。同様に、CAP(一貫性、可用性、分割許容度)定理も同様に困惑するトリレンマを含みます。これは分散コンピューティングが大規模計算の人気ソリューションとして人気を博して以来、コンピュータ科学者やソフトウェアエンジニアを悩ませてきました。今日はCAPの定理を深く掘り下げ、私たちのニーズに基づいた賢明なトレードオフの方法を学びます。
CAP定理
まず、CAP定理で述べられている三レマから始めましょう。CAPは一貫性、可用性、分割許容度の略です。CAP定理は、分散システムがネットワーク分割の際にこれら三つの特性のうち二つしか保証できないと述べています。次に、CAP定理の文脈で一貫性、可用性、分割許容を定義します。
一貫性
分散システムが整合的であれば、すべての読み取りリクエストは最新の書き込みまたはエラーを受け取ります。言い換えれば、一貫性があれば、どのノードに読み取りリクエストを行っても、常に分散システムに書き込まれた最新のデータを受け取ります。最新のデータが現在利用できない場合はエラーが発生します。
入手可能性
可用性とは、すべてのリクエストがエラーのない応答を受け取ることを意味しますが、その応答は必ずしも最新の書き込みを含んでいないものです。言い換えれば、可用性があればユーザーは常に要求したデータを受け取りますが、そのデータが古い場合があります。
分割許容
パーティションを許容する分散システムは、ノード間で任意の数のメッセージがネットワークによってドロップまたは遅延しても動作を続けます。言い換えれば、パーティション許容により、ノードの中にはメッセージを送れないノードがあってもシステムは動作し続けます。
ネットワーク分割が行われる際に、なぜこれら3つすべてを同時に達成できないのか疑問に思う方もいるでしょう。セス・ギルバートとナンシー・リンチによるよく分かりやすい概念実証は見つかりますが、非コンピュータ科学者には少し複雑で理解しにくいかもしれません。そこで、簡単な例を使った短い証明を提示します。
次の仮定をしましょう。1. ノードAとノードBの2つの独立したノードからなる分散システムがあります。2.ネットワーク障害により、この2つのノードは互いにメッセージを受け取ることができず、分散システムは相互に通信できない2つの部分に分割されています。3. 最新の書き込みはノードAに保存されます。4.ノードBはノードAからのメッセージを受け取ることができないため、ノードBは最新のデータを含みません。
では、なぜこのシステムが他の2つの特性を達成したのに、これら3つの特性すべてを保証できないのかを見てみましょう。
一貫性 + 入手可能性
分散システムが一貫していて利用可能であれば、システムが稼働している間に、すべての読み取りリクエストには最新のデータを含む非エラー応答が返ってきます。しかし、ノードBは最新のデータを提供できないため、これを実現できません。したがって、分散システムの運用時間中の一貫性と可用性を保証するために、一時的にシャットダウンし、パーティション許容範囲を犠牲にする必要があります。
一貫性 + 分割許容範囲
この組み合わせでは、システムは実行を続け、読み取り要求に応じて最新のデータ、または利用できない場合はエラーを送信しなければなりません。ノードBは最新の書き込みを取得していないため、システムの整合性を確保するためにエラーをディスパッチしなければなりません。したがって、このシナリオではノードBが非エラーメッセージを送信するために必要な可用性を保証することは不可能です。
可用性 + パーティション許容範囲
このシナリオでは、システムは常に動作を停止することはできません。また、読み取り要求に対してエラーのないメッセージで応答しなければなりません。最新の書き込みはノードB上でアクセスできないため、読み取り要求に応じて古いデータを送信せざるを得ず、結果的に一貫性に違反します。
一貫性、入手可能性、パーティション許容範囲の選び方のヒント
一貫性、可用性、パーティション許容度を同時に達成することは不可能であることを示したので、これら三つの望ましい特性の中からどのように選択するかについて説明します。一般的に、分散システムにはネットワーク分割を許容させる必要があります。理由は以下の通りです。1) ネットワーク分割はどこにでも存在し、2) ネットワーク分割があっても分散システムが稼働し続け、ユーザーが処理されていないリクエストで混乱しないようにしたいのです。
パーティション許容範囲が必須である以上、結局は一貫性と可用性のどちらかを単純に選ぶことです。経験則としては、ユーザーが常に最も正確なデータを得る必要がある場合、可用性よりも整合性を優先するのが良いでしょう。一貫性とパーティション許容度を目指すシステムの良い例としては、銀行や証券取引所などの金融機関向けに開発されたアプリケーションがあります。
一方で、私たちは一般的に、データの正確性のために良いユーザー体験を犠牲にしたくないなら、一貫性よりも可用性を優先します。ソーシャルメディアプラットフォームやゲームは、通常、可用性やパーティション許容度を目指すシステムの良い例です。
この記事では、CAP定理が述べていることを説明し、整合性、可用性、分割許容度の定義を示しました。その後、整合性、可用性、分割許容度の三位一体がなぜ達成不可能であるのかを詳しく説明しました。最後に、このトリレンマにおいて賢明に意思決定を行うためのヒントをいくつか提供しました。この記事がCAP定理についてより深い洞察を得て、システムを設計する際の意思決定にどう応用すればよいか、参考になれば幸いです。
今後の記事では、CAP定理のより包括的なバージョンであるPACELC定理について論じます。どうぞご期待ください!