데이터베이스 스케일링 (Database Scaling)
목차
데이터베이스 스케일링이란
데이터베이스 스케일링(Database Scaling) 은 데이터 양과 트래픽이 늘어날 때도 성능과 가용성을 유지하도록 데이터베이스 처리 능력을 확장하는 작업입니다.
이 문서는 데이터베이스 구현·운영 관점에서 스케일링을 어떻게 적용할지를 설명합니다.
서비스 전체에서 언제 샤딩이나 오토스케일링이 필요한지 같은 설계 판단은 확장성 문서와 함께 보면 경계가 더 분명해집니다.
스케일링을 논할 때는 보통 다음 세 가지를 함께 봅니다.
- 읽기 처리량을 늘릴 것인가
- 쓰기 처리량을 늘릴 것인가
- 저장 용량과 운영 안정성을 함께 확보할 것인가
읽기 확장과 쓰기 확장은 난이도가 다릅니다. 읽기는 복제본으로 비교적 쉽게 늘릴 수 있지만, 쓰기는 단일 primary 구조에서 병목이 생기기 쉽고 결국 데이터 분산까지 고민해야 합니다.
수직 스케일링과 수평 스케일링
수직 스케일링(Scale-Up) 은 기존 서버의 CPU, 메모리, 스토리지를 더 좋은 사양으로 키우는 방식입니다.
수평 스케일링(Scale-Out) 은 서버 수를 늘려 부하와 데이터를 분산하는 방식입니다.
| 항목 | 수직 스케일링 | 수평 스케일링 |
|---|---|---|
| 방법 | 한 대를 더 큰 장비로 교체 | 여러 대로 분산 |
| 장점 | 구조가 단순하다 | 확장 한계가 더 높다 |
| 단점 | 장비 한계와 SPOF가 남는다 | 운영 복잡도가 높다 |
| 적합한 경우 | 초기 단계, 중간 규모 서비스 | 대규모 트래픽, 대용량 데이터 |
실무에서는 보통 다음 순서로 갑니다.
- 수직 스케일링으로 먼저 버틴다.
- 읽기 복제본으로 읽기 부하를 분산한다.
- 그래도 안 되면 파티셔닝, 샤딩, CQRS 같은 구조적 분산을 검토한다.
읽기 확장을 위한 복제본
읽기 복제본(Read Replica) 은 primary의 데이터를 복제해 읽기 요청을 분산하는 방식입니다. 많은 관리형 데이터베이스 서비스도 이 방식을 제공합니다.1
- 장점: 읽기 트래픽 분산이 쉽고, 리포팅과 백오피스 조회를 분리하기 좋습니다.
- 단점: 대부분 비동기 복제이므로 replication lag가 발생할 수 있습니다.
- 주의점: 방금 쓴 데이터를 즉시 읽어야 하는 요청은 replica가 아니라 primary로 보내야 할 수 있습니다.
읽기 복제본은 특히 다음 상황에 유용합니다.
- 메인 서비스는 쓰기보다 읽기가 훨씬 많다
- 통계성 조회나 대시보드 조회가 무겁다
- 검색 전 단계의 보조 조회를 분리하고 싶다
다만 읽기 복제본은 쓰기 확장이 아니라 읽기 확장이라는 점을 분명히 구분해야 합니다.
샤딩
샤딩(Sharding) 은 데이터를 여러 데이터베이스 노드에 나누어 저장하는 수평 분산 방식입니다. 데이터와 요청을 여러 샤드로 분배해 단일 서버 한계를 넘기 위한 구조입니다.2
샤딩이 필요한 대표 상황은 다음과 같습니다.
- 단일 primary의 CPU, I/O, 저장 공간 한계에 도달했다
- 쓰기 처리량 자체가 너무 높다
- 특정 테이블의 크기가 너무 커 백업, 복구, 유지보수가 어려워졌다
샤딩의 대가도 분명합니다.
- cross-shard join과 집계가 어려워진다
- 트랜잭션 범위가 복잡해진다
- 운영, 모니터링, 리밸런싱 비용이 증가한다
샤딩 키가 중요한 이유
샤딩의 성패는 샤딩 키가 결정합니다.
- 분산이 고르게 되는가
- 핵심 조회가 특정 샤드만 타게 할 수 있는가
- 시간이 지나도 hot shard가 생기지 않는가
예를 들어 증가하는 ID나 시간값만 샤딩 키로 쓰면 특정 샤드에 쓰기가 몰릴 수 있습니다.
대표 샤딩 전략
- 범위 기반 샤딩: 날짜, ID 구간처럼 범위로 나눕니다.
- 장점: 범위 조회에 유리합니다.
- 단점: 특정 구간에 트래픽이 몰리면 hotspot이 생길 수 있습니다.
- 해시 기반 샤딩: 샤딩 키를 해시해 고르게 분산합니다.
- 장점: 분산이 비교적 균등합니다.
- 단점: 범위 조회 효율이 떨어질 수 있습니다.
- 지리 기반 샤딩: 리전이나 국가 단위로 나눕니다.
- 장점: 데이터 레지던시와 지연 시간 측면에서 유리합니다.
- 단점: 국가 간 조회와 이동이 복잡해질 수 있습니다.
파티셔닝과 샤딩의 차이
둘 다 데이터를 나눈다는 점은 같지만, 범위가 다릅니다.
| 항목 | 파티셔닝 | 샤딩 |
|---|---|---|
| 분할 위치 | 보통 하나의 DB 인스턴스 내부 | 여러 DB 인스턴스 간 |
| 목적 | 관리성과 조회 범위 축소 | 저장량과 처리량의 수평 확장 |
| 장점 | 비교적 단순하다 | 확장 한계가 높다 |
| 단점 | 단일 인스턴스 한계는 남는다 | 운영 복잡도가 높다 |
실무에서는 파티셔닝이 샤딩보다 먼저 검토되는 경우가 많습니다. 운영 복잡도가 훨씬 낮기 때문입니다.
어떤 전략을 먼저 선택할까
- 작은 규모
- 먼저 수직 스케일링
- 읽기 병목
- 캐시 + 읽기 복제본
- 대용량 단일 테이블
- 파티셔닝 + 아카이빙
- 쓰기 병목 또는 저장량 한계
- 샤딩 검토
즉, 샤딩은 마지막 카드에 가깝습니다. 대부분의 서비스는 캐시, 복제본, 파티셔닝만으로도 꽤 오래 버틸 수 있습니다.
운영 시 주의할 점
- 복제 지연 모니터링: replica lag가 커지면 오래된 데이터를 읽게 됩니다.
- 장애 전환 전략: failover 시 애플리케이션 연결, 쓰기 라우팅, 재동기화 절차가 준비돼 있어야 합니다.
- 재샤딩 비용: 샤딩 키를 잘못 잡으면 나중에 재분배 비용이 큽니다.
- 백업과 복구: 샤드 수가 늘수록 백업/복구 시점 정합성 관리가 어려워집니다.
- 운영 도구: 모니터링, 스키마 변경, 데이터 마이그레이션 자동화가 없으면 운영 난이도가 급격히 올라갑니다.
면접 포인트
- 읽기 확장과 쓰기 확장은 분리해서 설명해야 합니다.
- Read Replica는 읽기 확장에는 좋지만 replication lag를 동반할 수 있습니다.
- 샤딩은 확장성은 높지만 join, transaction, 운영 복잡도를 크게 올립니다.
- 대부분의 서비스는 수직 확장, 캐시, 복제본, 파티셔닝을 먼저 사용합니다.
- 샤딩을 설명할 때는 샤딩 키 선정 기준까지 말해야 답변이 완성됩니다.