🚀 들어가며 — 데이터가 너무 많아서 DB가 터질 것 같아요

요즘 서비스 운영하다 보면 진짜 데이터가 장난 아니게 쌓이잖아요?
유저 로그, 주문 내역, 클릭 이벤트, 채팅 메시지... 하루에도 수백만 건씩 쌓이는데
처음엔 그냥 MySQL 하나로 버티다가 어느 순간 쿼리가 30초씩 걸리기 시작하면 😱
그때부터 진짜 공부 시작하게 되는 거 알죠?ㅋㅋㅋ

그 공부의 첫 번째 관문이 바로 파티셔닝(Partitioning)과 샤딩(Sharding)이에요.
이 두 개념, 비슷해 보이지만 완전히 다른 레벨의 이야기거든요.
오늘 이 글에서 진짜 제대로, 팩트 위주로 싹 정리해드릴게요. 레츠고~ 🔥

📦 파티셔닝(Partitioning)이란? — 하나의 테이블을 조각조각

파티셔닝은 하나의 DB 서버 안에서 거대한 테이블을 여러 개의 작은 조각(파티션)으로 나누는 기술이에요.
물리적으로는 분리되어 있지만, 논리적으로는 여전히 하나의 테이블처럼 보이는 게 핵심이에요!
쉽게 말하면 서랍장 하나에 칸막이 쳐서 정리하는 느낌? 🗂️

파티셔닝의 주요 목적

파티셔닝을 쓰는 이유는 크게 세 가지예요:

① 쿼리 성능 향상
수억 건의 데이터가 있는 테이블에서 WHERE 조건으로 특정 범위만 조회할 때,
파티셔닝이 되어 있으면 해당 파티션만 스캔하면 되니까 훨씬 빠름!
이걸 파티션 프루닝(Partition Pruning)이라고 해요.

② 관리 편의성
오래된 데이터 삭제할 때 파티션 단위로 DROP하면 DELETE 쿼리보다 훨씬 빠르고 효율적이에요.
예를 들어 3년 전 로그 데이터 파티션 통째로 날리기 ✂️

③ 가용성 향상
특정 파티션에 문제가 생겨도 다른 파티션은 정상 동작할 수 있어요.

파티셔닝의 종류 4가지

-- MySQL 예시
CREATE TABLE orders (
    order_id INT,
    order_date DATE,
    amount DECIMAL(10,2)
)
PARTITION BY RANGE (YEAR(order_date)) (
    PARTITION p2022 VALUES LESS THAN (2023),
    PARTITION p2023 VALUES LESS THAN (2024),
    PARTITION p2024 VALUES LESS THAN (2025),
    PARTITION p_future VALUES LESS THAN MAXVALUE
);

-- MySQL 예시
CREATE TABLE sales (
    sale_id INT,
    region VARCHAR(20),
    amount DECIMAL(10,2)
)
PARTITION BY LIST COLUMNS(region) (
    PARTITION p_seoul VALUES IN ('서울', '경기'),
    PARTITION p_busan VALUES IN ('부산', '경남'),
    PARTITION p_other VALUES IN ('대구', '인천', '광주')
);

-- MySQL 예시
CREATE TABLE user_logs (
    log_id INT,
    user_id INT,
    action VARCHAR(50)
)
PARTITION BY HASH(user_id)
PARTITIONS 8;

-- MySQL 예시
CREATE TABLE sessions (
    session_id VARCHAR(64),
    user_id INT,
    created_at DATETIME,
    PRIMARY KEY (session_id)
)
PARTITION BY KEY(session_id)
PARTITIONS 4;

🌐 샤딩(Sharding)이란? — 서버를 여러 대로 늘려버리기

샤딩은 파티셔닝보다 훨씬 큰 스케일의 이야기예요.
여러 대의 DB 서버에 데이터를 분산해서 저장하는 방식이에요.
각각의 서버를 샤드(Shard)라고 부르고, 각 샤드는 전체 데이터의 일부만 가지고 있어요.
이건 서랍장 하나에 칸막이 치는 게 아니라, 서랍장 자체를 여러 개 사는 거임ㅋㅋㅋ 🗄️🗄️🗄️

샤딩은 수평 확장(Horizontal Scaling)의 핵심 전략이에요.
서버 한 대의 성능을 올리는 수직 확장(Scale-Up)은 한계가 있잖아요?
그래서 서버를 여러 대 추가해서 부하를 나누는 게 샤딩의 핵심 철학이에요!

샤딩의 주요 방식

