[Daily morning study] CAP 정리와 BASE 이론 — 분산 시스템의 일관성과 가용성
#daily morning study
CAP 정리란?
CAP 정리(CAP Theorem)는 Eric Brewer가 2000년에 제시하고 Gilbert와 Lynch가 2002년에 증명한 이론이다. 분산 데이터 시스템은 아래 세 가지 속성을 동시에 모두 만족할 수 없으며, 최대 두 가지만 보장할 수 있다는 내용이다.
| 속성 | 설명 |
|---|---|
| Consistency (일관성) | 모든 노드가 같은 시점에 동일한 데이터를 반환한다. 읽기 요청은 항상 최신 쓰기 결과나 오류를 반환해야 한다. |
| Availability (가용성) | 모든 요청이 (최신 데이터 여부와 무관하게) 반드시 응답을 받는다. 오류가 아닌 응답을 보장한다. |
| Partition Tolerance (파티션 내결함성) | 네트워크 파티션(노드 간 통신 단절)이 발생해도 시스템이 계속 동작한다. |
네트워크 파티션은 분산 시스템에서 피할 수 없는 현실이다. 따라서 P는 사실상 필수 조건이며, 실제 선택은 CP 시스템이냐 AP 시스템이냐의 문제가 된다.
CP vs AP 시스템
CP 시스템 (일관성 + 파티션 내결함성)
파티션 발생 시 일관성을 유지하기 위해 일부 노드를 사용 불가 상태로 만든다. 응답이 늦거나 거부될 수 있지만, 응답이 오면 반드시 일관된 데이터다.
대표 시스템: HBase, Zookeeper, etcd, Redis Cluster (기본 설정)
Client → Node A → (파티션 발생) → Node B 응답 불가
↓
오류 반환 (일관성 우선)
AP 시스템 (가용성 + 파티션 내결함성)
파티션 발생 시에도 모든 노드가 응답을 반환한다. 단, 노드마다 다른 데이터를 반환할 수 있으며, 파티션 해소 후 일관성을 맞춘다(Eventual Consistency).
대표 시스템: Cassandra, DynamoDB, CouchDB, Riak
Client → Node A → 응답 반환 (다소 오래된 데이터일 수 있음)
↓
파티션 해소 후 Node B와 동기화
CAP 정리의 한계와 PACELC 모델
CAP 정리는 파티션이 발생한 상황에서의 트레이드오프만 다룬다. 하지만 파티션이 없는 정상 상태에서도 레이턴시(latency)와 일관성 사이의 트레이드오프가 존재한다.
이를 보완하기 위해 PACELC 모델이 제안되었다.
- Partition 상황: Availability vs Consistency (기존 CAP)
- Else (정상 상태): Latency vs Consistency
| 시스템 | 파티션 상황 | 정상 상태 |
|---|---|---|
| DynamoDB | AP | EL (낮은 레이턴시 우선) |
| Cassandra | AP | EL |
| Zookeeper | CP | EC (강한 일관성 우선) |
| MySQL | CP | EC |
BASE 이론
BASE는 ACID의 대안으로 NoSQL과 분산 시스템에서 사용하는 설계 철학이다.
| 약어 | 의미 | 설명 |
|---|---|---|
| BAsically Available | 기본적으로 가용 | 시스템은 항상 응답하되, 일부 노드의 장애는 허용한다. |
| Soft state | 유연한 상태 | 입력이 없어도 시스템 상태가 시간에 따라 변할 수 있다(동기화 과정). |
| Eventually Consistent | 최종적으로 일관 | 업데이트가 전파되고 나면 결국 모든 노드가 동일한 상태가 된다. |
BASE는 완벽한 일관성 대신 높은 가용성과 확장성을 선택한다.
ACID: 강한 일관성, 트랜잭션 보장, 높은 신뢰성
BASE: 최종 일관성, 높은 가용성, 수평 확장 용이
Eventual Consistency (최종 일관성) 심화
최종 일관성은 “언젠가는 일관된 상태가 된다”는 보장이다. 그 사이에는 일시적 불일치 상태가 존재할 수 있다.
Read-Your-Writes Consistency
사용자가 방금 쓴 데이터는 자신의 읽기 요청에서 반드시 반영되어야 한다. 세션 스티키니스(session stickiness) 또는 리더 노드 읽기로 구현한다.
Monotonic Read Consistency
한 번 특정 상태를 읽었다면, 이후 읽기에서 그보다 이전 상태를 반환해선 안 된다.
Causal Consistency
인과 관계가 있는 연산들은 순서대로 반영되어야 한다.
Write A → Write B (A에 의존)
→ 다른 노드에서 B를 읽었다면 A도 반드시 반영된 상태여야 함
실제 시스템 설계에서의 적용
DNS — AP 시스템의 대표 사례
DNS 업데이트는 전 세계 서버에 즉시 전파되지 않는다. TTL이 만료될 때까지 일부 사용자는 구 IP를 받을 수 있다. 가용성을 최우선으로 하기 때문이다.
쇼핑몰 재고 시스템
- CP 선택: 결제 시점에 재고를 정확히 차감해야 한다면 강한 일관성이 필요하다.
- AP 선택: 상품 목록 페이지에서 재고 수량을 표시하는 건 약간 오래된 데이터도 허용 가능하다.
하나의 시스템에서도 기능별로 CP/AP를 선택적으로 적용하는 것이 일반적이다.
Cassandra의 Tunable Consistency
Cassandra는 요청마다 일관성 수준을 조절할 수 있다.
ONE → 1개 노드에서 응답 (낮은 일관성, 빠른 응답)
QUORUM → 과반수 노드에서 응답 (중간)
ALL → 모든 노드에서 응답 (강한 일관성, 느린 응답)
읽기와 쓰기 QUORUM이 교차하면(R + W > N) 강한 일관성을 보장할 수 있다.
ACID vs BASE 비교 정리
| 항목 | ACID | BASE |
|---|---|---|
| 일관성 | 강한 일관성 | 최종 일관성 |
| 가용성 | 낮을 수 있음 | 높음 |
| 확장성 | 수직 확장 | 수평 확장 |
| 적합 도메인 | 금융, 결제, 예약 | SNS, 로그, 검색, 추천 |
| 대표 DB | MySQL, PostgreSQL | Cassandra, DynamoDB |
요약
- 분산 시스템은 C, A, P를 동시에 만족할 수 없으며, P는 피할 수 없으므로 실질적 선택은 CP vs AP다.
- CP: 파티션 발생 시 일부 요청 거부, 데이터 정확성 보장
- AP: 파티션 발생 시 모든 요청 응답, 데이터 최신성 미보장
- BASE는 강한 일관성을 포기하는 대신 가용성과 확장성을 확보하는 철학이다.
- 실제 시스템에서는 기능과 비즈니스 요구사항에 따라 CP/AP를 혼용한다.
