데이터베이스 샤딩과 파티셔닝 전략 (Node.js 적용)

개요

데이터가 커지면 단일 데이터베이스만으로는 성능과 가용성을 유지하기 어렵다. 이때 사용하는 대표적 기법이 샤딩(sharding)과 파티셔닝(partitioning)이다. 두 기법은 목적과 구현 방식이 다르므로 요구사항에 맞춰 선택해야 한다. 본문에서는 개념 정리부터 Node.js 적용 예제까지 단계별로 설명한다.

핵심 개념

샤딩이란

샤딩은 데이터셋을 여러 독립적인 데이터베이스 인스턴스로 분산하는 방식이다. 각 샤드는 전체 데이터의 일부를 보유하며 수평 분할(horizontal partitioning) 형태로 구현된다. 샤드는 서로 다른 서버에 배포되어 읽기·쓰기 부하를 분산한다.

파티셔닝이란

파티셔닝은 하나의 데이터베이스 내에서 테이블을 논리적으로 분할하는 것이다. 보통 동일한 DBMS 인스턴스에서 동작하며, 파티션 키에 따라 물리적 파일이나 세그먼트로 나뉜다. 파티셔닝은 관리·쿼리 최적화에 유리하지만, 샤딩처럼 인스턴스 단위 확장은 제공하지 않는다.

주요 차이

• 스케일 범위: 샤딩은 다수의 머신으로 수평 확장 가능.
• 운영 복잡도: 샤딩은 라우팅·재분배 등 운영 비용이 높음.
• 쿼리 범위: 파티셔닝은 같은 인스턴스 내에서 복잡한 조인에 유리.

설계 고려사항

• 데이터 분포: 균등 분배가 가능한 키 선택이 핵심이다.
• 쿼리 패턴: 범위 조회가 많은지, 특정 키 조회가 많은지 분석.
• 일관성 요구사항: 트랜잭션 경계가 샤드 단위인지 전체인지 확인.
• 오프라인 재분배 비용: 샤드 추가·제거 시 데이터 이동 비용 계산.
• 운영·모니터링: 샤드별 지표와 재시도 로직 설계.

Node.js에서 샤딩 적용 전략

Node.js 애플리케이션은 샤드 라우팅 계층을 가질 필요가 있다. 라우터는 클라이언트 요청의 키를 기반으로 대상 샤드를 결정하고 해당 샤드에 쿼리를 전송한다. 간단한 샤딩 방식으로는 해시 기반(modulo) 분할이 있다. 아래는 MySQL을 가정한 예제다.

샤드 라우팅 예제 (MySQL)

const mysql = require('mysql2/promise');

// 샤드별 커넥션 풀
const shards = [
  mysql.createPool({ host: 'db1.example', user: 'app', database: 'appdb' }),
  mysql.createPool({ host: 'db2.example', user: 'app', database: 'appdb' }),
  mysql.createPool({ host: 'db3.example', user: 'app', database: 'appdb' })
];

function shardForUser(userId) {
  return shards[userId % shards.length];
}

async function getUser(userId) {
  const pool = shardForUser(userId);
  const [rows] = await pool.query('SELECT * FROM users WHERE id = ?', [userId]);
  return rows[0];
}

이 방식은 구현이 단순하지만, 샤드 수 변경 시 재분배가 필요하다. 이를 해결하려면 일관성 있는 해시(consistent hashing)나 범위 기반 샤딩을 고려한다.

데이터 파티셔닝과 Node.js 연동

파티셔닝은 DBMS 레벨에서 처리되므로 애플리케이션 코드 변경은 적다. 그러나 파티션 키 선택이나 파티션 추가 정책은 쿼리 성능에 영향을 준다. PostgreSQL의 범위 파티셔닝 예시와 Node.js 쿼리 사용 방법은 다음과 같다.

Postgres 파티션 예시

-- 범위 파티션 생성 (SQL)
CREATE TABLE events (
  id BIGSERIAL PRIMARY KEY,
  event_time TIMESTAMP NOT NULL,
  payload JSONB
) PARTITION BY RANGE (event_time);

CREATE TABLE events_2025 PARTITION OF events
  FOR VALUES FROM ('2025-01-01') TO ('2026-01-01');

Node.js에서는 기존과 동일한 쿼리로 접근하면 된다. 파티션 매칭은 DBMS가 처리하므로 애플리케이션 로직 변화가 거의 없다. 다만 파티션 유지와 인덱스 전략은 DBA와 협의한다.

운영과 모니터링

• 지표 수집: 샤드별 QPS, 레이턴시, 디스크 사용량 수집.
• 재분배 계획: 샤드 추가 전 데이터 이동 스크립트와 롤백 전략 준비.
• 백업 정책: 샤드별 일관성 있는 백업 시점 확보.
• 장애 대응: 샤드 실패 시 페일오버 및 읽기 전용 모드 고려.

결론

샤딩과 파티셔닝은 목적이 다르므로 혼용 전략도 가능하다. 먼저 쿼리 패턴과 성장 예측을 바탕으로 파티셔닝을 적용하고, 스케일 요구가 커지면 샤딩을 도입하는 단계적 접근이 현실적이다. Node DB 샤딩 설계와 데이터 파티셔닝 Node.js 적용은 설계 단계의 키 선택과 운영 자동화가 성공 여부를 좌우한다.