CAP, PACELC 개념·트레이드오프 정리

목차

1. 분산 시스템이 필요한 이유 (확장성, 장애 허용, 지연 문제 해결)
2. CAP(Consistency, Availability, Partition Tolerance) 개념
3. CA / CP / AP 시스템 실제 사례 (RDBMS, HBase, Cassandra 등)
4. PACELC 개념
5. 분산 시스템 설계 Trade-off
6. 요약
7. 참고

---

1. 분산 시스템이 필요한 이유 (확장성, 장애 허용, 지연 문제 해결)

분산 시스템은 단일 서버로 해결할 수 없는 문제를 풀기 위해 필요합니다. 주요 이유는 다음과 같습니다.

• 확장성 (Scalability)
  데이터와 트래픽이 기하급수적으로 증가할 때, 하나의 서버만으로는 처리 한계가 있습니다.
  여러 대의 서버를 수평적으로 확장(horizontal scaling)하면 처리량(throughput)과 저장 용량을 유연하게 늘릴 수 있습니다.
• 장애 허용 (Fault Tolerance)
  단일 서버가 다운되면 전체 서비스가 멈추는 단일 장애점(SPOF, Single Point of Failure)이 생깁니다.
  분산 시스템은 데이터를 복제(replication)하고 장애 감지 및 복구 메커니즘을 통해 일부 노드가 고장 나더라도 서비스가 지속되도록 합니다.
• 지연 문제 해결 (Latency Reduction)
  지리적으로 분산된 사용자에게 빠른 응답을 제공하기 위해, 가까운 데이터센터나 캐시 서버를 두는 방식이 필요합니다.
  분산 시스템은 지역별로 데이터를 분산 배치하여 지연(latency)을 줄이는 데 기여합니다.

---

2. CAP(Consistency, Availability, Partition Tolerance) 개념

CAP - 출처: https://data-science-blog.com/blog/2021/10/14/cap-theorem/

 
CAP 정리는 2000년대 초반에 정립된 분산 시스템 설계의 기본 원리입니다.

• Consistency (일관성, C)
  모든 노드가 같은 시점에 동일한 데이터를 보여주는 성질
  → 사용자가 어느 노드에 접속해도 항상 최신 데이터가 보장됨.
  
• Availability (가용성, A)
  모든 요청이 항상 응답을 받는 성질
  → 다만, 응답이 반드시 최신 데이터일 필요는 없음.
  
• Partition Tolerance (분할 허용, P)
  네트워크 장애로 노드 간 통신이 불가능한 상황(분할)이 발생하더라도 시스템이 동작할 수 있는 성질

CAP 핵심 포인트

1. “2 of 3” 단순화는 오해

• CAP은 흔히 세 가지 중 두 개만 선택 가능이라는 "2 of 3" 규칙으로 설명되지만, 실제로는 흑백논리가 아님.
• 실제로 일관성(C)과 가용성(A)은 0%/100%가 아니라 연속적인 스펙트럼에 존재함.
• 예: (일관성 40%, 가용성 60%) 또는 (일관성 20%, 가용성 80%)

2. Partition(네트워크 분할)은 피할 수 없음

• 분산 환경에서 네트워크 장애가 필연적으로 발생할 수 있음.
• 따라서 설계자는 결국 C와 A 중 어떤 속성을 우선시할지를 선택해야 함.

3. 선택은 전역이 아닌 국지적

• C ↔ A의 선택은 시스템 전체에 한 번만 내려지는 것이 아님.
• 연산 단위, 데이터 종류, 사용자 상황에 따라 달라질 수 있음.
• 예:
  - 은행 이체 → 강한 일관성(C) 필요 (가용성 희생 가능)
  - 소셜 미디어 좋아요 → 높은 가용성(A) 필요 (일관성 지연 허용)

C ↔ A 선택 예시

1. 강한 일관성(C)을 보장하는 경우

• 은행 계좌 이체
  - A 계좌에서 돈을 빼고, B 계좌에 입금하는 과정은 반드시 정확해야 합니다.
  - 만약 네트워크 분할 상황에서 A에서 돈만 빠져나가고 B에 입금이 안 되면 큰 문제가 발생.
  - 따라서 이 경우에는 가용성(A)을 희생하더라도 일관성(C)을 우선해야 합니다.
    → 사용자가 순간적으로 “서비스 지연” 메시지를 보는 것이 차라리 안전합니다.

2. 높은 가용성(A)을 우선하는 경우

