본문 바로가기
아키텍처

MSA에서 겹치지 않는 ID 만들기: Twitter Snowflake 알고리즘의 원리와 구현

by 공부 안하고 싶은 사람 2026. 3. 6.
반응형
Distributed System Design

분산 환경의 고유 키 고민,
Snowflake로 종결하기

 

안녕하세요, code-resting입니다. 서비스 규모가 커져 데이터베이스를 샤딩(Sharding)하거나 마이크로서비스로 분리하면, 기존의 AUTO_INCREMENT 방식은 한계에 부딪힙니다. 각 DB 서버마다 중복된 ID가 생성될 수 있기 때문이죠. 그렇다고 UUID를 쓰자니 인덱스 성능이 떨어지고 정렬이 어렵습니다. 오늘은 이 문제를 해결하기 위해 트위터(Twitter)에서 고안한 Snowflake 알고리즘을 파헤쳐 보겠습니다.

1. 기존 방식의 한계

  • Auto-increment: 분산 DB 환경에서 ID 충돌 방지를 위해 중앙 집중식 관리가 필요하며, 이는 성능 병목(SPOF)이 됩니다.
  • UUID: 128비트로 너무 길고, 시간 순서로 정렬되지 않아 B-Tree 인덱스 효율을 극도로 떨어뜨립니다.

2. Snowflake의 64비트 구조

Snowflake는 전체 64비트(Long 타입)를 여러 섹션으로 나누어 정보를 담습니다. 덕분에 중앙 서버 없이도 각 노드에서 독립적으로 유일한 ID를 생성할 수 있습니다.

  • 1 bit: 사용하지 않음 (양수 고정)
  • 41 bits: 타임스탬프 (밀리초 단위, 약 69년 사용 가능)
  • 10 bits: 데이터센터 ID + 서버(Worker) ID (최대 1,024개 노드 식별)
  • 12 bits: 일련번호 (동일 밀리초 내에서 생성되는 순서, 초당 약 400만 개 생성 가능)

3. 왜 Snowflake인가?

단순히 중복을 피하는 것 이상의 장점이 있습니다.

  1. 시간순 정렬 가능: 상위 비트가 타임스탬프이므로 ID 값 자체로 정렬이 가능하며, 이는 DB 인덱싱에 최적입니다.
  2. 고가용성: ID 생성을 위해 다른 서버와 통신할 필요가 없어 지연 시간이 거의 없습니다.
  3. 확장성: 서버 ID 할당만 관리하면 서버 대수를 자유롭게 늘릴 수 있습니다.

4. 실무 도입 시 주의사항

⏰ Clock Skew (시간 동기화 문제)

서버 간의 시간이 미세하게 다를 경우 ID 역전 현상이 발생할 수 있습니다. NTP(Network Time Protocol)를 통해 서버 시간을 동기화하거나, 이전 타임스탬프보다 현재 시간이 작을 경우 예외를 발생시키는 로직이 필수입니다.

💡 마치며

2026년 대규모 분산 시스템에서 데이터의 정체성을 부여하는 일은 성능과 직결됩니다. Snowflake는 단순하면서도 강력한 해법을 제시합니다. 라이브러리를 직접 구현하거나, 검증된 오픈소스(Baidu UidGenerator 등)를 활용해 프로젝트의 확장성을 미리 준비해 보세요.

© 2026 code-resting. All rights reserved.

반응형

댓글