470. 해시 샤딩 (Hash Sharding)과 분산 해시 함수

⚠️ 이 문서는 1억 명의 가입자 데이터를 여러 대의 데이터베이스 서버로 쪼개어 저장(Sharding)할 때, 특정 서버에만 데이터가 몰려 터지는 현상(핫스팟)을 막기 위해 수학적인 해시(Hash) 함수를 써서 데이터를 가장 골고루 예쁘게 뿌려주는 '해시 샤딩' 기법을 다룹니다.

핵심 인사이트 (3줄 요약)

본질: 회원의 고유한 값(예: User_ID)을 해시 함수에 넣고 돌려서 나온 결괏값(나머지)을 기준으로 데이터를 저장할 서버 번호를 결정하는 알고리즘이다.

가치: 어떤 데이터가 들어오든 기계적인 확률에 의해 모든 서버에 데이터가 $1/N$로 완벽하게 균등 분배되므로, 트래픽이 특정 서버에 몰리는 병목 현상(Hotspot)을 원천 차단한다.

한계: 범위 검색(BETWEEN 1 AND 100)을 하면 데이터가 사방에 흩어져 있어서 모든 서버를 다 뒤져야 하며, 서버 대수가 늘어나거나 줄어들면(증설/축소) 기존 데이터를 싹 다 이사시켜야 하는 치명적 문제가 발생한다.

Ⅰ. 개요: 카드 나눠주기 (Context & Necessity)

"유저 데이터를 3대의 서버(Shard A, B, C)에 나눠서 저장해 줘!"

레인지 샤딩 (범위 기준): "가입 연도 기준으로, 2024년은 A, 2025년은 B, 2026년은 C에 넣어!"
- 결과: 2026년에 신규 가입자가 폭주하자 C 서버만 터져버렸다. (핫스팟 문제 발생)
해시 샤딩 (수학적 분산): "유저 ID를 3으로 나눈 나머지(Modulo)를 구해! 나머지가 0이면 A, 1이면 B, 2면 C에 넣어!"
- 결과: 1번 유저는 B, 2번은 C, 3번은 A, 4번은 B... 가입 연도와 상관없이 데이터가 A, B, C에 완벽하게 33.3%씩 나뉘어 들어갔다!

이처럼 해시 샤딩은 데이터의 의미(의도)를 무시하고 오직 수학적인 난수(해시값)에 의존하여 데이터를 흩뿌리는 가장 공평한 배분 방식이다.

📢 섹션 요약 비유: 해시 샤딩은 트럼프 카드를 친구들에게 나눠주는 **'카드 돌리기'**와 같습니다. 카드의 무늬가 스페이드든 하트든 상관하지 않고 "너 한 장, 쟤 한 장, 쟤 한 장..." 순서대로(수학적 규칙으로) 무작정 돌리기 때문에, 게임이 시작될 때 모두가 정확히 똑같은 장수의 카드를 들고 시작할 수 있습니다.

Ⅱ. 해시 샤딩의 2가지 핵심 개념 ★

1. 샤딩 키 (Sharding Key / Partition Key)

해시 믹서기에 집어넣을 **'재료(컬럼)'**를 말한다.
주로 값이 절대로 변하지 않고 골고루 분포된 컬럼을 쓴다. (예: User_ID, Email)
만약 값이 자주 변하는 컬럼(예: 등급)을 샤딩 키로 쓰면, 유저가 레벨업을 할 때마다 다른 서버로 데이터를 이사시켜야 하므로 시스템이 망가진다.

2. 해시 함수와 모듈러(Modulo) 연산

가장 기초적인 해시 함수는 Hash(Key) % 서버 대수 다.
서버가 4대일 때, ID가 105인 유저가 오면? $105 \div 4 = 26 \cdots \textbf{나머지 1}$.
따라서 이 유저는 '1번 서버(Shard 1)'에 영구적으로 저장된다.

Ⅲ. 치명적 단점: 서버를 증설할 때 벌어지는 지옥

해시 샤딩은 평소에는 완벽하지만, 회사가 잘돼서 서버를 늘릴 때 지옥의 문이 열린다.

