Database Sharding & Partitioning

• **파티셔닝(Partitioning)**은 하나의 큰 테이블을 규칙에 따라 여러 개의 작은 물리적 조각(partition)으로 나누는 데이터베이스 기법
• **샤딩(Sharding)**은 파티셔닝의 특수한 형태로, 나눈 조각(shard)을 서로 다른 물리적 서버에 분산 저장하는 수평 확장(horizontal scaling) 기법
• 핵심 차이: 파티셔닝은 한 서버 안에서 테이블을 쪼개는 것, 샤딩은 여러 서버에 걸쳐 데이터를 쪼개는 것

해당 개념이 필요한 이유

한 대로 버티는 전략의 물리적 한계

API 응답이 느려지면 가장 먼저 떠오르는 해결책은 Vertical Scaling — 서버의 CPU, RAM, 디스크를 업그레이드하는 것이다. 실제로 대부분의 서비스는 이 방법으로 충분히 오래 버틴다. 하지만 이 전략에는 천장이 있다.

서버 1대의 물리적 한계:
- RAM: 최대 수 TB (비용 급증)
- 디스크 I/O: SSD도 초당 처리량에 상한선 존재
- CPU: 코어 수 늘려도 DB 쿼리는 병렬화에 한계
- 비용: 2배 성능 ≠ 2배 가격, 기하급수적으로 비싸짐

예를 들어, users 테이블이 1억 건이고 SELECT * FROM users WHERE name = '홍길동'을 실행한다고 하자. 인덱스가 있어도 1억 건의 인덱스 트리를 탐색해야 한다. 이 테이블을 월별 12개 파티션으로 나누면, WHERE created_at = '2025-01' 조건이 함께 있을 때 833만 건만 탐색하면 된다. 서버를 바꾸지 않고도 12배 빨라지는 셈이다.

한 대로 못 버티는 순간이 오는 이유

문제는 데이터가 선형으로 계속 증가한다는 점이다. 오늘 1억 건으로 충분한 서버가 내년에는 3억 건을 감당해야 한다. 서버 업그레이드 비용은 기하급수적으로 증가하지만, 샤딩은 저렴한 서버를 추가하는 것으로 거의 선형적으로 확장할 수 있다.

flowchart LR
    subgraph Vertical["Vertical Scaling (한 대 강화)"]
        direction TB
        V1["1억 건: 월 100만 원"] --> V2["3억 건: 월 500만 원"]
        V2 --> V3["10억 건: 월 3,000만 원"]
        V3 --> V4["30억 건: ???<br/>물리적 한계"]
    end

    subgraph Horizontal["Horizontal Scaling (샤딩)"]
        direction TB
        H1["1억 건: 서버 1대<br/>월 100만 원"] --> H2["3억 건: 서버 3대<br/>월 300만 원"]
        H2 --> H3["10억 건: 서버 10대<br/>월 1,000만 원"]
        H3 --> H4["30억 건: 서버 30대<br/>월 3,000만 원"]
    end

성능 말고도 한 대가 위험한 이유

서버가 한 대면, 그 한 대가 죽으면 서비스 전체가 멈춘다. 샤딩된 환경에서는 Shard 2가 죽어도 Shard 1, 3의 유저는 정상적으로 서비스를 이용할 수 있다. 클라이언트 앱에서 “일부 기능이 일시적으로 제한됩니다”라는 부분 장애 처리가 가능해지는 것이다.

정리: 단계적 접근

대부분의 서비스는 이 순서로 진행된다:

1. 인덱스 최적화 → 쿼리 자체를 빠르게 (가장 먼저, 가장 저렴)
2. Vertical Scaling → 서버 스펙 업그레이드 (간단하지만 비용 증가)
3. 파티셔닝 → 한 서버 안에서 테이블 분할 (운영 복잡도 낮음)
4. Replication → 읽기 전용 복제본으로 읽기 부하 분산
5. 샤딩 → 여러 서버에 데이터 분산 (최후의 수단, 운영 복잡도 높음)

샤딩이 최후의 수단인 이유는, 한번 도입하면 cross-shard JOIN, 분산 트랜잭션, 데이터 재배치 등 운영 복잡도가 급격히 증가하기 때문이다. “할 수 있는 한 안 하는 게 최선이지만, 해야 할 때는 반드시 해야 하는” 기술이다.

AS-IS

flowchart TD
    Client[클라이언트 앱] --> API[API 서버]
    API --> DB[(단일 DB 서버<br/>users 테이블: 1억 건)]

    style DB fill:#ffcccc

    DB --> Problem["문제:<br/>- SELECT 쿼리 수 초 소요<br/>- 디스크 I/O 포화<br/>- 백업에 몇 시간<br/>- 서버 한 대가 죽으면 전체 장애"]

