"우리 DB 는 CP 입니다" / "우리는 AP" — 흔히 듣지만 대부분 부정확. Brewer 가 실제로 증명한 건 더 좁고, 마케팅이 말하는 건 다른 것. PACELC 가 더 솔직한 프레임워크. 이 가이드는 CAP 의 정확한 의미와 실전 DB 의 trade-off 를 정리한다.
Brewer 가 실제로 증명한 것
CAP 정리 (2000 추측, 2002 Gilbert & Lynch 증명):
분산 시스템은 다음 3 가지를 동시에 100% 만족할 수 없다:
C — Consistency (linearizability — 한 시점 모두 같은 값)
A — Availability (모든 요청에 응답)
P — Partition tolerance (네트워크 partition 에도 동작)
→ 정확히는: partition (P) 발생 시 C 와 A 중 하나 포기해야 함.
요점:
- "100% 의 C, 100% 의 A, partition tolerance" 는 불가능
- partition 없을 때는 둘 다 가능 (CAP 의 함정)P 는 협상 불가
흔한 오해 — "CP, AP, CA 중 하나 골라야". 실제로는:
P (partition tolerance) 는 사실상 강제.
- 네트워크는 결국 partition 발생 (cable cut, switch fail, AZ outage)
- partition 없는 시스템은 "단일 데이터센터 단일 노드" 뿐
- 즉 P 를 포기 = 분산 시스템 자체를 포기
→ 실제 선택은 partition 발생 시 C vs A 중 어느 것 포기?
CP: partition 동안 응답 안 함 (consistency 유지)
AP: partition 동안 stale 데이터 반환 (availability 유지)CP vs AP — 거짓 양분
실제 시스템은 "전적으로 CP" 또는 "전적으로 AP" 가 거의 없다 — operation 별로, configuration 별로 trade-off:
MongoDB:
- default: AP-leaning (primary failover 중 잠시 stale read OK)
- majority read concern: CP-leaning
- write concern w=1 vs w=majority: 다른 trade-off
Cassandra:
- ONE consistency level: AP
- QUORUM: 중간
- ALL: CP
PostgreSQL:
- single-node: CAP 의미 X
- streaming replication async: AP (replica stale 가능)
- synchronous_commit=on: CP-leaning
→ "X 는 CP" 같은 라벨은 default configuration 의 단순화. 실제 운영은
operation 별 선택.PACELC — 더 솔직한 프레임워크 (2010 Abadi)
PA-CELC:
If Partition (P) — choose Availability (A) or Consistency (C)
Else (E) — choose Latency (L) or Consistency (C)
→ partition 없는 평소에도 latency vs consistency 의 trade-off 가 있다는 점 명시.
예:
- Spanner: PC + EC (강한 일관성 + 평소에도 latency 손해 OK)
- Cassandra: PA + EL (가용성 + 평소에도 빠른 latency, eventual 가능)
- DynamoDB: PA + EL (default), 또는 PC + EC (strong consistency mode)
- MongoDB: PA + EC (가용성, 평소엔 consistency)
- etcd: PC + EC (강한 일관성 항상)실제 DB 의 선택
| DB | partition | 평소 (else) | 특징 |
|---|---|---|---|
| Spanner | C (CP) | C | TrueTime + global Paxos 로 strong + 거의 zero lag |
| etcd / ZooKeeper | C (CP) | C | metadata store — consistency 가 가장 중요 |
| CockroachDB | C (CP) | C | NewSQL — Spanner-like, MVCC |
| MongoDB | A (AP) default | C | w=majority + read concern 로 CP 도 가능 |
| Cassandra | A (AP) | L | 고가용 + 낮은 latency, eventual 기본 |
| DynamoDB | A (AP) default | L | strong consistency mode 별도 (cost ↑) |
| Riak | A (AP) | L | Dynamo paper 의 직계 후예 |
partition 의 실제 빈도
Aphyr (Kyle Kingsbury) 의 Jepsen 테스트:
- cloud 환경에서 partition 은 매주 1-수 회 발생
- 보통은 ms 단위 짧음, 가끔 분 단위
- 같은 AZ 안에서도 partition 발생 (switch fail)
즉:
- "partition 거의 없으니 CP 로 가도 가용성 OK" 가정 위험
- AP 선택해도 partition 짧으면 사용자 영향 작음
- CP 선택 시 partition 동안 service down — SLA 와 직접 충돌Spanner 의 트릭 — TrueTime
Google Spanner 는 "CAP 의 C 와 A 둘 다 거의 가져옴" 으로 유명.
비밀:
- TrueTime API — GPS + 원자시계로 모든 데이터센터 clock 을 ±수 ms 동기화
- 모든 transaction 에 commit timestamp + uncertainty interval
- "이 transaction 의 commit 이 끝났다고 100% 보장될 때까지 잠시 wait"
→ "commit wait" — strong consistency 보장
비용:
- 각 데이터센터에 GPS antenna + atomic clock 인프라
- transaction latency 가 commit wait 만큼 증가 (수 ms)
- Google 만의 인프라 → 다른 곳 복제 어려움
→ CockroachDB, YugabyteDB 등 후속이 비슷한 접근 (NTP + heuristic) 시도.
다만 진짜 TrueTime 정확도는 Google 만.흔한 함정
- "우리는 CP" / "우리는 AP" 라벨링 — operation 별·configuration 별로 다름. blanket label 위험.
- partition 무시 — "내 데이터센터 안에서는 partition 없음" — 거짓. Jepsen 테스트 보면 발생 빈도 높음.
- eventual consistency 의 "결국" 시간 가정 — spec 상 보장 X. 분 단위 lag 가능. application 이 stale 데이터 처리 전략 명시 필수.
- strong consistency 의 비용 무시 — Spanner / etcd 의 write latency 가 single-node 보다 5-10× 큼. read-heavy 가 아니면 비싼 선택.
- CAP 와 ACID 혼동 — ACID 는 단일 transaction 의 보장, CAP 는 distributed 시스템의 trade-off. ACID 의 C (consistency) 는 CAP 의 C (linearizability) 와 다른 개념.
마무리
CAP 의 진짜 교훈은 "C 또는 A 중 골라" 가 아니라 "trade-off 가 있다, 의식적으로 선택해라". PACELC 가 더 정확한 프레임워크 — 평소의 latency vs consistency 도 고려.
실용 — 시스템마다 operation 별 단계 (read concern, write concern, consistency level) 를 명시적 선택. 마케팅 라벨에 의존하지 말고 실제 configuration 확인.