CAP 정리와 PACELC: 분산 시스템 트레이드오프 실전

분산 시스템 선택의 근거

데이터베이스를 선택하거나 설정할 때 "이 시스템이 파티션 발생 시 어떻게 동작하는가", "정상 운영 중 쓰기 레이턴시를 줄이려면 무엇을 포기하는가"를 알아야 한다. CAP 정리와 PACELC 정리는 이 질문에 구조화된 언어를 제공한다.

단순히 이론을 외우는 목적이 아니다. Cassandra를 CONSISTENCY ONE으로 읽을 때와 CONSISTENCY QUORUM으로 읽을 때의 차이, DynamoDB의 eventually consistent read와 strongly consistent read 중 어느 것을 써야 하는지, etcd가 분단 상황에서 왜 쓰기를 거부하는지—이 모든 판단이 CAP과 PACELC에서 나온다.

CAP 정리: 세 가지 속성과 실제 선택

2000년 Eric Brewer가 주장하고 2002년 Gilbert와 Lynch가 증명한 CAP 정리는 분산 시스템이 동시에 세 가지 속성 모두를 완벽하게 보장할 수 없다고 말한다.

핵심: P는 선택이 아니다

네트워크 분단(Partition)은 모든 현실 분산 시스템에서 발생한다. 케이블이 끊기고, 스위치가 재부팅되고, 패킷이 유실된다. P를 포기한다는 것은 분산 시스템을 포기하는 것과 같다. 단일 노드 DB는 P가 관계없지만, 그것은 분산 시스템이 아니다.

결론: 실제 선택은 CP vs AP이다. 분단이 발생했을 때 일관성을 지킬 것인가(CP), 가용성을 지킬 것인가(AP)?

• CP 선택: 분단 중 일부 노드는 쓰기를 거부하거나 응답하지 않는다. 데이터는 안전하지만 일시적으로 서비스 불가.
• AP 선택: 분단 중에도 모든 노드가 응답한다. 노드마다 다른 값을 돌려줄 수 있어 일관성이 깨질 수 있다.

CAP의 흔한 오해

"CA 시스템이 존재한다"는 오해

CAP 원래 논문에서 CA 예시로 들었던 PostgreSQL이나 MySQL 같은 관계형 DB는 단일 노드로 실행될 때는 분산 시스템이 아니므로 P 자체가 적용되지 않는다. 클러스터로 확장하면 P가 등장하고 C vs A 선택을 해야 한다.

"세 가지 중 정확히 두 가지를 고른다"는 오해

CAP는 연속적인 트레이드오프를 다루지 않는다. 현실의 시스템은 일관성과 가용성의 수준을 조절할 수 있다. Cassandra의 CONSISTENCY QUORUM은 AP이지만 eventual보다 강한 보장을 제공한다. CAP은 극단적 상황(분단 + 완벽한 보장)을 다루는 이론적 틀이다.

"CAP으로 모든 트레이드오프를 설명할 수 있다"는 오해

CAP은 분단 발생 시의 동작만 설명한다. 분단이 없는 정상 운영 중에도 일관성을 높이면 레이턴시가 올라간다. 이 트레이드오프를 설명하려면 PACELC가 필요하다.

PACELC: 정상 운영 중에도 트레이드오프가 있다

Daniel Abadi가 2012년에 제안한 PACELC 정리는 CAP를 두 경우로 확장한다.

P → A/C  (Partition 발생 시: Availability 또는 Consistency 선택)
E → L/C  (Else 정상 운영 시: Latency 또는 Consistency 선택)

PACELC의 실용적 가치는 E(Else) 부분이다. 분단은 드물게 발생하지만, 정상 운영 중 레이턴시와 일관성의 트레이드오프는 매 쓰기마다 발생한다. 운영자는 평상시에도 어떤 비용을 지불하는지 알아야 한다.

주요 시스템별 PACELC 분석

Cassandra: 튜너블 일관성

Cassandra는 기본값이 PA/EL이지만 일관성 수준 설정으로 동작을 바꿀 수 있다.

