TIL

리밸런싱 전략 (Rebalancing)

• 리밸런싱 = 노드 간 데이터·부하를 재분배하는 것 (노드 추가/제거, 데이터 증가 시)
• 목표 3가지
  • 부하를 노드 간 공정하게 분배
  • 리밸런싱 중에도 읽기/쓰기 가용
  • 이동하는 데이터를 최소화(불필요한 이동은 비용·부하)
• DDIA의 세 전략(고정 파티션 수 / 동적 파티셔닝 / 노드 비례)을 비교

안티패턴: hash mod N

• hash(key) % N(N = 노드 수)으로 노드를 정하면, 노드 추가로 N이 바뀔 때 대부분의 키가 다른 노드로 이동
• 이동량이 과해 운영 중 리밸런싱이 사실상 불가 → 아래 전략들이 이를 회피 (논리/물리 샤드 참고)

전략 1: 고정 파티션 수 (fixed number of partitions)

• 노드보다 훨씬 많은 파티션을 처음에 고정으로 만들고, 노드당 여러 개를 배정
• 노드 추가 = 기존 노드에서 파티션 몇 개를 통째로 가져옴(steal). 파티션의 수·경계는 불변, 배정만 바뀜
• 파티션 내부 데이터를 다시 쪼개지 않으므로 이동 단위가 명확
• 사용: Elasticsearch, Riak, Couchbase, Vitess (= 논리/물리 샤드의 그 방식)
• 주의: 파티션 수를 미리 잘 잡아야 함(초과 시 곤란). 데이터가 가변이면 파티션 크기 편차가 커질 수 있음

전략 2: 동적 파티셔닝 (dynamic partitioning)

• 파티션이 임계 크기를 넘으면 자동 split, 너무 작아지면 인접 파티션과 merge → 파티션 수가 데이터량에 비례해 변함 (B-tree 분할과 유사)
• split 후 절반을 다른 노드로 옮겨 균형을 맞춤
• key-range·hash 파티셔닝 모두에 적용 가능
• 사용: HBase, MongoDB, RethinkDB
• 장점: 데이터량에 적응 — 작으면 파티션 적어 오버헤드 ↓, 크면 자동으로 늘어남
• 주의: 빈 DB는 단일 파티션에서 시작 → 첫 split 전까지 한 노드가 모든 쓰기 부담. 이를 막으려 pre-splitting(초기 파티션 미리 분할)을 설정

전략 3: 노드 비례 (proportional to nodes)

• 노드당 파티션 수를 고정 → 총 파티션 수 ∝ 노드 수. 노드가 늘면 파티션도 늘어 파티션 크기는 비교적 안정
• 노드 추가 시 기존 파티션 중 일부를 랜덤으로 골라 split하고 절반을 새 노드가 가져감
• hash·consistent hashing과 잘 맞음 (랜덤 분할 지점 선택)
• 사용: Cassandra, Ketama
• 주의: 랜덤 split이라 분할이 불공정할 수 있음(시간이 지나며 평준화)

자동 vs 수동 리밸런싱

• 완전 자동 리밸런싱은 편하지만 위험할 수 있음
  • 리밸런싱은 비싼 작업(데이터 이동·요청 재라우팅)인데, 장애 감지와 겹치면 cascade — 노드가 잠시 느려짐 → 죽었다고 오판 → 리밸런싱 발동 → 부하 가중 → 다른 노드까지 악화
• 많은 시스템이 사람을 개입시킴 — 시스템이 재배치안을 제안하고 admin이 승인/실행 (Couchbase, Riak, Vitess 등)

요청 라우팅 (리밸런싱 후 키 찾기)

• 리밸런싱으로 파티션→노드 매핑이 바뀌면, 클라이언트가 올바른 노드를 찾아야 함
• 방식: ① 아무 노드에 요청 → 그 노드가 포워딩 ② 라우팅 티어가 중개 ③ 클라이언트가 매핑을 앎
• 보통 ZooKeeper·etcd 같은 coordination service로 매핑을 관리 (논리/물리 샤드의 라우팅 참고)

비교 요약

전략	파티션 수	노드 추가 시 동작	대표 사용
고정 파티션 수	처음에 크게 고정	파티션을 통째로 재배치(steal)	Elasticsearch, Riak, Vitess
동적 파티셔닝	데이터량에 비례(가변)	임계 초과 시 split → 절반 이동	HBase, MongoDB
노드 비례	노드 수에 비례	기존 파티션 일부를 랜덤 split	Cassandra

참고

• 데이터 중심 애플리케이션 설계(DDIA) 6장 — Partitioning / Rebalancing
• 논리/물리 샤드와 무중단 리샤딩