분산 시스템을 위한 유일 ID 생성기 설계

데이터베이스의 PK 세팅 전략을 세우려 한다.

그냥 DB에서 auto_increment 하면 되지 않나? ➡️ 분산되어있는 환경이기 때문에 불가능하다.

분산 DB 환경에선 생각보다 쉽지 않다. 방법을 찾아보자.

1단계 : 문제이해 및 설계범위 확정

시스템 설계 면접의 첫 단계는 적절한 질문을 통해 모호함을 없애고 설계 방향을 정하는 것이다.

지원자 vs 면접관 질문 예시

지원자 : ID는 어떤 특성을 갖나요?
면접관 : 유일해야 하고, 정렬 가능해야합니다
지원자 : 새로운 레코드에 붙일 ID는 항상 1만큼 큰 값이여야 하나요?
면접관 : ID의 값은 시간이 흐름에 따라 커지지만, 언제나 1씩 증가한다고는 할 수 없습니다.
지원자 : ID는 숫자로만 구성되나요?
면접관 : 그렇습니다.
지원자 : 시스템의 규모는 어느정도인가요?
면접관 : 초당 10,000 ID를 생성할 수 있어야 합니다.

질문을 통해 유추할 수 있는 요구사항은 다음과 같다.

1. ID는 유일해야 함
2. ID는 숫자로만 구성되어야 함
3. ID는 64비트로 표현될 수 있는 값이어야 함
4. ID는 발급날짜에 따라 정렬가능해야 함
5. 초당 10,000 ID 를 생성할 수 있어야 함

---

2단계 : 개략적 설계안 제시 및 동의 구하기

분산 시스템 상에서 ID 생성 전략을 알아보고 각각의 장단점과 위의 질문에 대해 적합한 전략인지 살펴보자.

다중 마스터 복제

이 접근법은 기본적으로 DB의 auto_increment 속성을 활용한다. 1만큼 증가시키는 것이 아닌 k(DB의 숫자)만큼 증가시킨다.

단점

• 규모를 확장하거나 축소할 때 문제가 있음

UUID

UUID는 컴퓨터 시스템에 저장되는 정보를 유일하게 식별하기 위한 128비트 짜리 숫자이다. UUID는 충돌 가능성이 지극히 낮다.(중복 UUID가 생길 확률은 초당 10억개의 UUID를 100년동안 만들어야 생김)

장점

• 단순함
• 서버 간 조율이 필요하지 않으므로 동기화 이슈 없음
• 규모 확장 간편함

단점

• 128비트로 길다
• 시간 순으로 정렬할 수 없음
• ID에 숫자가 아닌 값이 포함됨

티켓 서버

티켓 서버는 auto_increment 기능을 하는 중앙 서버에서 유일키를 생성해 내려주는 방식이다.

장점

• 유일성이 보장되는 숫자로만 구성된 ID를 쉽게 만들 수 있음
• 구현이 쉽고 중소 규모의 어플리케이션에 적합

단점

• 티켓서버가 SPOF(Single-Point-of_Failure)가 된다는 엄청난 단점

트위터 스노플레이크 접근법

이 전략은 기본적으로 ID를 여러 절로 분할한다.

섹션	설명
사인 비트	1비트를 할당한다. 쓰임세가 없지만 음양수를 구별할 때 사용할 수 있다.
타임스탬프	41비트를 할당한다. 기원시각으로부터 몇 밀리초가 지났는 지 알 수 있는 값이다.
Work ID	10비트를 할당한다.
일련번호	12비트를 할당한다. 각 서버에서는 ID를 생성할 때마다 1씩 증가시킨다. 1밀리초가 경과했을 때 0으로 초기화한다.