Availability vs. Consistency

Availability vs. Consistency

분산 시스템 설계에서 “Availability(가용성)” 과 “Consistency(일관성)” 는 동시에 완벽히 만족시키기 어려운 특성이다. 이는 CAP 정리에 의해 설명된다. 시스템 설계 시, 네트워크 분할 상황에서 어느 특성을 우선시할지 결정해야 하며, 이는 시스템의 목적과 요구사항에 따라 달라진다. 2025 년 현재 AI 기반 최적화와 서버리스 아키텍처의 발전으로 새로운 패러다임이 형성되고 있다.

핵심 개념

• 가용성 (Availability)
  가용성은 시스템이 서비스를 제공할 수 있는 능력을 의미한다. 분산 시스템에서 가용성이 높다는 것은 시스템의 일부가 실패하더라도 전체 시스템이 계속 작동하고 사용자 요청에 응답할 수 있음을 의미한다. 높은 가용성을 가진 시스템은 모든 작동 중인 노드가 항상 읽기 및 쓰기 요청에 응답할 수 있도록 보장한다.

• 일관성 (Consistency)
  일관성은 모든 노드가 동일한 시점에 동일한 데이터를 볼 수 있도록 보장하는 속성이다. 강한 일관성 (Strong Consistency) 을 가진 시스템에서는 데이터에 대한 업데이트가 발생한 후 모든 후속 읽기 작업이 업데이트된 값을 반환해야 한다. 이는 모든 노드가 항상 최신 데이터를 가지고 있어야 함을 의미한다.

• Partition Tolerance(분할 허용성)
  분산 시스템이 네트워크 분할(Partition) 상황에서도 계속 작동할 수 있는 능력을 의미한다. 네트워크 분할은 노드 간 통신이 단절되거나 지연되는 현상으로, 시스템의 일부가 격리되더라도 나머지 부분이 정상적으로 동작해야 함을 보장한다.

• CAP 정리 (CAP Theorem)
  CAP 정리는 2000 년 Eric Brewer 가 제안한 이론으로, 분산 시스템은 다음 세 가지 특성 중 동시에 두 가지만 보장할 수 있다고 주장한다:
  1. 일관성 (Consistency): 모든 노드가 동시에 동일한 데이터를 볼 수 있음
  2. 가용성 (Availability): 모든 요청이 성공 또는 실패 응답을 받음
  3. 분할 내성 (Partition Tolerance): 네트워크 분할 (노드 간 통신 실패) 발생 시에도 시스템이 계속 작동함
  실제 분산 환경에서는 네트워크 분할이 발생할 수 있기 때문에, 분할 내성 (P) 은 필수적으로 보장되어야 한다. 따라서 시스템 설계자는 일관성 (C) 과 가용성 (A) 중 하나를 선택해야 하는 상황에 직면한다.

• 네트워크 분할 (Network Partition)
  네트워크 분할은 네트워크 장애로 인해 노드 간의 통신이 불가능해지는 상황을 의미한다. 이러한 상황에서 시스템은 다음과 같은 선택을 해야 한다:

  1. 일관성을 우선시하여 일부 노드의 가용성을 포기 (CP 시스템)
  2. 가용성을 우선시하여 일시적으로 데이터 일관성을 포기 (AP 시스템)

• 일관성 모델 (Consistency Models)
  다양한 일관성 모델이 존재하며, 강한 일관성부터 약한 일관성까지 스펙트럼을 형성한다:

  1. 강한 일관성 (Strong Consistency): 모든 읽기는 가장 최근의 쓰기를 반영
  2. 결과적 일관성 (Eventual Consistency): 일정 시간이 지나면 모든 노드가 동일한 데이터를 갖게 됨
  3. 인과적 일관성 (Causal Consistency): 인과 관계가 있는 작업들에 대해서만 일관성 보장
  4. 세션 일관성 (Session Consistency): 동일 세션 내에서만 일관성 보장

