데이터베이스 확장을 위한 쿼리 오프로딩과 샤딩 설계
쿼리 오프로딩과 샤딩의 구조, CDC 복제 방식, 샤딩 키 선택과 재샤딩·트랜잭션 관리 시 고려할 점을 정리한다.
2026-08-14 · 최초 발행 2025-08-10
읽기 병목과 데이터 용량 한계는 다른 문제다
사용자와 데이터가 함께 늘어나는 서비스에서는 단일 데이터베이스가 처리 병목이 될 수 있다. 서버의 물리 성능을 높이는 수직적 확장(Scale-up)도 방법이지만, 노드를 추가해 부하를 나누는 수평적 확장(Scale-out)이 필요한 시점이 온다.
쿼리 오프로딩과 샤딩은 대표적인 수평 확장 전략이지만 해결하려는 대상이 다르다. 전자는 읽기와 쓰기 작업을 나누는 데 초점이 있고, 후자는 데이터를 여러 서버에 분산 저장하는 데 초점이 있다.
읽기 요청을 복제본으로 분산하는 쿼리 오프로딩
쿼리 오프로딩은 트랜잭션의 쓰기(CUD: Create, Update, Delete) 작업과 읽기(Read) 작업을 물리적으로 분리하는 방식이다. 쓰기는 원본 데이터베이스가 담당하고, 읽기는 복제된 데이터베이스로 보내 전체 처리량을 높인다.
이 구조에서는 읽기 요청을 병렬 처리할 수 있으며, 읽기와 쓰기가 서로에게 주는 부하를 줄일 수 있다.
Master DB는 모든 쓰기 트랜잭션을 처리하고 원본 데이터의 무결성을 보장한다. 변경 데이터 로그도 이곳에서 생성된다. Staging DB는 Master와 Slave 사이에서 복제 과정의 버퍼 역할을 하며, 복제 부하가 Master에 직접 집중되는 것을 막는다. Slave DB 또는 Read Replica는 읽기 트랜잭션만 처리하고, 여러 대를 구성해 읽기 요청을 나눈다. Master DB의 데이터는 지연시간(Latency)을 두고 Slave DB에 복제된다.
변경 데이터를 복제하는 CDC
CDC(Change Data Capture)는 원본 데이터베이스에서 바뀐 데이터를 식별해 대상 시스템으로 전달하는 기술이다. Master DB의 트랜잭션 로그(Backlog)를 모니터링하고, 변경 사항을 감지·캡처한 뒤 Staging DB를 거쳐 Slave DB로 전파한다. 이후 변경 데이터를 적용해 동기화한다.
구현 방식은 다음처럼 나뉜다.
- 로그 기반 CDC는 데이터베이스의 트랜잭션 로그를 직접 읽어 변경 사항을 추출한다.
- 트리거 기반 CDC는 데이터 변경 시 트리거를 통해 변경 사항을 캡처한다.
- 타임스탬프 기반 CDC는 레코드의 타임스탬프를 비교해 변경 사항을 식별한다.
데이터를 분할해 확장하는 샤딩
샤딩은 대규모 데이터베이스를 더 작은 부분인 샤드로 수평 분할하고, 여러 서버에 나누어 저장·처리하는 방식이다. 단일 데이터베이스의 용량 한계를 넘고 전체 처리량을 높이는 데 사용한다.
샤드 분할 기준은 데이터 접근 특성과 분포에 맞춰 정한다.
- 키 기반 샤딩(Key-Based Sharding)은 특정 컬럼인 샤딩 키를 기준으로 나눈다. 예를 들어 사용자 ID가 1-1000이면 샤드1, 1001-2000이면 샤드2에 저장할 수 있다.
- 범위 기반 샤딩(Range-Based Sharding)은 데이터 범위에 따라 나눈다. 거래일자가 2023년 1월인 데이터는 샤드1, 2월 데이터는 샤드2에 저장하는 방식이다.
- 해시 기반 샤딩(Hash-Based Sharding)은 샤딩 키의 해시 값을 계산해 데이터를 분할하며, 데이터를 균등하게 분산하는 데 효과적이다.
샤딩을 도입하면 데이터 증가에 따라 재샤딩(Re-sharding)이 필요해질 수 있다. 샤드 간 데이터 이동은 시스템 부하를 만들기 때문에 무중단 재샤딩 방법도 검토 대상이다.
서로 다른 샤드에 있는 테이블을 조인하는 일도 복잡해진다. 분산 조인이나 데이터 중복으로 대응할 수 있다. 여러 샤드에 걸친 트랜잭션에서는 원자성 보장이 문제가 되며, 2단계 커밋(Two-Phase Commit) 또는 사가(Saga) 패턴을 적용할 수 있다. 샤딩 키는 데이터 접근 패턴과 데이터 편중(Hotspot) 가능성을 함께 고려해 선택해야 한다.
전략 선택이 갈리는 지점
쿼리 오프로딩과 샤딩은 모두 노드를 추가하는 Scale-out 확장을 지원하고, 복제 기술을 활용해 데이터 동기화를 다룬다. Slave 노드를 통한 가용성 향상과 장애 시 Failover 메커니즘도 공통 관심사다.
| 측면 | 쿼리 오프로딩 | 샤딩 |
|---|---|---|
| 주요 목적 | 읽기/쓰기 작업 분리 | 데이터 분산 저장 |
| 데이터 구조 | 전체 데이터 복제 | 데이터 수평 분할 |
| 확장 초점 | 읽기 성능 향상 | 전체 시스템 확장성 |
| 데이터 일관성 | 약간의 지연 허용 | 즉시 일관성 유지 가능 |
| 구현 복잡도 | 상대적으로 단순 | 복잡한 설계 필요 |
| 적합한 상황 | 읽기가 많은 워크로드 | 대규모 데이터 처리 |
워크로드에 따른 적용 모습
전자상거래 플랫폼에서는 상품 조회를 Slave DB에서 처리하고 주문 처리는 Master DB가 맡길 수 있다. 이 방식으로 상품 조회 성능 200% 향상, 주문 처리 속도 30% 개선이라는 결과가 제시된다. 콘텐츠 관리 시스템도 콘텐츠 발행은 Master DB에서 수행하고, 사용자 콘텐츠 조회는 다수의 Slave DB로 분산해 트래픽 급증 시 안정적인 서비스를 제공할 수 있다.
소셜 미디어 플랫폼에서는 사용자 ID 기반 샤딩으로 사용자 데이터를 분산하고, 지역별 샤딩으로 지역 기반 콘텐츠를 최적화할 수 있다. 이는 수십억 사용자 데이터를 처리할 수 있는 구조다. 로그 분석 시스템은 시간 기반 샤딩으로 로그 데이터를 나누어 저장하고, 오래된 데이터는 저비용 스토리지로 옮긴다. 실시간 로그 처리 속도는 5배 향상될 수 있다.
운영 설계에서 확인할 지점
쿼리 오프로딩에서는 복제 지연(Replication Lag)을 모니터링해야 한다. 중요 데이터는 Master DB에서 직접 조회하는 방안도 고려할 수 있다. 세션 일관성 또는 스티키 세션(Sticky Session)을 구현해 사용자별로 동일한 Slave DB에 접근하게 하고, 읽기 요청 특성에 따라 Slave DB를 그룹화해 로드 밸런싱 알고리즘을 조정한다.
샤딩에서는 초기 설계 단계부터 확장성을 고려해 샤드 간 데이터 이동을 줄이고, 점진적 재샤딩 전략을 수립한다. 데이터 접근 패턴을 분석해 샤딩 키를 정하고 균등 분포를 고려해야 한다. 글로벌 트랜잭션에는 분산 트랜잭션 매니저를 도입하거나 최종 일관성(Eventual Consistency) 허용 여부를 검토한다.
클라우드 환경에서의 조합
AWS Aurora는 읽기 복제본 자동 확장 기능을 제공한다. Google Cloud Spanner는 글로벌 분산 데이터베이스이며, Azure Cosmos DB는 멀티 리전 샤딩 자동화를 제공한다.
자동 샤딩과 리밸런싱, AI 기반 쿼리 라우팅 최적화, 자가 치유(Self-healing) 기능도 강화되는 흐름이다. 쿼리 오프로딩과 샤딩을 결합하거나, RDBMS와 NoSQL을 통합하고, 엣지 컴퓨팅과 연계해 지역 분산 데이터 처리를 구성할 수도 있다.
워크로드 특성, 데이터 접근 패턴, 일관성 요구사항을 분석한 뒤 전략을 고르고 지속적으로 모니터링·최적화해야 한다. 읽기 요청이 많은 경우에는 쿼리 오프로딩이, 대규모 데이터를 분산 저장·처리해야 하는 경우에는 샤딩이 적합하며, 요구사항에 따라 두 방식을 조합할 수 있다.