CAP定理入門 - 分散システムの一貫性・可用性・分断耐性

CAP定理は、分散システムの設計を「三つから二つを選ぶ」と表すものではありません。ネットワーク分断が起きている間、強い一貫性と可用性を同時に保証することはできない、という定理です。

三つの言葉

ここでのCは「データの形式が正しい」ことではありません。またAは「速い」ことや「稼働率が99.9%」という一般的な可用性の指標と同じ意味ではありません。

分断が起きると何を選ぶか

二つの拠点の通信が切れた時、同じデータへ同時に要求が来るとします。

• 古い値を返さないことを優先するなら、片方の要求を待たせる・失敗させる必要があり、可用性を下げる選択です。
• 応答を返すことを優先するなら、片方が古い値を返す可能性を受け入れ、強い一貫性を下げる選択です。

分散システムで通信障害を完全に無視することはできないため、実務では「Pを捨ててCAにする」と単純には選べません。平常時にどの程度の遅延と一貫性を許容するかは、CAP定理だけでは決まりません。

設計で先に決めること

データベース製品をCP・APという一語だけで分類して選ぶのは危険です。設定、読み書きの方式、クォーラム、障害時の挙動で変わります。次の問いから始めます。

1. 分断中に古い値を見せると何が起きるか
2. 応答を待たせる・拒否すると何が起きるか
3. 競合した書き込みを、後でどう解決するか
4. 読み取りと書き込みの一貫性を、どの操作に必要とするか

在庫の確定や残高のように誤った値が大きな問題になる操作と、タイムライン表示のように少し古い値を許容できる操作は、同じ基準で設計しないことがあります。

PACELCとの関係

PACELCは、分断時（P）には可用性（A）か一貫性（C）を、通常時（E）にも遅延（L）か一貫性（C）を考えるための整理です。CAP定理の代わりではなく、平常時のトレードオフも忘れないための補助線です。

まとめ

CAP定理は「常に二つだけ」ではなく、「分断がある時にCとAを同時保証できない」という話です。製品名の分類で終わらせず、各操作で古い値と失敗応答のどちらが問題かを決めます。

参考リソース

• Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services
• PACELC paper（Yale University）

関連記事

• データベースマイグレーション戦略

×

PR

×

PR