dev zone/database

[Primary Key 생성 전략] #6. 유니크 정렬 숫자 (Snowflake, TSID 등)

voco choe 2025. 2. 11. 22:59

 

 

 

# 0. 들어가며

 

UUID는 랜덤성이 강해서 데이터베이스 성능에 악영향을 줄 수 있습니다. 그리고 이를 해결하기 위해 정렬 가능한 숫자로 된 유니크한 ID를 생성하는 방식이 등장했습니다. 이전의 문자열과 다른점은 숫자타입으로 좀 더 사용성을 높였습니다. 대표적인 방법으로 Snowflake, TSID, FlakeID 등이 있으며, 이 방식은 시간 기반 정렬이 가능하고, 중복 없는 고유한 ID를 제공합니다.

 

 

 

# 1. Snowflake 알고리즘의 원리 (타임스탬프 + 머신 ID + 시퀀스)

 

Snowflake는 Twitter에서 개발한 유니크한 정렬 숫자 ID 생성 방식입니다. ID를 64비트 숫자로 표현하여 UUID보다 작고, 정렬이 가능합니다. 앞부분은 시간 정보를 포함하므로 ID가 시간 순서대로 정렬되며 뒤쪽에 머신 ID + 시퀀스 번호를 추가하여 중복을 방지합니다. 

 

📌 Snowflake ID 구조 (64비트)

 

| 1비트 예약 | 41비트 타임스탬프 | 10비트 머신 ID | 12비트 시퀀스 번호 |

 

  • 1비트(예약): 사용하지 않음
  • 41비트(타임스탬프): 현재 시간(밀리초 단위) → ID를 시간순으로 정렬 가능!
  • 10비트(머신 ID): 서버나 데이터센터 ID → 분산 환경에서 중복 방지
  • 12비트(시퀀스 번호): 같은 밀리초에 생성된 ID를 구별

 

 

 

 

 

# 2. TSID, FlakeID 등의 비교

 

UUID나 Snowflake ID 외에도 유니크하고 정렬 가능한 숫자형 ID를 생성하는 다양한 방식이 있습니다. 예로 TSID와 FlakeID 등 많이 있습니다만 이 두가지에 대해서 설명하겠습니다. 이외에도 NanoID 등 다양한 방식이 있습니다. 

 

📌 TSID(Timestamped Secure ID)

  • UUID를 대체할 수 있는 정렬 가능한 숫자형 ID
  • UUID의 랜덤성을 유지하면서도 정렬 가능헙니다. 
  • 128비트(긴 버전)와 64비트(짧은 버전) 지원됩니다

 

📌 FlakeID

  • Snowflake와 매우 유사합니다
  • AWS 환경에서 Snowflake를 최적화한 버전
  • DynamoDB, NoSQL 환경에서 활용하기 좋습니다. 

 

 

 

# 3. 장점과 단점

 

장점 

 

✔ 정렬 가능 → 데이터베이스 성능 향상

  • 시간 순으로 정렬되므로 B+트리 인덱스 최적화 가능합니다.
  • UUID처럼 랜덤 삽입으로 인덱스 조각화 발생하지 않습니다

 

✔ 분산 환경에서도 중복 없음

  • 머신 ID + 시퀀스 번호를 포함하므로, 서버가 여러 개여도 중복 방지 가능합니다

 

✔ UUID보다 저장 공간 절약 가능

  • UUID(128비트)보다 숫자형 ID(64비트)가 더 작아 DB 저장 공간 효율적입니다

 

✔ 읽고 다루기 편리합니다

  • 145678912345678901 같은 숫자 ID는 550e8400-e29b-41d4-a716-446655440000 같은 UUID보다 로그 분석, 디버깅할 때 직관적입니

 

단점 

✔  ID 생성 시스템 필요 (Snowflake 서버 운영해야 함)

  • Snowflake ID를 생성하려면 별도의 서버 또는 라이브러리가 필요합니다
  • 단순히 UUID()처럼 자동 생성되는 것이 아니라, ID 생성 서버를 운영해야 합니다.

 

✔  시계 동기화 문제 (Clock Drift)

  • Snowflake는 타임스탬프 기반이라 서버 간 시간이 맞지 않으면 문제가 발생할 수 있습니다.
  • 해결 방법: NTP(Network Time Protocol)로 모든 서버 시간을 동기화합니다.

 

✔  초당 생성 가능한 ID 개수 제한 (성능 문제)

  • 12비트 시퀀스 번호는 한 밀리초에 4,096개까지만 ID 생성 가능합니다
  • 트래픽이 너무 많으면 ID 생성 속도가 한계에 도달할 수 있습니다.

 

 

 

 

# 4. 특정 상황에서 유리한 이유

 

✅ 로그 시스템, 트랜잭션 ID

  • 로그를 시간순으로 정렬해야 할 때 Snowflake ID가 유리합니다

 

✅ 소셜 미디어 서비스 (게시글, 댓글 ID)

  • 게시물 ID를 시간순으로 정렬해야 한다면, Snowflake ID가 유리합니다.

 

✅ 분산 데이터베이스 (NoSQL, DynamoDB, Cassandra)

  • 여러 개의 서버에서 중복 없이 ID 생성해야 할 때 Snowflake ID 사용하는것이 좋습니다.

 

✅ UUID보다 작은 저장 공간이 필요한 경우

  • 64비트 정렬 숫자 ID는 UUID(128비트)보다 저장 공간 절약 가능합니다.

 

 

 

# 5. UUID 성능 최적화 방법 (해결 방법)

 

✅ 1. 서버 간 시간 동기화 (Clock Drift 방지)

  • 모든 서버에 NTP(Network Time Protocol) 설정하여 시계 동기화
  • 서버 간 시간이 맞지 않으면, 동일한 타임스탬프에서 충돌이 발생할 수 있습니다. 

 

✅ 2. 머신 ID 범위 조정

  • 서버마다 고유한 머신 ID 할당 → 서버 간 중복 방지
  • 머신 ID를 더 많이 할당하여 단일 서버에서 생성하는 ID 개수 제한 해결할 수 있습니다.

 

✅ 3. 대체 알고리즘 사용 (TSID, ULID 등)

  • Snowflake ID의 한계를 극복하기 위해 TSID, ULID 같은 최신 방식 사용합니다. 
  • TSID는 UUID처럼 사용할 수 있지만, 정렬 가능하여 Snowflake의 장점을 가집니다.

 

 

 

 

# 6. 결론 

 

✅ UUID보다 정렬 가능한 ID가 필요할 때 사용하기 좋습니다. 
✅ 대규모 분산 환경에서 충돌 없이 ID를 생성해야 할 때 사용하기 좋습니다.
✅ 데이터베이스 인덱스 성능을 높이고 싶을 때 사용하기 좋습니다. 

 

 

 

 

 

🔹 Twitter Snowflake 알고리즘 설명 (GitHub 공식 문서)
📌 https://github.com/twitter-archive/snowflake

🔹 Snowflake ID vs UUID 성능 비교 논문 (Stanford 연구 자료)
📌 https://cs.stanford.edu/~manku/papers/consistent-hashing.pdf

🔹 TSID 공식 문서 (Time-Sorted Unique ID)
📌 https://github.com/jetpack-io/tsid

🔹 Flake ID 설명 (Boundary 개발자 블로그)
📌 https://boundary.com/blog/2013/10/flake-a-decentralized-k-ordered-id-generator-in-erlang

저작자표시 비영리 변경금지 (새창열림)