536. 샤드 키 불균형과 핫스팟 (Hotspot) 현상

⚠️ 이 문서는 데이터베이스 서버 100대를 사놓고 완벽하게 분산 저장을 했다고 믿었지만, 샤딩의 기준점(샤드 키)을 잘못 잡는 바람에 99대의 서버는 놀고 있고 오직 1대의 서버에만 트래픽이 집중되어 서버가 불타버리는 '핫스팟 현상'과 이를 대처하는 기술을 다룹니다.

(※ 469번(샤딩 기본), 470번(해시 샤딩) 문서의 심화 내용입니다.)

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

  1. 본질: 샤드 키(Sharding Key)는 데이터를 여러 대의 서버에 쪼개어 담기 위한 기준 컬럼이다. 이 기준을 잘못 잡으면 특정 서버(샤드)에만 데이터와 트래픽이 몰리게 된다.
  2. 핫스팟 (Hotspot): 특정 샤드가 감당할 수 있는 트래픽의 한계를 넘어서서 병목이 발생하는 현상이다. "가입 연월" 같은 순차적인 키를 썼을 때 최근 서버에만 몰리는 현상이 대표적이다.
  3. 해결책: 데이터가 가장 다양하게 퍼질 수 있는 카디널리티(분포도)가 높은 컬럼을 샤드 키로 고르거나, 2개의 컬럼을 묶은 '복합 샤드 키'를 사용해 핫스팟을 분산시켜야 한다.

Ⅰ. 개요: 99대는 놀고, 1대만 죽어간다 (Context & Necessity)

당신은 유명 아이돌 굿즈 쇼핑몰의 DBA다. 트래픽을 분산시키기 위해 MySQL 서버 4대를 사서 샤딩을 구축했다.

  • 샤드 키: 거주_지역
  • 샤드 1: 서울/경기
  • 샤드 2: 강원/충청
  • 샤드 3: 전라/경상
  • 샤드 4: 제주/기타

방탄소년단 굿즈가 오픈되었다. 10만 명의 팬이 몰려왔다.

  • 결과: 대한민국 인구의 50%가 몰려있는 '서울/경기' 지역 유저들이 접속을 시도하면서 샤드 1번 서버가 다운되었다.
  • 반면 제주도를 담당하는 샤드 4번 서버의 CPU는 1%도 돌지 않고 놀고 있었다.

이처럼 샤딩을 했음에도 불구하고 트래픽이 한 곳으로 집중되어 버리는 끔찍한 현상을 **핫스팟(Hotspot)**이라고 부른다.

📢 섹션 요약 비유: 핫스팟 현상은 **'마트의 불공평한 계산대'**와 같습니다. 계산대 4개를 열었는데 "1번은 젊은이, 2번은 어르신..." 이렇게 기준(샤드 키)을 잘못 세우면, 마트에 놀러 온 젊은이들은 1번 계산대에 100m 줄을 서서 땀을 흘리고, 2번 계산대 직원은 유튜브를 보며 노는 대참사가 발생합니다.

Ⅱ. 핫스팟을 유발하는 최악의 샤드 키 3가지 ★

샤딩을 구축할 때 절대 고르면 안 되는 샤드 키의 특징들이다.

1. 순차적으로 증가하는 키 (Monotonically Increasing)

  • 예시: 가입일, Auto Increment ID
  • 문제점: 이 키로 레인지 샤딩(Range Sharding)을 하면, "어제 가입한 사람", "오늘 가입한 사람" 등 최신 트래픽이 무조건 맨 마지막에 만들어둔 최신 샤드 서버 하나에만 100% 몰린다.

2. 카디널리티(Cardinality)가 너무 낮은 키

  • 예시: 성별 (남/여), 국적
  • 문제점: 데이터의 종류가 2개밖에 없으면, 내가 아무리 서버를 100대 사 와도 결국 데이터를 2개의 서버에밖에 나누어 담을 수가 없다.

3. 슈퍼스타(Superstar)가 존재하는 키

  • 예시: 연예인_ID (인스타그램 같은 곳에서)
  • 문제점: 해시 샤딩(Hash Sharding)을 써서 예쁘게 골고루 분배했다고 치자. 그런데 하필 '유재석'의 ID가 1번 서버에 배정되었다. 유재석이 사진을 올리는 순간, 1번 서버는 수천만 명의 접속자를 혼자 감당해야 해서 터져버린다. (해시 샤딩조차 핫스팟을 완벽하게 막을 수 없는 이유다.)

