Brain253. CAP 정리 (CAP Theorem)
핵심 인사이트 (3줄 요약)
- 본질: CAP 정리는 분산 시스템에서 일관성(Consistency), 가용성(Availability), 분단 내성(Partition Tolerance) 세 가지 특성 중 동시에 두 가지만 달성 가능하고, 세 가지를 모두 달성하는 것은 불가능하다고 주장하는 분산 시스템 이론이다.
- 가치: 분산 데이터베이스 설계의 근본적인 트레이드오프를 제시하여, 시스템 요구사항에 맞는 아키텍처 선택의 기준이 된다.
- 융합: PACELC 이론으로 확장되며, NoSQL 데이터베이스의 설계 철학을 설명하는 데 핵심적이고, RDBMS는 CA 시스템에 해당한다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
개념 정의
CAP 이론은 2000년 Eric Brewer가 제안하고 2002년 Gilbert와 Lynch가 수학적으로 증명한 이론으로, 분산 시스템은 다음 세 가지 특성 중 최대 두 가지만 동시에 보장받을 수 있다. 첫째, 일관성(Consistency)은 모든 노드가 동일한 시점에 동일한 데이터를 보는 특성이며, 둘째, 가용성(Availability)은 모든 요청에 대해 응답을 돌려주는 특성이며, 셋째, 분단 내성(Partition Tolerance)은 네트워크 분단이 발생해도 시스템이 동작하는 특성이다.
필요성
분산 시스템에서는 네트워크 분단(Partition)이不可避免하게 발생할 수 있다. 데이터 센터 간 네트워크 지연, 라우터 장애, 스위치 오작동 등 다양한 원인으로 네트워크 분단이 발생할 수 있다. 따라서 현실의 분산 시스템은 반드시 Partition Tolerance를 만족해야 하며, 설계자는 Consistency와 Availability 사이의 선택을 해야 한다. 이 선택이 시스템의 설계 방향을 결정하는 핵심 기준이 된다.
배경
2000년 ACM PODC(Principles of Distributed Computing)에서 Eric Brewer가 CAP 추측으로 제안하였고, 2002년 Nancy Lynch와 Seth Gilbert가 비동기 네트워크 모델에서 CAP 정리를 수학적으로 증명하였다. 이 정리는 이후 10년간 분산 시스템 설계의 핵심 원리로 자리잡았으며, NoSQL 운동의 이론적 기반이 되었다.
비유
CAP는 세 개의 우선순위가 같은 목표와 같다. 세 가지를 동시에 다 달성할 수 없어, 어떤 두 가지를 선택하든 나머지 하나는牺牲에 된다. 예를 들어, 세 명의 친구가 동시에 세 가지 소원을 사용할 수 있지만, 세 가지 모두는叶わわない 것과 같다.
📢 섹션 요약: CAP 정리는 분산 시스템 설계의 근본적 트레이드오프를 정의하며, 네트워크 분단이不可避免한 현실에서는 반드시 CP 또는 AP 중 하나를 선택해야 한다.
Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)
CAP 삼각형 구조
┌─────────────────────────────────────────────────────────────────────────────┐
│ CAP 삼각형 및 대표 시스템 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Consistency │
│ /\\ │
│ / \\ │
│ / \\ │
│ / CA \\ │
│ / ↖︎ \\ │
│ / \\ │
│ /──────────\\──────▶ Availability │
│ CP Systems AP Systems │
│ │
│ ┌───────────────────────────────────────────────────────────────────────┐ │
│ │ CA (Consistency + Availability) │ │
│ │ → 파티션 Tolerance 불필요 (네트워크 분단 없음 가정) │ │
│ │ → 단일 노드 데이터베이스, 전통적 RDBMS │ │
│ │ → 네트워크 분단이 발생하면 동작 불가 │ │
│ ├───────────────────────────────────────────────────────────────────────┤ │
│ │ CP (Consistency + Partition Tolerance) │ │
│ │ → 파티션 발생 시 가용성牺牲 │ │
│ │ → MongoDB, HBase, Redis Cluster, BigTable │ │
│ │ → 분단 발생 시 요청 응답 중단直到 복구 │ │
│ ├───────────────────────────────────────────────────────────────────────┤ │
│ │ AP (Availability + Partition Tolerance) │ │
│ │ → 파티션發生 시 일관성 sacrifice │ │
│ │ → Cassandra, DynamoDB, CouchDB, DNS │ │
│ │ → 분단 발생 시에도 응답하지만 데이터 불일치 가능 │ │
│ └───────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
[다이어그램 해설]
CAP 삼각형에서 세 꼭짓점은 C, A, P를 나타낸다. 현실의 분산 시스템은 반드시
P(Partition Tolerance)를 만족해야 한다. 네트워크 분단은不可避免하기 때문이다.
따라서 실제로는 CP 또는 AP 중 하나를 선택해야 한다. CP 시스템은 네트워크 분단
발생 시 일관성을 유지하기 위해 가용성을牺牲한다. 예컨대 MongoDB Replica Set에서
Primary 노드가 네트워크 분단되면, Secondary가 Primary 역할을引き継ぐ동안
요청을 처리하지 못한다. 반면 AP 시스템은 가용성을 유지하기 위해 일관성을
牺牲한다. Cassandra는 네트워크 분단 발생 시에도 모든 노드가 응답하지만,
반환하는 데이터는 각 노드의 현행 상태이므로 일치하지 않을 수 있다.
어떤 시스템을 선택할지는 애플리케이션의 요구사항에 따라 달라진다.
CP vs AP 시스템 상세 비교
┌─────────────────────────────────────────────────────────────────────────────┐
│ CP 시스템 vs AP 시스템 상세 비교 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────┬────────────────────────┬────────────────────────┐ │
│ │ 항목 │ CP 시스템 │ AP 시스템 │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 일관성 모델 │ 강철 일관성 │ 결과적 일관성 │ │
│ │ │ (항상 최신 데이터) │ (최종적으로 일치) │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 가용성 │ 분단 시 제한적 │ 항상 응답 │ │
│ │ │ (Primary 선출 대기) │ (모든 노드 응답) │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 대표 시스템 │ MongoDB, HBase, │ Cassandra, DynamoDB, │ │
│ │ │ Redis Cluster, BigTable │ CouchDB, Riak │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 적합 시나리오 │ 금융, 재고 관리, │ SNS, 메시징, IoT, │ │
│ │ │ 주문 관리 시스템 │ 캐시, 로그 수집 │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 데이터 모델 │ 키-값, 문서, 컬럼 패밀리 │ 키-값, 문서, 넓은 컬럼 │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 쓰기 처리 │ 단일 또는 소수 노드 │ 여러 노드에 동시 쓰기 │ │
│ │ │ (쓰기 충돌 없음) │ (쓰기 충돌 가능) │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 복구 방식 │ Primary 재선출 필요 │ 자동 복구 │ │
│ │ │ (서비스 일시 중단) │ (네트워크 복구 후 동기) │ │
│ └────────────────┴────────────────────────┴────────────────────────┘ │
│ │
│ 핵심 결론: │
│ CP 시스템은 "데이터의 정확성이 중요하다"는 전제 하에 설계되며, │
│ AP 시스템은 "서비스가 항상可以利用가능해야 한다"는 전제 하에 설계된다. │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] CP 시스템은 네트워크 분단 발생 시 일관성을 선택한다. MongoDB의 경우, Replica Set에서 Primary 노드가 분단되면Secondary 노드들이 새로운 Primary를 선출할 때까지 쓰기를 받지 않는다. 이 과정에서 가용성이 일시적으로牺牲된다. 반면 Cassandra 같은 AP 시스템은 네트워크 분단 발생 시에도 모든 노드가 응답하지만, 분단 양쪽에서 각각 쓰기가 발생하면 데이터 불일치가 발생할 수 있다. 이러한 차이는 애플리케이션의 성격에 따라 시스템 선택의 기준이 된다.
📢 섹션 요약: CAP 삼각형에서 현실의 분산 시스템은 반드시 P를 만족해야 하므로 CP 또는 AP 중 하나를 선택해야 하며, 이 선택은 시스템의 일관성 모델과 가용성 특성을 결정한다.
Ⅲ. 구현 및 실무 응용 (Implementation & Practice)
MongoDB (CP 시스템) 동작 예시
// MongoDB Replica Set에서 네트워크 분단 발생 시 동작
// 정상 상태: Primary로 모든 쓰기 처리
// {
// "members": [
// { "_id": 0, "host": "node1:27017", "stateStr": "PRIMARY" },
// { "_id": 1, "host": "node2:27017", "stateStr": "SECONDARY" },
// { "_id": 2, "host": "node3:27017", "stateStr": "SECONDARY" }
// ]
// }
// 네트워크 분단 발생 시 (node1과 node2, node3 간 분단):
// {
// "members": [
// { "_id": 0, "host": "node1:27017", "stateStr": "PRIMARY" }, // 여전히 Primary
// { "_id": 1, "host": "node2:27017", "stateStr": "SECONDARY" },
// { "_id": 2, "host": "node3:27017", "stateStr": "SECONDARY" }
// ]
// }
// node2, node3는 Majority를 확보하지 못하여 Primary 선출 실패
// → 읽기는 가능하나 쓰기는 불가 (가용성 감소)
// → 일관성은 유지 (모든 읽기가 동일한 데이터 반환)
Cassandra (AP 시스템) 동작 예시
-- Cassandra에서의 쓰기 동작 (AP 시스템)
-- 쓰기 시:
-- 1. 모든 노드에 동시에 쓰기 시도 (Local Quorum 기준)
-- 2. Quorum 수가 충족되면 성공으로 반환
-- 3. 충족되지 않으면 예외 발생
-- 예시:Consistency Level = QUORUM (노드 수의 과반)
-- CREATE KEYSPACE mykeyspace WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'dc1': 3};
-- 쓰기 예시
-- INSERT INTO users (id, name, email) VALUES (1, 'Kim', 'kim@example.com')
-- USING CONSISTENCY QUORUM;
-- 네트워크 분단 시:
-- • node1에만 기록된 데이터가 있고, node2, node3와 통신이 끊긴 경우
-- • node1에 기록은 성공하고, QUORUM(2)을 충족하여 클라이언트에 성공 반환
-- • 하지만 node2, node3에는 해당 데이터가 없음
-- • Eventually-consistent 방식으로 복구될 때까지 데이터 불일치 상태
CAP 선택 가이드
┌─────────────────────────────────────────────────────────────────────────────┐
│ CAP 시스템 선택 가이드 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ✅ CP 시스템 선택 (일관성 우선): │
│ ───────────────────────────────────────────────────────────────────── │
│ • 금융 거래, 결제 시스템: 잔액 불일치가 치명적 손실로 이어짐 │
│ • 재고 관리 시스템: overselling 방지를 위해 강철 일관성 필요 │
│ • 의료 시스템: 환자 데이터 불일치가 진단 오류로 이어질 수 있음 │
│ • 예약 시스템: double booking 방지를 위해 동기화 필수 │
│ │
│ ✅ AP 시스템 선택 (가용성 우선): │
│ ───────────────────────────────────────────────────────────────────── │
│ • SNS, 메시징: 일부 데이터 지연이 사용자 경험에 미미한 영향 │
│ • IoT 센서 데이터: 일부 데이터 손실보다 수집 중단이 더 문제 │
│ • 콘텐츠 관리: 빠른 응답이 사용자 만족에 더 중요 │
│ • 로그 분석: 약간의 데이터 불일치보다 가용성이 더 중요 │
│ │
│ ⚠️ 주의: 한 시스템 내에서라도 작업 유형에 따라 선택 가능 │
│ ───────────────────────────────────────────────────────────────────── │
│ • 금융 거래: CP (강한 일관성) │
│ • 프로필 조회: AP (빠른 응답) │
│ • 위 두 작업을 같은 Cassandra 클러스터에서 처리 가능 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
📢 섹션 요약: CAP 시스템 선택은 애플리케이션의业务 특성上 맞게 이루어져야 하며, 하나의 시스템 안에서도 작업 유형에 따라 CP와 AP를 혼합 사용하는 것이 가능하다.
Ⅳ. 품질 관리 및 테스트 (Quality & Testing)
CAP 분포 환경 테스트
┌─────────────────────────────────────────────────────────────────────────────┐
│ CAP 관련 품질 테스트 항목 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. 네트워크 분단 시뮬레이션 │
│ • 특정 노드 간 네트워크 연결 차단 │
│ • 분단 기간 중 읽기/쓰기 동작 확인 │
│ • 분단 복구 후 데이터 동기화 확인 │
│ │
│ 2. 일관성 수준 측정 │
│ • 분산 읽기 시 반환되는 데이터 버전 차이 분석 │
│ • 쓰기衝突 발생 빈도 및 해결 방식 확인 │
│ • Eventually consistent 상태 도달 시간 측정 │
│ │
│ 3. 가용성 측정 │
│ • 노드 장애 시 서비스 중단 시간 측정 │
│ • 자동 장애 복구 동작 확인 │
│ • Quorum 손실 시 시스템 동작 확인 │
│ │
│ 4. 성능 테스트 │
│ • 일관성 수준별 응답 시간 비교 │
│ • 네트워크 지연이 성능에 미치는 영향 분석 │
│ • 시스템 부하 시 일관성/가용성 트레이드오프 확인 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
📢 섹션 요약: CAP 관련 테스트는 네트워크 분단 상황 시뮬레이션, 일관성/가용성 측정, 성능 분석을 포함해야 하며, 실제 환경에서의 동작을 사전에 검증해야 한다.
Ⅴ. 최신 트렌드 및 결론 (Trends & Conclusion)
PACELC 이론으로의 확장
PACELC(PE-ELC)는 2010년 Daniel Abadi가 제안한 CAP의 확장 이론이다. CAP가 네트워크 분단 상황에서의 트레이드오프만 다루는 반면, PACELC는 네트워크가 정상일 때에도 일관성 vs 가용성(또는 지연 시간) 사이의 트레이드오프가 존재함을 보여준다.
┌─────────────────────────────────────────────────────────────────────────────┐
│ PACELC 모델 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 네트워크 분단 시 (CAP): │
│ ──────────────────────────────── │
│ • PC-EL: 일관성 우선 (强일관성,可用성牺牲) → MongoDB, HBase │
│ • PA-EL: 가용성 우선 (可用성维持, 일관성牺牲) → Cassandra, DynamoDB │
│ │
│ 네트워크 정상 시 (ELC): │
│ ──────────────────────────────── │
│ • PAX-SE: Strong consistency 우선 (지연 증가) │
│ • PAE-LE: Low latency 우선 (일관성 희생 가능) │
│ │
│ ┌───────────────┬────────────────────────┬────────────────────────┐ │
│ │ Database │ CAP 분류 │ PACELC 분류 │ │
│ ├───────────────┼────────────────────────┼────────────────────────┤ │
│ │ MongoDB │ CP │ PE-ELC │ │
│ │ Cassandra │ AP │ PE-ELC │ │
│ │ HBase │ CP │ PE-ELC │ │
│ │ DynamoDB │ AP │ PA-ELC │ │
│ │ CouchDB │ AP │ PE-ELC │ │
│ └───────────────┴────────────────────────┴────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
NewSQL의 등장
NewSQL은 CAP의 제약 속에서 가능한 한 C와 A를 모두 달성하려는新一代 분산 데이터베이스이다. Google Spanner, CockroachDB, TiDB, NuoDB 등이 대표적인 예이다. 이러한 시스템은 분산 환경에서 강한 일관성(ACID)을 제공하면서도, 수평적 확장성을 갖춘다. 그러나 PACELC에 따르면 이러한 시스템도 일관성과 지연 시간(가용성과 연결) 사이의 트레이드오프는 존재한다.
결론
CAP 정리는 분산 시스템 설계의 가장 기본적인 이론이며, 이후 PACELC 이론으로 확장되었다. 시스템을 설계할 때는 네트워크 분단 상황뿐 아니라 정상 작동 시의 동작까지 고려해야 한다. 무엇보다 중요한 것은, CAP 선택이一开始就 결정되는 것이 아니라 애플리케이션의 요구사항에 따라 지속적으로 평가되어야 한다는 것이다.
📢 섹션 요약: CAP 정리는 분산 시스템 설계의 핵심 이론이며, PACELC 이론으로 확장되어 네트워크 정상 시의 동작까지 고려해야 한다. 시스템 설계 시 일관성, 가용성, 지연 시간 사이의 트레이드오프를 명시적으로 평가해야 한다.
핵심 인사이트 ASCII 다이어그램 (Concept Map)
┌─────────────────────────────────────────────────────────────────────────────┐
│ CAP Theorem Concept Map │
│ │
│ Consistency │
│ ▲ │
│ /│\\ │
│ / │ │ │
│ / │ │ │
│ / │ │ │
│ / │ │ │
│ Availability ◀──────┴────┴─┴──────▶ Partition Tolerance │
│ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ CA │ │ CP │ │ AP │ │
│ │ (단일 DB) │ │(MongoDB) │ │(Cassandra) │ │
│ │ 전형적 RDBMS │ │强일관성優先 │ │可用性優先 │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
│ 관련 개념: PACELC, Eventual Consistency, 2PC, NewSQL, Consensus │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
참고
- CAP 정리는 Gilbert와 Lynch의 2002년 논문에서 수학적으로 증명되었다.
- 현실의 분산 시스템은 반드시 Partition Tolerance를 만족해야 하므로, CP 또는 AP 중 선택해야 한다.
- PACELC 이론은 네트워크 정상 시의 동작까지 고려해야 함을 강조한다.
- CAP 선택은 고정된 것이 아니라 애플리케이션 요구사항에 따라 동적으로 평가되어야 한다.