튜토리얼 목록

분산시스템위한 ID

DDX LAB·5일 전
섹션 01

왜 분산 유일 ID가 필요한가

여러 서버가 동시에 데이터를 만들 때도 서로 겹치지 않는 번호가 필요한 이유와 실제 사용처를 이해합니다.

분산 유일 ID 생성기는 여러 서버가 동시에 데이터를 만들어도 서로 겹치지 않는 식별자를 빠르게 발급하는 장치입니다. 사용자, 주문, 게시글, 결제, 채팅 메시지처럼 시스템 안에서 각각을 정확히 가리켜야 하는 데이터에 붙입니다.

분산 시스템에서는 모든 서버가 중앙 데이터베이스에 매번 묻지 않고도 “이 번호는 나만 사용한다”라고 확신할 수 있어야 합니다. 결국 이 문제는 단순한 번호 매기기가 아니라 성능, 장애 대응, 확장성을 함께 해결하는 설계 문제입니다.

섹션 02

요구사항을 정확히 해석하기

유일성, 64비트, 숫자형, 시간 정렬, 처리량이라는 조건이 실제 설계에서 무엇을 의미하는지 살펴봅니다.

이 사례에서는 ID가 겹치지 않고, 64비트 숫자로 표현되며, 대체로 생성 시간순으로 커지고, 초당 10,000개 이상 생성되어야 합니다. 여기에 실무에서는 발급 지연, 장애 시 동작, 서버 증설 방식, 운영 난이도도 함께 봐야 합니다.

참고
요구사항끼리는 충돌할 수 있습니다. 완벽한 순차 증가를 원하면 중앙 조정이 쉬워지지만 느려지고, 완전한 분산 생성을 원하면 시계와 서버 번호 관리가 어려워집니다.
섹션 03

후보 방식 비교하기

다중 마스터, UUID, 티켓 서버, 스노플레이크가 어떤 문제를 해결하고 어떤 대가를 치르는지 비교합니다.

다중 마스터 방식은 서버마다 다른 수열을 사용하고, UUID는 각 서버가 독립적으로 긴 값을 만들며, 티켓 서버는 중앙 발급기가 순번을 나눠줍니다. 스노플레이크는 시간·서버 위치·같은 순간의 순번을 한 숫자에 합쳐 중앙 조정 없이 생성합니다.

어느 방식이 절대적으로 최고인 것은 아니며, ID 길이, 정렬성, 장애 허용, 운영 복잡도 중 무엇을 우선하는지에 따라 선택이 달라집니다.

섹션 04

스노플레이크 ID의 구조

64비트 안에 시간, 데이터센터, 서버, 일련번호를 어떻게 배치하고 결합하는지 이해합니다.

대표적인 구성은 1비트 부호 + 41비트 타임스탬프 + 5비트 데이터센터 ID + 5비트 서버 ID + 12비트 일련번호입니다. 각 조각이 “언제, 어디서, 같은 순간의 몇 번째인지”를 나타내므로 서로 통신하지 않는 서버도 다른 숫자를 만들 수 있습니다.

참고
그림 설명: 하나의 긴 64비트 막대를 다섯 칸으로 나누고, 왼쪽의 시간 영역이 가장 크며 오른쪽 끝에 짧은 일련번호 영역이 놓인 형태입니다.
섹션 05

운영 중 발생하는 위험

알고리즘보다 더 중요한 시계, 서버 번호, 용량 한계, 보안 문제를 살펴봅니다.

가장 큰 위험은 서버 시간이 뒤로 가는 현상과 같은 서버 ID가 두 노드에 중복 배정되는 현상입니다. 둘 중 하나만 발생해도 이미 사용한 시간·노드 조합을 다시 사용하여 충돌 가능성이 생깁니다.

따라서 생성 코드는 짧아도, 시간 동기화 정책, 노드 등록, 장애 복구, 모니터링까지 포함해야 안전한 시스템이 됩니다.

섹션 06

상황에 맞는 방식 선택하기

모든 서비스에 스노플레이크가 필요한 것은 아니며, 규모와 요구에 따라 가장 단순한 해법을 고르는 기준을 정리합니다.

데이터베이스가 한 대이고 쓰기 경로가 단순하면 auto_increment나 데이터베이스 시퀀스가 가장 좋은 출발점입니다. 여러 지역에서 독립적으로 쓰고, 64비트 숫자와 시간 정렬이 중요하면 스노플레이크가 적합하며, 조정 없는 단순 생성이 더 중요하면 UUID 계열이 편합니다.

참고
좋은 설계는 가장 복잡한 기술을 고르는 것이 아니라 현재 요구를 만족하는 가장 단순한 기술을 고르고, 확장 시점과 이전 경로를 준비하는 것입니다.