TIL

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

• 분산 시스템에선 auto_increment로는 유일 ID를 보장할 수 없다.
• 한 대의 DB 서버로는 트래픽을 감당할 수 없고 지연을 낮추기도 힘들다.

유일 ID 생성기 요구 사항 예시

• ID는 유일해야 한다.
• ID는 숫자로만 구성되어야 한다.
• ID는 64비트로 표현될 수 있는 값
• ID는 발급 날짜에 따라 정렬 가능해야 한다.
• 초당 10,000개 ID를 만들 수 있어야 한다.

유일 ID 생성기 설계 방안

• 다중 마스터 복제 (multi-master replication)
• UUID (Universally Unique Identifier)
• 티켓 서버 (ticket server)
• 트위터 스노플레이크 접근법 (twitter snowflake)

다중 마스터 복제

• 데이터베이스의 auto_increment 기능을 활용하는 방법
• 단 ID 값을 1만큼이 아닌 k만큼 증가시킨다. (k: 사용 중인 DB 서버의 수)
• DB 수를 늘리면서 유일 ID가 보장되고 초당 생산 가능 ID 수도 늘릴 수 있다.
• 문제점
  • 여러 데이터 센터에 걸쳐 규모를 늘리기 어렵다.
  • ID 유일성은 보장되겠지만 그 값이 시간 흐름에 맞추어 커지도록 보장할 순 없다.
  • 서버를 추가하거나 삭제할 때도 잘 동작하도록 만들기 어렵다.

UUID

• UUID는 128비트짜리 수로 충돌 가능성이 지극히 낮다.
  • 위키에 의하면초당 10억 개의 UUID를 100년 동안 계속 만들어야 충돌 확률이 50%로 올라간다고 함
• UUID는 서버 간 조율 없이 독립적으로 생성 가능하다.
• 장점
  • UUID 생성은 서버 사이 조율이 필요 없고 동기화 이슈도 없어 단순
  • 각 서버가 자기가 쓸 ID를 만드는 구조라 규모 확장도 쉽다.
• 단점
  • ID가 128비트로 길다. (요구사항에 맞지 않음)
  • ID를 시간순으로 정렬할 수 없다.
  • ID에 숫자가 아닌 값이 포함된다. (요구사항에 맞지 않음)

티켓 서버

• 티켓 서버 아이디어의 핵심은 auto_increment 기능을 갖춘 DB 서버를 중앙 집중형으로 하나만 사용하는 것
• 장점
  • 유일성이 보장되는 숫자로만 구성된 ID를 쉽게 만들 수 있다.
  • 구현하기 쉽고 중소 규모 애플리케이션에 적합
• 단점
  • 티켓 서버가 SPOF가 된다.
  • 그렇다고 티켓 서버가 여러 대가 되면 동기화 문제가 발생

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

• 트위터에서 사용하는 독창적인 ID 생성 기법
• 64비트 ID 구조를 아래와 같이 구성한다.
  • 사인(sign) 비트: 1비트를 할당. 당장은 쓰임새가 없지만 음수, 양수 구분에 사용할 수 있을 것
  • 타임스탬프: 41비트를 할당. 기원 시간 이후로 몇 밀리초 경과했는지 나타내는 값
  • 데이터센터 ID: 5비트 할당. 즉 2^5=32개 데이터센터를 지원할 수 있다.
  • 서버 ID: 5비트 할당. 데이터센터당 32개 서버를 사용 가능
  • 일련번호: 12비트 할당. 각 서버는 ID를 생성할 때마다 이 번호를 1씩 증가시킨다. 이 값은 1밀리초가 경과할 때마다 0으로 초기화된다.

마무리

추가로 다음과 같은 사안을 논의할 수도 있다.

• 시계 동기화 (time synchronization)
  • 위 방법들은 ID 생성 서버들이 전부 같은 시계를 쓴다고 가정한 방법
  • 한 서버가 여러 코어에서 실행될 경우 유효하지 않을 수도 있다.
  • 여러 서버가 물리적으로 독립된 여러 장비에서 실행되는 경우도 마찬가지
  • NTP(Network Time Protocol)은 이 문제를 해결하는 가장 보편적인 수단
• 각 절의 길이 최적화
  • 동시성이 낮고 수명이 긴 애플리케이션이라면 일련번호 절의 길이를 줄이고 타임스탬프 길이를 늘리는 것이 효과적
• 고가용성
  • ID 생성기는 필수 불가결이므로 아주 높은 가용성을 제공해야 한다.