• ACID 와 BASE
  데이터베이스 시스템은 일관성과 가용성에 대한 접근 방식에 따라 다음과 같이 분류된다:

  1. ACID(원자성, 일관성, 격리성, 지속성): 강한 일관성을 중시하는 관계형 데이터베이스에서 주로 사용
  2. BASE(기본 가용성, 소프트 상태, 결과적 일관성): 가용성을 중시하는 NoSQL 데이터베이스에서 주로 사용

• PACELC 이론
  CAP 정리를 확장한 PACELC 이론은 네트워크 분할 (P) 발생 시 일관성 (C) 과 가용성 (A) 중 선택해야 하며, 분할이 없을 때 (E) 는 대기 시간 (L) 과 일관성 (C) 중 선택해야 한다고 설명한다. 이는 시스템 설계 시 더 세밀한 트레이드오프를 고려할 수 있게 한다.

목적 및 필요성

1. 분산 시스템 설계의 기본 원칙 제공
   가용성과 일관성의 트레이드오프를 이해하는 것은 분산 시스템 설계의 기본 원칙이다. 이를 통해 시스템 설계자는 비즈니스 요구사항에 맞는 적절한 결정을 내릴 수 있다.

2. 시스템 성능과 신뢰성 최적화
   적절한 가용성과 일관성 균형을 찾음으로써 시스템의 성능과 신뢰성을 최적화할 수 있다. 비즈니스 상황에 따라 필요한 특성을 우선시하여 리소스를 효율적으로 활용할 수 있다.

3. 확장 가능한 아키텍처 설계
   분산 시스템의 확장성을 고려할 때, 가용성과 일관성의 균형은 핵심적인 결정 요소이다. 이를 이해함으로써 미래 성장에 대비한 확장 가능한 아키텍처를 설계할 수 있다.

4. 비즈니스 요구사항 충족
   다양한 비즈니스 도메인은 서로 다른 가용성과 일관성 요구사항을 가진다. 예를 들어, 금융 시스템은 일관성이 중요하지만, 소셜 미디어 플랫폼은 가용성이 더 중요할 수 있다.

핵심 개념 비교

주요 기능 및 역할

특징

추가 비교 분석

핵심 원칙

CAP 정리 (CAP Theorem)

CAP 정리는 분산 시스템에서 일관성 (Consistency), 가용성 (Availability), 분할 내성 (Partition Tolerance) 세 가지를 동시에 만족시킬 수 없다는 원칙이다.

네트워크 분할이 발생할 때, 시스템은 다음 중 하나를 선택해야 한다:

1. CP(일관성 + 분할 내성): 일관성을 유지하기 위해 일부 노드의 가용성 포기
2. AP(가용성 + 분할 내성): 가용성을 유지하기 위해 일시적으로 일관성 약화
3. CA(일관성 + 가용성): 실제 분산 환경에서는 네트워크 분할이 불가피하므로 이론적으로만 가능

CAP 정리 적용 예시

• CP 시스템 동작 원리

  1. 네트워크 분할 발생 시 소수 파티션의 노드는 쓰기 작업을 거부
  2. 다수 파티션에서만 쓰기 허용
  3. 분할이 해결되면 동기화 진행

• AP 시스템 동작 원리

  1. 네트워크 분할 발생 시 모든 노드에서 계속 읽기/쓰기 허용
  2. 분할 기간 동안 노드 간 데이터 불일치 발생
  3. 분할이 해결되면 충돌 해결 메커니즘을 통해 일관성 회복

PACELC 이론

PACELC 이론은 CAP 정리를 확장한 개념으로, 네트워크 분할 상황과 정상 상황을 모두 고려한다:

• P: 네트워크 분할 발생 시
  • A vs C: 가용성과 일관성 중 선택
• E: 네트워크가 정상일 때
  • L vs C: 지연 시간 (Latency) 과 일관성 중 선택

이 이론은 분할이 발생하지 않는 일반적인, 정상 상황에서도 트레이드오프가 존재함을 명시한다.

즉, PACELC 는 다음과 같은 의미를 가짐:

“If a partition occurs (P), then the system must choose between Availability (A) and Consistency (C); Else (E), when the system is running normally, it must choose between Latency (L) and Consistency (C).”

PACELC 기반 비교 분석

• PACELC 이론은 CAP 의 한계를 보완하여, 시스템이 정상 상태일 때의 선택 기준까지 포함하므로 더 정밀한 설계 판단에 유리하다.
• Latency-Sensitive 서비스(예: 채팅, 검색, IoT) 는 PA/EL 이 적합하다.
• Strong Consistency 가 요구되는 서비스(예: 금융, 재고, 주문 시스템) 는 PC/EC 기반 설계가 필요하다.
• Tunable Consistency 옵션을 제공하는 Cassandra 나 DynamoDB 같은 시스템을 활용하면 상황에 맞는 유연한 전략 수립이 가능하다.

데이터 일관성 모델

1. 강한 일관성 (Strong Consistency):
   • 모든 읽기 작업은 가장 최신의 쓰기 작업을 반영
   • 예: 관계형 데이터베이스 (MySQL, PostgreSQL)
2. 약한 일관성 (Weak Consistency):
   • 읽기 작업이 최신 업데이트를 반영하지 않을 수 있음
   • 예: 메모리 캐시 (Redis, Memcached)
3. 결과적 일관성 (Eventual Consistency):
   • 일정 시간이 지나면 모든 노드가 동일한 데이터 상태를 가짐
   • 예: DynamoDB, Cassandra
4. 인과적 일관성 (Causal Consistency):
   • 인과 관계가 있는 작업에 대해서만 일관성 보장
   • 예: MongoDB 의 인과적 일관성 세션

ACID vs. BASE

• ACID: 전통적인 관계형 데이터베이스가 따르는 트랜잭션 특성으로, 강한 일관성 보장
• BASE: NoSQL 데이터베이스가 따르는 특성으로, 가용성과 성능 우선

주요 원리 및 작동 원리

분산 시스템에서의 일관성 유지 메커니즘

• 합의 알고리즘 (Consensus Algorithms)
  분산 시스템에서 노드 간 합의를 이루기 위한 알고리즘:

  1. Paxos: 비동기 네트워크에서 노드 간 합의를 이루는 알고리즘
  2. Raft: Paxos 보다 이해하기 쉽게 설계된 합의 알고리즘
  3. Byzantine Fault Tolerance(BFT): 악의적인 노드가 존재하는 환경에서도 합의를 이루는 알고리즘

• 쿼럼 (Quorum) 기반 시스템
  쿼럼은 분산 시스템에서 최소한의 동의 수준을 정의한다:

  • 쓰기 쿼럼 (W): 쓰기 작업이 성공하기 위해 필요한 노드 수
  • 읽기 쿼럼 (R): 읽기 작업이 성공하기 위해 필요한 노드 수
  • 총 노드 수 (N): 시스템의 총 노드 수
    일관성 보장을 위해서는 W + R > N 조건을 만족해야 한다.

• 복제 전략 (Replication Strategies)

  1. 동기식 복제 (Synchronous Replication):
     • 모든 복제본이 업데이트될 때까지 클라이언트에 응답하지 않음
     • 강한 일관성 보장, 높은 지연 시간
  2. 비동기식 복제 (Asynchronous Replication):
     • 주 노드가 업데이트되면 클라이언트에 즉시 응답
     • 복제는 백그라운드에서 진행
     • 낮은 지연 시간, 일관성 약화

가용성 보장 메커니즘

• 다중화 (Redundancy)
  시스템 구성 요소를 중복으로 배치하여 장애에 대비한다:

  1. 데이터 중복: 여러 노드에 동일한 데이터 저장
  2. 서비스 중복: 동일한 서비스를 여러 인스턴스로 실행

• 장애 감지 및 복구 (Failure Detection and Recovery)

  1. 하트비트 (Heartbeat): 노드 간 주기적으로 신호를 주고받아 상태 확인
  2. 타임아웃 (Timeout): 일정 시간 응답이 없으면 장애로 판단
  3. 자동 복구 (Auto-recovery): 장애 발생 시 자동으로 시스템 복구

