469. 샤딩 (Sharding)과 파티셔닝

⚠️ 이 문서는 하나의 데이터베이스 서버(하드디스크)가 도저히 감당할 수 없을 만큼 데이터가 비대해졌을 때, 테이블을 빵 썰듯이 가로로 숭덩숭덩 썰어서 여러 대의 작은 서버에 나눠 담는 '샤딩(수평 분할)' 기술을 다룹니다.

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

본질: 커다란 테이블 하나를 똑같은 뼈대(스키마)를 가진 여러 개의 작은 테이블 조각(Shard)으로 쪼개서, 각각을 서로 다른 물리적 서버에 분산 저장하는 기술이다.

해결 과제: 데이터베이스의 용량 한계를 극복하고, 트래픽(읽기/쓰기)을 여러 대의 서버로 완벽하게 분산시키는 궁극의 스케일 아웃(Scale-out) 기법이다.

한계: 샤딩을 적용하는 순간 서로 다른 샤드(서버) 간의 조인(JOIN) 연산은 사실상 불가능해지며, 특정 샤드에만 트래픽이 몰리는 '핫스팟(Hotspot)' 문제를 막기 위해 샤딩 키(Sharding Key)를 예술적으로 설계해야 한다.

Ⅰ. 개요: 1억 명의 가입자 (Context & Necessity)

단일 MySQL 서버는 보통 데이터가 1,000만 건을 넘어가면 인덱스 크기가 RAM 용량을 초과하여 성능이 뚝 떨어진다. 1억 명이 넘어가면 디스크 용량조차 버티지 못한다.

스케일 업 (Scale-up): CPU와 RAM을 돈 주고 더 비싼 걸로 바꾼다. 한계가 명확하다.
스케일 아웃 (Scale-out): 싼값의 서버를 10대로 늘린다.

이 10대의 서버에 데이터를 어떻게 담을까? "회원 번호 끝자리가 0번인 사람은 0번 서버에, 1번인 사람은 1번 서버에 넣자!" 이렇게 규칙을 정해서 데이터를 물리적으로 찢어발기는 것이 바로 **샤딩(Sharding)**이다.

📢 섹션 요약 비유: 샤딩은 **'동사무소 민원 창구'**와 같습니다. 손님이 너무 많아서 창구 1개(단일 서버)로는 감당이 안 되니까, 창구를 10개로 늘리고 "생일이 1월인 분은 1번 창구로, 2월인 분은 2번 창구로 가세요"라고 분산시키는 것과 똑같습니다.

Ⅱ. 샤딩과 파티셔닝의 차이점

두 용어는 거의 똑같은 뜻(데이터 쪼개기)으로 쓰이지만, **'물리적 위치'**가 다르다.

파티셔닝 (Partitioning): 테이블을 논리적으로 쪼개지만, 결국 쪼개진 파일들은 같은 컴퓨터(하드디스크 1개) 안에 있다. (예: 2026년 데이터 파티션, 2027년 데이터 파티션)
샤딩 (Sharding): 파티셔닝의 특수한 형태(수평 분할)로, 쪼개진 조각(Shard)들을 **아예 서로 다른 컴퓨터(서버 A, 서버 B)**에 물리적으로 찢어놓는 것이다.

Ⅲ. 샤딩 키 (Sharding Key) 분배 전략 ★

"어떤 기준으로 데이터를 쪼갤 것인가?" 이 기준을 샤딩 키라고 부르며, 3가지 대표 방식이 있다.

1. 해시 샤딩 (Hash Sharding)

원리: 회원 ID를 해시 함수에 넣고 돌린 결괏값(나머지 연산)을 기준으로 서버를 배정한다. (예: User_ID % 3)
장점: 데이터가 3대의 서버에 가장 골고루, 예쁘게 분산된다. (핫스팟 발생 확률 0%)
단점: 나중에 서버 1대를 추가해서 4대로 만들면, 해시 함수가 % 4로 바뀌면서 기존 1억 명의 데이터를 전부 다 이사(재배치)시켜야 하는 대참사가 발생한다. (Consistent Hashing으로 완화 가능)