⚖️ 파티셔닝 vs 샤딩 — 핵심 차이점 완전 정리

자 이제 두 개념을 나란히 놓고 비교해볼게요.
이 표 하나면 면접에서도 자신 있게 설명할 수 있음ㅋㅋㅋ 💪

🏗️ 수직 파티셔닝 vs 수평 파티셔닝 — 파티셔닝도 종류가 있어요

파티셔닝 안에서도 또 나뉘어요. 이거 모르면 반쪽짜리 지식임ㅋㅋ
수직 파티셔닝과 수평 파티셔닝으로 나뉘는데, 완전히 다른 개념이에요!

수평 파티셔닝 (Horizontal Partitioning)

행(Row) 단위로 데이터를 나누는 방식이에요.
같은 컬럼 구조를 유지하면서 데이터를 여러 파티션에 분산해요.
우리가 앞에서 배운 범위, 리스트, 해시 파티셔닝이 모두 수평 파티셔닝이에요!

수직 파티셔닝 (Vertical Partitioning)

열(Column) 단위로 데이터를 나누는 방식이에요.
자주 쓰는 컬럼과 잘 안 쓰는 컬럼을 분리해서 성능을 높여요.
이건 사실 정규화(Normalization)와 개념이 겹치기도 해요!

🔧 실제 DB별 파티셔닝/샤딩 구현 방법

이론만 알면 뭐해요, 실제로 어떻게 쓰는지 알아야죠!
주요 DB별로 파티셔닝과 샤딩 구현 방법을 살펴볼게요 🛠️

MySQL — 파티셔닝

MySQL 5.1부터 파티셔닝을 지원해요. 가장 많이 쓰이는 방식이에요!

-- 기존 테이블에 파티셔닝 추가
ALTER TABLE user_activities
PARTITION BY RANGE (UNIX_TIMESTAMP(created_at)) (
    PARTITION p202301 VALUES LESS THAN (UNIX_TIMESTAMP('2023-02-01')),
    PARTITION p202302 VALUES LESS THAN (UNIX_TIMESTAMP('2023-03-01')),
    PARTITION p202303 VALUES LESS THAN (UNIX_TIMESTAMP('2023-04-01')),
    PARTITION p_future VALUES LESS THAN MAXVALUE
);

-- 파티션 정보 확인
SELECT PARTITION_NAME, TABLE_ROWS
FROM INFORMATION_SCHEMA.PARTITIONS
WHERE TABLE_NAME = 'user_activities';

-- 오래된 파티션 삭제 (초고속!)
ALTER TABLE user_activities DROP PARTITION p202301;

-- 새 파티션 추가
ALTER TABLE user_activities
REORGANIZE PARTITION p_future INTO (
    PARTITION p202304 VALUES LESS THAN (UNIX_TIMESTAMP('2023-05-01')),
    PARTITION p_future VALUES LESS THAN MAXVALUE
);

PostgreSQL — 파티셔닝

PostgreSQL 10부터 선언적 파티셔닝(Declarative Partitioning)을 지원해요.
MySQL보다 더 유연하고 강력한 파티셔닝 기능을 제공해요!

-- 부모 테이블 생성 (파티션 테이블)
CREATE TABLE orders (
    order_id BIGSERIAL,
    customer_id INT,
    order_date DATE NOT NULL,
    amount DECIMAL(12,2)
) PARTITION BY RANGE (order_date);

-- 자식 파티션 생성
CREATE TABLE orders_2023_q1
    PARTITION OF orders
    FOR VALUES FROM ('2023-01-01') TO ('2023-04-01');

CREATE TABLE orders_2023_q2
    PARTITION OF orders
    FOR VALUES FROM ('2023-04-01') TO ('2023-07-01');

CREATE TABLE orders_2023_q3
    PARTITION OF orders
    FOR VALUES FROM ('2023-07-01') TO ('2023-10-01');

CREATE TABLE orders_2023_q4
    PARTITION OF orders
    FOR VALUES FROM ('2023-10-01') TO ('2024-01-01');

-- 인덱스는 각 파티션에 자동 적용됨
CREATE INDEX ON orders (order_date);

-- 쿼리 실행 시 파티션 프루닝 자동 적용
EXPLAIN SELECT * FROM orders
WHERE order_date BETWEEN '2023-04-01' AND '2023-06-30';

MongoDB — 샤딩

MongoDB는 샤딩을 기본 기능으로 지원해요.
mongos(샤드 라우터), Config Server, Shard로 구성돼요!

// mongos에서 샤딩 설정
// 1. 샤딩 활성화
sh.enableSharding("myDatabase")