• 부하 분산 (Load Balancing)
  요청을 여러 노드에 분산시켜 가용성과 성능을 향상시킨다:

  1. 라운드 로빈 (Round Robin): 순차적으로 노드에 요청 할당
  2. 최소 연결 (Least Connection): 연결 수가 가장 적은 노드에 요청 할당
  3. 일관된 해싱 (Consistent Hashing): 노드 추가/제거 시 재분배를 최소화

구조 및 아키텍처

CP(일관성 + 분할 내성) 시스템 아키텍처

CP 시스템은 일관성을 우선시하며, 네트워크 분할 발생 시 가용성을 희생한다.

주요 특징

1. 마스터 - 슬레이브 구조: 쓰기 작업은 마스터 노드에서만 처리
2. 동기식 복제: 대부분의 노드가 데이터를 복제한 후에야 트랜잭션 완료
3. 강한 일관성 모델: 모든 노드가 항상 동일한 데이터 상태를 유지
4. 쿼럼 기반 의사 결정: 노드 다수의 동의를 필요로 함

대표적인 CP 시스템

• ZooKeeper: 분산 조정 서비스
• HBase: 분산 컬럼형 데이터베이스
• etcd: 분산 키 - 값 저장소
• MongoDB(기본 설정): 문서 지향 데이터베이스

아키텍처 구성 요소

1. 합의 관리자 (Consensus Manager): Paxos, Raft 등의 합의 알고리즘 구현
2. 상태 복제기 (State Replicator): 노드 간 상태 복제 담당
3. 로그 관리자 (Log Manager): 작업 로그 관리 및 재생
4. 장애 감지기 (Failure Detector): 노드 상태 모니터링

AP(가용성 + 분할 내성) 시스템 아키텍처

AP 시스템은 가용성을 우선시하며, 네트워크 분할 발생 시 일관성을 희생한다.

주요 특징

1. 멀티 마스터 구조: 모든 노드가 읽기/쓰기 작업 처리 가능
2. 비동기식 복제: 로컬 노드에서 작업 완료 후 다른 노드로 비동기적 복제
3. 결과적 일관성 모델: 일정 시간 후에 모든 노드가 동일한 상태에 도달
4. 충돌 해결 메커니즘: 데이터 충돌 해결을 위한 벡터 클럭, 머지 등 활용

대표적인 AP 시스템

• Cassandra: 분산 NoSQL 데이터베이스
• DynamoDB(기본 설정): AWS 의 관리형 NoSQL 데이터베이스
• Riak: 분산 키 - 값 저장소
• CouchDB: 문서 지향 데이터베이스

아키텍처 구성 요소

1. 안티 - 엔트로피 프로토콜 (Anti-entropy Protocol): 노드 간 상태 동기화
2. 벡터 클럭 (Vector Clocks): 이벤트 순서 추적 및 충돌 감지
3. 머지 해결기 (Merge Resolver): 충돌 자동 해결
4. 가십 프로토콜 (Gossip Protocol): 클러스터 멤버십 및 상태 정보 전파

CA(일관성 + 가용성) 시스템의 한계

CA 시스템은 네트워크 분할에 대한 내성이 없으므로, 실제 분산 환경에서는 구현이 불가능하다. 그러나 네트워크 분할이 드물게 발생하는 환경에서는 CA 에 가까운 시스템을 구현할 수 있다.

주요 특징

1. 단일 데이터 센터 내 배포: 네트워크 분할 가능성 최소화
2. 고가용성 네트워크 인프라: 중복 네트워크 연결
3. 로컬 복제: 지연 시간 최소화를 위한 로컬 복제
4. 장애 조치 메커니즘: 빠른 복구를 위한 자동 장애 조치

예시

• 단일 데이터 센터 내 MySQL 클러스터
• 로컬 네트워크의 PostgreSQL 복제 설정

12. 장점과 단점

