[Daily morning study] CAP 정리와 분산 데이터베이스 설계
#daily morning study
CAP 정리란
분산 시스템에서는 세 가지 속성을 동시에 모두 보장할 수 없다는 이론이다. 2000년 Eric Brewer가 제안했고, 2002년 Gilbert와 Lynch가 수학적으로 증명했다.
세 가지 속성은 다음과 같다.
| 속성 | 이름 | 설명 |
|---|---|---|
| C | Consistency (일관성) | 모든 노드가 항상 동일한 데이터를 반환한다 |
| A | Availability (가용성) | 모든 요청은 반드시 응답을 받는다 (성공 또는 실패) |
| P | Partition Tolerance (파티션 허용성) | 네트워크 분리가 발생해도 시스템이 동작을 계속한다 |
핵심: 네트워크 파티션(P)은 분산 시스템에서 피할 수 없다. 따라서 실제로는 CP 또는 AP 중 하나를 선택하는 문제가 된다.
세 가지 조합과 트레이드오프
CP (Consistency + Partition Tolerance)
네트워크 파티션이 발생하면 일관성을 지키기 위해 일부 노드의 요청을 거부한다.
- 데이터는 항상 정확하지만, 일부 노드가 응답 불가 상태가 될 수 있다.
- 대표 시스템: HBase, ZooKeeper, MongoDB(기본 설정)
[시나리오]
Node A ─── Node B ─── (파티션 발생) ─── Node C
→ Node C가 격리되면, C로 오는 쓰기 요청을 거부
→ 오래된 데이터를 반환하는 것보다 오류를 반환하는 걸 선택
적합한 경우: 금융 거래, 재고 관리 등 데이터 정확성이 최우선인 경우
AP (Availability + Partition Tolerance)
네트워크 파티션이 발생해도 모든 노드가 응답을 반환한다. 단, 노드마다 서로 다른(오래된) 데이터를 줄 수 있다.
- 가용성을 지키기 위해 일관성을 포기한다.
- 나중에 데이터를 동기화하는 최종 일관성(Eventual Consistency) 모델을 사용한다.
- 대표 시스템: Cassandra, DynamoDB, CouchDB, DNS
[시나리오]
Node A ─── Node B ─── (파티션 발생) ─── Node C
→ Node C가 격리되어도 요청에 응답
→ 파티션 복구 후 A, B와 데이터를 동기화
적합한 경우: SNS 피드, 장바구니, 상품 추천 등 약간의 불일치를 허용할 수 있는 경우
CA (Consistency + Availability) — 사실상 분산 시스템에서 불가
파티션 허용성이 없다는 건 단일 노드, 즉 분산 시스템이 아닌 경우를 의미한다.
- 대표 시스템: 단일 서버 RDBMS (MySQL, PostgreSQL — 분산 구성 없이)
- 실제 분산 환경에서는 네트워크 장애를 완전히 피할 수 없으므로 CA는 이론적 조합에 가깝다.
최종 일관성 (Eventual Consistency)
AP 시스템에서 가용성을 확보하기 위해 도입하는 개념이다. 일시적으로 노드 간 데이터가 달라도, 충분한 시간이 지나면 모든 노드가 동일한 상태로 수렴한다는 보장을 제공한다.
쓰기 → Node A 업데이트 완료
↓ 비동기 복제
Node B 업데이트 중...
↓
Node B 업데이트 완료 (최종 일관성 달성)
최종 일관성은 강도에 따라 세분화된다.
| 수준 | 설명 | 예시 |
|---|---|---|
| Strong Consistency | 모든 읽기가 최신 쓰기를 반환 | ZooKeeper |
| Monotonic Read | 같은 클라이언트는 항상 더 최신 데이터를 읽음 | — |
| Read-Your-Writes | 자신이 쓴 데이터는 항상 읽을 수 있음 | — |
| Eventual Consistency | 시간이 지나면 수렴 | DynamoDB, Cassandra |
PACELC 정리
CAP 정리의 한계를 보완한 이론이다. 파티션이 없는 정상 상태에서도 지연(Latency) vs 일관성(Consistency) 트레이드오프가 존재한다는 점을 추가했다.
P (파티션 발생 시): A vs C 선택
E (정상 상태 시): L vs C 선택
| 시스템 | 파티션 시 | 정상 시 |
|---|---|---|
| DynamoDB | AP | EL (지연 우선) |
| Cassandra | AP | EL |
| HBase | CP | EC (일관성 우선) |
| MongoDB | CP | EC |
실제 설계에서의 선택 기준
데이터 특성으로 판단
강한 일관성 필요 → CP
예) 은행 잔액, 주문 재고, 결제 상태
일시적 불일치 허용 → AP
예) 좋아요 수, 조회수, SNS 피드, 장바구니
읽기/쓰기 비율로 판단
- 읽기가 압도적으로 많은 서비스 → AP + 캐싱 레이어
- 쓰기 충돌이 자주 발생 → CP + 분산 잠금
주요 DB별 CAP 포지션 정리
| 데이터베이스 | 분류 | 특징 |
|---|---|---|
| MySQL (단일) | CA | 분산 아님, 단일 노드 |
| MySQL (Galera Cluster) | CP | 동기 복제 |
| PostgreSQL | CA/CP | 복제 구성에 따라 달라짐 |
| MongoDB | CP | Primary 장애 시 선거 과정 중 unavailable |
| Cassandra | AP | 튜너블 일관성 (quorum 조정 가능) |
| DynamoDB | AP | 기본 최종 일관성, 강한 일관성도 선택 가능 |
| Redis Cluster | AP | 파티션 시 일부 데이터 손실 가능 |
| ZooKeeper | CP | 리더 선출, 과반수 동의 기반 |
| HBase | CP | HDFS 기반, 강한 일관성 |
Cassandra의 튜너블 일관성
Cassandra는 AP 시스템이지만, 읽기/쓰기 요청 시 일관성 수준을 직접 지정할 수 있어 유연하다.
-- ONE: 한 노드에서만 확인 (빠르지만 일관성 낮음)
SELECT * FROM orders WHERE id = 1 USING CONSISTENCY ONE;
-- QUORUM: 과반수 노드 확인 (속도와 일관성 균형)
SELECT * FROM orders WHERE id = 1 USING CONSISTENCY QUORUM;
-- ALL: 모든 노드 확인 (느리지만 강한 일관성)
SELECT * FROM orders WHERE id = 1 USING CONSISTENCY ALL;
쓰기와 읽기의 일관성 수준 합이 복제 계수(RF)보다 크면 강한 일관성 달성 가능하다.
RF = 3, W = QUORUM(2), R = QUORUM(2)
W + R = 4 > RF = 3 → Strong Consistency 달성
정리
- CAP 정리는 분산 시스템 설계의 근본적인 제약을 설명한다.
- 네트워크 파티션은 피할 수 없으므로, 실질적인 선택은 CP vs AP이다.
- CP는 데이터 정확성이 중요할 때, AP는 가용성과 성능이 중요할 때 선택한다.
- PACELC는 정상 상태에서도 지연 vs 일관성 트레이드오프가 있다는 점을 보완했다.
- 실제 시스템(Cassandra, DynamoDB)은 설정을 통해 일관성 수준을 조정할 수 있다.
