Day 6: 확장성과 분산 데이터베이스

• 수직적 확장 vs 수평적 확장
  • Scale-Up과 Scale-Out 개념
• 샤딩(Sharding) & 레플리케이션(Replication)
  • 데이터 파티셔닝 전략
  • 마스터-슬레이브 복제, 멀티 마스터
• NoSQL 상세
  • Key-Value Stores (Redis, DynamoDB)
  • Document DB (MongoDB), Column Store (Cassandra)
• 분산 트랜잭션 & CAP 이론
  • 일관성(Consistency), 가용성(Availability), 파티션 내성(Partition Tolerance)

---

오늘날, 데이터베이스가 커지고 트래픽이 늘어나면서 단일 서버로 처리하기 어려운 상황이 빈번해졌다. 이에 대응하기 위해 수평적 확장(Scale-Out), 샤딩(Sharding), 레플리케이션(Replication) 같은 분산 전략을 활용하며, 이를 기술적으로 뒷받침해줄 NoSQL 시스템들이 각광받고 있다. 또한, 분산 트랜잭션을 다룰 때는 CAP 이론이 중요한 지침으로 작용한다.

1. 수직적 확장 vs 수평적 확장

1.1 Scale-Up (수직적 확장)

• 개념
  • 기존 서버의 하드웨어 사양(CPU, 메모리, 디스크 등)을 고성능 장비로 교체하거나 업그레이드하는 방식
  • 예) 8코어 CPU → 32코어 CPU, 16GB RAM → 256GB RAM
• 장점
  • 애플리케이션 구조 변경 없이 단일 서버의 성능을 즉시 높일 수 있음
  • DB 스키마나 운영 로직 변경이 비교적 단순
• 단점
  • 고성능 장비는 비용이 급격히 증가(가격 대비 성능 한계가 존재)
  • 물리적 한계(CPU 코어 수, 메인보드 슬롯 등)에 부딪히면 더 이상 확장 어려움

1.2 Scale-Out (수평적 확장)

• 개념
  • 더 많은 서버(노드)를 추가해, 데이터와 트래픽을 분산 처리
  • 예) 일반 PC 수십 대 또는 클라우드 VM을 병렬로 묶어 대규모 트래픽 처리
• 장점
  • 저비용 서버 여러 대를 연결해 대용량 처리가 가능
  • 고가의 단일 장비를 사용하는 것보다 장애에 대한 내결함성(Fault Tolerance) 강화
• 단점
  • 노드 간 통신·데이터 분산 전략 등 분산 시스템 복잡도가 증가
  • 일관성 유지나 데이터 동기화 문제가 발생할 수 있음

---

2. 샤딩(Sharding) & 레플리케이션(Replication)

2.1 샤딩(Sharding)

• 개념
  • 대규모 테이블(또는 컬렉션)을 여러 파티션(Shard)으로 나누어, 서로 다른 노드(서버)에서 관리
  • 예) 사용자 데이터를 사용자 ID 범위별로 분할(11,000,000 → Shard A, 1,000,001 → Shard B)
• 장점
  • 단일 노드의 저장·처리 한계를 극복, 수평 확장성(Scalability) 확보
  • 각 Shard는 독립적으로 쿼리를 처리하므로 병렬 성능 향상
• 단점
  • 샤딩 키(Sharding Key) 설계가 중요(균등 분배가 안 되면 특정 샤드에 부하 집중)
  • 분산 쿼리 시, 여러 샤드를 동시에 조회해야 하므로 복잡도 상승

2.2 레플리케이션(Replication)

• 개념
  • 동일 데이터 사본(Copy)을 여러 노드에 복제하여, 읽기 부하 분산 혹은 장애 대비(High Availability) 목적
• 마스터-슬레이브(Master-Slave)
  • Master DB가 쓰기를 담당, Slave DB들이 Master 변경 사항을 실시간으로 받아 반영
  • Slave DB에서 주로 읽기 쿼리를 수행(읽기 스케일 아웃)
  • Master 장애 시, Slave 중 하나가 승격(Promotion)되어 새 Master가 됨
• 멀티 마스터(Multi-Master)
  • 여러 노드가 동시에 읽기·쓰기를 처리, 각 노드 간 충돌(Conflict)을 해결해야 함
  • 충돌 관리 로직이 복잡해지는 대신, 쓰기 확장성 증대

