•
이번 장에서는 분산 시스템에서 사용될 유일 ID 생성기를 설계한다.
•
이 질문을 받으면 보통은 DB에 의존적인 auto_increment 속성을 먼저 떠올릴텐데, 이는 분산 환경에서 적합하지 않으며 DB 서버 하나로는 요구를 감당하기가 어려울 것이다.
1단계 문제 이해 및 설계 범위 확정
•
설계 문제를 풀어낼 때, 항상 가장 먼저 할 일은, 모호한 요구사항을 질문을 통해 풀어내는 것이다.
•
유일 ID 생성기 설계를 위해 해볼만한 질문은 다음과 같다.
◦
ID는 어떤 특성을 가져야 하는가?
▪
유일하던가, 정렬 가능하다던가 등
◦
ID 생성 규칙은 어떻게할 것인가?
▪
ID가 1씩 증가한다던가, 시간 흐름에 따라 변한다던가
◦
ID는 어떻게 구성할 것인가?
▪
숫자로만 구성된다던가, 문자열로만 구성된다던가
◦
시스템 규모는 어느정도인가?
▪
초당 n개의 ID를 만들 수 있어야 한다던가
2단계 개략적 설계안 제시 및 동의 구하기
•
분산 시스템에서 유일성을 보장해야 한다면 다음과 같은 선택지가 있다.
◦
다중 마스터 복제
◦
UUID
◦
티켓 서버
◦
트위터 스노플레이크
다중 마스터 복제
•
이 접근법은 데이터베이스의 auto_increment 기능을 사용하는 것이다.
•
다만, 다음 ID 값을 요청할 때, 1씩 증가하는 것이 아닌 서버의 수 k만큼씩 증가시킨다.
•
이 방법은 다음과 같은 단점을 가진다.
◦
여러 데이터 센터에 걸쳐 규모를 늘리기 어렵다.
◦
ID의 유일성은 보장되지만 값이 시간 흐름에 맞추어 커진다고 보장할 수는 없다.
◦
서버를 추가하거나 삭제할 때 처리가 복잡하다.
UUID
•
UUID는 유일성이 보장되는 ID를 만드는 또 하나의 간단한 방법으로 중복없이 ID를 제공할 수 있다.
•
장점
◦
UUID 구현이 단순하다.
◦
각 서버가 자기가 쓸 ID를 알아서 만드는 구조이므로 서버 확장도 쉽다.
•
단점
◦
ID가 128비트로 길다. 스펙이 부족한 경우, 더 짧은 UUID를 사용하던가 해야한다.
◦
ID를 시간순으로 생성할 수 없다.
◦
ID에 숫자가 아닌 값이 포함될 수 있다.
티켓 서버
•
티켓 서버는 유일성이 보장되는 ID를 만들어 내는 하나의 방법이다.
•
이 아이디어는 auto_increment 기능을 갖춘 데이터베이스 서버, 즉 티켓 서버를 중앙 집중형으로 하나만 사용하는 것이다.
•
장점
◦
유일성이 보장되는 오직 숫자로만 구성된 ID를 쉽게 만들 수 있다.
◦
구현하기 쉽고, 중소 규모 애플리케이션에 적합하다.
•
단점
◦
티켓 서버가 단일 실패 지점이 된다.
▪
이 이슈를 피하려면 분산하게 되는데, 데이터 동기화같은 새로운 문제가 발생한다.
스노플레이크 접근법
•
트위터가 사용하는 ID 생성 기법으로 ID를 분할해 구현하는 방식이다.
•
다음과 같이 예시를 들 수 있다.
◦
사인 비트(1비트) : 추후 활용을 위해 남겨두는 여분의 비트다.
◦
타임스탬프(41비트) : 밀리초를 이용해 시간의 흐름을 표현하기 위한 비트다.
◦
데이터센터 ID(5비트) : 사용가능한 비트를 할당한다. 5비트의 경우, 최대 32개의 데이터센터를 지원할 수 있다.
◦
서버 ID(5비트) : 사용가능한 양의 비트를 할당한다. 5비트의 경우, 최대 32개의 서버를 지원할 수 있다.
◦
일련번호(12비트): 각 서버에서는 ID를 생성할 때마다 이 일련 번호를 1만큼 증가시킨다. 이 값은 1밀리초가 경과할 때마다 0으로 초기화한다.
3단계 상세 설계
•
스노플레이크 접근법을 사용하는 경우 상세 설계는 다음과 같다.
•
애플리케이션 레벨에서 값의 변경이 발생하는 단계는 타임스탬프, 일련번호 정도이다.
타임스탬프
•
타임스탬프는 시간의 흐름에 따라 점점 큰 값을 가지게 되므로 결국 해당 항목을 사용하면 ID를 시간순으로 정렬이 가능해진다.
•
임의로 할당한 41비트로 표현가능한 최댓값은 2^41 - 1 밀리초이며 이는 대략 69년에 해당한다. 따라서 이는 최대 69년 동안 정상적으로 동작할 수 있다.
일련번호
•
일련번호는 12비트로 할당했으므로 1밀리초당 최대 4096개의 동시요청을 처리할 수 있다.
4단계 마무리
•
이번 장에서는 유일성이 보장되는 ID 생성기 구현에 사용되는 전략들을 살펴보았다.
◦
다중 마스터 복제
◦
UUID
◦
티켓 서버
◦
스노플레이크
•
설계를 진행하고 시간이 조금 남는 다면 다음을 추가로 논의해볼 수 있다.
◦
시계 동기화
▪
ID 생성 서버들마다 다른 시계를 사용하게될 가능성이 있다. NTP는 이를 해결하는 가장 보편적 수단이다.
◦
각 절의 길이 최적화
▪
임의로 설정한 비트를 요구사항에 맞춰 재설계해볼 수 있을 것이다.
◦
고가용성
▪
ID 생성기는 필수 불가결 컴포넌트이므로 아주 높은 가용성을 제공하기 위해 다양한 방법들을 제안할 수 있다.
