샤딩 운영 과제

전역 ID는 번호 체계가 아니라 조율 위치를 정하는 설계입니다

각 샤드가 동시에 INSERT하면 로컬 번호는 쉽게 겹칩니다. 그래서 ID 전략은 전역 고유성, 대략 시간순 정렬, 운영 의존성 사이에서 어디에 비용을 둘지 결정합니다.

ID를 고를 때 같이 보는 기준
고유성샤드 결과를 합쳐도 충돌하지 않는가
정렬성삽입 순서가 인덱스와 로그에 우호적인가
운영성워커 규칙·발급기·재샤딩에 얼마나 묶이는가

출발점: 각 샤드의 AUTO_INCREMENT는 서로 모릅니다

한 샤드 안에서는 문제없어도, 전역에서 모으면 같은 ID가 반복됩니다.

결국 정하는 것

누가 만든다각 샤드가 바로 만들지, 중앙 발급기를 둘지
무엇을 담나시간, 워커, 샤드 번호를 ID 형식에 넣을지
무엇을 감수하나정렬 손실, 시계 관리, 재샤딩 제약 중 어느 비용을 받을지
조율을 줄이는 쪽

샤드 안에서 바로 생성

별도 서버 없이 빠르게 만들 수 있지만, 정렬성이나 규칙 관리는 전략마다 다릅니다.

UUID v4

랜덤

조율 없이 바로 만들 수 있지만, 순서가 섞여 B-Tree locality가 약합니다.

ULID

시간 + 랜덤

UUID보다 시간순 정렬이 읽히기 쉬워 로그·이벤트성 데이터에 잘 맞습니다.

Snowflake ID

시간 + 워커 + 시퀀스

정렬성과 64비트 정수 형태는 좋지만, 워커 ID와 시계 오차를 운영해야 합니다.

통제를 높이는 쪽

형식이나 발급기를 함께 관리

전역 규칙은 분명해지지만, 샤드 토폴로지나 별도 인프라에 더 묶입니다.

샤드 ID + Seq

구조가 드러남

구현은 단순하고 어느 샤드 데이터인지 바로 읽히지만, 재샤딩 때 형식 제약이 생깁니다.

중앙 발급

ID 서버

규칙을 한곳에서 통제하기 쉽지만, 고가용성이 약하면 병목이나 SPOF가 됩니다.

핵심: 샤딩의 ID 전략은 “겹치지 않는 번호”를 고르는 일이 아니라, 조율 비용을 어디에 둘지 선택하는 일입니다.