• 소셜 미디어 게시글 좋아요(Like) 버튼
  - 네트워크 분할 시에도 사용자가 “좋아요”를 누르면 즉시 반영된 것처럼 보여주는 게 중요.
  - 이후 네트워크가 복구되면 서버 간 데이터를 동기화(Eventually Consistent).
    → 약간의 데이터 불일치(좋아요 수가 순간적으로 다르게 보이는 문제)는 허용 가능.

3. 혼합 전략(상황별 선택)

• 전자상거래 시스템
  - 주문 결제: 반드시 강한 일관성 필요 → 결제 실패/중복 방지를 위해 C 선택.
  - 상품 조회: 가용성 우선 → 다소 오래된 재고 수량이 보이더라도 사용자가 페이지를 빠르게 열 수 있어야 함.

---

3. CA / CP / AP 시스템 실제 사례 (RDBMS, HBase, Cassandra 등)

CA 시스템 (Consistency + Availability)

• 특징
  - 네트워크 분할을 전제로 하지 않는 환경(단일 노드, 단일 데이터센터)에서 일관성과 가용성을 모두 만족
  - 확장성이나 분할 허용성은 약하지만, 전통적인 OLTP 트랜잭션에 최적화.
• 예시: Oracle, MySQL, PostgreSQL (분산 환경이 아닌 경우)
• 실제 적용사례
  - 은행, 증권사, 보험사의 전통적 금융 시스템 (코어 뱅킹, 계좌 관리 등)
    → 데이터 불일치 및 서비스 중간 종료는 치명적인 이슈이므로 일관성 및 가용성은 항상 최선 유지해야함.
    → 네트워크 분할 고려보다는 단일 데이터센터 내 고가용성 장비(HA 클러스터)로 해결

CP 시스템 (Consistency + Partition Tolerance)

• 특징
  - 네트워크 분할이 발생하면 가용성을 일부 희생하더라도 강한 일관성을 보장
  - 리더 선출(Leader election) 구조를 가지며, 합의가 끝날 때까지 일부 요청은 차단됨
• 예시: HBase, MongoDB(기본 설정), Zookeeper
  - 리더 노드가 응답 불가 시, 다른 노드가 선택되기 전까지 일부 요청이 차단 → 가용성 저하
  - 대신 데이터 불일치가 없도록 강력한 일관성 유지
• 실제 적용사례
  - HBase → Hadoop 생태계
    → 실제 로그/센서 데이터 저장, 시계열 DB 용도로 활용
    → 전자상거래, 소셜 서비스의 백엔드 → 데이터 일관성을 유지해야 하는 도메인(예: 상품 주문 내역, 결제 로그)
  - MongoDB
  → 문서 기반(JSON/BSON) 스키마 유연성 덕분에 데이터 구조 변화 대응이 쉬움
  - Zookeeper → Kafka, HDFS 등
    → 분산 시스템의 메타데이터 관리, 리더 선출 등에 활용

AP 시스템 (Availability + Partition Tolerance)

• 특징
  - 네트워크 분할 상황에서도 서비스 중단 없이 요청을 처리
  - 일관성은 Eventually Consistent 모델을 채택 → 데이터 불일치가 일정 시간 동안 발생할 수 있음
• 예시: Cassandra, Amazon DynamoDB
• 실제 적용사례
  - Cassandra → Netflix, Instagram, Uber, Twitter
    → 글로벌 유저 수 억 단위 서비스에서 빠른 응답성과 무중단 서비스를 위해 사용
    → 예: Netflix는 사용자 시청 기록과 추천 데이터를 Cassandra에 저장
  - DynamoDB → Amazon, LinkedIn
    → 쇼핑 카트, 세션 관리, 실시간 피드 관리에 활용
    → 예: Amazon은 DynamoDB로 전 세계 장바구니 상태를 가용성 우선으로 유지

---

4. PACELC 개념

CAP 트레이드오프

• CAP 이론은 분할(Partition) 발생 시 시스템이 일관성(Consistency) 과 가용성(Availability) 중 하나에 비중을 더 두어야 합니다. (연속 스펙트럼 형태)
• 하지만 시스템은 분할이 없는 환경에서도 지연(Latency) 과 일관성(Consistency) 사이의 트레이드오프에 직면합니다.

PACELC 개념

PACELC - 출처: https://mark-kim.blog/cap_pacelc/cap_pacelc_theorem/

다니엘 아바디(Daniel Abadi)는 이를 보완하기 위해 PACELC 정리를 제안했습니다.

