[Paper] Stateless Snowflake: 클라우드-애그노스틱 Distributed ID Generator Using Network-Derived Identity

Source: arXiv - 2512.11643v1

Overview

이 논문은 Stateless Snowflake이라는 클라우드에 구애받지 않는 ID 생성 프로토콜을 소개한다. 기존 Snowflake 생성기에서 흔히 발생하는 수동 할당 혹은 중앙 집중식 워커 ID 관리라는 약점을 없앤다. 컨테이너의 프라이빗 IPv4 주소에서 노드 고유성을 추출함으로써, Kubernetes와 같은 현대적인 자동 스케일링 환경에서도 외부 코디네이션 서비스 없이 고처리량·k‑ordered ID를 제공한다.

Key Contributions

• 네트워크 기반 아이덴티티: 컨테이너의 프라이빗 IP 주소를 결정론적인 고유성 원천으로 사용해 정적 워커 ID나 ZooKeeper‑style 코디네이션이 필요 없게 함.
• 수정된 비트 레이아웃 (1‑41‑16‑6): IP‑파생 엔트로피에 16비트를 할당하면서도 단조로운 타임스탬프와 시퀀스 카운터를 유지, 노드당 밀리초당 최대 64 K ID 생성 가능.
• 클라우드에 구애받지 않는 구현: AWS, GCP, Azure에서 검증되어 주요 퍼블릭 클라우드 전반에 걸쳐 별도 클라우드‑특화 조정 없이 동작함을 입증.
• 무상태 마이크로서비스 친화성: 생성기를 경량 라이브러리 또는 사이드카 형태로 패키징할 수 있어 영구적인 상태를 요구하지 않으며, 컨테이너‑네이티브 배포 파이프라인에 자연스럽게 녹아듦.
• 상태 기반 생성기와 동등한 성능: 3‑노드 클러스터에서 약 31 K ID/초를 달성, 전통적인 Snowflake와 비슷한 처리량을 제공하면서 사실상 무제한 수평 확장성을 제공.

Methodology

1. 고유성 도출 – 컨테이너가 시작될 때 라이브러리는 프라이빗 IPv4 주소(예: 10.0.3.5)를 읽는다. 이 주소를 해시하고 16비트로 잘라 노드‑특정 식별자를 만든다. 동일 VPC/서브넷 내에서는 고유함이 보장된다.
2. 비트 할당 – 64‑비트 Snowflake ID는 다음과 같이 분할된다:
   • 1 비트 부호 비트(항상 0)
   • 41 비트 밀리초 정밀도 타임스탬프(커스텀 epoch 기준)
   • 16 비트 네트워크‑파생 노드 ID
   • 6 비트 밀리초당 시퀀스 카운터(노드당 ms당 최대 64 ID)
3. 생성 흐름 – 각 요청 시 생성기는:
   • 현재 타임스탬프를 읽는다.
   • 타임스탬프가 이전 호출과 동일하면 6‑비트 시퀀스를 증가시킨다(소진 시 다음 밀리초로 넘어감).
   • 세 필드를 결합해 64‑비트 정수로 만든 뒤 반환한다.
4. 무상태성 – 외부 저장소나 코디네이션이 전혀 필요하지 않다. 메모리에 유지되는 상태는 마지막 타임스탬프와 시퀀스 카운터뿐이며, 프로세스 재시작 시 자동으로 초기화된다.
5. 평가 설정 – 저자들은 AWS(EKS), GCP(GKE), Azure(AKS) Kubernetes 클러스터에 사이드카 형태로 배포했다. 파드 수와 네트워크 부하를 다양하게 바꾸며 처리량(TPS)과 지연시간을 측정했으며, ZooKeeper 기반 전통 Snowflake 구현과 비교했다.

Results & Findings

• 처리량 한계: 노드당 이론적 최대치(≈64 K TPS)는 네트워크 I/O와 컨테이너 스케줄링이 지연을 주도하기 때문에 실제로는 도달하지 않는다.
• 확장성: 노드를 추가하면 집계 TPS가 선형적으로 증가해 “실질적으로 무한한” 수평 확장성 주장이 입증된다.
• 단조성: 파드가 재생성·재스케줄링되더라도 IP‑파생 노드 컴포넌트가 결정론적이므로 클러스터 전체에서 ID가 k‑ordered 상태를 유지한다.
• 운영 단순성: 외부 코디네이션 서비스가 필요 없으므로 배포 복잡도와 장애 가능성이 크게 감소한다.

Practical Implications

• Zero‑ops ID 서비스: 팀은 생성기를 마이크로서비스에 직접 삽입하거나 사이드카로 실행할 수 있어 ZooKeeper, etcd, Consul 등을 별도로 프로비저닝할 필요가 없다.
• 원활한 자동 스케일링: 파드가 확대·축소될 때마다 새 인스턴스가 IP에서 고유한 노드 ID를 자동으로 얻어 급격한 스케일링 시 레이스 컨디션이 사라진다.
• 비용 절감: 코디네이션 레이어를 제거함으로써 인프라 비용이 감소하고 클라우드‑중립 CI/CD 파이프라인이 단순화된다.
• 기존 Snowflake ID와 호환: 64‑비트 포맷과 k‑ordering 덕분에 데이터베이스, 메시지 큐, 트레이싱 도구 등 기존 ID 파싱 로직을 그대로 사용할 수 있다.
• 엣지·하이브리드 배포: 방법이 프라이빗 IP만 필요하므로 온‑프레미스 VM, 엣지 디바이스, 멀티‑클라우드 클러스터에서도 동일하게 동작해 진정한 분산 아키텍처를 지원한다.

Limitations & Future Work

• IP 주소 충돌: 동일 서브넷 내에서 프라이빗 IP가 고유하다는 전제에 의존한다. 서로 다른 클러스터 간 CIDR이 겹칠 경우 충돌이 발생할 수 있으며, 이를 방지하려면 추가 네임스페이스 처리가 필요하다.
• 시퀀스 공간: 밀리초당 6비트 시퀀스는 노드당 최대 64 ID만 생성할 수 있다. 매우 버스트가 심한 워크로드에서는 이 한계에 도달할 수 있다.
• 시계 동기화: 모든 Snowflake 변형과 마찬가지로 시계가 느슨하게 동기화돼야 한다. 큰 시계 스큐가 발생하면 단조성이 깨질 수 있다.
• 향후 방향: 저자들은 MAC 주소와 IP 해시를 결합한 풍부한 엔트로피 소스를 탐색해 노드‑ID 공간을 확대하고, 경량 시계 드리프트 감지를 통합하며, 10 k 이상 노드 규모 클러스터에서의 성능을 평가하는 연구를 제안한다.

Authors

• Manideep Reddy Chinthareddy

Paper Information

• arXiv ID: 2512.11643v1
• Categories: cs.DC
• Published: December 12, 2025
• PDF: Download PDF