시스템 디자인 아틀라스
패턴 / 분산 고유 ID
⌕ 개념·패턴·사례 검색 ⌘ K
학습 로드맵
홈 / 패턴 / 분산 환경의 고유 ID 생성 설계
PATTERN · INTERMEDIATE읽기 20분검토일 2026-08-23

분산 환경의
고유 ID 생성 설계

중앙 시퀀스의 단순함을 넘어, 여러 worker가 충돌 없이 ID를 발급하게 만드는 시간·소유권·장애 대응의 설계 패턴입니다.

시스템 디자인 아틀라스·설계 패턴·사실과 설계 가정을 구분
개념 이해장애 대응운영 관점진도 저장
#30초 핵심 요약

고처리량 ID는 요청마다 중앙 저장소를 호출하지 않고, 로컬의 timestamp + worker-id + sequence로 만든다. 대신 worker-id는 lease와 fencing으로 단독 소유하게 하고, 시계 역행은 논리 시간 또는 fail-closed 정책으로 막는다. ID는 접근 권한이 아니라 식별자일 뿐이다.

발급 경로로컬·무중앙 RPC
충돌 방지Lease + fencing
시계 이상Guard + alert
01 · REQUIREMENTS

유일성과 순서를 분리해서 묻는다

# 요구사항

“정렬되는 ID”와 “전역 순서가 보장되는 ID”는 다릅니다. 먼저 namespace, 공개 여부, 리전 독립성, 초당 피크를 확정해 어떤 종류의 고유성이 필요한지 좁힙니다.

R1전역 유일성

서로 다른 worker와 재시작 이후에도 동일 bit 조합을 만들지 않습니다.

R2정렬은 힌트

시간 비트는 인덱스 지역성을 돕지만 동시 이벤트의 총순서를 뜻하지 않습니다.

R3고가용 발급

registry는 제어 평면이고, 정상 상태 발급에는 매 요청 참여하지 않습니다.

R4공개 경계

추측 가능한 ID를 URL에 쓰더라도 접근 제어를 생략하지 않습니다.

02 · HIGH-LEVEL DESIGN

비트 조합과 clock guard의 이중 방어

# 아키텍처

아래 값은 41비트 시간·10비트 worker·12비트 sequence라는 예시 설계 가정입니다. UUIDv7은 표준 UUID 형식이며 이 worker/sequence 구성을 요구하지 않습니다.

로컬 ID 발급과 시계 역행 방어 SVG DIAGRAM · 예시 bit budget
timestamp, worker, sequence로 ID를 만들고 시계 역행을 방어하는 흐름worker lease를 확보한 생성기가 현재 시각을 마지막 논리 시각과 비교해 ID 비트를 만들며, 시계가 뒤로 가면 논리 시간을 유지하고 경보를 보내는 구조Worker leaseid + fencing tokenClock guardnow ≥ last timestamp?64-bit IDtimestampworkerseq41 bits · 10 bits · 12 bitsObject writeprimary keyClock rollback detectedlogical time 유지 또는 발급 중지 + alert제어 평면: 시작·갱신 시에만 lease정상 발급: 외부 RPC 없음
구분해야 할 두 장애 · 시계 역행은 한 생성기의 시간원 문제이고, worker-id 충돌은 둘 이상의 생성기가 같은 소유권을 가진 배포·제어 평면 문제입니다. sequence 증가만으로 worker-id 충돌을 해결할 수 없습니다.
03 · WRITE / READ FLOW

발급은 로컬, 소유권은 검증 가능하게

# 흐름
1Lease 확보

시작 시 registry의 CAS로 worker-id와 fencing token을 임대합니다.

2시간 비교

`now`와 `last_timestamp`를 비교해 새 ms 또는 같은 ms를 판별합니다.

3Sequence 증가

같은 ms면 증가시키고 소진 시 다음 ms까지 backpressure를 겁니다.

4쓰기·읽기

객체의 primary key로 쓰고, 읽기 정렬에는 정확한 전역 순서를 가정하지 않습니다.

04 · TRADEOFFS

표준 UUID, 중앙 시퀀스, bit 조합의 선택

# 트레이드오프
방식
발급 경로
주요 강점
운영상 주의
DB sequence
중앙
단순한 순서 모델
primary·failover가 쓰기 한계가 될 수 있음
UUIDv4
로컬
노드 조율 불필요
확률적 충돌, 인덱스 지역성 약함
UUIDv7
로컬
시간 정렬에 유리한 표준 형식
시계·단조성 구현 정책 확인
time + worker + seq
로컬 + 제어
작고 높은 처리량
lease·fencing·clock guard 필요
05 · FAILURE MODES

충돌이 나기 전에 멈추고 증명한다

# 장애 5가지
↶시계 역행

NTP 보정이나 VM 재개 뒤 현재 시간이 `last_timestamp`보다 작아집니다.

대응 · logical time 유지 또는 fail closed; rollback 폭과 지속 시간을 경보로 보냅니다.
≡worker-id 충돌

두 프로세스가 같은 worker bit를 동시에 사용하면 실제 중복 후보가 생깁니다.

대응 · CAS lease와 fencing token으로 이전 소유자를 격리합니다.
↑sequence 소진

한 worker가 한 밀리초의 sequence 공간을 모두 씁니다.

대응 · 다음 tick 대기, 큐·rate limit, worker 분산으로 p99를 보호합니다.
⌁registry 분할

새 인스턴스가 안전하게 lease를 얻거나 갱신할 수 없습니다.

대응 · 새 발급자는 fail closed; quorum·grace 정책을 사전 시험합니다.
↻재시작 상태 유실

프로세스가 마지막 논리 시간을 잊은 채 너무 이른 시각에서 시작합니다.

대응 · 안전 상태 저장 또는 시작 보류로 last time 재사용을 막습니다.
⌛timestamp 수명 종료

epoch와 timestamp bit의 유효 기간이 다가오면 해석·발급이 깨질 수 있습니다.

대응 · versioned generator를 병행하고 파서·저장소 호환성을 검증합니다.
06 · OPERATIONS

보안·관측·비용을 발급기와 함께 운영한다

# 운영
⌾보안과 개인정보

ID는 인증 토큰이 아닙니다. 객체마다 인가를 확인하고, 로그의 원문 ID는 hash·샘플·보존 기간으로 통제합니다.

audit: lease change + instance identity
⌁관측 가능성

충돌의 최종 신호인 duplicate key는 0이어야 합니다. rollback, sequence 대기, lease 잔여 시간을 분리해 봅니다.

clock_rollback_ms · sequence_wait_ms
₩비용과 용량

발급 RPC는 줄지만 quorum registry, 감사 로그, cardinality, 백업과 chaos test 비용은 남습니다.

8B ID ≠ index + replica + WAL cost
면접 모드 · 추가 질문05:00
“여러 리전에서 초당 100만 개 주문 ID를 발급해야 합니다. DB sequence를 쓰지 않는다면 bit budget을 어떻게 정하고, 시계 역행과 worker-id 충돌을 각각 어떻게 막으며, 어떤 지표로 안전성을 증명하겠습니까?”
요구사항 분리lease·fencingclock guardduplicate key 검증
NEXT PATTERN분산 레이트 리미터 설계
→
EDITORIAL NOTES

작성·검토·참고 자료

콘텐츠 원칙
이 문서는 독립적으로 재작성한 한국어 학습 자료입니다. 사실과 학습용 설계 가정을 구분합니다.
최종 검토
예상 학습 시간
20분

참고 자료

사실 오류·출처 정정은 문의·정정 페이지로 알려 주세요.