서비스 성장의 통과 의례, DB 병목 현상
사용자가 늘어나고 데이터가 쌓이면 애플리케이션 서버보다 먼저 비명을 지르는 곳이 바로 데이터베이스(DB)입니다. "사이트가 느려졌다"는 불만의 80% 이상은 DB 병목에서 시작됩니다.
이때 개발자와 인프라 담당자는 두 가지 선택지를 놓고 고민하게 됩니다. 데이터를 똑같이 복사해서 여러 곳에 둘 것인가(Replication), 아니면 데이터를 조각내어 분산 저장할 것인가(Sharding)입니다. 이 글에서는 헷갈리기 쉬운 두 개념의 차이와 도입 시점을 명확히 정리해 드립니다.
1. 리플리케이션(Replication): 데이터를 복제하여 읽기 성능 향상
리플리케이션은 말 그대로 데이터를 '복제'하는 기술입니다. 가장 흔히 사용되는 Master-Slave(Primary-Secondary) 구조를 예로 들어보겠습니다.
작동 원리
하나의 원본 데이터베이스(Master)에 데이터가 기록되면, 그 내용이 실시간으로 연결된 여러 개의 복제 데이터베이스(Slave)로 복사됩니다.
- Master (주 서버): 데이터의 생성(Create), 수정(Update), 삭제(Delete) 등 '쓰기' 작업을 전담합니다.
- Slave (부 서버): Master로부터 데이터를 받아와 동기화하고, 오직 '읽기(Select)' 작업만 처리합니다.
장점: 읽기 분산 (Read Scalability)
대부분의 웹 서비스는 글을 쓰는 빈도보다 읽는 빈도가 압도적으로 높습니다(약 8:2 또는 9:1 비율). 리플리케이션을 적용하면 쓰기 트래픽은 Master 하나가 감당하지만, 읽기 트래픽은 여러 대의 Slave가 나누어 처리하므로 전체적인 조회 속도가 획기적으로 빨라집니다. 또한, Master가 고장 나면 Slave 중 하나를 승격시켜 서비스를 유지할 수 있어 고가용성(HA) 확보에도 유리합니다.
한계점
모든 Slave가 Master와 동일한 데이터를 가져야 하므로, 데이터 동기화 과정에서 시차(Replication Lag)가 발생할 수 있습니다. 방금 쓴 글이 목록에서 바로 보이지 않는 현상이 이에 해당합니다. 또한, '쓰기' 성능은 여전히 Master 한 대의 성능에 종속된다는 한계가 있습니다.
2. 샤딩(Sharding): 데이터를 조각내어 쓰기 성능 향상
리플리케이션으로도 감당이 안 될 만큼 데이터가 거대해지거나, '쓰기' 요청 자체가 폭주한다면 어떻게 해야 할까요? 이때 등장하는 것이 샤딩입니다. 이를 수평 분할(Horizontal Partitioning)이라고도 합니다.
작동 원리
거대한 하나의 테이블을 여러 개의 작은 조각(Shard)으로 나누어 물리적으로 서로 다른 서버에 저장하는 방식입니다. 예를 들어, 회원 데이터 1억 건이 있다면 1번 서버에는 ID 1~5000만 번을, 2번 서버에는 5001만~1억 번을 저장하는 식입니다. 이때 데이터를 나누는 기준이 되는 키를 샤드 키(Shard Key)라고 합니다.
장점: 쓰기 분산 (Write Scalability) 및 용량 한계 극복
리플리케이션과 달리 샤딩은 쓰기 작업 자체가 여러 서버로 분산됩니다. 따라서 이론적으로 서버를 추가하는 만큼 쓰기 성능과 저장 용량을 무한대로 확장할 수 있습니다. 단일 서버의 하드웨어 스펙 한계를 넘어설 수 있는 유일한 방법입니다.
한계점
구현과 운영 난이도가 극도로 높습니다. 데이터가 쪼개져 있기 때문에 여러 샤드에 걸쳐 있는 데이터를 합쳐서 조회하는 조인(JOIN) 연산이 매우 어렵거나 불가능해집니다. 또한, 한쪽 샤드에만 데이터가 몰리는 '데이터 편중(Data Skew)' 현상이 발생하면 샤딩의 효과가 반감되므로, 초기에 샤드 키를 아주 신중하게 설계해야 합니다.
3. 비교 요약: 언제 무엇을 선택해야 할까?
구분 | 리플리케이션 (Replication) | 샤딩 (Sharding) |
핵심 개념 | 데이터 복제 (Copy) | 데이터 분할 (Partition) |
주 목적 | 읽기(Read) 성능 분산, 고가용성 | 쓰기(Write) 성능 분산, 대용량 저장 |
데이터 형태 | 모든 서버가 동일한 데이터 보유 | 각 서버가 서로 다른 데이터 보유 |
구현 난이도 | 낮음 (대부분의 DBMS가 기본 지원) | 높음 (애플리케이션 레벨의 수정 필요) |
적합한 상황 | 조회수가 많은 뉴스, 커뮤니티, 쇼핑몰 | 데이터가 급증하는 메신저, 로그 시스템, 결제 |
4. 단계적 접근 전략: 리플리케이션에서 샤딩으로
처음부터 샤딩을 도입하는 것은 '오버 엔지니어링'이 될 확률이 높습니다. 일반적인 스타트업이나 서비스의 성장 단계에 따른 데이터베이스 확장 전략은 다음과 같습니다.
- 단일 DB 최적화: 인덱스(Index) 튜닝과 쿼리 최적화로 최대한 버팁니다.
- 캐시(Cache) 도입: Redis 등을 활용해 DB로 가는 읽기 요청 자체를 줄입니다.
- 리플리케이션 도입: 읽기 트래픽이 많아지면 Master-Slave 구조로 읽기 부하를 분산합니다.
- 샤딩 도입: 쓰기 트래픽이 한계에 도달하거나 데이터 양이 수십억 건을 넘어가면 그때 샤딩을 고려합니다.
기술보다 비즈니스 특성이 먼저다
리플리케이션은 ‘협동'이고, 샤딩은 '분업'입니다.
조회 성능이 중요한지, 방대한 데이터 저장이 중요한지 비즈니스의 특성을 먼저 파악하세요. 최근에는 AWS Aurora나 Google Spanner 같은 클라우드 네이티브 데이터베이스들이 이러한 복잡한 확장성 문제를 자동으로 관리해주기도 합니다. 무조건적인 신기술 도입보다는, 현재 우리 서비스의 병목 구간이 '읽기'인지 '쓰기'인지를 모니터링 툴을 통해 정확히 진단하는 것이 성공적인 아키텍처의 시작입니다.