글로벌하게 유니키한 키를 만들어야 할때, 보통은 uuid를 떠올리지만 snowflake방식을 선택하면 아래와 같은 장점이 있다.

 

비교 항목 UUIDv4 Snowflake
크기(Storage) 128 bit (16 바이트) 64 bit (8 바이트)
인덱스 단편화 완전 랜덤 삽입 → B-tree 인덱스 단편화↑ 시간순으로 순차적 증가 → 단편화↓
순차성(Time-sortable) 불가능 상위 비트에 밀리초 타임스탬프 내장 → 정렬 가능
생성 비용 랜덤 엔트로피 생성 → CPU & 메모리 부하 다소 높음 단순 비트 연산 + 시퀀스 → 매우 경량
메타데이터 내장 없음 타임스탬프·데이터센터ID·노드ID·시퀀스 정보 포함
충돌 위험 충돌 확률 극히 낮으나 완전히 배제 불가 노드ID+시퀀스 조합으로 충돌 사실상 0 (전제: 노드ID 관리)
디버깅·추적 편의성 ID만으로 “언제 생성됐는지” 파악 불가 ID만으로 생성 시각·생성 주체(노드) 추적 가능

 

언제 UUID를 쓰고, 언제 Snowflake를 쓰나?

  • UUIDv4
    • 단순 분산 식별자(ID)만 필요하고, 시간순 정렬·인덱스 단편화 이슈가 크지 않은 애플리케이션
    • 예: 각종 리소스(사용자·세션·토큰) 식별 등
  • Snowflake
    • 고TPS 분산 시스템에서 시간순 처리·인덱스 효율·멱등 ID가 중요할 때
    • 예: 이벤트 로깅, 메시징 시스템, 주문·트랜잭션 ID
반응형

'System Architect' 카테고리의 다른 글

OIDC(Open ID Connect)  (0) 2025.06.18
outbox 패턴  (0) 2025.06.16
쿠버네티스(K8s, kubernetes)  (0) 2025.06.01
업스트림(upstream)/다운스트림(downstream)  (0) 2025.05.30
딥링크  (0) 2025.05.23

+ Recent posts