현재 상태 (서버 3대):
- ID 10 유저: $10 \div 3 = \textbf{나머지 1}$ $\rightarrow$ 1번 서버에 저장됨.
서버 1대 추가 (총 4대):
- 사장님이 서버를 1대 추가했다. 이제 나누는 수(모듈러)가 4가 되었다!
- 아까 그 ID 10 유저를 찾으려고 쿼리를 날린다.
- 라우터: "$10 \div 4 = \textbf{나머지 2}$네? 2번 서버 가서 찾아봐!"
- 대참사: 2번 서버에는 데이터가 없다! 1번 서버에 있기 때문이다.

이 문제를 해결하려면, 서버 대수를 3에서 4로 바꾸는 순간 **기존 3대의 서버에 들어있던 1억 명의 데이터를 전부 다 꺼내서 새 공식(% 4)으로 다시 계산한 뒤 이사(재배치)**시켜야 한다. 이 과정(Re-sharding) 동안 쇼핑몰은 문을 닫아야 한다.

┌──────────────────────────────────────────────────────────────┐
│           해시 샤딩(Hash Sharding)의 Re-sharding(재배치) 대참사 시각화   │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│ [ 🚀 기존: 서버 3대 (모듈러 3) ]                                  │
│   ID 1 ──(나머지 1)──▶ [ 서버 1 ]                                │
│   ID 2 ──(나머지 2)──▶ [ 서버 2 ]                                │
│   ID 3 ──(나머지 0)──▶ [ 서버 0 ]                                │
│   ID 4 ──(나머지 1)──▶ [ 서버 1 ]                                │
│                                                              │
│ [ 💥 서버 증설: 서버 4대 (모듈러 4로 변경됨!) ]                      │
│   ID 1 ──(나머지 1)──▶ [ 서버 1 ] (가만히 있어도 됨 🟢)              │
│   ID 2 ──(나머지 2)──▶ [ 서버 2 ] (가만히 있어도 됨 🟢)              │
│   ID 3 ──(나머지 3)──▶ [ 서버 3 ] (서버 0에서 3으로 이사 가야 함! 🚨) │
│   ID 4 ──(나머지 0)──▶ [ 서버 0 ] (서버 1에서 0으로 이사 가야 함! 🚨) │
│                                                              │
│ ★ 특징: 나누는 숫자가 바뀌는 순간, 전체 데이터의 70~80%가 대이동을 시작한다!   │
└──────────────────────────────────────────────────────────────┘

Ⅳ. 결론

"완벽한 균형을 얻은 대가로, 유연성을 잃어버렸다." 해시 샤딩은 특정 서버가 터져나가는 핫스팟(Hotspot) 현상을 막는 가장 훌륭하고 수학적인 방법이다. 하지만 스타트업처럼 트래픽을 예측할 수 없어서 서버를 수시로 늘렸다 줄였다 해야 하는 환경에서 단순 모듈러(% N) 기반의 해시 샤딩을 채택하는 것은 자살 행위와 같다. 이 치명적인 리샤딩(Re-sharding) 문제를 극복하기 위해 천재 아키텍트들은 "서버가 늘어나도 이사하는 데이터를 최소화하자!"라는 아이디어로 **'일관된 해싱(Consistent Hashing - 471번 문서)'**이라는 궁극의 우회로를 발명해 내게 된다.

📌 관련 개념 맵

관련 아키텍처: 샤딩 (Sharding - 469번 문서)
대안 전략: Range Sharding (범위 샤딩 - 데이터 몰림 현상 주의), Directory Sharding
해결 기술: Consistent Hashing (컨시스턴트 해싱 - 서버 증설 시 데이터 대이동 방지)
주요 제약: 여러 샤드(서버)를 넘나드는 JOIN이나 범위 검색(BETWEEN)은 절대 불가능하다.

👶 어린이를 위한 3줄 비유 설명

해시 샤딩은 100명의 학생을 3개의 반으로 나눌 때, '번호표'를 3으로 나눠서 똑같이 33명씩 배정하는 방법이에요.
모두가 공평하게 나눠 가지니까, 어느 한 반만 학생이 넘쳐서(핫스팟) 선생님이 힘들어하는 일이 절대 없죠!
근데 갑자기 전학생이 많이 와서 '4반'을 새로 만들면 어떻게 될까요? 번호표 나누기 공식이 '4'로 바뀌면서, 기존 반에 있던 친구들 절반 이상이 가방을 싸고 다른 반으로 우르르 이사를 해야 하는 끔찍한 날이 온답니다!