TO-BE (파티셔닝)

flowchart TD
    Client[클라이언트 앱] --> API[API 서버]
    API --> DB[(DB 서버 1대)]

    DB --> P1[users_2024<br/>3천만 건]
    DB --> P2[users_2025<br/>4천만 건]
    DB --> P3[users_2026<br/>3천만 건]

    style DB fill:#ccffcc

    Note["한 서버 안에서 테이블만 분할<br/>→ 쿼리 시 필요한 파티션만 스캔"]

TO-BE (샤딩)

flowchart TD
    Client[클라이언트 앱] --> API[API 서버 / Router]

    API --> S1[(Shard 1<br/>서버 A<br/>user_id 1~33M)]
    API --> S2[(Shard 2<br/>서버 B<br/>user_id 33M~66M)]
    API --> S3[(Shard 3<br/>서버 C<br/>user_id 66M~100M)]

    style S1 fill:#cce5ff
    style S2 fill:#cce5ff
    style S3 fill:#cce5ff

    Note["여러 서버에 데이터 분산<br/>→ 읽기/쓰기 부하를 나눔"]

파티셔닝 vs 샤딩: 핵심 비교

구분	파티셔닝 (Partitioning)	샤딩 (Sharding)
데이터 위치	한 서버 안에서 테이블 분할	여러 서버에 데이터 분산
목적	쿼리 성능 향상, 관리 편의	수평 확장(horizontal scaling)
복잡도	상대적으로 낮음 (DB가 알아서 라우팅)	높음 (라우터, 샤드 키 관리 필요)
장애 영향	서버 1대 죽으면 전체 영향	일부 샤드만 영향 (나머지 정상)
JOIN	파티션 간 JOIN 자유로움	샤드 간 JOIN 매우 어렵거나 불가
확장 한계	서버 1대의 물리적 한계	서버 추가로 거의 무한 확장

파티셔닝 3가지 방법

1. Range Partitioning (범위 기반)

특정 컬럼의 값 범위로 나눈다. 시계열 데이터에 가장 적합.

-- 날짜 범위로 파티셔닝
CREATE TABLE orders (
    order_id    int,
    order_date  date,
    amount      int
) PARTITION BY RANGE (order_date);
 
-- 2025년 1월 파티션
CREATE TABLE orders_2025_01 PARTITION OF orders
    FOR VALUES FROM ('2025-01-01') TO ('2025-02-01');
 
-- 2025년 2월 파티션
CREATE TABLE orders_2025_02 PARTITION OF orders
    FOR VALUES FROM ('2025-02-01') TO ('2025-03-01');

클라이언트 관점에서 보면: SELECT * FROM orders WHERE order_date = '2025-01-15' 쿼리를 보내면, DB가 자동으로 orders_2025_01 파티션만 스캔한다. 나머지 11개월치 데이터는 아예 보지 않는다. 이것을 Partition Pruning이라 한다.

2. List Partitioning (목록 기반)

특정 컬럼의 값 목록으로 나눈다. 지역, 카테고리 등 이산적인 값에 적합.

CREATE TABLE users (
    user_id  int,
    country  text,
    name     text
) PARTITION BY LIST (country);
 
CREATE TABLE users_kr PARTITION OF users
    FOR VALUES IN ('KR');
CREATE TABLE users_us PARTITION OF users
    FOR VALUES IN ('US');
CREATE TABLE users_jp PARTITION OF users
    FOR VALUES IN ('JP');

3. Hash Partitioning (해시 기반)

컬럼 값에 해시 함수를 적용하여 균등하게 분배한다. 범위나 목록으로 나누기 어려울 때 사용.

CREATE TABLE sessions (
    session_id  int,
    user_id     int,
    data        text
) PARTITION BY HASH (user_id);
 
-- 4개로 균등 분할 (modulus 4, remainder 0~3)
CREATE TABLE sessions_p0 PARTITION OF sessions
    FOR VALUES WITH (MODULUS 4, REMAINDER 0);
CREATE TABLE sessions_p1 PARTITION OF sessions
    FOR VALUES WITH (MODULUS 4, REMAINDER 1);
CREATE TABLE sessions_p2 PARTITION OF sessions
    FOR VALUES WITH (MODULUS 4, REMAINDER 2);
CREATE TABLE sessions_p3 PARTITION OF sessions
    FOR VALUES WITH (MODULUS 4, REMAINDER 3);

샤딩 3가지 방법