// 2. 컬렉션에 샤딩 적용 (해시 기반)
sh.shardCollection(
    "myDatabase.users",
    { "user_id": "hashed" }
)

// 3. 범위 기반 샤딩
sh.shardCollection(
    "myDatabase.orders",
    { "order_date": 1 }
)

// 4. 샤드 상태 확인
sh.status()

// 5. 청크 분포 확인
db.adminCommand({ listShards: 1 })

Vitess — MySQL 샤딩 솔루션

Vitess는 YouTube가 개발한 MySQL 샤딩 미들웨어예요.
현재 CNCF(Cloud Native Computing Foundation) 프로젝트로 운영 중이에요.
Slack, Pinterest, GitHub 등 대형 서비스에서 사용 중이에요!

-- Vitess VSchema 설정 예시
{
  "sharded": true,
  "vindexes": {
    "hash": {
      "type": "hash"
    }
  },
  "tables": {
    "users": {
      "column_vindexes": [
        {
          "column": "user_id",
          "name": "hash"
        }
      ]
    }
  }
}

-- 애플리케이션은 일반 MySQL 쿼리 그대로 사용
-- Vitess가 알아서 적절한 샤드로 라우팅해줌!
SELECT * FROM users WHERE user_id = 12345;

🌟 실제 서비스 사례 — 대형 서비스들은 어떻게 했을까?

이론 공부도 좋지만, 실제 사례를 보면 훨씬 와닿잖아요?
유명한 서비스들이 어떻게 파티셔닝/샤딩을 활용했는지 살펴볼게요 👀

📸 Instagram — 샤딩으로 수십억 사진 처리

Instagram은 초기에 PostgreSQL을 사용했는데, 사용자가 폭발적으로 늘면서 샤딩이 필요해졌어요.
그들이 선택한 방식은 논리적 샤딩(Logical Sharding)이에요.

핵심 아이디어: 샤드 ID를 ID 자체에 인코딩하는 방식!
Instagram의 ID는 64비트로 구성되어 있어요:

💬 Discord — 수조 건의 메시지 처리

Discord는 처음에 MongoDB를 썼다가 Cassandra로 마이그레이션했어요.
그 후 ScyllaDB로 또 마이그레이션... 데이터 규모가 커지면서 계속 진화한 거예요.

Discord의 메시지 데이터는 channel_id + message_id를 복합 파티션 키로 사용해요.
같은 채널의 메시지는 같은 파티션에 저장되어 빠른 조회가 가능하고,
채널별로 데이터가 분산되어 부하도 균등하게 나눠져요.

🛒 Shopify — Vitess로 MySQL 샤딩

Shopify는 수백만 개의 쇼핑몰을 운영하는 플랫폼이에요.
각 쇼핑몰(Shop)을 기준으로 샤딩을 구현했어요.

Shopify의 샤딩 전략: Shop ID 기반 샤딩
같은 쇼핑몰의 모든 데이터(주문, 상품, 고객)는 같은 샤드에 저장돼요.
이렇게 하면 쇼핑몰 내부 쿼리에서 크로스-샤드 조인이 발생하지 않아요!

🎵 Spotify — 파티셔닝으로 재생 기록 관리

Spotify는 수억 명의 사용자 재생 기록을 관리해야 해요.
날짜 기반 범위 파티셔닝을 사용해서 오래된 데이터를 효율적으로 관리해요.
최근 데이터는 자주 조회되고, 오래된 데이터는 아카이빙하는 패턴에 딱 맞는 전략이에요!

⚡ 샤딩의 핵심 문제들 — 이것만 알면 실무에서 안 당함

샤딩이 만능처럼 보이지만, 실제로 도입하면 골치 아픈 문제들이 한가득이에요.
미리 알고 대비하면 훨씬 덜 고생할 수 있어요! 😤

🔥 문제 1: 핫스팟(Hotspot) 문제

특정 샤드에 트래픽이 몰리는 현상이에요.
범위 기반 샤딩에서 자주 발생해요.

🔄 문제 2: 리샤딩(Resharding) 문제

샤드 수를 변경해야 할 때 발생하는 문제예요.
해시 기반 샤딩에서 특히 심각해요.

// 일관된 해싱(Consistent Hashing) 개념 코드
// 가상 노드(Virtual Node)를 사용해서 균등 분산

class ConsistentHash {
    constructor(replicas = 150) {
        this.replicas = replicas;  // 가상 노드 수
        this.ring = new Map();     // 해시 링
        this.sortedKeys = [];
    }