• P (Partition) 발생 시 → A (Availability) 와 C (Consistency) 사이에서 선택해야 한다.
• E (Else, 정상 상태) → L (Latency) 과 C (Consistency) 사이에서 선택해야 한다.

즉, PACELC는 분할이 있을 때뿐만 아니라, 없을 때도 일관성과 지연 사이의 균형이 필요하다는 점을 강조합니다.

약자 풀이

• P (Partition) : 네트워크 분할 발생 시
• A (Availability) : 가용성
• C (Consistency) : 일관성
• E (Else) : 분할이 발생하지 않은 정상 상태에서
• L (Latency) : 지연 시간
• C (Consistency) : 일관성

의미

• CAP 정리: 분할 상황에서 C vs A 선택
• PACELC 정리:
  • 분할 시 → C vs A
  • 정상 시 → C vs L
• 따라서 분산 시스템 설계자는 단순히 C vs A뿐 아니라, 평상시의 C vs L까지 고려해 애플리케이션 특성에 맞는 최적 균형점을 찾아야 합니다.

---

5. 분산 시스템 설계 Trade-off

해당 내용 말고도 다양한 트레이드오프가 분명 존재합니다.
떠오르는 다른 트레이드오프나 현업에서 경험하신 사례가 있다면, 댓글로 남겨주시면 환영합니다~

1) CAP 속성의 연속적 스펙트럼

• 일관성(C): Strong → Bounded Staleness → Read-your-writes → Eventual 등 다양한 단계.
• 가용성(A): 99%~99.999%(“five nines”) 수준으로 수치화 가능.
• 분할 내성(P): “모든 분할 허용” vs “일부만 허용” 등 강약 조절 가능.

정리: CAP은 절대적 이분법이 아니라, 설계자가 어느 지점을 선택할지 결정하는 문제.
 

2) 분할 상황(Partition Mode) 설계 패턴

질문: "분할이 발생하면 어떤 정책을 적용할 것인가?"
CA 시스템

• 단일 데이터센터 내 RDB
• 분할이 거의 없을 때 C와 A 모두 제공 가능

CP 시스템

• 분할 시 A를 희생, C를 유지
• 예: HBase, ZooKeeper

AP 시스템

• 분할 시 C를 희생, A를 유지
• 예: Cassandra, Dynamo

정리: CAP은 “분할 시 fallback 전략을 설계하는 가이드라인”
 

3) Consistency 전략

• 최종 일관성(Eventual Consistency): DNS, CDN처럼 즉시 정합성이 필요 없는 시스템에 적합.
• 강한 일관성(Strong Consistency): 금융·재고 관리처럼 정확성이 핵심인 도메인에 필요.
• 조정 가능한 일관성(Tunable Consistency): Cassandra처럼 쿼리 단위로 C/A 선택 가능.
  예: 주문 처리(강한 C), 로그(약한 C)
  
• 정족수(Quorum) 기반 합의: Paxos, Raft(합의 알고리즘)로 C와 A를 균형 있게 달성.

참고 개념

1. Eventual Consistency(최종적 일관성)

• 시스템의 모든 복제본이 결국 최종적으로 같은 값을 가지는 상태(동기화)가 될 것임을 의미.
• 다만, 언제 동기화될지는 보장되지 않음.

2. 정족수(Quorum)

• 회의에서 “결정을 내리기 위해 필요한 최소 인원”과 같은 개념
• 분산 시스템에서는 읽기/쓰기 연산 시 다수 노드의 응답을 받아야만 유효하다고 보는 원리
• 예: Cassandra에서 W + R > N 규칙 (W=쓰기 확인 수, R=읽기 확인 수, N=전체 복제본 수)
• 이를 통해 분산 환경에서 데이터 정합성 보장 가능

3. Redis 분산락과의 관계

• Redis 분산락(Redlock)은 여러 Redis 노드 중 과반수 이상(정족수) 에서 락 획득에 성공하면 자원 잠금을 인
• 즉, 정족수 개념을 응용한 분산락 구현 방식
• 차이점
  - Quorum → 분산 DB 합의/일관성 유지 목적 (읽기·쓰기 연산)
  - Redis 분산락 → 동시 자원 접근 제어 목적 (락 관리)

 

4) Latency vs Consistency (PACELC 관점)

• CAP은 분할 시 선택만 다루지만,
• PACELC는 정상 상황(Else) 에서도 지연(Latency) vs 일관성(C) 의 트레이드오프가 있음을 강조.
• 예:
  • Google Spanner → GPS/원자시계로 글로벌 강한 일관성 달성 (대신 비용↑, 지연↑).
  • Cassandra → 지연을 줄이고 응답 우선 (일관성은 Eventually).

 