---

3. NoSQL 상세

관계형 DB(RDBMS)는 강력한 트랜잭션 처리와 SQL 인터페이스를 제공하지만, 특정 규모나 데이터 특성에 따라 NoSQL 모델이 더 적합한 경우가 있다.

3.1 Key-Value Stores

• 예시: Redis, AWS DynamoDB
• 특징
  • 간단한 <Key, Value> 구조, Value는 비정형(문자열, 직렬화 객체 등) 가능
  • 매우 빠른 읽기·쓰기(캐싱, 세션 저장 등)
  • 범용적인 쿼리나 조인 기능이 부족

3.2 Document DB

• 예시: MongoDB, CouchDB
• 특징
  • JSON, BSON 같은 문서 기반으로 데이터 저장
  • 유연한 스키마(각 문서 구조가 달라도 무관)
  • 대규모 샤딩(Scale-Out)과 고성능 읽기/쓰기에 적합

3.3 Column Store (Wide Column)

• 예시: Apache Cassandra, HBase
• 특징
  • 열(Column) 단위로 데이터를 묶어 저장
  • 특정 컬럼만 읽거나 쓰는 쿼리에 매우 효율적(OLAP/분석 성향)
  • 큰 스케일의 분산 환경에 맞춰 설계

추가: Graph DB(Neo4j, JanusGraph 등)는 노드-엣지 관계에 특화. SNS나 경로 탐색, 추천 시스템에서 인접 관계를 효율적으로 처리.

---

4. 분산 트랜잭션 & CAP 이론

4.1 분산 트랜잭션

• 개념
  • 여러 노드/DB가 참여하는 트랜잭션으로, 2PC(2-Phase Commit) 등 프로토콜을 통해 원자성을 보장
  • 노드 간 네트워크 지연, 장애 상황에서 복잡한 조율이 필요
• 장단점
  • 트랜잭션 ACID를 분산 환경에서도 유지할 수 있으나, 성능 저하와 복잡도가 커짐
  • 많은 현대 시스템은 완벽한 분산 트랜잭션 대신, Sagas 패턴(분산 보상 트랜잭션) 등을 활용해 유연하게 일관성을 맞춘다

4.2 CAP 이론

• 개념: 분산 시스템에서 일관성(Consistency), 가용성(Availability), 파티션 내성(Partition Tolerance) 중 2가지만 완벽히 만족 가능하다는 이론
  1. 일관성(C): 모든 노드가 같은 시점에 동일한 데이터를 보장
  2. 가용성(A): 노드 일부가 장애가 나더라도, 전체 시스템은 계속 요청에 응답
  3. 파티션 내성(P): 네트워크 단절(Partition) 상황에서도 시스템이 동작/복구 가능한 능력
• CA/CP/AP Trade-off
  • CP(일관성+파티션 내성)를 추구하면 네트워크 분할 시 일부 요청을 거절(가용성 희생)
  • AP(가용성+파티션 내성)를 추구하면 네트워크 분할 시 일시적 데이터 불일치(일관성 희생)를 감수
  • RDBMS 성향 시스템은 주로 CP에 가까우며, DynamoDB 같은 시스템은 AP 성향이 강하다

---

요약

1. 확장성(Scalability)
   • 수직 확장(Scale-Up)은 장비 업그레이드를 통한 단순 접근, 한계 비용이 큼
   • 수평 확장(Scale-Out)은 노드 여러 대를 병렬로, 분산 설계 복잡도 증가
2. 샤딩 & 레플리케이션
   • 샤딩: 대규모 데이터 파티션으로 분산 저장
   • 레플리케이션: 동일 데이터 사본을 여러 노드에 유지 (마스터-슬레이브 / 멀티 마스터)
3. NoSQL
   • Key-Value, Document, Column Store 등 다양한 모델이 있고, 스키마 유연성·수평 확장성에 강점
4. 분산 트랜잭션 & CAP
   • 2PC, Sagas 등으로 분산 환경에서 트랜잭션 일관성을 유지하려면 복잡도가 증가
   • CAP 이론에 따라 일관성·가용성·파티션 내성 중 Trade-off를 이해해야 한다