12 KiB
title, source_type, url, archive_url, related_branches, related_projects, tags, created
| title | source_type | url | archive_url | related_branches | related_projects | tags | created | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| company-tech-blog / Twitter Engineering — Announcing Snowflake (분산 고유 ID 생성 네트워크 서비스) | company-tech-blog | https://blog.x.com/engineering/en_us/a/2010/announcing-snowflake | https://github.com/twitter-archive/snowflake/tree/snowflake-2010 |
|
|
|
2026-05-31 |
Twitter Engineering — Announcing Snowflake (분산 고유 ID 생성 네트워크 서비스)
Layer:
raw/company-tech-blogs/— Twitter Engineering Blog (2010) 의 Snowflake ID 생성 시스템 원문 발췌. 원본 블로그 URL (blog.x.com) 은 접근 불가 (HTTP 403). 내용은 공식 GitHub 아카이브 태그snowflake-2010README 에서 추출. 검증된 요약은/ingest후wiki/concepts/에 별도 작성. 원본은 raw 에 영구 보관.
Parent / 활용 branch (필수, 최소 1개+)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-resource-identifier-contract | D1 (resource ID default 형식): Snowflake 의 datacenter_id + worker_id 조율 부담을 근거로 단일 generator skeleton 에서의 명시적 거부 증거 / D10 (DB primary key): 64bit 단일 컬럼 BIGINT fit 가능성 / D13 (multi-tenancy): datacenter_id 가 partition 힌트를 ID 에 인코딩하는 대안 패턴 사례 |
출처 / Source
- 원본 URL: https://blog.x.com/engineering/en_us/a/2010/announcing-snowflake
- 아카이브 URL: https://github.com/twitter-archive/snowflake/tree/snowflake-2010 (archived 2021-09-18, 읽기 전용)
- 저자 / 조직: Twitter Engineering (Raffi Krikorian 외)
- 발행일: 2010년 6월
- 마지막 확인일: 2026-05-31
- 주의: 원본 블로그 (
blog.x.com및 레거시blog.twitter.com) 는 HTTP 403 / 301 redirect 반환으로 WebFetch 불가. 본 문서의 모든 인용은 공식 GitHub 아카이브snowflake-2010태그 README 에서 Self-Grep 검증 완료.
왜 저장했는지 / Why archived
Snowflake 는 분산 시스템에서 time-ordered 64bit 고유 ID 를 생성하는 Twitter 의 접근법으로, datacenter_id + worker_id 인코딩 방식이 feature-resource-identifier-contract 에서 검토한 ID 후보군 중 하나다. ca-skeleton 은 단일 generator 가정(단일 JVM 프로세스, worker 조율 불필요)이므로 Snowflake 를 명시적으로 거부하는 결정(D1)의 근거 자료로 보관한다. 동시에 64bit 레이아웃이 BIGINT primary key(D10)와 정합하는 설계 강점과, datacenter_id 가 multi-tenancy partition 힌트를 ID에 인코딩하는 대안 패턴(D13)을 사례로 기록한다.
핵심 인용 / Key quotes (verbatim, 5개)
[§Solution] "id is composed of: time - 41 bits (millisecond precision w/ a custom epoch gives us 69 years) / configured machine id - 10 bits - gives us up to 1024 machines / sequence number - 12 bits - rolls over every 4096 per machine (with protection to avoid rollover in the same ms)" — GitHub
snowflake-2010README §Solution, lines 47–50
[§Requirements / Uncoordinated] "For high availability within and across data centers, machines generating ids should not have to coordinate with each other." — GitHub
snowflake-2010README §Requirements / Uncoordinated, line 21
[§Requirements / Compact] "There are many otherwise reasonable solutions to this problem that require 128bit numbers. For various reasons, we need to keep our ids under 64bits." — GitHub
snowflake-2010README §Requirements / Compact, line 37
[§Requirements / Performance] "minimum 10k ids per second per process" — GitHub
snowflake-2010README §Requirements / Performance, line 16
[§Requirements / Time Ordered] "We can guarantee, however, that the id numbers will be k-sorted (references: http://portal.acm.org/citation.cfm?id=70413.70419 and http://portal.acm.org/citation.cfm?id=110778.110783) within a reasonable bound (we're promising 1s, but shooting for 10's of ms)." — GitHub
snowflake-2010README §Requirements / Time Ordered, line 29
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| SNOWFLAKE-C1 | Snowflake ID 는 총 64bit 미만으로 구성된다: 41bit timestamp (ms 정밀도, custom epoch) + 10bit machine ID (최대 1024 머신) + 12bit sequence (머신당 ms 당 최대 4096개) | [§Solution] "id is composed of: time - 41 bits (millisecond precision w/ a custom epoch gives us 69 years) / configured machine id - 10 bits - gives us up to 1024 machines / sequence number - 12 bits - rolls over every 4096 per machine" | company-case-study |
분산 다중 노드 환경에서 고유 ID 생성이 필요한 시스템 | 단일 JVM generator 에서 이 분할이 최적임을 증명하지 않음. 10bit machine ID 는 사전 설정(coordinated) worker ID 할당이 전제됨 |
| SNOWFLAKE-C2 | ID 생성에 노드 간 조율(coordination) 이 불필요하도록 설계하는 것이 고가용성의 핵심 요건이다 | [§Requirements / Uncoordinated] "For high availability within and across data centers, machines generating ids should not have to coordinate with each other." | company-case-study |
다수 데이터센터 / 다수 노드 환경의 ID 생성 시스템 | 단일 generator 환경에서도 이 요건이 동일하게 적용된다는 뜻이 아님. 또한 worker ID 사전 할당 자체가 별도의 외부 조율(ZooKeeper 등)을 요구함을 이 Claim 은 직접 언급하지 않음 |
| SNOWFLAKE-C3 | 고성능 ID 생성 시스템은 프로세스당 초당 최소 10,000개의 ID 를 생성할 수 있어야 한다 | [§Requirements / Performance] "minimum 10k ids per second per process" | company-case-study |
Twitter 규모의 분산 서비스 ID 생성 요건 | 이 throughput 요건이 일반 백엔드 서비스에 동일하게 적용되어야 한다는 뜻이 아님. 12bit sequence 로 ms당 4096개 = 초당 약 4백만 개의 이론 최대치는 별도 계산이며 원문 직접 인용이 아님 |
| SNOWFLAKE-C4 | ID 는 64bit(128bit 대안 아닌) 이하여야 한다 | [§Requirements / Compact] "There are many otherwise reasonable solutions to this problem that require 128bit numbers. For various reasons, we need to keep our ids under 64bits." | company-case-study |
Twitter 의 ID 저장·인덱싱·전송 요건 | "we need to keep our ids under 64bits" 는 Twitter 내부 요건(MySQL BIGINT 컬럼 등). BIGINT fit 이 곧 최선의 DB PK 선택임을 일반적으로 증명하지 않음 |
| SNOWFLAKE-C5 | Snowflake ID 는 정확한 순서가 아닌 k-sorted (합리적 오차 범위 내 정렬) 를 보장한다 | [§Requirements / Time Ordered] "We can guarantee, however, that the id numbers will be k-sorted [...] within a reasonable bound (we're promising 1s, but shooting for 10's of ms)." | company-case-study |
비동기 분산 연산이 많은 API 에서 ID 기반 페이지네이션 / "since this id" 조회 패턴 | 동일 ms 내 단조 증가(monotonicity) 와 k-sorted 는 다른 보장임. RFC 9562 UUIDv7 의 monotonicity 보장과 직접 비교할 수 없음 |
Strength 허용값 (적용 근거)
본 자료는 Twitter Engineering 이 자사 시스템에서 Snowflake 를 어떻게 설계했는지를 직접 기술한 company-case-study 다. 공식 표준(RFC, ISO) 이 아니므로 모든 Claim 은 company-case-study 로 표기한다.
Usage Boundaries / 적용 경계
이 자료가 직접 증명하는 것
- SNOWFLAKE-C1: Snowflake 의 64bit 레이아웃(41+10+12 bit 분할)과 custom epoch 설계 — D10 에서 BIGINT fit 가능성의 사례 근거
- SNOWFLAKE-C2: 고가용성을 위해 노드 간 ID 조율 불필요 설계가 요건임 — 역설적으로, Snowflake 의 worker ID 는 사전 조율이 필요함을 시사 (D1 Snowflake 거부 근거)
- SNOWFLAKE-C3: Twitter 규모에서 프로세스당 초당 10k+ ID 요건이 존재함
- SNOWFLAKE-C4: 64bit 이하 ID 가 128bit 대안보다 선호됨 (MySQL BIGINT 컬럼 호환성)
- SNOWFLAKE-C5: 분산 환경에서 엄격한 전역 순서 대신 k-sorted 보장이 현실적 대안임
이 자료가 증명하지 않는 것
- Snowflake 의 worker ID 할당이 ZooKeeper 등 별도 외부 코디네이터 없이 동작할 수 있다는 것 (원문은 이를 직접 기술하지 않음)
- 단일 generator 환경(ca-skeleton 기본 가정)에서 Snowflake 레이아웃이 적합하다는 것
- 12bit sequence → ms당 4096개 → 초당 4M개 이론 최대 throughput (원문에서 직접 명시하지 않음, 계산 추론임)
- datacenter_id(5bit) + worker_id(5bit) 로의 10bit 분할 (이 구체적 분할은 원문
snowflake-2010README 에 없음 — 블로그 원문 또는 후속 구현체에서 언급됨) - Snowflake ID 가 GDPR Article 4(1) "identifier" 에 해당하는지 여부
- 단조 증가(monotonicity) 보장 (k-sorted 와 다름)
내 프로젝트에 적용하려면 추가 확인이 필요한 것
- D1 Snowflake 거부 근거 보강: SNOWFLAKE-C2 는 "조율 불필요" 를 요건 으로 제시하지만, 실제 Snowflake 구현에서 worker ID 사전 배정이 외부 코디네이터(ZooKeeper)를 요구한다는 사실은 원문이 아닌 구현체(소스코드)에서 확인 필요. 이 부분은 현재
needs-confirmation - D10 BIGINT fit: SNOWFLAKE-C4 는 64bit 이하를 사용한다는 Twitter 내부 요건을 기술함. PostgreSQL/MySQL 에서 BIGINT(8바이트)가 UUID(16바이트)보다 인덱스 성능에서 유리한지는 별도 벤치마크(UUID-V7-PERF-Cx, 미보관) 로 확인 필요
- D13 multi-tenancy: Snowflake 의 10bit machine ID 가 datacenter partition 힌트로 활용 가능한지는 배포 아키텍처에 따라 다르며, ca-skeleton 단일 generator 가정에서는 적용 범위 없음
메모 / Notes
- 원본 블로그 URL (
blog.x.com/engineering/en_us/a/2010/announcing-snowflake) 은 HTTP 403 반환.blog.twitter.com은 301 redirect →blog.x.com으로 redirect (같은 403). Wayback Machine (web.archive.org) 도 WebFetch 제한. 최종적으로 공식 GitHub 아카이브snowflake-2010태그 README 에서 추출. - 원문 README 에는 "datacenter_id 5bit + worker_id 5bit" 의 구체적 분할이 명시되어 있지 않다. 이 분할은 블로그 본문(접근 불가) 또는 후속 구현체에서 언급됨. Claims 에는 포함하지 않았고, 원문이 기술하는 "10 bits - gives us up to 1024 machines" 만 인용.
- SNOWFLAKE-C3 의 초당 4백만개 이론치는 12bit × 1000ms = 4,096,000/sec 계산 추론이며 원문에 없음 — branch-note 의 메모로만 남기고 Claims 에는 포함하지 않음.
- Snowflake 는 2010년 Apache Thrift 기반 Scala 서버로 구현되었고, 이후 Twitter-server 기반으로 재작성됨. GitHub 아카이브는 2021년 9월 archived (read-only).
- 추가로 봐야 할 동일 출처 페이지:
https://github.com/twitter-archive/snowflake/blob/snowflake-2010/README.md(raw 텍스트), Sonyflake(Sony), Instagram's ID generation approach (similar 64bit layout).
Related / 관련
- 같은 주제 관련 raw 자료:
- raw/official-docs/rfc9562-uuid — UUID v7 time-ordered 64bit 설계와 비교 (RFC9562-C1~C5)
- raw/company-tech-blogs/segment-ksuid — KSUID 158bit (32bit 초 단위 timestamp + 128bit 랜덤) 비교 (KSUID-C1~C3)
- raw/company-tech-blogs/planetscale-nanoid-api — NanoID + BIGINT dual column 사례 비교
- 이 자료를 인용한 wiki 요약: (생성 시 추가)
- 유사 Snowflake-variant 시스템: Sonyflake, Instagram ID (64bit = 41bit epoch ms + 13bit shard + 10bit sequence), Discord Snowflake (42bit timestamp + 10bit worker + 12bit increment)