5) Throughput vs Consistency

• 분산 시스템에서 높은 처리량(Throughput) 을 확보하려면,
  일부 일관성 모델을 완화하거나 책임을 다른 계층(예: Kafka Consumer)으로 위임하는 경우가 많습니다.
• 반대로 강한 일관성(Strong Consistency) 을 철저히 보장하면 동시 처리량은 상대적으로 제한됩니다.

• 예시 1: Kafka
  • Append-only 로그 구조를 채택해 파티션 단위로 높은 처리량과 순차적 일관성을 보장
  • 하지만 “메시지를 언제 소비했는가”는 시스템이 관리하지 않고 Consumer가 오프셋을 직접 관리해야 함.
    - 중복 처리 (at-least-once),
    - 누락 처리 (at-most-once),
    - Exactly-once 처리 보장 → 모두 Consumer 설계 복잡성에 의존
  • 즉, Kafka는 일관성을 희생하지 않고, Throughput을 높이는 대신 Consumer 측 부담을 늘린 구조.
• 예시 2: RDBMS (전통적 DB)
  • 트랜잭션 단위로 강한 일관성(ACID) 을 철저히 보장
  • 그 대가로, 수평 확장이 어렵고(샤딩 난이도) 처리량과 확장성은 제한적.

 

6) Storage & 비용 Trade-off

• 복제(replication) vs 샤딩(sharding)
  - 복제: 데이터 정합성과 가용성↑, 하지만 저장 비용 증가.
  - 샤딩: 확장성과 성능↑, 하지만 일관성 관리가 어려움.

---

6. 요약

분산 시스템이 필요한 이유

• 확장성: 트래픽·데이터 폭증 시 수평 확장으로 대응.
• 장애 허용: 복제/장애 복구로 SPOF 제거.
• 지연 해결: 지역별 배치·캐시로 빠른 응답 제공.

CAP 개념

• C(Consistency): 모든 노드가 동일한 데이터 제공
• A(Availability): 모든 요청에 응답 가능
• P(Partition tolerance): 네트워크 단절 시에도 동작 유지
• CAP 핵심 포인트
  - “2 of 3” 단순화는 오해 → C/A는 연속 스펙트럼
  - 분산 시스템에서 Partition은 피할 수 없음
  - 선택은 전역이 아닌 연산/데이터 단위/상황 별로 달라질 수 있음

 CA / CP / AP 시스템 사례

• CA: 단일 데이터센터 내 RDBMS (Oracle, MySQL) → 금융권 코어 시스템
• CP: HBase, MongoDB, Zookeeper → 로그 저장, 메타데이터 관리
• AP: Cassandra, DynamoDB → Netflix 시청 기록, Amazon 장바구니

CAP 한계와 PACELC

• CAP은 “분할 상황”에서만 C vs A를 다룸
• PACELC: 분할 시(C vs A), 정상 시(C vs Latency)도 고려해야함.

 

분산 시스템 설계 Trade-off

CAP 속성의 연속적 스펙트럼

• C: Strong → Bounded Staleness → Eventual 등 단계적 선택 가능
• A: 99%~99.999%(five nines) 수준으로 수치화
• P: “모든 분할 허용” vs “일부만 허용” 등 강약 조절

Partition Mode 설계 패턴

• CA: 단일 데이터센터 내 RDB → 분할 거의 없음
• CP: 분할 시 A 희생, C 유지 (HBase, ZooKeeper)
• AP: 분할 시 C 희생, A 유지 (Cassandra, DynamoDB)

Consistency 전략

• Eventual Consistency: DNS, CDN → 즉시 정합성 불필요
• Strong Consistency: 금융, 재고 관리 → 정확성이 핵심
• Tunable Consistency: Cassandra → 쿼리 단위로 C/A 선택
• Quorum 합의: Paxos, Raft → C와 A 균형 달성

추가 트레이드오프

• Latency vs Consistency: Google F1 Spanner(강한 C, 지연↑) vs Cassandra(지연↓, Eventually)
• Throughput vs Consistency: Kafka(처리량↑, 소비자 부담↑) vs RDBMS(일관성↑, 처리량↓)
• Storage vs 비용: Replication(정합성↑, 비용↑) vs Sharding(확장성↑, 관리 복잡도↑)

---

 

7. 참고

• https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/