데이터베이스 샤딩과 샤드 키

데이터가 한 서버에 다 들어가지 않거나 한 서버가 요청을 감당하지 못하면, 데이터베이스를 여러 서버로 나누는 방법을 생각하게 돼. 이때 어려운 건 서버를 늘리는 일이 아니야. 어떤 행을 어느 서버에 둘지 정하는 규칙, 즉 샤드 키가 조회와 운영의 모양을 바꾼다는 점이 핵심이야.¹

한 줄로 말하면

데이터베이스 샤딩은 전체 데이터를 여러 데이터베이스 서버, 즉 샤드에 나눠 저장하는 수평 확장이야. 샤드 키는 각 행이 어느 샤드에 들어갈지 결정하는 열 또는 열 조합이고, 이 선택은 데이터가 고르게 퍼지는지와 한 번의 조회가 몇 개의 샤드를 건드리는지를 함께 결정해.

비유로 이해하기

도서관의 책을 여러 건물에 나눠 보관한다고 생각해 보자. 책의 분류 규칙이 좋아서 한 사람이 찾을 책이 한 건물에 모이면 빠르게 찾을 수 있지만, 규칙이 나쁘면 모든 건물을 돌아다녀야 해. 데이터베이스에서 그 분류 규칙이 샤딩 전략이고, 책의 분류에 쓰는 기준이 샤드 키야.

여기까지가 이해를 돕는 비유야. 실제로는 프록시가 쿼리를 알맞은 샤드로 보내고, 데이터 분포·조회 조건·변경 빈도·장애 대응까지 함께 설계해야 해.

정확한 정의

샤딩된 데이터베이스에는 전체 데이터의 일부만 가진 여러 서버가 있어. 애플리케이션이 모든 샤드의 위치와 연결을 직접 관리하면 샤드 수가 늘수록 코드가 복잡해질 수 있어서, 중간의 프록시가 쿼리를 받아 대상 샤드로 라우팅하는 구조를 쓸 수 있어.¹

flowchart LR
    App[애플리케이션] --> Proxy[프록시·라우터]
    Proxy --> S1[샤드 1]
    Proxy --> S2[샤드 2]
    Proxy --> S3[샤드 3]
    Key[샤드 키와 분할 규칙] --> Proxy

샤딩 전략은 행을 샤드에 배치하는 규칙이야. 대표적으로 값의 구간을 나누는 범위 샤딩과, 샤드 키를 해시해 분배하는 해시 샤딩이 있어. 범위 샤딩은 규칙을 이해하기 쉽지만 값이 한쪽 구간에 몰리면 특정 샤드만 과부하가 걸릴 수 있고, 해시 샤딩은 비슷한 값도 서로 다른 샤드로 흩어 데이터 분포를 고르게 만들 여지가 있어.¹

샤드 키를 고를 때는 값의 카디널리티, 즉 서로 다른 값이 얼마나 많은지를 봐야 해. 값이 거의 모두 다르면 분산에 유리할 수 있고, 고정 길이의 식별자는 길이가 제각각인 문자열보다 해시 계산에도 유리할 수 있어. 다만 카디널리티가 높다는 이유만으로 충분하지는 않아. 실제로 자주 실행하는 조회가 그 키를 조건에 포함하는지도 같이 봐야 해.¹

왜 중요한가

샤드 키의 좋은 선택은 데이터를 고르게 나누는 것과 조회를 좁히는 일을 동시에 돕는다. 예를 들어 사용자별 기록을 사용자가 조회하는 시스템이라면, 기록과 사용자를 같은 user_id 기준으로 배치할 때 한 사용자의 데이터를 한 샤드에서 찾기 쉬워질 수 있어. 반대로 사용자의 기록을 다른 열의 범위로 나누면 같은 사용자의 데이터를 찾으려고 여러 샤드에 물어봐야 할 수 있어. 이것이 교차 샤드 조회야.¹