쓰기 일관성 = ONE    → 하나의 노드에만 써도 성공 (낮은 레이턴시, 높은 가용성)
쓰기 일관성 = QUORUM → 과반 노드에 써야 성공 (더 강한 일관성, 더 높은 레이턴시)
쓰기 일관성 = ALL    → 모든 노드에 써야 성공 (최강 일관성, 하나 다운 시 실패)

읽기 + 쓰기 일관성의 합이 복제 계수(RF)를 초과하면 읽기가 항상 최신 쓰기를 반영하는 read-your-write consistency가 보장된다. 예: RF=3에서 QUORUM + QUORUM = 4 > 3.

DynamoDB: eventually consistent vs strongly consistent

DynamoDB 기본 읽기는 PA/EL 방식이다. Strongly consistent read(ConsistentRead: true)를 사용하면 읽기 용량 유닛(RCU)이 2배 소모되고 레이턴시도 올라간다. 이것이 EL → EC로 전환하는 비용이다.

etcd / ZooKeeper: PC/EC

Kubernetes 클러스터 상태를 저장하는 etcd는 Raft 합의 기반의 PC/EC 시스템이다. 리더를 잃으면 새 리더가 선출될 때까지 쓰기를 받지 않는다. 가용성보다 일관성을 선택한 것이다. Kubernetes 컨트롤 플레인이 분단 중 파드 생성을 멈추는 이유가 여기에 있다.

MongoDB: 복잡한 튜닝 가능 범위

MongoDB는 기본적으로 PC/EC 쪽에 가깝다. 레플리카셋에서 Primary 장애 시 Failover가 완료될 때까지 쓰기를 거부(CP 동작). 하지만 {w: 1} 쓰기 설정 + readPreference: secondary를 조합하면 AP처럼 동작시킬 수 있다.

운영자 판단 기준

CAP와 PACELC를 운영 결정으로 연결하는 핵심 질문은 두 가지다.

1. 파티션 발생 시 무엇을 포기할 것인가?

2. 정상 운영 중 레이턴시와 일관성 사이에서 어떤 비용을 지불할 것인가?

강한 일관성(EC)은 쓰기마다 쿼럼을 기다리므로 레이턴시가 올라간다. 지리 분산 클러스터에서는 수십~수백 ms 차이가 생긴다. 이 비용이 비즈니스 요구사항에 비해 너무 크다면 EL 쪽으로 설정을 완화한다. 완화한다면 충돌 해소 전략(LWW, CRDT, 애플리케이션 로직)을 함께 설계해야 한다.

CAP → PACELC 한 문장 요약

CAP: 분단 시 일관성(C)과 가용성(A) 중 하나를 포기해야 한다.
PACELC: 분단 시 C vs A, 그리고 정상 시 레이턴시(L) vs 일관성(C) 사이에서도 선택해야 한다.

운영자는 시스템 문서에서 기본 PACELC 분류를 파악하고, 워크로드별로 설정 가능한 범위 안에서 정확한 위치를 잡아야 한다. "이 DB가 일관성을 보장한다"는 말은 어떤 설정에서, 어떤 분류에서, 어떤 조건 하에 그런지를 확인하지 않으면 의미가 없다.

다음 장에서는 분산 시스템이 실제로 합의를 이루는 메커니즘인 Raft와 Paxos, 그리고 리더 선출과 split-brain 방지를 다룬다.

References

• Brewer, E. (2000). Towards robust distributed systems — https://people.eecs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf
• Gilbert, S. & Lynch, N. (2002). Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services — https://dl.acm.org/doi/10.1145/564585.564601
• Abadi, D. (2012). Consistency Tradeoffs in Modern Distributed Database System Design: CAP is Only Part of the Story — https://www.cs.umd.edu/~abadi/papers/abadi-pacelc.pdf
• Wikipedia, PACELC design principle — https://en.wikipedia.org/wiki/PACELC_design_principle
• TheCodeForge, "PACELC Theorem: When CAP Isn't Enough" — https://thecodeforge.io/system-design/pacelc-theorem/
• Apache Cassandra documentation, Consistency — https://cassandra.apache.org/doc/latest/cassandra/managing/operating/consistency.html
• Amazon DynamoDB, Read Consistency — https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html
• Instaclustr Blog, "Cassandra vs MongoDB: Using CAP Theorem" — https://www.instaclustr.com/blog/cassandra-vs-mongodb/