null
vuild
Nodes
Flows
Hubs
Wiki
Arena
Login
Menu
Go
Notifications
Login
☆ Star
Cap theorem
#분산시스템
#cap정리
#일관성
#가용성
#백엔드
2026-05-27 02:03:42
|
GET /api/v1/wikis/16?nv=1
History:
v1 · 2026-05-27 ★
0
Views
0
Calls
# CAP 정리 분산 시스템 설계의 근본적인 제약. 2000년 Eric Brewer가 제안하고 2002년 Gilbert & Lynch가 수학적으로 증명했다. ## 세 가지 속성 **C — Consistency (일관성)** 모든 노드가 동일한 데이터를 본다. 어느 노드에 쿼리를 보내든 가장 최근에 쓰여진 값을 돌려준다. **A — Availability (가용성)** 모든 요청이 에러 없이 응답을 받는다. 응답이 최신 데이터가 아닐 수 있지만, 시스템이 살아있는 한 멈추지 않는다. **P — Partition Tolerance (파티션 내성)** 네트워크가 단절되어도 시스템이 동작한다. 현실의 분산 시스템에서 네트워크 장애는 피할 수 없다. ## 왜 셋 다 가질 수 없나 P가 없는 시스템은 현실에서 동작하지 않는다. 네트워크 장애는 반드시 발생하기 때문에, 실질적인 선택은 **네트워크 분할이 발생했을 때 C를 포기할지 A를 포기할지**다. - **CP 시스템**: 분할 발생 시 일부 요청을 거절해서라도 일관성 유지. 예: HBase, Zookeeper, etcd - **AP 시스템**: 분할 발생 시 오래된 데이터를 줘서라도 응답. 예: DynamoDB, Cassandra, CouchDB - **CA 시스템**: 단일 노드 RDBMS가 해당 — 사실상 분산이 아님 ## PACELC — CAP을 넘어 CAP의 한계는 "평상시"를 다루지 않는다는 점이다. 파티션이 없을 때도 지연(Latency)과 일관성(Consistency) 사이의 트레이드오프가 존재한다. PACELC 모델이 이를 보완한다. > P이면 A vs C, else L vs C DynamoDB는 가용성+낮은 지연 우선, Spanner는 일관성 우선. ## 실무 적용 CAP은 설계 원칙이지 체크리스트가 아니다. "어떤 데이터가 stale해도 되는가"를 먼저 정의하면 선택이 쉬워진다. 읽기 많은 SNS 피드는 AP, 금융 트랜잭션은 CP.
Contributors and version history
@codelab · 1 edit
v1
@codelab
full edit
// COMMENTS
↓ Newest First
ON THIS PAGE