    addNode(node) {
        for (let i = 0; i < this.replicas; i++) {
            const hash = this.hash(`${node}:${i}`);
            this.ring.set(hash, node);
            this.sortedKeys.push(hash);
        }
        this.sortedKeys.sort((a, b) => a - b);
    }

    getNode(key) {
        const hash = this.hash(key);
        // 해시 링에서 시계 방향으로 가장 가까운 노드 찾기
        for (const k of this.sortedKeys) {
            if (hash <= k) return this.ring.get(k);
        }
        return this.ring.get(this.sortedKeys[0]);
    }

    hash(key) {
        // 실제로는 MD5, SHA-1 등 사용
        let h = 0;
        for (let c of key) h = (h * 31 + c.charCodeAt(0)) & 0xFFFFFFFF;
        return h;
    }
}

const ch = new ConsistentHash();
ch.addNode('shard-1');
ch.addNode('shard-2');
ch.addNode('shard-3');

console.log(ch.getNode('user:12345'));  // → 'shard-2'
console.log(ch.getNode('user:67890'));  // → 'shard-1'

🔗 문제 3: 크로스-샤드 쿼리 문제

여러 샤드에 걸친 JOIN이나 집계 쿼리가 필요할 때 발생해요.
이게 샤딩의 가장 큰 단점 중 하나예요!

💰 문제 4: 분산 트랜잭션 문제

여러 샤드에 걸친 트랜잭션이 필요할 때 발생해요.
ACID 보장이 매우 어려워져요!

🎯 파티셔닝 + 샤딩 함께 쓰기 — 최강 조합

파티셔닝과 샤딩은 서로 배타적인 게 아니에요!
각 샤드 내부에서 파티셔닝을 적용하면 더 강력한 성능을 낼 수 있어요.
이걸 복합 파티셔닝(Composite Partitioning)이라고도 해요 🔥

Cassandra의 파티셔닝 + 클러스터링

Cassandra는 이 개념을 아주 잘 구현한 DB예요.
파티션 키(Partition Key)로 어느 노드에 저장할지 결정하고,
클러스터링 키(Clustering Key)로 파티션 내부 정렬을 결정해요!

-- Cassandra CQL 예시
CREATE TABLE user_messages (
    user_id UUID,           -- 파티션 키: 어느 노드에 저장할지
    message_date DATE,      -- 클러스터링 키: 파티션 내 정렬
    message_id TIMEUUID,    -- 클러스터링 키: 시간순 정렬
    content TEXT,
    PRIMARY KEY ((user_id, message_date), message_id)
) WITH CLUSTERING ORDER BY (message_id DESC);

-- 특정 사용자의 특정 날짜 메시지 조회 (초고속!)
SELECT * FROM user_messages
WHERE user_id = ? AND message_date = '2024-01-15'
LIMIT 50;

Cassandra에서 (user_id, message_date)가 복합 파티션 키예요.
같은 사용자의 같은 날짜 메시지는 같은 노드에 저장되어 빠른 조회가 가능하고,
다른 사용자는 다른 노드에 분산되어 부하가 균등하게 나눠져요!

📊 성능 비교 — 실제로 얼마나 빨라질까?

"이론은 알겠는데 실제로 얼마나 빨라져요?" 라고 물어보시는 분들을 위해!
일반적인 성능 개선 수치를 공유할게요 (환경마다 다를 수 있어요!)

🛡️ 파티셔닝/샤딩 설계 시 체크리스트

실제로 파티셔닝이나 샤딩을 도입할 때 반드시 확인해야 할 것들이에요.
이 체크리스트 하나면 실수를 많이 줄일 수 있어요! ✅

🔮 최신 트렌드 — 클라우드 시대의 파티셔닝/샤딩

요즘은 클라우드 DB 서비스들이 파티셔닝/샤딩을 자동으로 처리해줘서
개발자가 직접 구현할 일이 줄어들고 있어요.
하지만 원리를 모르면 설정도 못 하고 트러블슈팅도 못 하니까 알아야 해요! 😤

☁️ 클라우드 DB의 자동 샤딩

🆕 NewSQL — 샤딩을 내장한 새로운 DB들

전통적인 RDBMS의 ACID 보장 + NoSQL의 수평 확장성을 동시에 제공하는
NewSQL 계열 DB들이 주목받고 있어요!

📝 마무리 — 핵심 정리

자 이제 파티셔닝과 샤딩에 대해 완전히 정리됐죠?ㅋㅋㅋ
마지막으로 핵심 내용을 한 번 더 정리해드릴게요!