Overview
오늘은 데이터베이스 샤딩(Database Sharding) 개념과 작동 원리에 대해 자세히 알아보려고 한다.
샤딩은 데이터베이스의 확장성과 성능을 향상시키는 중요한 기법이며, 대규모 트래픽을 처리하는 시스템에서 필수적으로 고려되는 기술이다.
DB 샤딩(Sharding)이란?
데이터베이스 샤딩은 매우 큰 데이터베이스를 샤드라고 하는 더 작고, 빠르고, 관리하기 쉬운 부분으로 분리하는 데이터베이스 파티셔닝 유형이다. 샤드라는 단어는 전체의 작은 부분을 의미한다.
각 샤드는 독립적인 데이터베이스이며, 샤드가 집합적으로 전체 데이터베이스를 구성한다. 샤딩은 모놀리식 데이터베이스 설정보다 데이터 증가 및 관련 로드를 더 효과적으로 관리하는 데 도움이 되므로 확장성 솔루션으로 사용된다.
샤딩의 핵심 개념
- 데이터를 여러 개의 독립적인 데이터베이스(샤드, Shard)로 분산
- 각 샤드는 전체 데이터의 일부만 저장 (모든 데이터가 하나의 데이터베이스에 저장되는 모놀리식(monolithic) 구조와 대비됨)
- 샤딩을 통해 데이터베이스의 성능을 향상시키고, 트래픽이 많아질 때도 효율적인 확장이 가능
쉽게 말해, 하나의 커다란 도서관을 여러 개의 분관(Branch)으로 나누어 책을 관리하는 것과 비슷하다.
샤딩의 필요성
- 수직적 확장(Scale-up) 한계를 극복
- 데이터베이스를 하나의 서버에서만 운영하면, 서버의 성능에 한계가 발생
- 샤딩을 적용하면 여러 개의 서버를 활용하여 수평적 확장(Scale-out)이 가능
- 성능 및 응답 속도 개선
- 특정 샤드에서만 데이터가 저장되므로 쿼리 성능이 향상됨
- 부하 분산(Load Balancing)
- 한 곳에 집중되는 트래픽을 여러 샤드로 분산하여 서버 과부하 방지
- 고가용성(High Availability) 보장
- 특정 샤드가 다운되어도 다른 샤드에서 데이터가 유지됨
샤딩 작동 방식
샤딩에 대한 가장 일반적인 접근 방식은 다음과 같다.
- 키 기반(또는 해시 기반) 샤딩(Key-Based (or Hash-Based) Sharding): 각 행에는 행과 연결된 샤딩 키의 해시를 기반으로 샤드가 할당됩니다. 이는 간단하고 균일한 배포를 보장하지만 융통성이 없을 수 있다.
- 범위 기반 샤딩(Range-Based Sharding): 특정 키의 범위에 따라 데이터를 분할한다. 이는 액세스 패턴이 대체로 범위 기반인 경우(예: 날짜 범위)에 유용하다.
- 목록 기반 샤딩(List-Based Sharding): 데이터는 값 목록을 기반으로 분할된다. 예를 들어 각 국가의 데이터를 특정 샤드에 할당할 수 있다.
- 디렉터리 기반 샤딩(Directory-Based Sharding): 조회 서비스는 각 데이터 조각의 샤드 위치를 결정한다. 이를 통해 유연성이 향상되고 단순한 키, 범위 또는 목록 방법 이상의 복잡한 기준을 수용할 수 있다.
1️⃣ 키 기반(해시 기반) 샤딩 (Key-Based (or Hash-Based) Sharding)
- 데이터의 특정 샤딩 키(Sharding Key) 값을 해싱(Hashing)하여 특정 샤드에 저장하는 방식
- 균등한 데이터 분포가 가능하여 로드 밸런싱이 뛰어남
- 하지만, 샤드 추가 또는 제거 시 해시 값이 변경되면 데이터 재분배 필요
예제: 사용자 ID를 기반으로 샤딩
def get_shard(user_id, total_shards):
return hash(user_id) % total_shards # 해시 값을 샤드 개수로 나눈 나머지 값이 샤드 번호가 됨- 사용자가 `user_id = 101` 이면 `get_shard(101, 3)` → 샤드 2로 배정
2️⃣ 범위 기반 샤딩 (Range-Based Sharding)
- 특정 범위에 따라 데이터를 분할하는 방식
- 날짜, ID, 숫자 값 등의 범위 기준으로 데이터를 샤드에 저장
- 특정 범위의 데이터를 조회할 때 빠르게 처리 가능하지만, 데이터가 특정 샤드에 집중될 위험(Hot Spot Issue)이 있음
예제: 사용자의 ID 범위에 따라 샤드 배정
- 1~1000번 사용자 → Shard A
- 1001~2000번 사용자 → Shard B
- 2001~3000번 사용자 → Shard C
-- 예제: 1~1000 ID는 shard_a, 1001~2000 ID는 shard_b
SELECT * FROM shard_a.users WHERE id BETWEEN 1 AND 1000;- 특정 사용자 범위의 데이터를 쉽게 조회할 수 있지만, 특정 샤드에 데이터가 집중될 가능성이 있음
3️⃣ 목록 기반 샤딩 (List-Based Sharding)
- 특정 카테고리나 그룹을 기준으로 데이터 샤드를 분리하는 방식
- 예를 들어, 국가별, 지역별, 부서별 데이터 분리에 적합
- 데이터의 자연스러운 분리가 가능하지만, 샤드 간 데이터 불균형 발생 가능성 존재
예제: 국가별 사용자 샤딩
- 한국(KR) → Shard 1
- 미국(US) → Shard 2
- 일본(JP) → Shard 3
SELECT * FROM shard_kr.users WHERE country = 'KR';- 한 국가의 사용자가 급증하면 해당 샤드에 부하가 집중될 위험이 있음
4️⃣ 디렉터리 기반 샤딩 (Directory-Based Sharding)
- 샤드의 위치 정보를 별도의 디렉터리 서비스에서 관리하는 방식
- 데이터베이스가 아닌 메타데이터 테이블 또는 별도의 서비스가 샤드 위치를 결정
- 유연성과 확장성이 뛰어나지만, 디렉터리 서비스 장애 발생 시 전체 서비스에 영향을 미칠 수 있음
예제: 디렉터리 서비스 활용
- 데이터베이스 조회 전에 디렉터리 서비스에서 해당 데이터의 샤드 위치를 확인
def get_shard_from_directory(user_id):
return directory_service.get_shard(user_id) # 디렉터리 서비스에서 샤드 정보 조회- 샤드 위치를 동적으로 관리할 수 있지만, 디렉터리 서비스가 단일 장애점(Single Point of Failure, SPOF)이 될 위험이 있음
샤딩 동작 방식
샤딩된 데이터베이스에서 쿼리가 처리되는 과정은 다음과 같다.
1️⃣ 클라이언트가 데이터 요청을 보냄
2️⃣ 로드 밸런서(Load Balancer) 가 요청을 처리할 적절한 샤드를 찾음
3️⃣ 디렉터리 서비스(Directory Service) 가 데이터가 위치한 샤드를 식별
4️⃣ 해당 샤드(DB1, DB2, DB3 등)로 쿼리를 전달하여 요청을 처리
5️⃣ 처리된 데이터를 클라이언트에 반환
샤딩을 적용하면 시스템이 확장될 때 데이터베이스 부하를 효과적으로 분산 가능
DB 샤딩의 장점과 단점
장점
- 수평적 확장(Scale-out) 가능
- 쿼리 성능 향상 (병렬 처리 가능)
- 데이터베이스 부하 분산 (로드 밸런싱)
- 고가용성 (단일 샤드 장애 시에도 서비스 지속 가능)
단점
- 샤드 추가 및 데이터 재분배의 어려움
- Cross-Shard Join이 어려움 (다른 샤드의 데이터와 조인 시 성능 저하)
- 샤딩 로직이 애플리케이션 코드에 포함되어야 할 수도 있음
마무리
DB 샤딩(Sharding) 은 대규모 트래픽과 데이터 처리 문제를 해결하는 확장성 기법으로, 클라우드 환경과 글로벌 서비스에서 널리 사용된다.
샤딩을 선택할 때 고려해야 할 점
- 데이터 분포가 고르게 되는지 확인
- 데이터 이동과 확장성을 고려한 설계
- Cross-Shard 쿼리 문제 해결 방안 마련
샤딩을 적용하면 DB 성능이 향상되고 확장성이 뛰어난 시스템을 구축할 수 있지만, 설계 시 데이터 분배와 관리 문제를 신중하게 고려해야 한다.
Reference
https://aws.amazon.com/ko/what-is/database-sharding/
https://nadermedhatthoughts.medium.com/understand-database-sharding-the-good-and-ugly-868aa1cbc94c
'Database' 카테고리의 다른 글
| 데이터베이스 인덱스(Index) 최적화 방법 (4) | 2025.03.21 |
|---|---|
| PostgreSQL 개념 및 특징(with MySQL) (0) | 2024.03.29 |
| MongoDB란? (2) | 2023.05.20 |
| DB 스키마란?(Schema) (0) | 2023.04.21 |
| Mariadb란? (사용법) (0) | 2022.01.14 |