7장. 분산 시스템을 위한 유일 ID 생성기 설계
1단계. 문제 이해 및 설계 범위 확정
| - | 요구사항 |
|---|---|
| ID의 특성 | 유일해야 하고 정렬 가능해야 함 |
| ID의 타입 | 숫자 64비트로 표현될 수 있는 값 생성 시점에 따른 정렬 가능 |
| 시스템 규모 | 초당 10,000 ID 생성 가능해야 함 |
2단계. 개략적 설계안 제시및 동의 구하기
- 분산 시스템에서 유일성이 보장되는 ID 생성 기법은 다양함
- 선택지
- 다중 마스터복제(multi-master replication)
- UUID(Universally Unique Identifier)
- 티켓 서버(ticket server)
- 트위터 스노플레이크(twitter snowflake) 접근법
2-1. 다중 마스터 복제
- DB의
auto_increment기능을 활용하는 방법 - 단, 1씩 증가가 아닌 K(분산 DB 수)씩 증가
2-2. UUID(v4)
특징
- 컴퓨터 시스템에 저장되는 정보를 유일하게 식별하기 위한 128비트 수
| 장점 | 단점 |
|---|---|
| 단순의존성·조율 없음(완전 분산) 서버 사이의 조율이 필요 없으므로 동기화 이슈 없음 성숙한 생태계: 거의 모든 언어/DB/프레임워크가 지원 각 서버가 스스로 UUID 생성-> 규모 확장 용이 | I16바이트(문자열 표기 36자)라 공간·전송량 부담이 정수형보다 큼 비정렬(random) 키 시간순 정렬이 필요하면 애플리케이션 레벨로 정렬 키를 따로 둬야 함 ID에 숫자가 아닌 값 포함 가능 |
2-3. 티켓 서버
- 플리커는 분산 기본키를 만들기 위해 티켓 서버 기술 활용
auto_increment기능을 갖춘 DB 서버(티켓 서버)를 중앙 집중형으로 하나만 사용하는 방식
| 장점 | 단점 |
|---|---|
| 구현 용이 중소 규모 앱에 적합 | 티켓 서버가 SPOF가 됨 |
2-4. 트위터 스노우플레이크 접근법
- 64비트 정수를 여러 절(
타임스탬프 | 노드ID | 시퀀스)로 비트 분할해 시간 정렬과 완전 분산을 동시에 달성하는 방식
생성
sign bit: 1비트 할당timestamp: 기준 epoch 이후 경과 ms(또는 ns)- 노드 ID(머신/프로세스)
- 데이터 센터 ID: 5비트 할당. 2^5 = 32개 데이터 센터 지원 가능
- 서버 ID: 5비트 할당. 데이터 센터당 32개 서버 사용 가능
- 일련번호
- 각 서버에서는 ID 생성 시 일련 번호 1씩 증가
- 1ms 경과할 때마다 초기화됨(즉, 같은 ms 내 증가하는 시퀀스 비트)
[ 1bit 예약 | 41bit 타임스탬프 | 10bit 노드ID | 12bit 시퀀스 ]3단계. 상세 설게
노드 ID
- 데이터 센터 ID와 서버 ID는 시스템이 시작할 때 결정되며, 일반적으로 운영중에는 변경되지 않음
- 변경 시 ID 충돌이 발생할 수 있음
4단계. 추가 논의 사항
시계 동기화(clock synchronization)
- 하나의 서버에서 여러 코어가 실행될 경우 ID 생성 서버들이 전부 같은 시계를 사용하지 않을 수도 있음
- 해결 방법 중 하나: NTP(
Network Time Protocol)
각 절의 길이 최적화
- 동시성이 낮고 수명이 긴 앱이라면 일련번호의 길이를 줄이고 타임스탬프 절의 길이를 늘이는 것을 고려 가능
고가용성
5. 참고 내용
5-1. UUID v4 (난수형)
정의
- 128비트 UUID
- 상수 비트(버전/variant)를 제외한 122비트를 암호학적으로 충분한 난수로 채우는 식별자
보장/성질
- 완전 분산: 중앙 없이 생성
- 정렬성 없음: 삽입 위치가 랜덤 → 인덱스 단편화 유발 가능
- 충돌 확률: 현실적으로 극히 낮음(122비트 공간)
- 개인정보 노출 없음: 시간/노드 정보 미포함
권장 유스케이스
- “그냥 충돌 없이 잘 돌아가는 전역 고유키”가 필요하고 DB 인덱스 비용을 감수할 수 있을 때
- 마이크로서비스/이벤트ID/추적ID 등 중앙 조율이 싫을 때
5-2. UUID 버전
- v7 과 v4 비교
- v7 장점: 타임스탬프를 상위비트에 두어 삽입 정렬성↑, 범위쿼리·시계열 조회에 유리. 인덱스 단편화↓, 캐시 친화적
- v4 장점: 구현·호환성 측면에서 가장 널리 쓰이고 라이브러리 풍부.
- DB 성능/정렬성이 중요하면 v7, 단순 분산 유일 키면 v4도 충분
| 버전 | 핵심 아이디어 | 정렬성 | 충돌 위험 | 비고 |
|---|---|---|---|---|
| v1 | 시간 + 노드(MAC) | 어느 정도(시간 기반) | 매우 낮음 | MAC 유출·시계 이슈 우려 |
| v3 | 네임스페이스 + 이름의 MD5 | 없음 | 동일 입력→동일 출력 | 보통 v5 선호 |
| v4 | 난수 122비트 | 없음 | 극저 | 가장 널리 사용 |
| v5 | 네임스페이스 + 이름의 SHA-1 | 없음 | 동일 입력→동일 출력 | 디터미니스틱 ID 필요 시 |
| v6 | v1 재배열(시간 정렬성 개선) | 높음 | 매우 낮음 | 과도기적, 채택 제한적 |
| v7 | 시간(Unix ms)+난수 | 높음(시간 정렬) | 극저 | 최신 표준 경향, 실무 선호↑ |
| v8 | 커스텀 필드 | 설계에 따름 | 설계에 따름 | 실험/도메인 특화용 |
6. 용어
- 정렬성(orderability): 시간이 흐를수록 값이 대체로 증가
- 충돌 확률: 서로 다른 두 생성 결과가 동일 키가 되는 확률(이상적으로 0에 가깝다)
- 완전 분산성: 중앙 조율 없이 각 노드가 독립적으로 생성 가능