1. Range-Based Sharding (범위 기반)

파티셔닝의 Range와 같은 원리이지만, 각 범위가 다른 서버에 저장된다.

Shard 1 (서버 A): user_id 1 ~ 1,000,000
Shard 2 (서버 B): user_id 1,000,001 ~ 2,000,000
Shard 3 (서버 C): user_id 2,000,001 ~ 3,000,000

단점: 신규 가입자가 계속 Shard 3에만 몰리는 핫스팟(hotspot) 문제 발생 가능.

2. Hash-Based Sharding (해시 기반)

Shard Key에 해시 함수를 적용하여 어느 서버에 저장할지 결정한다.

shard_number = hash(user_id) % 서버_수

예: hash(12345) % 3 = 1  → Shard 2 (서버 B)
    hash(67890) % 3 = 0  → Shard 1 (서버 A)

장점: 데이터가 균등하게 분산됨. 단점: 서버를 추가할 때(리샤딩) 대부분의 데이터 재배치 필요.

3. Directory-Based Sharding (디렉토리 기반)

별도의 lookup table로 “이 데이터는 어느 서버에?”를 관리한다.

Lookup Table:
┌──────────┬─────────┐
│ user_id  │ shard   │
├──────────┼─────────┤
│ 12345    │ Shard 1 │
│ 67890    │ Shard 2 │
│ ...      │ ...     │
└──────────┴─────────┘

가장 유연하지만, lookup table 자체가 단일 장애 지점(SPOF)이 될 수 있다.

Shard Key 선택이 중요한 이유

Shard Key는 “어떤 기준으로 데이터를 서버에 나눌 것인가”를 결정하는 컬럼이다. 잘못 고르면 특정 서버에 부하가 몰리는 핫스팟이 발생한다.

좋은 Shard Key의 조건 3가지:

조건	의미	나쁜 예
높은 Cardinality	가능한 값의 종류가 많아야 함	gender (M/F 두 가지뿐)
균등한 Frequency	각 값의 출현 빈도가 비슷해야 함	country (한국 유저 90%면 한 샤드에 몰림)
비단조적 변화	시간에 따라 한 방향으로 증가하면 안 됨	created_at (최신 샤드만 뜨거워짐)

클라이언트 개발자가 체감하는 영향

샤딩된 DB를 사용하는 서비스의 API를 호출할 때, 클라이언트 쪽에서 알아야 할 점:

1. 정렬/페이지네이션이 느려질 수 있음

클라이언트: GET /users?sort=created_at&page=3

→ 서버는 모든 샤드에서 데이터를 가져와서 합친 후 정렬해야 함
→ 단일 DB보다 응답이 느릴 수 있음

2. Cross-Shard 조회의 제약

클라이언트: GET /users/123/friends (user 123의 친구 목록)

→ user 123은 Shard 1에 있지만
→ 친구들은 Shard 1, 2, 3에 흩어져 있음
→ 여러 샤드를 동시에 조회해야 함 (fan-out query)
→ 응답 지연 가능

3. 일관성(Consistency) 이슈

클라이언트: POST /transfer (A → B 송금)

→ A의 잔액은 Shard 1, B의 잔액은 Shard 2
→ 두 서버에 걸친 트랜잭션이 필요 (분산 트랜잭션)
→ 실패 시 부분만 반영될 수 있음
→ 클라이언트는 "처리 중" 상태를 다룰 준비 필요

4. 특정 API만 느린 이유

GET /user/123          → Shard Key로 바로 찾음 → 빠름 (ms)
GET /users?name=홍길동  → 모든 샤드 스캔 필요 → 느림 (초)

Shard Key가 아닌 컬럼으로 검색하면, 모든 샤드를 다 뒤져야 하기 때문에 Scatter-Gather 패턴이 되어 느려진다.

언제 파티셔닝? 언제 샤딩?

flowchart TD
    A{테이블이 너무 큰가?} -->|Yes| B{한 서버로 감당 가능?}
    A -->|No| Z[현재 구조 유지]
    B -->|Yes| C[파티셔닝으로 충분]
    B -->|No| D{읽기/쓰기 부하<br/>분산이 필요한가?}
    D -->|Yes| E[샤딩 도입]
    D -->|No| F[Replication으로<br/>읽기 분산]

일반적으로 파티셔닝을 먼저 적용하고, 그래도 한계에 도달하면 샤딩으로 확장한다. 샤딩은 운영 복잡도가 크게 증가하므로 최후의 수단에 가깝다.

참고 문서

• PostgreSQL - Table Partitioning
• MongoDB - Database Sharding Explained
• AWS - What is Database Sharding?