Brain257. BASE 속성 (BASE Properties)
핵심 인사이트 (3줄 요약)
- 본질: BASE 속성은 Basically Available, Soft-state, Eventually consistent의 세 단어로 구성된 NoSQL 및 분산 시스템의 설계 철학으로, ACID의 반대되는 개념으로 강철 일관성 대신 결과적 일관성을 채택한다.
- 가치: 대규모 분산 시스템에서 가용성과 확장성을 우선시하면서도, 궁극적으로는 일관된 상태에 도달할 수 있게 해주는 현실적 설계 원칙이다.
- 융합: CAP 정리, 결과적 일관성, NoSQL, 분산 시스템과 밀접하게 연관되며, ACID와 함께 데이터베이스 설계의 두 축을 형성한다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
개념 정의
BASE는 Eric Brewer가 2010년 O'Reilly conferences에서 CAP 정리를 설명하면서 사용한 약어로, Basically Available, Soft-state, Eventually consistent의 세 가지 특성을 나타낸다. BASE는 ACID(원자성, 일관성, 격리성, 영속성)와 대비되는 개념으로, 강한 일관성 대신 결과적 일관성을 채택하고 가용성과 확장성을 우선시하는 설계 철학이다.
필요성
전통적 RDBMS는 ACID 트랜잭션을 통해 강한 일관성을 보장하지만, 이는 수직적 확장(Scale-up)의 한계와 중앙 집중적架构의 한계를 가진다. 인터넷 규모의 대규모 분산 시스템에서는 수평적 확장(Scale-out)이 필수적이며, 이를 위해서는 CAP의 AP 쪽으로 설계 방향이 결정되어야 한다. BASE는 이러한 AP 시스템의 설계 원칙을 체계화한 것이다.
배경
BASE는 1980년대까지 거슬러 올라갈 수 있지만, 2000년대 후반 NoSQL 운동과 함께 대중화되었다. Amazon Dynamo 논문(2007)에서 Eventually consistent 모델을 제시한 이후, Facebook, Google, Amazon 등 대규모 인터넷 기업의 분산 시스템 설계 철학으로 자리잡았다.
ACID vs BASE 비교
┌─────────────────────────────────────────────────────────────────────────────┐
│ ACID vs BASE: 두 가지 설계 철학 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────┬────────────────────────┬────────────────────────┐ │
│ │ 항목 │ ACID │ BASE │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 기본 관점 │ 강철 일관성 우선 │ 가용성 우선 │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 일관성 모델 │ 언제나 일관된 상태 │ 결과적 일관성 │ │
│ │ │ │ (궁극적으로 일관) │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 트랜잭션 │ 완전한 원자성 │ 부분 완료 상태 허용 │ │
│ │ │ │ │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 격리 수준 │ 직렬 가능성 보장 │ 동시성 제어가 느슨 │ │
│ │ │ │ │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 영속성 │ 트랜잭션 완료 시 │ 쓰기 성공 시 즉시 │ │
│ │ │ 즉시 디스크 기록 │ 반환 (백그라운드 기록) │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 시스템 상태 │ 항상 결정적 │ 언제나 불확정적 │ │
│ │ │ (Deterministic) │ (Non-deterministic) │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 동시성 제어 │ 엄격한 잠금 기반 │ 낙관적 제어, MVCC 등 │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 적합 시나리오 │ 금융, 회계, 주문 관리 │ 웹, SNS, IoT, 캐시 │ │
│ ├────────────────┼────────────────────────┼────────────────────────┤ │
│ │ 대표 시스템 │ Oracle, PostgreSQL, │ Cassandra, DynamoDB, │ │
│ │ │ MySQL InnoDB │ MongoDB, Redis │ │
│ └────────────────┴────────────────────────┴────────────────────────┘ │
│ │
│ 핵심 결론: │
│ ACID는 "정확성이 가장 중요하다"는 전제, BASE는 "서비스가 항상 │
│ 利用可能해야 한다"는 전제에서 출발한다. 어느 쪽이 우월한 것이 아니라 │
│ 시스템 요구사항에 맞는 선택이 중요하다. │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
비유
ACID는 "모든 계좌 잔고가 동시에 정확히 일치해야 한다"는 은행의 원칙과 같고, BASE는 "밤사이 ATM이 끊겨도 아침에 전부 동기화되면 OK"라는 인터넷 서비스의 현실적 접근법과 같다.
📢 섹션 요약: BASE는 ACID와 대비되는 설계 철학으로, 강철 일관성 대신 결과적 일관성을 채택하고 가용성과 확장성을 우선시하는 NoSQL의 핵심 원칙이다.
Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)
BASE 세 가지 속성 상세
┌─────────────────────────────────────────────────────────────────────────────┐
│ BASE 세 가지 속성 상세 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. Basically Available (기본적 가용성) │
│ ──────────────────────────────────────── │
│ • 시스템이 항상 利用可能한 것은 아니지만, 기본적인 기능은 利用可能하게 │
│ 유지한다는 뜻 │
│ • 분산 시스템에서 일부 노드가故障해도 전체 시스템이死守 않도록 설계 │
│ • 모든 노드에 동시에 쓰기하지 않고,利用可能な 노드에서 처리 │
│ • 예: Cassandra에서 일부 노드 장애 시에도 읽기/쓰기 가능 │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ [단일 장애점 없음] │ │
│ │ │ │
│ │ Node A ──────┬─────── Node B │ │
│ │ │ │ │ │ │
│ │ │ │ │ │ │
│ │ ▼ ▼ ▼ │ │
│ │ 정상运作 部分故障 정상运作 │ │
│ │ │ │
│ │ ※ Node A 또는 B가故障해도 나머지가 처리 계속 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 2. Soft-state (부드러운 상태) │
│ ──────────────────────────────────────── │
│ • 시스템 상태가 항상 확정적이지 않으며,시간経過에 따라 변화한다는 뜻 │
│ • 복제 지연, 네트워크 분단 등으로 인해 노드 간 데이터 불일치가 발생할 수 있음 │
│ • 상태는 외부 입력이나 복제에 의해 결정되지 않고 흐르듯 변화 │
│ • 예: 쓰기 직후의 MongoDB 복제셋에서 Primary와 Secondary 간 데이터 차이 │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ [Soft-state 예시] │ │
│ │ │ │
│ │ Time T0: W("A"=1) → Node A 성공 │ │
│ │ Time T1: R("A") → Node A: 1, Node B: null (복제 지연) │ │
│ │ Time T2: R("A") → Node A: 1, Node B: 1 (복제 완료) │ │
│ │ │ │
│ │ ※ 일시적으로 다른 상태가 공존 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 3. Eventually consistent (결과적 일관성) │
│ ──────────────────────────────────────────── │
│ • 시스템이 계속 작동하면, 궁극적으로 모든 복제본이 동일한 상태에 도달한다는 뜻 │
│ • 즉각적 일관성은 아니지만, 충분한 시간이 지나면 모든 노드가同一해진다 │
│ • 예: Cassandra에서 모든 노드가 궁극적으로同一한 값을 가지게 된다 │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ [Eventually Consistent 예시] │ │
│ │ │ │
│ │ 쓰기 ──▶ 성공 반환 ──▶ 백그라운드 복제 ──▶ 모든 노드 동일 │ │
│ │ │ │
│ │ ※ 사용자는 쓰기 성공 후 바로 결과를 확인할 수 없지만 │ │
│ │ 결국에는 확인 가능 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
[다이어그램 해설] BASE의 세 가지 속성은 상호 보완적으로 작동한다. Basically Available은 일부 노드가故障してもシステム全体が利用可能な 상태를 유지한다는 것이고, Soft-state는 시스템 상태가時間經過에 따라 변화한다는 것이며, Eventually consistent는 궁극적으로 일관된 상태에 도달한다는 것이다. 이 세 가지가 결합하여, 대규모 분산 환경에서 가용성과 확장성을 확보하면서도 궁극적으로 일관된 상태에 이를 수 있다.
CAP과 BASE의 관계
┌─────────────────────────────────────────────────────────────────────────────┐
│ CAP 정리과 BASE의 관계 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ CAP 삼각형 │
│ │
│ Consistency │
│ /\\ │
│ / \\ │
│ / \\ │
│ / \\ │
│ / CA \\ │
│ / ↖︎ \\ │
│ ◀───────────▶ Availability │
│ Partition Tolerance │
│ │
│ ┌───────────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ CAP의 P (Partition Tolerance) 선택 → 분산 시스템은 필수적으로 P │ │
│ │ │ │
│ │ → CP 선택 시: Strong Consistency + Partition Tolerance │ │
│ │ → ACID에 가까움 (은행, 금융 시스템에 적합) │ │
│ │ │ │
│ │ → AP 선택 시: Availability + Partition Tolerance │ │
│ │ → BASE에 가까움 (웹, SNS, IoT에 적합) │ │
│ │ │ │
│ │ 즉, BASE는 CAP의 AP 쪽에 위치하는 설계 철학이다. │ │
│ │ │ │
│ └───────────────────────────────────────────────────────────────────────┘ │
│ │
│ ACID ═══════════════════════════════════════════════════════▶ BASE │
│ (강철 일관성 + 원자성) VS (가용성 + 확장성) │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
📢 섹션 요약: BASE는 CAP 정리에서 AP 쪽에 해당하는 설계 철학으로, Soft-state와 Eventually consistent를 통해 가용성과 확장성을 확보한다.
Ⅲ. 구현 및 실무 응용 (Implementation & Practice)
Cassandra에서의 BASE 구현
-- Cassandra는 BASE 원칙을 따르는 AP 시스템
-- 1. Basically Available: 쓰기/읽기 항상 가능
-- 전체 클러스터가故障하지 않는 한 읽기/쓰기 가능
CREATE KEYSPACE myapp
WITH REPLICATION = {'class': 'NetworkTopologyStrategy', 'dc1': 3};
-- 쓰기: 하나의 노드라도 살아 있으면 처리
INSERT INTO users (id, name) VALUES (1, 'Kim')
USING CONSISTENCY ANY;
-- ANY: 하나의 노드에 기록되면 성공 반환
-- 2. Soft-state: 복제 지연으로 인한 일시적 불일치 허용
-- 아래 시나리오에서 불일치가 발생할 수 있음
-- Node A: "user:1" = "Kim" (최신)
-- Node B: "user:1" = null (아직 미복제)
-- Node C: "user:1" = "Lee" (네트워크 분단 중 다른 클라이언트가 기록)
-- 3. Eventually consistent: 궁극적 일관성
-- • Read Repair: 읽기 시 오래된 복제본 자동 수정
-- • Anti-Entropy Repair: 주기적 복제본 동기화
-- • Gossip Protocol: 노드 간 상태 전파
-- Consistency Level에 따른 일관성 보장
-- • ANY: 가용성 최고, 일관성 가장 낮음
-- • ONE, TWO, THREE: 지역적 일관성
-- • QUORUM: 균형점 (과반 일관성)
-- • ALL: 일관성 최고, 가용성 가장 낮음
BASE 환경에서의 설계 고려사항
┌─────────────────────────────────────────────────────────────────────────────┐
│ BASE 시스템 설계 고려사항 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. 불일치 감수 설계 │
│ ───────────────────── │
│ • 비즈니스에서 허용 가능한 불일치 수준 정의 │
│ • 사용자에게 불일치를告知하는 UX 설계 │
│ • 예: SNS에서 "좋아요" 수가 즉시 반영되지 않아도 OK │
│ │
│ 2. 충돌 해결 전략 │
│ ───────────────── │
│ • Last Writer Wins: 단순하지만 일부 데이터 손실 가능 │
│ • Timestamp 기반: 시간 서버 의존성 │
│ • Version vectors: 복잡하지만 정확한 충돌 감지 │
│ • 애플리케이션 수준 병합: 가장 유연하지만 구현 복잡 │
│ │
│ 3. 읽기 복구 (Read Repair) │
│ ───────────────────────── │
│ • 읽기 시 최신 데이터로 복제본 수정 │
│ •バックグラウンド에서 실행 │
│ • 데이터 품질 향상 │
│ │
│ 4. 일관성 수준 선택 │
│ ───────────────── │
│ • 쓰기/읽기 비율에 따라 동적으로 선택 │
│ • QUORUM: 균형점 │
│ • 예: 쓰기 빈번 → ONE (가용성 우선), 읽기 빈번 → ALL (일관성 우선) │
│ │
│ 5. 모니터링 및 알림 │
│ ─────────────────── │
│ • 복제 지연 모니터링 (복제 지연 임계값 설정) │
│ • 불일치 발생 빈도 추적 │
│ • 노드 장애 시 복구 시간 측정 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
📢 섹션 요약: BASE 시스템 설계 시 불일치 감수 수준, 충돌 해결 전략, 모니터링 등을 사전에 설계해야 하며, 비즈니스 요구에 맞게 일관성 수준을 동적으로 선택해야 한다.
Ⅳ. 품질 관리 및 테스트 (Quality & Testing)
BASE 시스템 테스트
┌─────────────────────────────────────────────────────────────────────────────┐
│ BASE 시스템 품질 테스트 항목 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ [Basically Available 테스트] │
│ ────────────────────────────── │
│ □ 노드 장애 시 읽기/쓰기 계속 여부 확인 │
│ □ 장애 노드 복구 후 복제 재구성 동작 확인 │
│ □ 클러스터 과반수 미만 장애 시 서비스 수준 확인 │
│ │
│ [Soft-state 테스트] │
│ ────────────────── │
│ □ 복제 지연으로 인한 일시적 불일치 발생 확인 │
│ □ 네트워크 분단 시 노드 간 상태 차이 분석 │
│ □ 상태 변화 추적 (상태 전이 다이어그램 활용) │
│ │
│ [Eventually Consistent 테스트] │
│ ───────────────────────────────── │
│ □ 쓰기 후 모든 노드가同一해지는 시간 측정 (Staleness Window) │
│ □ Read Repair 동작 확인 │
│ □ Anti-Entropy Repair 동작 확인 │
│ □ 충돌 해소 방식 동작 확인 (LWW, Version 등) │
│ │
│ [성능 테스트] │
│ ─────────── │
│ □ Consistency Level별 성능 비교 │
│ □ 노드 수 증가에 따른 성능 변화 (확장성) │
│ □ 부하 시 일관성/가용성 트레이드오프 확인 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
📢 섹션 요약: BASE 시스템 테스트는 가용성, 상태 불확정성, 결과적 일관성, 성능을 모두 검증해야 하며, 장애 상황과 복구 시나리오를 반드시 포함해야 한다.
Ⅴ. 최신 트렌드 및 결론 (Trends & Conclusion)
NewSQL의 도전
NewSQL은 ACID의 강철 일관성과 BASE의 확장성을 모두 추구하는 시도이다. Google Spanner, CockroachDB, TiDB 등이 대표적이다. 그러나 PACELC 이론에 따르면 완전히 Free한 것은 아니며, 일관성과 지연 시간 사이의 트레이드오프는 여전히 존재한다.
HTAP의 융합
HTAP(Hybrid Transactional/Analytical Processing)는 OLTP와 OLAP를 하나의 플랫폼에서 처리하는 기술로, ACID 기반 트랜잭션 처리와 BASE 기반 분석 처리를 혼합하려는 시도이다. TiDB, SAP HANA 등이 HTAP를 지원한다.
결론
BASE는 대규모 분산 시스템의 설계 철학으로, 강철 일관성(ACID)을牺牲하는 대신 가용성과 확장성을 확보한다. 이는 인터넷 규모의 웹 애플리케이션, SNS, IoT 등에서 필수적이다. 그러나 BASE를 선택하는 것은 일관성을牺牲하는 것이므로, 비즈니스 요구사항을 면밀히 분석하여 ACID와 BASE 중 적절한 것을 선택해야 한다.
📢 섹션 요약: BASE는 ACID와 대비되는 분산 시스템의 설계 철학으로, 가용성과 확장성을 우선시하지만 결과적 일관성만 보장한다. 시스템 요구사항에 맞게 ACID와 BASE 중 선택해야 한다.
핵심 인사이트 ASCII 다이어그램 (Concept Map)
┌─────────────────────────────────────────────────────────────────────────────┐
│ BASE Concept Map │
│ │
│ ┌────────────────────────────────┐ │
│ │ BASE │ │
│ │ Basically Available │ │
│ │ + Soft-state │ │
│ │ + Eventually Consistent │ │
│ └───────────────┬────────────────┘ │
│ │ │
│ ┌───────────────────┼───────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Basically │ │ Soft-state │ │ Eventually │ │
│ │ Available │ │ (상태 불확정)│ │ Consistent │ │
│ │ (가용성 우선) │ │ │ │ (궁극적 일관) │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ CAP 정리 │ │
│ │ AP 시스템 ← BASE → CP 시스템 (ACID) │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 관련 개념: CAP, ACID, NoSQL, NewSQL, Eventually Consistent, MVCC │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
참고
- BASE는 Basically Available, Soft-state, Eventually consistent의 세 가지 속성으로 구성된다.
- BASE는 CAP의 AP 쪽에 해당하는 설계 철학이다.
- ACID는 강철 일관성, BASE는 결과적 일관성을 제공한다.
- BASE 시스템 설계 시 불일치 감수 수준, 충돌 해결 전략, 모니터링을 사전에 설계해야 한다.