교차 샤드 조회는 여러 서버에 요청을 보내고 결과를 모으는 추가 네트워크·CPU 작업을 만든다. 모든 교차 샤드 조회가 잘못된 것은 아니지만, 자주 실행되는 핵심 조회가 매번 전체 샤드를 훑는다면 샤딩으로 얻으려던 확장 효과가 줄어들 수 있어. 그래서 샤드 키는 저장 분포만이 아니라 애플리케이션의 주요 조회 경로를 보고 정해야 해.

실제 예시

사용자별 걸음 수 기록을 저장한다고 해 보자. step_count를 샤드 키로 삼으면 값의 범위에 따라 기록이 나뉘지만, 한 사용자의 기록을 날짜별로 읽을 때 여러 샤드에 요청해야 할 수 있어. user_id를 기준으로 삼으면 같은 사용자의 기록이 한 샤드에 모일 가능성이 커져 그 조회를 한 곳으로 좁히기 쉬워.¹

샤드 키의 변경 빈도도 중요해. 샤드 키 값이 바뀌면 행이 다른 샤드로 이동해야 할 수 있기 때문이야. 계속 변하는 측정값을 키로 쓰면 한 행이 반복해서 이동할 수 있지만, 거의 바뀌지 않는 식별자를 쓰면 샤드 수를 늘리거나 줄이는 재분할 같은 구조 변경이 있을 때까지 위치가 안정적일 수 있어.¹

샤드 수가 늘어나는 재분할은 단순히 서버 한 대를 더 연결하는 일이 아니야. 기존 행을 새 배치 규칙에 맞춰 옮기면서, 서비스 중인 조회와 쓰기를 함께 다뤄야 해. 따라서 처음부터 완벽한 키를 찾는 것만큼 현재 데이터 분포와 주요 쿼리를 관찰하고, 재분할 경로를 준비하는 일이 중요해.¹

헷갈리지 말아야 할 점

샤딩과 복제는 달라. 샤딩은 데이터를 여러 서버에 나눠 담고, 복제는 같은 데이터를 다른 서버에 복사해 내구성과 가용성을 높이는 방식이야. 한 샤드에 복제본을 둘 수도 있어.
샤딩은 인덱스의 대체물이 아니야. 한 샤드 안에서 조건에 맞는 행을 찾는 문제는 여전히 인덱스와 쿼리 실행 계획의 영향을 받아. 전체 테이블 스캔과 같은 문제는 샤딩 뒤에도 남을 수 있어.
샤드 수가 많다고 항상 빠르지 않아. 프록시와 샤드가 늘면 용량을 나눌 수 있지만, 프록시의 처리 한계·라우팅 비용·교차 샤드 조회가 함께 생겨.
높은 카디널리티만 보고 키를 고르면 안 돼. 데이터가 고르게 퍼져도 주요 조회가 그 키를 사용하지 않으면 여러 샤드를 조회하게 될 수 있어.
샤딩은 N+1 쿼리와 다른 문제야. N+1 쿼리와 애플리케이션 병목은 애플리케이션이 조회를 반복하는 패턴이고, 교차 샤드 조회는 한 요청을 여러 데이터베이스 서버가 나눠 처리하는 구조의 문제야. 한 요청에서 둘이 함께 나타날 수도 있어.

남은 질문들

트래픽이 계속 변하는 서비스에서 범위 샤딩의 경계를 어떻게 다시 나눌까?
여러 테이블을 같은 샤드 키로 묶는 기준은 조인과 데이터 생명주기에 따라 어떻게 달라질까?
온라인 재분할 중 읽기·쓰기를 안전하게 이어 가려면 어떤 검증과 되돌리기 경로가 필요할까?

PlanetScale, 「Database Sharding」(2025-01-09) 원문. ↩︎ ↩︎² ↩︎³ ↩︎⁴ ↩︎⁵ ↩︎⁶ ↩︎⁷ ↩︎⁸

🥚

Explorer

Recent Notes