최근 회사에서 데이터가 많아지고 조회도 점점 늘어나면서 DB 커넥션이 과도하게 생성되어 서버가 멈추는 사례가 발생하고 있습니다.
이를 보완하기 위한 방법 중 하나로 샤딩에 대해 공부하고 정리해보았습니다.
DB 샤딩(Sharding)에 대해서
대규모 트래픽을 처리하거나 데이터가 폭발적으로 증가하는 서비스를 운영하다 보면, 단일 데이터베이스 인스턴스로는 감당할 수 없는 상황이 발생합니다. 이럴 때 등장하는 개념이 바로 DB 샤딩(Sharding) 입니다.
본 글에서는 샤딩의 개념, 방식, 장단점, 설계 시 고려사항 등을 정리했습니다.
1. 샤딩이란?
샤딩은 데이터를 논리적으로 분리하고, 각 조각을 물리적으로 독립된 데이터베이스 인스턴스에 분산 저장하는 기술입니다. 하나의 거대한 테이블을 작은 조각들로 나누어 각기 다른 서버에 저장함으로써, 부하를 분산하고 성능을 향상시킬 수 있습니다.
비유하자면, 한 명의 배달원이 10,000건의 주문을 처리하는 대신, 10명의 배달원이 각자 1,000건씩 처리하도록 분담하는 방식과 유사합니다.
2. 샤딩의 필요성
샤딩은 일반적으로 다음과 같은 문제를 해결하기 위해 도입합니다.
- 데이터 폭증: 테이블의 row 수가 수천만, 수억 건에 달할 경우 성능이 급격히 저하됩니다.
- 트래픽 병목: 단일 DB에 모든 요청이 집중되면 CPU, I/O, 네트워크 병목이 발생합니다.
- 확장 한계: 수직 확장(scale-up)은 물리적 한계와 비용 부담이 큽니다.
- 고가용성 확보: 일부 샤드 장애 시 전체 서비스 장애로 이어지지 않도록 분산 설계가 필요합니다.
3. 샤딩 방식
샤딩은 나누는 기준과 방식에 따라 여러 유형이 존재합니다. 가장 일반적으로 사용하는 방식은 수평 샤딩입니다.
3.1 수평 샤딩 (Horizontal Sharding)
- 테이블의 row 단위로 데이터를 분산 저장합니다.
- 예를 들어, 유저 ID가 0
9999는 DB1, 1000019999는 DB2에 저장합니다. - 대부분의 샤딩 시스템은 이 방식을 사용합니다.
3.2 수직 샤딩 (Vertical Sharding)
- 테이블을 컬럼 단위로 나누어 다른 데이터베이스에 저장합니다.
- 예를 들어, 유저 기본 정보는 DB1, 결제 정보는 DB2에 저장하는 방식입니다.
- 도메인 분리가 명확한 경우에 사용합니다.
3.3 기능 기반 샤딩
- 서비스의 기능 또는 도메인 단위로 데이터베이스를 분리합니다.
- 예를 들어, 회원 시스템은 DB1, 주문 시스템은 DB2로 운영합니다.
- MSA 환경에서 자주 사용하는 방식입니다.
3.4 해시 기반 샤딩
- 샤딩 키에 해시 함수를 적용해 고르게 분산합니다.
- 균등 분산에는 유리하지만, 어떤 샤드에 데이터가 들어갔는지 알기 어렵습니다.
4. 샤딩 키 설계
샤딩의 핵심은 데이터를 어떤 기준으로 나눌지 정하는 것입니다. 이를 결정하는 키를 샤딩 키(Sharding Key)라고 합니다.
4.1 좋은 샤딩 키의 조건
- 균등 분산: 특정 샤드에 데이터가 쏠리지 않도록 설계해야 합니다.
- 쿼리 예측 가능성: 샤딩 키로부터 어느 샤드를 조회할지 쉽게 판단할 수 있어야 합니다.
- 변하지 않는 값: 샤딩 키는 주로 기본키 또는 자주 변경되지 않는 값이어야 합니다.
- 비즈니스 도메인에 맞는 선택: 단순한 숫자 ID가 아닌, 지역, 계정 유형 등 도메인에 맞는 기준이 될 수 있습니다.
5. 샤딩의 장점
샤딩을 올바르게 도입했을 경우, 다음과 같은 이점을 얻을 수 있습니다.
| 항목 | 설명 |
|---|---|
| 수평 확장 | 서버를 가로로 추가하면서 성능을 향상시킬 수 있습니다. |
| 고가용성 | 한 샤드가 장애를 일으켜도 전체 장애로 이어지지 않습니다. |
| 성능 향상 | 읽기/쓰기 부하를 분산시켜 병목 현상을 줄일 수 있습니다. |
| 데이터 분리 | 지역별, 도메인별로 데이터가 분산되어 관리가 용이합니다. |
6. 샤딩의 단점
샤딩은 만능은 아닙니다. 적절히 설계하지 않거나 복잡한 시스템에서는 오히려 관리 포인트가 늘어납니다.
| 문제점 | 설명 |
|---|---|
| JOIN 제약 | 서로 다른 샤드 간의 조인을 수행할 수 없습니다. 앱에서 조인 로직을 따로 구현해야 합니다. |
| 트랜잭션 분산 | 여러 샤드를 포함하는 트랜잭션은 분산 트랜잭션 처리(2PC 등)가 필요합니다. |
| 운영 복잡도 증가 | 샤드 수가 많아질수록 모니터링, 백업, 배포 등의 관리가 어려워집니다. |
| 재샤딩 어려움 | 샤딩 키 변경이나 샤드 재구성은 서비스에 큰 영향을 줄 수 있습니다. |
7. 샤딩 설계 시 고려할 점
샤딩은 설계 단계에서 많은 고려가 필요합니다. 실무에서는 다음과 같은 점을 신중히 검토해야 합니다.
- 샤딩 키 선택: 잘못 선택하면 특정 샤드로 부하가 몰리거나, 쿼리가 복잡해집니다.
- 샤드 수 결정: 초기에는 적은 수로 시작하고, 점진적으로 늘릴 수 있는 구조로 설계합니다.
- 라우팅 로직 설계: 어떤 요청이 어느 샤드로 가야 하는지 결정하는 라우팅 계층이 필요합니다.
- 샤딩 전략 명시화: 향후 유지보수를 위해 문서화와 코드 명세를 철저히 해야 합니다.
- 재샤딩 플랜 수립: 데이터 증가 또는 분포 불균형에 대비해 재샤딩 전략을 사전에 준비합니다.
8. 대표적인 샤딩 시스템/기술
| 기술 | 설명 |
|---|---|
| Vitess | MySQL 기반 분산 DB 프레임워크. YouTube에서 사용 |
| Citus | PostgreSQL 확장 모듈로 샤딩 지원 |
| MongoDB | 기본적으로 샤딩 기능을 내장 |
| CockroachDB | 자체적으로 샤딩과 복제를 자동으로 수행하는 NewSQL 기반 DB |
| ProxySQL, ShardingSphere | 애플리케이션과 DB 사이에서 샤딩 라우팅을 처리하는 미들웨어 |
9. 실제 적용 사례
대규모 서비스를 운영하는 기업들은 대부분 샤딩을 적극적으로 활용하고 있습니다.
- 카카오: 사용자 수와 메시지 트래픽이 많아 유저 ID 기준 샤딩 적용
- 쿠팡: 주문/결제 데이터가 많아 도메인 분리 + 샤딩 적용
- 글로벌 SaaS 기업: 국가 또는 리전 기반으로 샤드 구성
마무리
샤딩은 대규모 서비스의 성능과 안정성을 위한 강력한 도구입니다. 그러나 도입에는 많은 고려가 필요하며, 설계부터 운영까지 정교한 전략이 요구됩니다. 단순히 성능 개선만을 목적으로 무분별하게 도입하면 오히려 시스템이 복잡해지고 관리 부담이 커질 수 있습니다.
샤딩은 성능과 복잡성 사이의 균형을 잡는 문제입니다. 현재 시스템이 샤딩이 필요한 상태인지, 필요한 경우 어떤 방식으로 적용할지 신중히 판단하고, 장기적인 관점에서 설계해야 합니다.