7장 - 분산 시스템을 위한 유일 ID 생성기 설계
목표
분산 환경에서는 auto_increment 데이터 베이스 기본키를 사용하지 못한다.
서버 한대로는 요구를 감당할 수 없으며, 지연시간을 낮추기 어려움
유일 ID 생성기를 설계해 보자.
1단계 문제 이해 및 설계 범위 확정
지원자의 질문
- ID는 어떤 특성인지?
- 새로운 ID는 항상 1만큼 큰 값인지
- ID는 숫자로만 구성되어있는지?
- 시스템 규모는?
면접관 대답
- ID는 유일해야하며, 정렬 가능해야함
- 시간의 흐름에 커진값이지만 항상 1증가를 보장하지는 않아도됨
- 숫자로만 구성
- 시스템 규모는 초당 10,000개 ID를 생성
개략적 설계안 제시 및 동의 구하기
유일성이 보장되는 ID를 만드는 방법을 먼저 알아보자
다중 마스터 복제
데이터베이스 auto_increment기능을 활용
k개의 데이터베이스 서버에 대해 id값을 k만큼 증가시킴
- 데이터베이스 서버 1 : 1,3,5 ...
- 데이터베이스 서버 2 : 2,4,6 ...
데이터베이스 수를 늘리면 초당 생성 가능 ID수도 늘릴 수 있다는 장점 존재
단점
- 여러 데이터 센터에 걸쳐 규모를 늘릴 수 없음
- 시간 흐름에 맞추어 커지도록 보장 불가능
- 서버를 추가, 삭제시 잘 동작 불가능
UUID
저장되는 정보를 유일하게 식별하기 위한 128비트 짜리 수
중복되기 힘드므로 각각 서버간에 각각 사용가능
장점
- UUID를 만드는 것은 단순하다, 서버사이의 동기화 문제도 일어나지않음
- 각각 만드므로 규모확장 쉬움
단점
- ID길이가 128비트로 고정되며 길다
- 시간 순으로 정렬이 불가능
- ID에 숫자가 아닌 값이 포함
티켓서버
auto_increment 기능을 갖춘 데이터베이스 서버 = 티켓서버를 중앙 집중형으로 하나만 사용하는 것이다.
장점
- 조건을 만족하는 ID를 쉽게 만들 수 있다.
- 구현핳기 쉽고, 중소 규모 애플리케이션에 적합하다.
단점
- 티켓 서버가 SPOF가 된다.
트위터 스노플레이크 접근법
- 사인비트 : 나중을 위해 유보해 두는 값
- 타임스탬프 : 기원 시각 이후 몇 밀리초가 경과했는지를 나타내는 값 = 시간 값
- 데이터센터 ID : 2^5=32개 데이터센터 지원
- 서버 ID : 2^5=32개 서버 지원
- 일련번호 : 각 서버는 생성시 1씩증가, 1밀리초가 경과할 때마다 0으로 초기화
3단계 상세 설계
트위터 스노플레이크 접근법을 사용하여 설계를 진행해 보자
데이터 센터 ID와 서버 ID는 시스템이 시작할 때 결정된다.
타임스탬프
스노플레이크에서 타임스탬프가 시간이 흐름에 따라 점점 큰 값을 갖게 되므로, 정렬 가능
일련번호
어떤 서버가 같은 밀리초 동안 하나 이상의 ID를 만들어 낸 경우에만 0보다 큰 값을 갖게 된다.
4단계 마무리
유일성이 보장되는 ID 생성기 구현에 쓰일 수 있는 다양한 전략 등을 살펴보았다. 설계를 진행하고 시간이 조금 남는다면 다음을 논의해 볼 수 있다.
- 시계 동기화 : 생성 서버들의 시계를 동기화할 필요성이 존재한다. -> ntp로 해결
- 각 절(section)의 길이 최적화 : 서버의 특성마다 다른 ID를 생성
동시성이 낮고 수명이 긴 애플리케이션이라면 일련번호를 줄이고 타임스탬프를 늘리는 것이 효과적 - 고가용성 : 필수 불가결 컴포넌트(mission critical) 이므로 아주높은 가용성을 제공
- mission critical : 사업 운영 또는 단체에 필수적인 요인