복제와 샤딩으로 바라보는 데이터 확장의 한계
웹 서버나 API 서버는 비교적 쉽게 Scale Out이 가능하지만, 데이터베이스는 같은 방식으로 확장하기가 어렵다. 많은 시스템에서 성능 병목의 원인이 DB로 이어지는 이유도 여기에 있다. 이 글에서는 DB가 왜 Scale Out에 취약한지, 그리고 이를 해결하기 위해 사용되는 복제와 샤딩 개념을 중심으로 정리한다.
DB 확장이 어려운 이유부터 살펴보자
데이터베이스는 단순히 요청을 처리하는 서버가 아니다.
DB는 데이터의 정합성과 일관성을 책임진다.
이로 인해 다음과 같은 제약이 생긴다.
- 데이터 중복 관리 필요
- 동시에 여러 요청이 같은 데이터를 수정
- 트랜잭션 처리와 잠금 발생
이 특성 때문에 DB는 웹 서버처럼 단순히 여러 대로 나누기 어렵다.
Scale Out이 쉬운 서버와 어려운 서버의 차이
웹 서버는 다음 특성을 가진다.
- 요청 간 의존성 낮음
- 상태를 외부로 분리 가능
- 동일한 로직을 여러 대에서 실행 가능
반면 DB는 다음과 같다.
- 데이터 상태 자체가 핵심
- 모든 요청이 같은 데이터를 바라봄
- 쓰기 충돌과 정합성 문제가 발생
이 차이가 Scale Out 난이도를 결정한다.
DB 확장의 첫 번째 선택: Scale Up
실무에서 DB 확장의 첫 단계는 대부분 Scale Up이다.
- CPU, 메모리 성능 향상
- 디스크 성능 개선
- 네트워크 대역폭 증가
구조 변경 없이 성능을 높일 수 있기 때문에 초기 대응으로 가장 많이 선택된다. 하지만 이 방식에도 물리적 한계가 존재한다.
DB 복제(Replication)란 무엇인가
복제는 하나의 주 DB(Primary) 와 하나 이상의 복제 DB(Replica) 를 두는 구조다.
- Primary: 쓰기 담당
- Replica: 읽기 담당
복제를 통해 읽기 트래픽을 분산할 수 있다.
복제 구조의 장점
DB 복제는 다음 문제를 해결한다.
- 읽기 트래픽 분산
- 조회 성능 향상
- 일부 장애 대응 가능
특히 조회가 많은 서비스에서는 효과가 크다.
복제의 한계
복제는 Scale Out의 완전한 해답이 아니다.
- 쓰기 트래픽은 여전히 Primary에 집중
- 복제 지연 발생 가능
- 데이터 최신성 보장 어려움
즉, 복제는 읽기 확장에는 유효하지만 쓰기 확장에는 한계가 있다.
DB 샤딩(Sharding)이란 무엇인가
샤딩은 데이터를 여러 DB로 분할해 저장하는 방식이다.
예를 들면 다음과 같다.
- 사용자 ID 기준 분할
- 지역 기준 분할
- 해시 기반 분할
각 샤드는 독립적인 DB로 동작한다.
샤딩의 장점
샤딩의 가장 큰 장점은 쓰기 확장이다.
- 데이터 분산 저장
- 쓰기 트래픽 분산
- 단일 DB 한계 극복
대규모 서비스에서 필연적으로 등장하는 구조다.
샤딩의 어려움
샤딩은 구조적으로 복잡하다.
- 샤드 키 설계 난이도 높음
- 조인과 트랜잭션 처리 어려움
- 데이터 재분배 비용 큼
한 번 잘못 설계하면 되돌리기 어렵다.
복제와 샤딩의 차이
두 개념의 차이는 명확하다.
- 복제
- 동일한 데이터 복사
- 읽기 확장
- 구조 단순
- 샤딩
- 데이터 분할
- 읽기와 쓰기 확장
- 구조 복잡
복제는 비교적 쉽게 도입할 수 있지만, 샤딩은 신중한 설계가 필요하다.
실무에서의 일반적인 DB 확장 순서
대부분의 시스템은 다음 순서를 따른다.
- Scale Up
- 읽기 복제 도입
- 캐시 도입
- 샤딩 검토
샤딩은 최후의 선택지에 가깝다.
DB Scale Out이 어려운 진짜 이유
DB Scale Out이 어려운 핵심 이유는 하나다.
- 데이터 일관성을 유지하면서 분산해야 하기 때문
웹 서버와 달리, DB는 단순한 요청 분산만으로는 해결되지 않는다.
정리
DB는 데이터 정합성과 트랜잭션을 책임지는 시스템이기 때문에 Scale Out이 어렵다. 복제는 읽기 트래픽을 분산하는 데 효과적이지만 쓰기에는 한계가 있으며, 샤딩은 근본적인 확장 방법이지만 구조적 복잡도가 높다. 실무에서는 Scale Up과 복제, 캐시를 먼저 적용하고, 샤딩은 신중하게 선택하는 것이 일반적이다.