分散システムで考えておくべきこと~CAP定理とは?|DApps(ブロックチェーンを活用したアプリケーション)のことなら

TOP  コラム  分散システムで考えておくべきこと~CAP定理とは?

分散システムで考えておくべきこと~CAP定理とは?

2018.11.19

コラム

分散システムで考えておくべきこと~CAP定理とは?

ブロックチェーン関連でも知っておきたいCAP定理
近年のようにさまざまなものがデータ化され、やりとりされるようになった世界では、1つの管理データベースで膨大かつ多様なデータを取り扱うのは現実的ではありません。格納するデータベースが1つに集中していると、処理負荷が過大となりシステムダウンを起こす危険性が高まりますし、サイバー攻撃や天災、故障などでデータが逸失してしまうリスクもあります。

より安定的に、アクセスの集中による負荷の肥大化への耐性を高め、さまざまなシステムダウンのリスクを減らして運用して行くには、分散化を図ることが必要です。そのため、クライアント・サーバー型の基本は変更しないものの、地理的・物理的に管理データベースを分散させ、リスクの低減を図る分散データベースの仕組みや、ブロックチェーン技術を活かしたインフラが強く求められています。

しかし、こうした分散システムにおいて、考えておかねばならない問題に「CAP定理」というものがあります。今回はこのCAP定理について学んでいきましょう。

3つのうち2つしか満たせない??
CAP定理とは、2000年にEric Brewer氏が提唱し、2002年にSeth Gilbert氏とNancy Lynch氏によって証明されたもので、共通のデータを取り扱う複数ノードで構成された一連の分散システムで指摘できるとされる、ひとつの定理です。提唱者の名前にちなみ、ブリュワーの定理と呼ばれることもあります。

この定理によると、分散システムではどんなネットワークであっても、ノード間のデータ複製において、以下のデータベースとして望まれる3要素をすべて同時に満たすことは不可能で、3つのうち2つまでしか完全には満たせないとされています。

少し難解ですが、3要素を具体的にみていきましょう。1つ目は「Consistency(一貫性)」です。全ノードが一意なデータを保持している状態で、誰かが更新を行ったらその後は必ずどこにおいても更新後のデータが確認できる、共有値の統一性、唯一性を指します。

2つ目は「Availability(可用性)」で、誰もが読み込み・書き込みのアクセスが常に可能であること、特定のノードの障害時も他のノードは問題なくスムーズに利用できる、ロック待ちになるといったこともない、100%の応答性が確保されていることです。

最後の3つ目は「Partition Tolerance(分断耐性)」で、ネットワークに問題が生じてもダウンすることなく継続運用が実現されること、データに破損が生じても他から参照可能で通常動作に影響が及ばないことを指しています。

この3つの頭文字をとって“CAP”定理といい、除かれる要素に応じて、システムはCA、CP、APの3種類に分類されます。ただしこれは2択的な選択を迫るものではなく、1つの要素特性しかもっていないもの、どの要素特性も持ち得ていないものもあります。

そして主張されているのは、あくまでも“同時に完全な達成は保証できない”ということですから、設計において何を最重視するか、どこを段階的な保証で許容するか、特性に応じてよく考えることが最善の結果を生む、ということである点に注意しておきましょう。

ブロックチェーンはおよそAP型
システムの具体例で説明すると、OracleやMicrosoft SQL Serverなど、多くのデータベースサーバー・ソフトが該当する、データを効率よく格納管理するために関係性から構造を定義、構造の組をまとめて整理していくRDBMS(リレーショナルデータベース管理システム)は、分散されておらず「P」の分断耐性に弱みをもっています。よってCA型が選択されているといえます。

分散データベースの場合では、目的によりCPかAPが選択されていますが、CPが選択されるケースが多く、しかしサービスとして可用性を完全に捨てるわけにもいきませんから、可用性の一部と一貫性の大半を妥協したかたちで成立させることが一般的です。

サーバーが増えるとロック待ちが発生する、エラーになったら再実行が必要だが、サービスは維持されるといった仕組みや、時間は要するが最終的には一貫性が保たれるといった仕組みになりますね。

ではブロックチェーンはどうでしょうか。ゼロダウンタイムなどの特性を考えれば、自然に解答はみえてくるでしょう。可用性と分断耐性には強く、一貫性にやや弱みがあるAP型が基本形です。

Peerがネットワークを形成し、同等の機能をもって運用されていますから、システムが落ちることはなく、一部に問題が生じてもすぐに復旧できる高い分断耐性があります。しかし冗長さから、あるノードに書き込まれたデータが全体に反映されるまでには、どうしてもタイムラグが発生してしまいます。

合意形成により、最終的には一貫性が保たれ、正しい時系列で統一された値のデータがネットワーク全体で保持される結果となりますが、伝播していくある一時の状態では一貫性が確保されていないことになります。このように時間的な制限を緩め、結果的に一貫性、整合性が保持されるかたちで、3要素のカバーに近づけているのです。

CPを採ることも論理的には可能ですが、その場合、データは一貫しているものの、トランザクションに関する合意形成を妨げる向きがあれば、ネットワークに分割・分離が生じ、全体が利用できなくなる可能性があります。

分散システムにおけるCAP定理は、より信頼性を高め、最適な運用を図っていくため、トレードオフとしてどの部分を許容するか、そしてそれによって生じる課題をどうカバーしていくかという問題です。仕組み上の問題として認識することで、特性や求められる対処などへの理解を深めましょう。

▼DApps総研
https://dapps-info.com/

(画像は写真素材 足成より)