CAP을 확장해 분단이 없는 평상시의 선택까지 포함한 모델.
| if (P) | then | A or C | 분단이 나면 → 가용성이냐 일관성이냐 |
|---|---|---|---|
| else | L or C | 평상시에는 | → 지연(Latency)이냐 일관성이냐 |
읽는 법: Partition이면 Availability냐 Consistency냐, Else Latency냐 Consistency냐.
왜 CAP만으로는 부족한가
분단은 드문 사건이다. 1년에 몇 번 있을까 말까 한 상황을 두고 시스템 성격을 규정하는 것은 실용적이지 않다.
정작 매일 영향을 주는 것은 평상시의 트레이드오프다.
쓰기를 할 때 모든 복제본의 확인을 기다린다 → 일관성 ↑, 지연 ↑
리더만 쓰고 바로 응답한다 → 지연 ↓, 일관성 ↓
이 선택이 사용자가 매일 체감하는 것이다. PACELC는 이것을 명시적으로 다룬다.
분류
| 시스템 | 분류 | 읽는 법 |
|---|---|---|
| DynamoDB, Cassandra | PA/EL | 분단 시 가용성, 평상시 저지연 |
| BigTable, HBase | PC/EC | 항상 일관성 우선 |
| MongoDB | PA/EC | 분단 시 가용성, 평상시 일관성 |
| MySQL 클러스터 | PC/EC | 항상 일관성 |
| PNUTS(야후) | PC/EL | 분단 시 일관성, 평상시 저지연 |
PA/EL 조합이 가장 흔하다 — 인터넷 서비스는 대체로 속도와 가용성을 우선한다.
왜 평상시에도 트레이드오프가 있나
복제본이 여러 곳에 있으면 동기화 자체에 시간이 든다.
서울 ─── 미국 서부 : 왕복 약 150ms
미국 복제본의 확인까지 기다리면 모든 쓰기가 150ms 이상 걸린다. 안 기다리면 빠르지만 미국에서 읽는 사용자는 옛 값을 볼 수 있다.
분단이 없어도 물리적 거리는 존재한다 — 이것이 PACELC의 통찰이다. 빛의 속도는 협상 대상이 아니다.
설계에 어떻게 쓰나
같은 시스템 안에서도 데이터마다 다르게 정할 수 있다.
- 결제 트랜잭션 — → EC (느려도 정확하게)
- 상품 조회 — → EL (빠르게, 잠깐 옛 값이어도 됨)
- 재고 표시 — → EL (표시는 대략)
- 재고 차감 — → EC (실제 차감은 정확히)
"재고 표시는 EL, 차감은 EC" 같은 구분이 실무의 답이다. 전체를 한쪽으로 몰지 않는다.
면접에서
CAP만 말하면 평범하지만, "CAP은 분단 시만 다루는데 실제로는 평상시의 지연-일관성 트레이드오프가 더 자주 문제가 됩니다" 라고 하면 분산 시스템을 실제로 고민해 본 사람으로 보인다.