가용성 중심 (AP) 시스템

일관성 중심 (CP) 시스템

강점과 약점

실무 적용 예시

활용 사례

시스템의 각 구성 요소는 요구되는 특성에 따라 적절한 CAP 조합을 선택하여 구현된다.

시나리오 설명

온라인 쇼핑 플랫폼에서는 사용자 경험을 향상시키기 위해 장바구니 기능을 제공한다. 이 시스템은 다음과 같은 요구사항을 가진다:

• 가용성 (Availability): 사용자는 언제든지 장바구니에 상품을 추가하거나 조회할 수 있어야 한다.
• 일관성 (Consistency): 결제 시점에는 장바구니의 상태가 정확하게 반영되어야 하며, 재고 부족 등의 문제가 없어야 한다.

이러한 요구사항을 만족시키기 위해 시스템은 다음과 같은 전략을 채택한다:

• AP 시스템: 상품을 장바구니에 추가하거나 조회하는 기능은 높은 가용성을 위해 AP(Availability and Partition Tolerance) 시스템으로 구현된다. 이로 인해 네트워크 분할이 발생하더라도 사용자는 장바구니 기능을 사용할 수 있다.

• CP 시스템: 결제 기능은 데이터의 일관성을 보장하기 위해 CP(Consistency and Partition Tolerance) 시스템으로 구현된다. 결제 시점에는 모든 데이터가 정확하게 반영되어야 하므로, 일관성을 우선시한다.

다이어그램

아래 다이어그램은 온라인 쇼핑 플랫폼에서의 장바구니 시스템의 구성과 흐름을 나타낸다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

[사용자]
   |
   v
[장바구니 서비스 (AP 시스템)]
   |
   v
[결제 서비스 (CP 시스템)]
   |
   v
[재고 관리 시스템]

• 장바구니 서비스: 사용자의 상품 추가/조회 요청을 처리하며, 높은 가용성을 제공한다.
• 결제 서비스: 결제 요청을 처리하며, 데이터의 일관성을 보장한다.
• 재고 관리 시스템: 상품의 재고를 관리하며, 결제 시점에 재고를 확인한다.

이 사례에서 배울 수 있는 점

1. 도메인별 요구사항 분석: 모든 구성 요소에 동일한 접근 방식을 적용하지 않고, 각 도메인의 요구사항에 맞게 CP 와 AP 특성을 선택적으로 적용
2. 하이브리드 접근법: 단일 서비스 내에서도 데이터 중요도나 작업 유형에 따라 다른 일관성 모델 적용 가능
3. 비즈니스 영향 고려: 일관성과 가용성 중 어떤 것이 비즈니스에 더 중요한지 분석하여 결정
4. 사용자 경험 최적화: 사용자에게 직접 영향을 미치는 기능은 가용성을, 백엔드 처리는 일관성을 우선시
5. 복잡성 관리: 다양한 기술 스택 사용 시 운영 복잡성이 증가하므로 이를 관리하기 위한 전략 필요

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

단계별 고려사항

주의사항

최적화하기 위한 고려사항 및 주의할 점

고려사항

주의사항

최신 동향

주목해야 할 기술들

앞으로의 전망

추가 학습 내용

용어 정리

참고 및 출처

• CAP 정리 재고찰
• CAP 정리 쉬운 소개
• 데이터 중심 애플리케이션 설계(Martin Kleppmann)
• 구글 Spanner 논문
• AWS 일관성 모델 문서
• PACELC 이론
• MongoDB 일관성 모델
• Cassandra 아키텍처
• Jepsen DB 일관성 분석
• CAP Theorem Revisited – robertgreiner.com
• A Plain English Introduction to CAP Theorem – ksat.me
• PACELC Explained – ScyllaDB
• CRDTs – Conflict-free Replicated Data Types – Microsoft Research
• The Raft Consensus Algorithm – The Secret Lives of Data
• CAP Theorem Illustrated Guide
• Google Spanner CAP 접근법
• AWS 아키텍처 센터 - CAP 패턴