2. 레인지 샤딩 (Range Sharding)

원리: 데이터의 특정 범위(Range)를 기준으로 서버를 나눈다. (예: 1월~4월 가입자는 1번 서버, 5월~8월은 2번 서버)
장점: 특정 범위의 데이터를 한꺼번에 긁어올 때(범위 검색) 엄청 빠르다. 서버를 추가하기도 쉽다.
단점: 핫스팟(Hotspot) 문제. 만약 12월에 이벤트가 터져서 가입자가 폭주하면, 12월을 담당하는 3번 서버만 트래픽 폭탄을 맞고 터져버린다. (1번, 2번 서버는 놀고 있음)

3. 디렉토리 샤딩 (Directory / Lookup Sharding)

원리: 1번, 2번 방식처럼 기계적인 수학 공식이 아니라, "어떤 데이터가 어떤 서버에 있다"는 목록(디렉토리)을 중앙의 라우터가 직접 들고 있는 방식이다.

┌──────────────────────────────────────────────────────────────┐
│           해시 샤딩 (Hash Sharding) 작동 방식 및 분배 시각화            │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│ [ 👨‍💻 유저 가입 요청 ]                                          │
│   "ID: 1004"                                                 │
│                                                              │
│ ┌────────────────────────┐                                   │
│ │ 🧮 라우터 (해시 함수)    │   1004 % 3 (서버 개수) = 2            │
│ │ Hash(1004) = 2번 서버  │ ──▶ (2번 서버로 보내라!)              │
│ └────────────────────────┘                                   │
│         │                  │                  │              │
│         ▼                  ▼                  ▼              │
│  [ 📦 Shard 0 ]     [ 📦 Shard 1 ]     [ 📦 Shard 2 ]      │
│   (나머지 0인 애들)      (나머지 1인 애들)     (나머지 2인 애들)       │
│                                           * ID: 1004         │
│                                                              │
│ ★ 특징: 데이터가 무조건 수학적으로 골고루(1/N) 흩어지는 가장 공평한 방법이다.│
└──────────────────────────────────────────────────────────────┘

Ⅳ. 결론

"샤딩은 최후의 수단(Last Resort)이어야 한다." 많은 스타트업이 "우리는 1억 트래픽을 대비할 거니까 처음부터 MySQL 샤딩을 구축하자!"라고 허세를 부린다. 하지만 샤딩을 도입하는 순간 1번 샤드와 2번 샤드 간의 조인(JOIN) 쿼리는 불가능해지며, 2PC(462번 문서) 같은 복잡한 분산 트랜잭션 로직을 애플리케이션 단에 우겨넣어야 한다. 따라서 인덱스 튜닝, 쿼리 최적화, 캐싱(Redis), 스케일 업(하드웨어 교체), 마스터-슬레이브 복제(461번 문서) 등 할 수 있는 모든 최적화를 다 해보고도 정 안 될 때, 피눈물을 흘리며 도입해야 하는 가장 비싼 수술이 바로 샤딩이다.

📌 관련 개념 맵

관련 이론: 수평 분할 (Horizontal Fragmentation - 460번 문서)
대척점 아키텍처: Scale-up (수직적 확장 - 컴퓨터 성능을 높임)
발생하는 딜레마: CAP 이론 (463번 문서 - 분산 환경에서의 일관성 포기 문제)
해결 기술: Consistent Hashing (일관된 해싱 - 해시 샤딩에서 서버 증설 시 데이터 이동을 최소화하는 알고리즘)

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

1,000명의 아이들이 한 명의 산타 할아버지한테 선물을 달라고 편지를 보내면, 산타 할아버지가 편지를 읽다가 쓰러지시겠죠?
샤딩은 산타 할아버지를 10명으로 복제(?)한 다음, "1월생은 1번 산타에게, 2월생은 2번 산타에게 편지 보내!"라고 규칙을 정해주는 거예요.
이렇게 하면 1명의 산타는 100장의 편지만 읽으면 되니까, 전 세계 모든 어린이에게 아주 빠르게 선물을 줄 수 있답니다!