DB가 커졌을 때 꼭 알아야 할 '샤딩(Sharding)'의 개념과 방법들

운영 중인 서비스가 성공적으로 자리를 잡으면서 데이터가 빠르게 쌓이고 있다고 생각해보자.

예를 들어, 우리가 만든 도서 리뷰 시스템의 데이터가 1천만 건을 넘어가고 있다고 가정해보자.

 

처음엔 하나의 데이터베이스(MySQL)에 모든 리뷰와 도서 정보를 담고 있었는데, 이제는 단일 서버로는 더 이상 처리하기 어렵다. 이럴 때 우리가 사용할 수 있는 대표적인 방법이 바로 샤딩(Sharding)이다.

샤딩이 무엇인지, 어떤 방식으로 하는지, 어떤 장단점이 있는지 지금부터 하나씩 정리해보자.

샤딩(Sharding)이란?

샤딩이란 데이터베이스를 하나의 서버가 아니라 여러 개의 서버에 나눠서 저장하는 방법을 말한다. 데이터를 분산시켜서 처리 속도를 높이고, 데이터가 늘어나도 쉽게 확장할 수 있게 만드는 방법이다.

쉽게 말해 큰 책장을 여러 개의 작은 책장으로 나눠서 책을 분산시키는 것과 비슷하다. 그러면 책을 찾기도 쉽고, 각 책장에 부하가 줄어든다.

샤딩은 왜 필요할까?

단일 DB 서버는 어느 시점부터 성능 한계에 도달한다. 데이터가 많아질수록 쿼리 응답 속도가 느려지고, 메모리와 CPU 사용량도 급격히 증가한다. 더 좋은 하드웨어로 업그레이드하는 방법(Scale-Up)도 있지만 비용이 비싸고 한계가 있다.

샤딩은 서버를 추가로 배치해서 데이터를 나눠 저장하는 방식(Scale-Out)이기 때문에, 비용과 효율성 측면에서 더 유리한 선택이다.

샤딩의 대표적인 방법 3가지

샤딩은 크게 세 가지 방식으로 구분된다.

1. 범위 기반 샤딩(Range-based Sharding)
2. 해시 기반 샤딩(Hash-based Sharding)
3. 디렉터리 기반 샤딩(Directory-based Sharding)

각각 어떤 특징이 있는지 알아보자.

1️⃣ 범위 기반 샤딩(Range-based Sharding)

이 방식은 특정 범위를 기준으로 데이터를 나누는 방식이다.

예를 들어 리뷰 시스템에서 리뷰 ID를 기준으로:

• 1번 서버: 리뷰 ID 1 ~ 5,000,000
• 2번 서버: 리뷰 ID 5,000,001 ~ 10,000,000

이렇게 범위를 명확히 나눠 데이터를 저장한다.

장점

• 데이터를 쉽게 찾고 관리할 수 있다.
• 특정 범위의 데이터를 조회할 때 효율적이다.

단점

• 데이터가 고르게 분산되지 않을 수 있다.
• 데이터가 특정 서버에 몰리는 "데이터 쏠림 현상"이 발생할 수 있다.

2️⃣ 해시 기반 샤딩(Hash-based Sharding)

이 방식은 특정 값을 해시(Hash)함수로 처리해 데이터가 저장될 서버를 정하는 방법이다.

리뷰 ID로 다시 예를 들면, 리뷰 ID를 서버 수로 나눈 나머지로 나누는 것이다.

• 리뷰 ID % 서버 수 = 샤드 번호

예를 들어 서버가 2개라면:

• 리뷰 ID 1, 3, 5 → 서버 1
• 리뷰 ID 2, 4, 6 → 서버 2

이렇게 나누는 방식이다.

장점

• 데이터가 비교적 균등하게 분산된다.
• 서버가 추가될 때도 분산 관리가 쉽다.

단점

• 범위 조회가 어렵다 (예: 최근 작성된 리뷰 100건 조회 등)
• 샤드 개수가 바뀌면 데이터가 많이 이동해야 할 수도 있다.

3️⃣ 디렉터리 기반 샤딩(Directory-based Sharding)

이 방식은 별도의 "매핑 테이블(디렉터리)"을 두어, 데이터가 어디 있는지 관리하는 방법이다.

예를 들어, 리뷰 ID 별로 실제 저장된 서버를 매핑 테이블에 저장한다.

리뷰 ID	서버 번호
1	서버 A
2	서버 B
3	서버 A

 

이렇게 별도의 디렉터리가 데이터를 관리한다.

장점

• 데이터를 매우 유연하게 관리할 수 있다.
• 샤드 추가 시 데이터 이동이 적다.

단점

• 매핑 테이블 관리 비용과 복잡도가 높다.
• 매핑 테이블 자체가 병목 지점이 될 수 있다.

물리적 샤딩과 논리적 샤딩의 개념

샤딩을 적용할 때 알아두면 좋은 두 가지 개념이 더 있다.

• 물리적 샤딩(Physical Sharding): 실제로 데이터를 나눈 물리적인 DB 서버 단위.
• 논리적 샤딩(Logical Sharding): 물리적인 샤드의 수와 관계없이 시스템에서 인식하는 가상의 샤드 단위.

예를 들어 물리적 DB 서버는 2대이지만, 논리적으로는 4개의 샤드가 있다고 시스템이 인식하도록 설정할 수 있다. 이렇게 하면 서버를 추가하거나 데이터를 재배치할 때 시스템 변경 없이 쉽게 관리할 수 있다.

샤딩을 할 때 고려해야 할 점

샤딩을 할 때는 다음과 같은 고민을 꼭 해야 한다.

• 데이터가 어떻게 조회되는지(단일 조회 vs 범위 조회)
• 데이터 증가 속도가 얼마나 빠른지
• 확장성이 얼마나 중요한지
• 데이터가 균등하게 분산될 수 있는 기준은 무엇인지(샤드 키 선정)

실무에서는 어떻게 적용할까?

현실에서는 보통 해시 기반 샤딩을 가장 많이 쓴다. 균등 분산이 비교적 쉽고, 관리가 간편하기 때문이다. 다만, 범위 조회가 중요한 서비스라면 범위 기반 샤딩이나 디렉터리 기반 샤딩이 더 효율적일 수 있다.

또한, 현실에서는 이 방식들을 혼합해서 쓰기도 한다. 예를 들어, 사용자는 해시로 나누고, 각 사용자의 리뷰 데이터는 디렉터리 기반으로 관리하는 식이다.

이 강의에서는 리뷰 시스템의 데이터가 많아졌다는 가정하에, 해시 기반 샤딩을 예시로 설명하고 있다.

---

이번 글에서 샤딩의 기본 개념과 종류, 고려사항까지 알아봤다.

데이터베이스 확장 문제를 고민할 때 이 글이 작은 도움이라도 되었으면 좋겠다.