システムデザイン レッスン6
CAP定理と整合性モデル
分散システムにおける一貫性・可用性・分断耐性のトレードオフを示すCAP定理と整合性モデルの種類を学ぶ
CAP定理の正確な意味
CAP定理は「一貫性(Consistency)・可用性(Availability)・分断耐性(Partition tolerance)の 3つのうち、好きな2つを自由に選んで実装できる」としばしば俗説的に説明されますが、これは正確ではありません。
正確には、分散システムでネットワーク分断が実際に発生した際に、 一貫性(C)と可用性(A)のどちらを優先するかを選ばなければならない、というトレードオフを示す定理です。
Node A <---- network ----> Node B
(通信が分断された状態)
Node A にだけ書き込みリクエストが来た場合:
選択肢1 (Consistency優先 = CP):
Node B と同期できないので、Node A は応答を拒否/エラーを返す
-> 一貫性は守られるが、可用性が失われる
選択肢2 (Availability優先 = AP):
Node A は同期できないまま書き込みに応答する
-> 可用性は保たれるが、Node A と Node B の間に一時的な不整合が生じるなぜP(分断耐性)は事実上前提なのか
複数のノードが物理的に離れたネットワークで通信する以上、ケーブルの断線・スイッチの故障・ 一時的な遅延などによる分断はいつか必ず起こりえます。 分断が起きないことを前提にしたシステムは、分散システムとして現実的ではありません。
そのため実務上の議論は「CかAかPか」の3択ではなく、「分断が起きた瞬間に、CとAのどちらを優先する設計にするか」 というCP系かAP系かの選択にほぼ収束します。
CP系とAP系の具体例
CP系(一貫性を優先)
分断中は不確かな応答をするくらいなら、応答を拒否する
- • 銀行の残高更新など、古い値を返すことが許されない用途
- • 一部の分散データベースの強整合モード
AP系(可用性を優先)
分断中でも応答を返し続け、後で整合性を収束させる
- • SNSの「いいね」数のような、多少古くても致命的でない情報
- • 一部のNoSQLデータベースの結果整合モード
整合性モデルの種類
強整合性(Strong Consistency)
更新後、どのノードにアクセスしても必ず最新の値が返る。実現にはノード間の同期コストがかかる
結果整合性(Eventual Consistency)
更新直後は古い値が返ることがあるが、時間が経てば最終的にすべてのノードの値が収束する
因果整合性(Causal Consistency)
因果関係のある操作(例: 投稿とその返信)の順序だけは保証し、無関係な操作の順序は保証しない中間的なモデル
ポイント
- CAP定理は「3つから2つを選ぶ」俗説ではなく、「分断発生時にCとAのどちらを優先するか」を示す定理
- 分散システムである以上、分断耐性(P)は事実上の前提となり、議論の中心はCP系かAP系かになる
- 強整合性・結果整合性・因果整合性など、扱うデータの性質に応じた整合性モデルを選択する
確認クイズ
1 / 4CAP定理の正確な内容として適切なものはどれか？