Ⅲ. 실무 팁: 핫스팟 해결 전략

아키텍트들은 이 문제를 풀기 위해 머리를 쥐어짠다.

  1. 복합 샤드 키 (Composite Shard Key)
    • "지역 하나만 쓰니까 서울에 몰리네?"
    • 해결: [거주_지역 + 회원_ID] 두 개를 합쳐서 샤드 키를 만든다. 그러면 서울 유저들도 회원 ID의 해시값에 따라 1, 2, 3, 4번 서버로 골고루 찢어지게 된다.
  2. 랜덤 접두사 (Random Prefix) 추가
    • 순차적으로 증가하는 가입일 키를 꼭 써야 한다면, 앞에다가 1~100 사이의 무작위 난수를 붙여버린다.
    • 예: 2026-04-10 $\rightarrow$ 87_2026-04-10
    • 이렇게 하면 같은 날 가입한 사람이라도 87번, 12번, 3번 서버로 골고루 흩어진다. (대신 나중에 특정 날짜를 검색할 때 100대의 서버를 다 뒤져야 하는 Scatter-Gather 쿼리가 발생하므로 주의해야 한다.)
┌──────────────────────────────────────────────────────────────┐
│           순차적 샤드 키로 인한 핫스팟(Hotspot) 발생 시각화               │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│ [ 🔑 샤드 키: "가입_연월" (Range Sharding) ]                      │
│                                                              │
│  [ 📦 Shard 1 ]      [ 📦 Shard 2 ]      [ 📦 Shard 3 ]      │
│  (1월~4월 가입자)      (5월~8월 가입자)      (9월~12월 가입자)     │
│                                                              │
│   (지금은 11월)                                 🔥🔥🔥🔥🔥      │
│     💤💤               💤💤           [ 👨‍💻 신규 유저 10만 명 몰림 ]│
│   (아무도 없음)           (아무도 없음)           (서버 터짐!)           │
│                                                              │
│ ★ 원인: 최신 트래픽은 항상 최신 날짜에 몰리므로 앞의 두 서버는 놀게 된다.      │
└──────────────────────────────────────────────────────────────┘

Ⅳ. 결론

"샤딩은 기술의 문제가 아니라, 비즈니스 이해의 문제다." 샤드 키를 잘못 고르는 것은 데이터베이스 아키텍처에서 저지를 수 있는 가장 치명적이고 돌이킬 수 없는 실수다. 인덱스는 잘못 만들면 지우고 다시 만들면(DROP INDEX) 그만이지만, 샤드 키를 잘못 잡아서 서버가 한쪽으로 기울어지면 기존 1억 명의 데이터를 다시 다른 서버로 이사(Re-sharding)시키는 동안 수일간의 서비스 다운타임을 각오해야 한다. 따라서 아키텍트는 우리 회사의 트래픽이 '누구를 중심으로', '어느 시간대에', '어떤 패턴으로' 발생하는지 비즈니스의 본질을 100% 꿰뚫고 있어야만 완벽한 샤드 키를 찾아낼 수 있다.

📌 관련 개념 맵

  • 기반 기술: Sharding (샤딩 - 469번 문서), Partitioning
  • 분배 알고리즘: Hash Sharding (470번 문서), Range Sharding, Directory Sharding
  • 관련 지표: Cardinality (카디널리티 - 값의 다양성 정도)
  • 해결 기술: Consistent Hashing (일관된 해싱 - 471번 문서)

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

  1. 핫스팟은 선생님이 반 친구들 30명에게 "청소할 구역을 정해줄게!"라고 하는 상황이에요.
  2. 만약 "안경 쓴 사람은 화장실 청소, 안 쓴 사람은 교실 청소!"라고 했는데 우리 반 29명이 안경을 안 썼다면? 교실 청소하는 친구들만 죽어나는 거죠 (핫스팟 발생).
  3. 이걸 막기 위해 선생님은 "출석 번호 홀수는 화장실, 짝수는 교실!"처럼 무조건 절반으로 딱 떨어지는 공평한 기준(좋은 샤드 키)을 찾아내야 한답니다!