분산 데이터베이스 기초

데이터를 여러 서버에 나누어 운영할 때 가장 먼저 만나는 기법이 레플리케이션(Replication)과 샤딩(Sharding)입니다. 레플리케이션은 같은 데이터를 복제해 읽기와 가용성을 보강하고, 샤딩은 데이터를 분할해 저장 용량과 쓰기 부하를 나눕니다. 대신 복제 지연, 장애 조치, 샤드 키, 분산 트랜잭션 같은 운영 비용이 함께 생깁니다.

분산 데이터베이스가 필요한 이유

분산 목적	주로 쓰는 기법	설명
읽기 확장	레플리케이션	읽기 요청을 복제본으로 분산
쓰기 확장	샤딩	데이터를 나누어 특정 서버에 쓰기 부하가 몰리지 않게 함
고가용성	레플리케이션	장애 시 다른 복제본을 기준점으로 승격
지역 분산	멀티 리전 복제	사용자와 가까운 리전에서 읽고, 쓰기 정책은 별도로 설계

레플리케이션

레플리케이션은 같은 데이터를 여러 서버에 복사하여 가용성과 읽기 성능을 높이는 기법입니다. 다만 복제본이 항상 즉시 같은 상태라는 뜻은 아니며, 동기화 방식과 읽기 설정에 따라 사용자가 보는 데이터가 달라질 수 있습니다.

Primary-Replica (기존 Master-Slave)

가장 흔한 레플리케이션 구조입니다. 하나의 Primary가 쓰기 기준점이 되고, Replica는 변경 로그를 따라가며 읽기 부하 분산이나 장애 대비에 활용됩니다. 기존 문헌의 Master-Slave라는 표현은 요즘 Source-Replica 또는 Primary-Replica로 바꾸어 쓰는 추세입니다.

장점	주의점
읽기 부하를 Replica로 분산	최신 읽기가 필요하면 Primary 또는 강한 읽기 설정 필요
장애 시 Replica 승격 가능	비동기 복제에서는 lag와 rollback 가능성 존재
백업/분석 부하를 분리 가능	쓰기 기준점은 여전히 Primary에 집중
구조가 비교적 이해하기 쉬움	자동 failover와 클라이언트 재시도 설계 필요

복제 방식: 동기 vs 비동기

복제의 동기화 수준에 따라 데이터 일관성과 성능 사이의 트레이드오프가 달라집니다.

복제 지연(Replication Lag) 문제

비동기 복제에서 Primary와 Replica의 데이터가 일시적으로 다른 현상입니다. Replica 읽기는 빠르게 부하를 줄일 수 있지만, 방금 쓴 값을 반드시 즉시 읽어야 하는 업무에서는 read-after-write 보장이 깨질 수 있습니다.

Failover (장애 조치)

Primary 장애 시 적절한 Replica를 새로운 Primary로 승격하고, 클라이언트의 연결 경로를 다시 잡는 과정입니다. 선거와 승격이 끝날 때까지 쓰기가 멈출 수 있고, 비동기 복제에서는 마지막 일부 쓰기 처리 방식도 함께 고려해야 합니다.

Multi-Primary / Multi-Master

여러 노드 또는 리전에서 쓰기를 받을 수 있는 구조입니다. 쓰기 지연을 줄이거나 지역 가용성을 높일 수 있지만, 양쪽에서 동시에 같은 데이터를 수정하면 충돌이 발생하므로 충돌 해결 정책과 업무 규칙이 필요합니다.

비교	Primary-Replica	Multi-Primary
쓰기 경로	Primary 중심	여러 노드/리전에서 쓰기 가능
복잡도	비교적 낮음	충돌 해결과 수렴 정책 필요
충돌	같은 Primary 안에서 통제	동시 수정 충돌 가능
장애 대응	선거와 승격 필요	지역 장애에는 유리하지만 조율 필요
주요 사용	일반 OLTP, 읽기 확장	멀티 리전, 협업, 오프라인 동기화

샤딩

샤딩(Sharding)은 데이터를 여러 서버에 나누어 저장하는 기법입니다. 레플리케이션이 복사라면, 샤딩은 분할입니다. 단일 서버로 감당하기 어려운 저장량과 쓰기 부하를 나누지만, 샤드 키가 나쁘면 hot shard, scatter-gather query, cross-shard transaction 문제가 생깁니다.

샤드 키 선택

샤딩의 성패는 샤드 키(Shard Key) 선택에 크게 좌우됩니다. 좋은 샤드 키는 데이터가 고르게 퍼지고, 자주 실행하는 쿼리가 특정 샤드로 라우팅되며, 시간이 지나도 특정 범위에 쓰기가 몰리지 않게 합니다.

해시 기반 샤딩

범위 기반 샤딩

일관성 해싱

해시 기반 샤딩에서 샤드를 추가하거나 제거할 때 일관성 해싱(Consistent Hashing)은 데이터 재배치를 줄이는 대표 기법입니다. 다만 모든 제품이 일관성 해싱을 쓰는 것은 아니며, 예를 들어 Redis Cluster는 고정된 hash slot을 노드에 배분하는 방식을 사용합니다.

샤딩의 과제

샤딩은 강력하지만 여러 운영 과제를 수반합니다.

레플리케이션 + 샤딩 조합

실무에서는 레플리케이션과 샤딩을 함께 사용합니다.

합의 알고리즘

분산 시스템에서 여러 노드가 같은 순서와 같은 결정을 공유하도록 만드는 방법입니다. 모든 데이터 요청에 항상 합의가 들어가는 것은 아니지만, 리더 선출, 메타데이터 변경, 강한 복제, 분산 트랜잭션처럼 “하나의 기준점”이 필요한 곳에서 중요합니다.

알고리즘	특징	사용 제품/계열
Raft	리더 기반, 이해하기 쉬운 로그 복제	etcd, CockroachDB, TiKV 계열
Paxos	합의 알고리즘의 이론적 근간	Google Spanner, Chubby 계열
ZAB	ZooKeeper의 원자 브로드캐스트 프로토콜	Apache ZooKeeper
PBFT	비잔틴 장애까지 고려	일부 블록체인/허가형 네트워크

핵심 개념	설명
레플리케이션	같은 데이터 복사 → 읽기 확장, 가용성 보강
샤딩	데이터 분할 → 쓰기 부하와 저장량 분산
일관성 해싱	노드 변경 시 재배치 범위를 줄이는 해싱 기법
합의 알고리즘	리더 선출, 로그 순서, 메타데이터 변경의 기준점
CAP 정리	네트워크 분할 시 C와 A 사이의 장애 대응 선택
Failover	장애 감지 후 기준 노드를 승격하고 경로 재설정
복제 지연	비동기 복제에서 일시적 불일치와 rollback 위험
샤드 키	데이터 분배와 쿼리 라우팅을 결정하는 설계 축

다음 절에서는 RDB와 NoSQL의 선택 기준을 다루겠습니다.