분산 시스템을 위한 유일 ID 생성기 설계 (가상 면접 사례로 배우는 대규모 시스템 설계)

분산 시스템에서 유일성이 보장되는 ID를 만드는 방법은 여러 가지다. 우리는 다음과 같은 선택지를 살펴볼 것이다.
- 다중 마스터 복제
- UUID
- 티켓 서버
- 트위터 스노플레이크 접근법

#### 다중 마스터 복제
데이터베이스의 auto_increment 기능을 활용하는 것이다. 다만 증가시킬때 1이 아닌 서버의 갯수만큼 증가시킨다. 이렇게 하면 규모 확장성 문제를 어느 정도 해결할 수 있다.  
1서버 - 1, 3 ,5 ....
2서버 - 2, 4, 6 ....
하지만 중대한 단점이 있다.
- 여러 데이터 센터에 걸쳐 규모를 늘리기 어렵다
- ID의 유일성은 보장되겠지만 그 값이 시간 흐름에 맞추어 커지도록 보장할 수는 없다
- 서버를 추가하거나 삭제할 때도 잘 동작하도록 만들기 어렵다

#### UUID
UUID는 컴퓨터 시스템에 저장되는 정보를 유일하게 식별하기 위한 128비트짜리 수다.

장점
- UUID를 만드는것은 단순하다. 서버 사이의 조율도 필요없다.
- 각 서버가 자기가 쓸 ID를 알아서 만드는 구조이므로 규모 확장도 쉽다.

단점
- ID가 길다
- ID를 시간순으로 정렬할 수 없다
- ID에 숫자가 아닌 값이 포함될 수 있다

#### 티켓 서버
티켓 서버는 유일성이 보장되는 ID를 만들어 내는 데 쓰일 수 있는 또 하나의 흥미로운 방법이다. 이 아이디어의 핵심은 auto_increment 기능을 갖춘 데이터베이스 서버를 중앙 집중형으로 하나만 사용하는 것이다.

장점
- 유일성 보장. 숫자로만 구성된 ID
- 구현이 쉽고, 중소 규모 애플리케이션에 적합
단점
- 티켓서버에 장애가 나면 이용하는 모든 서버에 영향
- 장애를 위해 여러 서버를 구성하면 동기화 이슈 발생

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

구성
사인비트 - 타임스탬프 - 데이터센터ID - 서버ID - 일련번호

- 사인(sign) 비트: 1비트를 할당한다. 지금으로서는 쓰임새가 없지만 나중을 위해 유보해 둔다. 음수와 양수를 구별하는 데 사용할 수 있을 것이다.
- 타임스탬프(timestamp): 41비트를 할당한다. 기원 시각(epoch) 이후로 몇 밀리초(millisecond)가 경과했는지를 나타내는 값이다. 본 설계안의 경우에 는 기원 시각으로 트위터 스노플레이크 구현에서 사용하는 값 1288834974 657(Nor 04, 2010, 01:42:54 UTC에 해당)을 이용할 것이다.
- 데이터센터 ID: 5비트를 할당한다. 따라서 25= 32개 데이터센터를 지원할 수 있다.
- 서버 ID: 5비트를 할당한다. 따라서 데이터센터당 32개 서버를 사용할 수 있다.
- 일련번호: 12비트를 할당한다. 각 서버에서는 ID를 생성할 때마다 이 일련 번호를 1만큼 증가시킨다. 이 값은 1밀리초가 경과할 때마다 0으로 초기화 (reset)된다.

타임스탬프는 제한된 비트수가있기때문에 특정 기간이후는 오버플로가날 수 있다.