CAP 定理
IBM® Cloudant® for IBM Cloud® は、 「結果整合性」 モデルを使用します。 IBM Cloudantの一部を更新すると、最終的にはシステムの他の部分から更新が認識されます。
このモデルがどのように機能し、 なぜ IBM Cloudant を使用するうえで不可欠な 部分なのかを理解するために、整合性が何を意味しているかを考えてみます。
整合性は、データベース内のトランザクションを確実に処理および報告するために必要な 4 つの 「ACID」 プロパティーの 1 つです。
さらに、整合性は "CAP" 定理における 3 つの属性の 1 つである。 これらの属性は、 Consistency (整合性)、Availability (可用性)、および Partition tolerance (分断耐性) です。 この定理は、 IBM Cloudant のような分散コンピューター・システムでは不可能であると述べています。 3 つの属性を 同時に保証します。
- Consistency (整合性)。すべてのノードで同じデータが同時に表示される。
- Availability (可用性)。すべての要求が、成功したか失敗したかに関する応答を受信することを保証する。
- Partition tolerance (分断耐性)。システムのどこか一部が破損または故障してもシステムは稼働し続ける。
3 つの属性をすべて同時に保証することが不可能だということは、 IBM Cloudant が Consistency (整合性) 属性を保証していないことを意味します。 更新が伝搬するにしたがって、システムは完全な整合性へと収束していくと言われています。
結果整合性は、パフォーマンスには有益です。 強整合性モデルでは、システムは、書き込み要求または更新要求を完了する前に、すべての更新が完全および正常に伝搬するのを待機しなければなりません。 結果整合性モデルでは、システム全体の伝搬が 裏で 継続している間、書き込み要求または更新要求をほぼ即時に返すことができます。
理論的理由と実際的理由の両方により、データベースはこれらの 3 つの属性のうち 2 つだけを示すことができます。 データベースの整合性と可用性の優先順位付けは簡単です。 単一ノードには、データの単一コピーが保管されます。 しかし、このモデルは拡大が困難になります。なぜなら、より良いパフォーマンスを得るには、追加のノードを使用するのではなく、ノードのアップグレードが必要になるからです。 また、小さなシステム障害でも単一ノード・システムをシャットダウンする可能性があり、いかなるメッセージ損失も大きなデータ損失を意味します。 これらの問題に対応するには、システムがより洗練される必要があります。
分断耐性でのトレードオフ
通常、整合性と分断耐性を優先するデータベースは、システム内の多くのノードのうちの 1 つがリーダーとして選出される、プライマリー - セカンダリーのセットアップを採用します。 リーダーだけがデータ書き込みを承認し、すべての 2 次ノードはリーダーからデータを複製して読み取りを処理します。 リーダーがネットワークへの接続を失ったり、そのシステムのノードの多くと通信できなくなったりすると、残りのノードは新しいリーダーを選出します。 この選択プロセスはシステムによって異なり、 重大な問題の原因となる可能性があります。
IBM Cloudant は、「プライマリー - プライマリー」セットアップを採用して、可用性と分断耐性を優先しています。そのため、すべてのノードが、そのノードのデータ割り当て部分に対する書き込みと読み取りの両方を受け入れることができます。 複数のノードに、データの各割り当て部分のコピーが含まれています。 各ノードは、他のノードのデータをコピーします。 あるノードがアクセス不能になると、ネットワークが回復する間、他のノードが代わりにサービスを提供できます。 このようにして、システムは、任意のノード障害にもかかわらずタイムリーにデータを返し、 最終的な整合性を維持します。 絶対的整合性の優先順位を下げた場合のトレードオフは、すべてのノードで同じデータが表示されるまでに時間がかかることです。 その結果として、新しいデータがシステムで伝搬する間、一部の応答に古いデータが含まれることがあります。
アプローチの変更
1 つの整合したデータ・ビューを維持することは理にかなっており、容易に理解できます。なぜなら、リレーショナル・データベースはユーザーの代わりにこの作業を実行しているからです。 データベース・システムと対話する、Web ベースのサービスはこのように振る舞うことが期待されています。 しかし、その期待は、必ずこのように動作することを意味しているわけではありません。 整合性は初めから存在するものではなく、 アプローチを変えるためには若干の作業が必要になります。
実際、整合性は、多くのエンタープライズ・クラウド・サービスにとって、必ずしも不可欠なものではありません。 大規模で使用頻度が高いシステムでは、システムの一部で障害が発生する確率が高くなります。 可用性と結果整合性を優先要件として設計されたデータベースは、アプリケーションの接続を維持することに、より適しています。 アプリケーション・データの整合性の対処は事後に行うことができます。
企業におけるアプリケーションの可用性対整合性
人気のある Web ベースのサービスを見ると、人々が既に高可用性を期待しており、 多くの場合そうしていることに気付かずに、 喜んでこの可用性を結果整合データと交換していることが示されています。
多くのアプリケーションは、可用性のためにユーザーを誤った方向に導いています。 以下の ATM について考慮してください。 一貫性のない銀行データが、それを認識せずにお金を当座貸越することができる理由です。 操作を続行する前にネットワーク内のすべてのノードを停止して口座の預金残高の金額を記録しなければならない場合、 銀行システム全体でお客様の口座の預金残高の整合したビューを表示するというのは現実的ではありません。 より良い選択は、システムの可用性を高めることです。
銀行業界は、1980 年代にこのことを理解しましたが、多くの IT 組織はまだ、可用性のために整合性を犠牲にすることに懸念を持っています。 販売チームが CRM アプリにアクセスできない時にかかってくるサポート・コールの数について考えてみてください。 次に、データベース更新をアプリケーション全体に伝搬するのに数秒間かかるということに彼らが気付きさえするかどうかについて考えてみてください。
可用性は、予想されるよりもずっと整合性に勝っています。 その他のいくつかの例としては、オンライン・ショッピングのカート・システム、HTTP キャッシュ、および DNS があります。 組織は、ユーザーの不満、生産性の損失、および逃した好機などのダウン時間のコストについて考える必要があります。
理論から実装へ
高可用性についての取り組みは、クラウド・アプリケーションにとって不可欠です。 そうしないと、全体的なデータベース整合性は、事業が拡大していくにつれて大きなボトルネックとして残ります。 高可用性のアプリケーションは、最新のデータでないとしても、データに常にアクセスできる必要があります。 それこそが結果整合性の概念であり、怖れるものではありません。 大きな規模では、何の答えも提供しないよりは、完全に正解でなくても答えを提供した方が良いということがあります。
データベース・システムでは、さまざまな方法で可用性と整合性の複雑さが隠されていますが、 複雑さは常に存在します。 IBM Cloudant、CouchDB、および他の NoSQL データベースのチームは、最良の方策として、開発者が設計プロセスの早い段階でこのような複雑さを解決する必要があると考えています。 最初に困難な作業を行うことにより、アプリケーションは最初から拡大する準備ができるので、サプライズの数が減ります。