CAP 정리(Brewer’s Theorem)는 분산 시스템에서 일관성(Consistency), 가용성(Availability), 파티션 허용성(Partition Tolerance) 중 동시에 2가지만 보장할 수 있다는 원리다.
| 속성 | 정의 |
|---|---|
| Consistency (C) | 모든 노드가 동일한 최신 데이터를 반환 (선형화 가능성) |
| Availability (A) | 모든 요청이 오류 없이 응답 (일부 노드 장애 시에도) |
| Partition Tolerance (P) | 네트워크 파티션(메시지 손실·지연) 발생 시에도 동작 지속 |
실제 선택: 네트워크 파티션은 불가피하므로 P는 항상 선택. 결국 CP vs AP의 선택이 된다.
| 구분 | CP (Consistency + Partition) | AP (Availability + Partition) |
|---|---|---|
| 특성 | 파티션 시 일관성 유지, 가용성 희생 (일부 요청 거부) | 파티션 시 가용성 유지, 일관성 희생 (Stale 데이터 허용) |
| 대표 시스템 | HBase, Zookeeper, etcd, MongoDB (강한 일관성 모드) | Cassandra, DynamoDB, CouchDB |
| 적합 용도 | 금융 거래, 재고 관리, 분산 잠금 | 소셜 미디어 피드, DNS, 장바구니 |
| 구분 | ACID | BASE |
|---|---|---|
| 일관성 | 강한 일관성 (Strong Consistency) | 결과적 일관성 (Eventual Consistency) |
| 가용성 | 낮음 (락·롤백으로 대기 발생) | 높음 (항상 응답, 최신 데이터 아닐 수 있음) |
| 적합 DB | MySQL, PostgreSQL, Oracle | Cassandra, DynamoDB, Redis |
| BASE 풀이 | Basically Available: 항상 응답, Soft State: 시간에 따라 상태 변화 가능, Eventually Consistent: 최종적으로 일관 상태 도달 | |
| 구분 | Paxos | Raft |
|---|---|---|
| 이해도 | 이론적으로 복잡, 구현 어려움 | “이해 가능성”을 목표로 설계, 명확한 리더 선출 |
| 리더 선출 | 암묵적 | 명시적 (Term 기반 Election) |
| 로그 복제 | 복잡한 2단계 프로토콜 | 리더가 팔로워에 Log Entry 복제, 과반수 커밋 |
| 활용 사례 | Google Chubby, Apache Zookeeper (ZAB 유사) | etcd, CockroachDB, TiKV, Consul |
Raft 동작 원리: ① 리더 선출(Election) → ② 로그 복제(Log Replication) → ③ Safety(커밋된 로그는 절대 변경 안됨) 세 가지 서브 문제로 분리하여 이해 용이성 달성
CAP 정리는 분산 시스템 설계의 근본 제약이며, 파티션 내성을 전제로 CP(일관성 우선)와 AP(가용성 우선) 중 비즈니스 요구에 따라 선택한다. Raft는 Paxos보다 이해하기 쉽게 설계되어 etcd·CockroachDB 등 현대 분산 시스템의 표준 합의 알고리즘이 되었다.
요양원 선택 전 반드시 확인해야 할 체크리스트를 공개합니다. 공식 평가 자료 조회법, 방문 시 확인…
공공기관 채용 비리의 실태와 피해 지원자의 대응법을 정리했습니다. 채용 비리 신고 방법, 공익신고자 보호제도, 취준생…
주식 손실을 세금 절약에 활용하는 합법적 방법을 공개합니다. 해외주식 손익통산, ISA 계좌 활용, 연금계좌 절세까지…
배달이 예상 시간보다 크게 늦으면 취소·환불을 요청할 수 있습니다. 배달앱별 지연 취소 방법과 잘못 배달됐을…
통신비 절약의 핵심은 요금제 최적화입니다. 내 데이터 사용량 확인법, 알뜰폰 전환 비교, 위약금 없이 요금제…