분산 시스템에서는 여러 서버가 동시에 데이터를 생성하기 때문에 전역적으로 충돌 없는 ID를 발급하는 것이 필수적이다. 단일 서버 환경에서는 DB의 AUTO_INCREMENT 컬럼이나 단순 카운터로도 충분하지만 분산 환경에서는 다음 문제가 발생한다.
- 여러 서버가 동시에 같은 ID를 발급할 수 있음
- 서버가 추가/제거될 때 ID 할당 규칙이 깨질 수 있음
- 높은 QPS 상황에서 고가용성과 성능을 동시에 만족해야 함
즉, 분산 환경에서는 전역적으로 유일하고 순서가 유지되며 빠르고 안정적으로 발급 가능한 ID 생성기가 필요하다.
이상적인 ID의 조건
분산 시스템에서 ID는 단순히 "고유"해야 하는 것을 넘어서 다음 조건을 만족하는 것이 바람직하다.
1. 유일성 (Uniqueness)
여러 서버와 여러 데이터센터에서 동시에 발급하더라도 충돌하지 않는 값을 보장해야 한다. 중복된 ID가 나오면 데이터 무결성이 깨지고 심각한 장애로 이어질 수 있다.
2. 정렬 가능성 (Orderliness)
시간 순서대로 ID가 생성된다면 데이터 정렬과 조회가 쉬워지고 인덱스 효율도 높아진다. 특히 로그나 트랜잭션 데이터는 순서 보장이 중요한 경우가 많다.
3. 고성능 (High Performance)
ID는 모든 데이터 생성의 필수 전제 조건이므로 초당 수십만~수백만 QPS를 감당할 수 있어야 한다. 병목 없이 빠르게 발급하는 것이 중요하다.
4. 확장성 (Scalability)
서버가 수평적으로 확장되더라도 별도의 충돌 처리 없이 자동으로 확장 가능한 구조여야 한다. 특정 서버나 데이터센터에 의존하지 않고 쉽게 늘리거나 줄일 수 있어야 한다.
단순한 방법과 한계
1. UUID (Universally Unique Identifier)
UUID는 충돌 확률이 극히 낮은 랜덤 기반 ID로 생성이 간단하고 중앙 관리가 필요 없다. 하지만 128비트의 긴 문자열 형태라 저장 효율이 낮고 정렬 가능성이 보장되지 않아 인덱스에 불리하다. 데이터베이스에서 성능 저하가 발생할 수 있다.
2. DB Auto-Increment
단일 데이터베이스의 자동 증가 컬럼을 사용하면 고유성과 순서가 모두 보장된다. 하지만 단일 서버에 의존하므로 단일 장애 지점(SPOF)이 생기며 수평 확장이 어렵다. 또한 트래픽이 커질수록 DB가 병목이 된다.
실제 사용되는 기법
1. 티켓 서버(Ticket Server)
중앙 서버 하나가 카운터처럼 ID를 발급해주는 방식이다. 유일성과 순서를 보장할 수 있지만 서버가 다운되면 전체 시스템이 멈춘다. 즉, 단일 장애 지점(SPOF) 문제가 있다.
2. 다중 티켓 서버 (Sharded Ticket Server)
여러 티켓 서버를 두고 ID 범위를 분산해서 발급한다. 예를 들어 서버 A는 짝수 ID, 서버 B는 홀수 ID를 발급하도록 나눌 수 있다. 이를 통해 단일 서버 장애를 피할 수 있지만 서버 간 동기화와 범위 관리가 복잡하다.
3. Twitter Snowflake 알고리즘
가장 널리 알려진 분산 ID 생성 알고리즘으로 시간 + 머신 ID + 시퀀스 번호를 조합해 유일성을 보장한다.
- 41비트 시간 정보: 약 69년간 사용 가능
- 10비트 머신 ID: 최대 1024대 서버 식별 가능
- 12비트 시퀀스 번호: 한 밀리초당 최대 4096개 ID 생성 가능
- 나머지 1비트: 부호 비트
이 구조를 통해 전역 유일성, 시간 순서성, 고성능을 동시에 만족한다. 다만 시스템 시간이 뒤로 밀릴 경우(Clock Skew 문제) 오작동 가능성이 있어 NTP 동기화 등 별도 고려가 필요하다.
4. 데이터베이스 High/Low 패턴
DB에서 큰 범위의 ID 블록을 미리 가져와서 애플리케이션에서 소모하는 방식이다. 예를 들어 DB에서 1~1000번 구간을 가져와 캐시에 저장해 두고 애플리케이션이 필요할 때 그 범위에서 ID를 할당한다. DB 부하는 줄어들지만 여러 서버가 동시에 사용할 경우 범위 관리가 까다롭다.
📝 느낀점
분산 ID 생성기는 단순히 "번호 뽑기" 문제가 아니라 확장성, 안정성, 정렬성까지 고려해야 하는 설계 문제라는 걸 느꼈다. 특히 Snowflake 같은 알고리즘은 "시간 + 노드 + 시퀀스" 조합으로 문제를 우아하게 해결하는데 이를 직접 구현해보면 서버 클러스터 동작을 이해하는 데 큰 도움이 될 것 같다. 또한, 단일 장애 지점(SPOF)이라는 개념이 설계 전반에서 얼마나 중요한지 다시 깨달았다. 단순히 성능이 아니라 운영 중 발생할 수 있는 장애를 어떻게 피할 것인가가 핵심이라는 점이 인상 깊었다.
