109 lines
12 KiB
Markdown
109 lines
12 KiB
Markdown
---
|
||
title: company-tech-blog / Twitter Engineering — Announcing Snowflake (분산 고유 ID 생성 네트워크 서비스)
|
||
source_type: company-tech-blog
|
||
url: https://blog.x.com/engineering/en_us/a/2010/announcing-snowflake
|
||
archive_url: https://github.com/twitter-archive/snowflake/tree/snowflake-2010
|
||
related_branches: [feature-resource-identifier-contract]
|
||
related_projects: [ca-skeleton]
|
||
tags: [company-tech-blog, ca-skeleton, data-modeling, resource-identifier]
|
||
created: 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-2010` README 에서 추출.
|
||
> 검증된 요약은 `/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-2010` README §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-2010` README §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-2010` README §Requirements / Compact, line 37
|
||
|
||
> [§Requirements / Performance] "minimum 10k ids per second per process"
|
||
— GitHub `snowflake-2010` README §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-2010` README §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-2010` README 에 없음 — 블로그 원문 또는 후속 구현체에서 언급됨)
|
||
- 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)
|