Brain254. CP 시스템 / AP 시스템 / CA 시스템
핵심 인사이트 (3줄 요약)
- 본질: CAP 정리에 따른 분산 시스템 분류로, CP는 일관성과 분단 내성을, AP는 가용성과 분단 내성을, CA는 일관성과 가용성을 선택한 시스템이며, 현실의 분산 시스템은 반드시 P를 만족해야 하므로 실질적으로는 CP 또는 AP만 가능하다.
- 가치: 데이터베이스 선택 시 시스템의 일관성 모델과 가용성 특성을 이해하는 데 핵심적인 기준을 제공한다.
- 융합: CAP 정리, PACELC 이론, 일관성 수준(Isolation Level), 복제 전략과 밀접하게 연관된다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
개념 정의
CAP 정리에 따른 세 가지 시스템 분류는 분산 데이터베이스의 설계 철학과 동작 특성을 이해하는 핵심이다. CP 시스템(Consistency + Partition Tolerance)은 네트워크 분단 발생 시 일관성을 유지하기 위해 가용성을犠牲하며, AP 시스템(Availability + Partition Tolerance)은 네트워크 분단 발생 시에도 가용성을 유지하기 위해 일관성을犠牲한다. CA 시스템(Consistency + Availability)은 네트워크 분단이 발생하지 않는다는 가정 하에 동작한다.
필요성
분산 데이터베이스를 선택할 때, 시스템이 CP와 AP 중 어느 쪽에 속하는지 이해하는 것은 시스템의 동작 특성을 예측하는 데 필수적이다. 금융 시스템에는 CP 시스템이 적합하고,sns나IoT에는 AP 시스템이 적합하다. 이러한 분류를 이해하지 못하면 시스템 요구사항에 맞지 않는 선택을 할 수 있어 치명적인 문제를 야기할 수 있다.
배경
2000년 Eric Brewer의 CAP 추측 이후, 분산 데이터베이스는 설계之初에 CP 또는 AP 중 하나를 선택해야 했다. 2010년 이후에는 NewSQL이 등장하여 CAP의 제약을 극복하려는 시도가 있지만, 여전히 PACELC 이론이 적용되는 등 기본적 분류는 유효하다.
CA 시스템에 대한 오해
CA 시스템은 네트워크 분단이 발생하지 않는다는 가정 하에 동작하므로, 단일 노드 데이터베이스나 네트워크 분단이 발생하지 않는 환경에서만 작동한다. 그러나 현실의 분산 시스템에서는 네트워크 분단이不可避免하므로, CA 시스템은 이론적으로만 존재하며, 실질적인 분산 데이터베이스는 항상 P를 만족해야 한다. 전형적 RDBMS(Oracle, PostgreSQL 등)는 단일 노드에서는 CA처럼 동작하지만, 분산 환경에서는 CP 또는 AP로 동작한다.
비유
CP 시스템은 "정확한 답만 해야 한다"는 원칙이 있고, AP 시스템은 "답은 항상 해야 한다"는 원칙이 있다. CA 시스템은 "네트워크가 끊어지지 않는다는 이상적 환경"에서만 존재하는 이론적 분류이다.
📢 섹션 요약: CP와 AP는 CAP 정리에서 파티션 내성(P)을 만족하는 현실적 분산 시스템의 두 축이며, CA 시스템은 이론적 분류에 불과하다.
Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)
CP vs AP vs CA 시스템 구조 비교
┌─────────────────────────────────────────────────────────────────────────────┐
│ CP vs AP vs CA 시스템 구조 비교 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ [CP 시스템 동작: 일관성 우선] │
│ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 네트워크 분단 발생 시 │ │
│ │ │ │
│ │ 노드 A ────── ✕ (분단) ────── 노드 B │ │
│ │ │ │ │ │
│ │ ▼ ▼ │ │
│ │ 쓰기 불가 쓰기 불가 │ │
│ │ (가용성牺牲) (가용성牺牲) │ │
│ │ │ │
│ │ → 모든 노드가 동일한 데이터를 반환 (일관성 유지) │ │
│ │ → 응답 지연 또는 서비스 불가가상 가능 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ [AP 시스템 동작: 가용성 우선] │
│ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 네트워크 분단 발생 시 │ │
│ │ │ │
│ │ 노드 A ────── ✕ (분단) ────── 노드 B │ │
│ │ │ │ │ │
│ │ ▼ ▼ │ │
│ │ 쓰기/읽기 가능 쓰기/읽기 가능 │ │
│ │ (일관성 sacrifice) (일관성 sacrifice) │ │
│ │ │ │
│ │ → 모든 노드가 응답 (가용성 유지) │ │
│ │ → 노드 간 데이터 불일치 가능 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ [CA 시스템: 이론적 분류] │
│ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ • 네트워크 분단이 발생하지 않는 환경에서만 가능 │ │
│ │ • 단일 노드 데이터베이스 또는 전용线路으로 연결된 서버 │ │
│ │ • 예: 전통적 RDBMS (단일 노드 모드) │ │
│ │ • 분산 환경에서는 적용 불가 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
[다이어그램 해설]
CP 시스템은 네트워크 분단 시 일관성을 선택한다. 모든 노드가 동일한 데이터를
반환하도록 보장하지만, 일부 노드가 응답하지 않을 수 있어 가용성이牺牲된다.
예를 들어 MongoDB Replica Set에서 Primary가 분단되면, 새로운 Primary가
선출될 때까지 전체 클러스터의 쓰기가 중단된다. 반면 AP 시스템은 네트워크
분단 시에도 모든 노드가 계속 응답하지만, 노드 간 데이터가 불일치할 수 있다.
Cassandra에서 네트워크 분단이 발생하면, 각 노드가 독립적으로 쓰기를 수락하며
복구 후 Eventually consistent 상태가 된다.
대표 시스템 목록
┌─────────────────────────────────────────────────────────────────────────────┐
│ CAP 시스템 분류별 대표 데이터베이스 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────┬──────────────────────────────────────────────────┐ │
│ │ CP 시스템 │ MongoDB, HBase, Redis Cluster, BigTable, │ │
│ │ │ HDFS (Hadoop Distributed File System), │ │
│ │ │ Memcached (분산 모드) │ │
│ ├────────────────┼──────────────────────────────────────────────────┤ │
│ │ AP 시스템 │ Cassandra, DynamoDB, CouchDB, Riak, │ │
│ │ │ Amazon S3, DNS, Web DNS, │ │
│ │ │ Voldemort, Kyoto Cabinet │ │
│ ├────────────────┼──────────────────────────────────────────────────┤ │
│ │ CA 시스템 │ 전형적 RDBMS (Oracle, PostgreSQL, MySQL │ │
│ │ │ - 단일 노드 모드), MS Access │ │
│ │ │ ※ 분산 환경에서는 실질적으로 CP 또는 AP로 동작 │ │
│ └────────────────┴──────────────────────────────────────────────────┘ │
│ │
│ NewSQL (CAP 제약을 극복하려는 시도): │
│ ┌────────────────┬──────────────────────────────────────────────────┐ │
│ │ Google │ Spanner (글로벌 분산, 강철 일관성) │ │
│ │ CockroachDB │ 글로벌 분산, Strong consistency │ │
│ │ TiDB │ MySQL 호환, 강철 일관성 │ │
│ │ NuoDB │ Elasitc SQL, 강철 일관성 │ │
│ └────────────────┴──────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] CP 시스템의 대표인 MongoDB는 Replica Set에서 Primary 노드가 분단되면, Secondary 노드들이 Majority 기반 새 Primary를 선출한다. 선출이 완료될 때까지 클러스터 전체의 쓰기가 불가능하다. AP 시스템의 대표인 Cassandra는 Gossip 프로토콜을 통해 노드 상태를 전파하며, 쓰기 시 Quorum(과반) 노드에 기록되면 성공으로 반환한다. 네트워크 분단 시에도 각 노드가 독립적으로 쓰기를 수락하며, 복구 후 읽기 시 충돌 해소(Last Writer Wins 또는 Timestamp 기반)를 수행한다.
일관성 수준과 CAP의 관계
┌─────────────────────────────────────────────────────────────────────────────┐
│ 일관성 수준별 CAP 분류 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 일관성 수준이 강할수록 → CP 시스템에 가까워짐 │
│ 일관성 수준이 약할수록 → AP 시스템에 가까워짐 │
│ │
│ Strong Consistency (강철 일관성) │
│ ──────────────────────────────── │
│ • Linearizability: 모든 연산이 글로벌 시계 순서로 실행 │
│ • Sequential Consistency: 모든 노드가 동일한 순서로 연산 관찰 │
│ → CP 시스템의 특성 │
│ │
│ Eventual Consistency (결과적 일관성) │
│ ───────────────────────────────── │
│ • 읽기가 즉시 반영되지 않을 수 있음 │
│ •最终적으로 모든 복제본이 동일해짐 │
│ → AP 시스템의 특성 │
│ │
│ Causal Consistency (인과적 일관성) │
│ ───────────────────────────────── │
│ • 원인과 결과의 관계가 올바르게 보존 │
│ • 병렬 연산은 순서 보장 불가 │
│ → CP와 AP 사이의 중간 지점 │
│ │
│ ┌────────────────┬────────────────────────┬────────────────────────┐ │
│ │ 시스템 │ 일관성 모델 │ CAP 분류 │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ Zookeeper │ Sequential Consistency │ CP │ │
│ │ etcd │ Linearizability │ CP │ │
│ │ Cassandra │ Eventual Consistency │ AP │ │
│ │ DynamoDB │ Eventual (Tunable) │ AP │ │
│ │ MongoDB │ Strong (default) │ CP │ │
│ └────────────────┴────────────────────────┴────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
📢 섹션 요약: CP 시스템은 강철 일관성을, AP 시스템은 결과적 일관성을 제공하며, 시스템의 일관성 수준을 이해하는 것이 CAP 분류를 이해하는 데 필수적이다.
Ⅲ. 구현 및 실무 응용 (Implementation & Practice)
MongoDB (CP) 설정 및 동작
// MongoDB Replica Set 설정 (CP 시스템)
{
"_id": "myReplicaSet",
"members": [
{ "_id": 0, "host": "node1:27017", "priority": 2 },
{ "_id": 1, "host": "node2:27017", "priority": 1 },
{ "_id": 2, "host": "node3:27017", "priority": 1 }
],
"settings": {
"chainingAllowed": false, // Secondary에서 Primary로의 복제 허용 안함
"getLastErrorModes": {
"majority": { "majority": 2 } // 쓰기 시 Majority 확인 필요
}
}
}
// 쓰기 Concern 설정
db.collection.insertOne(
{ name: "Kim" },
{ writeConcern: { w: "majority", j: true, wtimeout: 5000 } }
)
// w: "majority" → 과반 노드에 기록되어야 성공
// j: true →磁盘에 기록되어야 성공
// 네트워크 분단 시: w: "majority" 미충족으로 쓰기 실패
Cassandra (AP) 설정 및 동작
-- Cassandra 클러스터 설정 (AP 시스템)
-- keyspace 생성 시 NetworkTopologyStrategy 사용
CREATE KEYSPACE mykeyspace
WITH REPLICATION = {
'class': 'NetworkTopologyStrategy',
'dc1': 3,
'dc2': 3
}
AND DURABLE_WRITES = true;
-- Tunable Consistency: 읽기/쓰기 시 일관성 수준 조정 가능
-- Consistency Level: ANY (가장 낮은 일관성, 가장 높은 가용성)
-- ALL (가장 높은 일관성, 가장 낮은 가용성)
-- QUORUM (과반, 균형점)
-- ONE (하나의 노드, 가장 높은 가용성)
-- 쓰기: 항상 가용성 우선
INSERT INTO users (id, name, email) VALUES (1, 'Kim', 'kim@test.com')
USING CONSISTENCY QUORUM;
-- 읽기: Quorum 단위로 읽기
SELECT * FROM users WHERE id = 1 USING CONSISTENCY QUORUM;
-- 네트워크 분단 시:
-- • 노드 수가 QUORUM 미만의 쓰기만 수락 → 일부 노드에만 기록
-- • 읽기 시 다른 버전의 데이터를 반환할 수 있음
-- • 복구 후 eventually consistent 상태 달성
시스템 선택 실무 가이드
┌─────────────────────────────────────────────────────────────────────────────┐
│ CP vs AP 시스템 선택 가이드 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ CP 시스템이 적합한 경우: │
│ ───────────────────────────────────────────────────────────────────── │
│ ✅ 금융 거래, 송금 시스템: 잔액 불일치가 금전적 손실로 이어짐 │
│ ✅ 항공좌석 예약, 호텔 예약: double booking 방지가 핵심 │
│ ✅ 재고 관리 (유통): overselling으로 인한 고객 불만 방지 │
│ ✅ 의료 데이터: 환자 정보 불일치가 진료 오류로 이어질 수 있음 │
│ ✅ 재무 회계: 트랜잭션 정합성이 최우선 │
│ │
│ AP 시스템이 적합한 경우: │
│ ───────────────────────────────────────────────────────────────────── │
│ ✅ SNS, 메시징 플랫폼: 빠른 응답과 가용성이 사용자 경험에直接影响 │
│ ✅ IoT 센서 데이터 수집: 일부 데이터 손실보다 수집 중단이 더 문제 │
│ ✅ 전자상거래 상품 검색/조회: 상품 정보의 즉각적 일관성보다 빠른 응답이 중요 │
│ ✅ 로그 분석, 모니터링: 대량 쓰기를 빠르게 수락하는 것이 중요 │
│ ✅ 게임 리더보드: 실시간 순위 업데이트가 필요하지만 약간의 불일치 허용 │
│ │
│ ⚠️ 주의: 하나의 애플리케이션에서도用途별로 다른 시스템 선택 가능 │
│ ───────────────────────────────────────────────────────────────────── │
│ 예: 전자상commerce 플랫폼 │
│ • 주문/결제 → CP 시스템 (MongoDB, PostgreSQL) │
│ • 상품 검색/조회 → AP 시스템 (Elasticsearch) │
│ • 세션/캐시 → Redis (AP 시스템) │
│ • 분석/리포팅 → 분석용 DB (AP 시스템) │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
📢 섹션 요약: CP와 AP 시스템 선택은 애플리케이션의业务 특성에 따라 달라지며, 하나의 시스템에서 다양한 용도의 DB를 혼합 사용하는 것이 일반적이다.
Ⅳ. 품질 관리 및 테스트 (Quality & Testing)
CP/AP 시스템 테스트 전략
┌─────────────────────────────────────────────────────────────────────────────┐
│ CP/AP 시스템 테스트 체크리스트 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ [CP 시스템 테스트] │
│ ───────────────── │
│ □ 네트워크 분단 시 쓰기 불가 확인 │
│ □ 분단 복구 후 일관성 자동 복구 확인 │
│ □ Primary 선출 시간 측정 (서비스 중단 시간) │
│ □ 쓰기 Concern 미달 시 오류 처리 확인 │
│ □ Majority 쓰기/읽기 시 데이터 정합성 확인 │
│ │
│ [AP 시스템 테스트] │
│ ───────────────── │
│ □ 네트워크 분단 시 모든 노드 응답 확인 │
│ □ 분단 중 쓰기 후 분단 복구 시 데이터 불일치 수준 측정 │
│ □ 쓰기 충돌 발생 시 해결 방식 (LWW, Timestamp) 확인 │
│ □ 읽기不一致 수준 측정 (Staleness) │
│ □ Eventually consistent 상태 도달 시간 측정 │
│ │
│ [공통 테스트] │
│ ───────────── │
│ □ 노드 장애/복구 시 동작 확인 │
│ □ 부하 테스트 시 일관성/가용성 트레이드오프 확인 │
│ □ 네트워크 지연이 성능에 미치는 영향 분석 │
│ □ 백업/복구 시 데이터 정합성 확인 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
📢 섹션 요약: CP 시스템은 네트워크 분단 시 일관성 복구 능력을, AP 시스템은 가용성 유지 및 Eventually consistent 복구 능력을 검증해야 한다.
Ⅴ. 최신 트렌드 및 결론 (Trends & Conclusion)
NewSQL의 등장
NewSQL은 CAP의 제약을 극복하려는 시도이다. Google Spanner, CockroachDB, TiDB, NuoDB 등은 분산 환경에서도 강철 일관성(ACID)을 제공하면서 수평적 확장성을 갖추고 있다. 그러나 PACELC 이론에 따르면 이러한 시스템도 지연 시간(가용성과 연결)과의 트레이드오프는 존재한다.
하이브리드 접근
현실의 시스템에서는 CP와 AP를 혼합 사용하는 것이 일반적이다. 예를 들어 전자상commerce 플랫폼에서는 주문/결제에 CP 시스템(MongoDB)을 사용하고, 상품 검색에 AP 시스템(Elasticsearch)을 사용하는 것이 대표적이다. 이를 폴리글랏 퍼시스턴스(Polyglot Persistence)라고 한다.
결론
CP와 AP 시스템의 선택은 분산 데이터베이스 설계의 가장 근본적인 결정이다. 시스템을 이해하고 올바르게 선택하는 것이 매우 중요하며, 하나의 시스템이 모든 용도에 적합할 수는 없다. 애플리케이션의 요구사항을 분석하여 적절한 시스템을 선택하고, 필요시 여러 시스템을 조합하여使用해야 한다.
📢 섹션 요약: CP와 AP 시스템의 선택은 애플리케이션 요구사항에 따라 달라지며, 하나의 시스템으로 모든 것을 해결할 수 없음을認識하여 폴리글랏 퍼시스턴스 접근이 필요하다.
핵심 인사이트 ASCII 다이어그램 (Concept Map)
┌─────────────────────────────────────────────────────────────────────────────┐
│ CP vs AP vs CA Concept Map │
│ │
│ ┌───────────────────┐ │
│ │ CAP Theorem │ │
│ └─────────┬─────────┘ │
│ │ │
│ ┌───────────────────┼───────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ CA │ │ CP │ │ AP │ │
│ │ (단일 노드) │ │(MongoDB 등) │ │(Cassandra 등)│ │
│ │ 비현실적 │ │일관성優先 │ │可用성優先 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │ │ │
│ │ ▼ ▼ │
│ │ ┌─────────────┐ ┌─────────────┐ │
│ │ │ Strong │ │ Eventual │ │
│ │ │ Consistency │ │ Consistency │ │
│ │ └─────────────┘ └─────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────┐ │
│ │ NewSQL: CAP 제약을 극복하려는 시도 │ │
│ │ (Spanner, CockroachDB, TiDB, NuoDB) │ │
│ └─────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
참고
- CA 시스템은 네트워크 분단이 발생하지 않는 환경에서만 존재하는 이론적 분류이다.
- 현실의 분산 시스템은 반드시 Partition Tolerance를 만족해야 하므로 CP 또는 AP만 가능하다.
- CP와 AP의 선택은 애플리케이션의 일관성/가용성 요구사항에 따라 결정되어야 한다.
- 하나의 애플리케이션에서 다양한 용도에 따라 CP와 AP 시스템을 혼합 사용할 수 있다.