[가상 면접 사례로 배우는 대규모 시스템 설계 기초] 7장. 분산 시스템을 위한 유일ID 설계

 

'auto_increment 속성이 설정된 관계형 데이터베이스의 기본 키를 쓰면 되지 않을까?'
-> 분산 환경에서는 이 접근법이 안 먹힐텐데.. DB 한대로는 요구를 감당할 수 없음
-> 여러 DB server를 쓰는 경우에는 지연 시간(delay)을 낮추기가 무척 힘들 것

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

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

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

분산 시스템에서 유일성이 보장되는 ID를 만드는 여러 가지 방법

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

1. 다중 마스터 복제 (multi-master replication)
   [사진첨부]

• 데이터베이스의 auto_increment 기능을 활용. 다만 다음 id의 값을 구할 때는 1만큼 증가시켜서 얻 게 아니라, k만큼 증가
  ( k=현재 사용 중인 데이터 베이스 서버의 수 )
• 규모 확장성 문제 해결 가능. DataBase의 수를 늘리면 초당 생산 가능 ID 수도 늘릴 수 있기 때문
• [ 단점 1 ] 여러 데이터 센터에 걸치 규모를 늘리기 어려움
  [ 단점 2 ] ID의 유일성은 보장되겠지만 그 값이 시간 흐름에 맞추어 커지도록 보장할 수는 없음
  [ 단점 3 ] 서버를 추가하거나 삭제할 때도 잘 동작하도록 만들기 어려움

1. UUID

• UUID는 컴퓨터 시스템에 저장되는 정보를 유일하게 식별하기 위한 128비트짜리 수
• UUID 값은 충돌 가능성이 지극히 낮음
  [사진]
• [ 장점 1 ] UUID를 만드는 것은 단순함. 서버 사이의 조율 또한 필요 없음 - 동기화 이슈 없음
• [ 장점 2 ] 각 서버가 자기가 쓸 ID를 알아서 만드는 구조라 규모 확장도 쉬움
• [ 단점 ] ID가 128비트로 김, ID를 시간순으로 정렬할 수 없음, ID에 숫자(numeric)가 아닌 값이 포함될 수 있음

1. 티켓 서버
   [사진]

• 해당 아이디어의 핵심: auto_increment 기능을 갖춘 데이터베이스 서버, 즉 티켓 서버를 중앙 집중형으로 하나만 사용하는 것
• [ 장점 1 ] 유일성이 보장되는 오직 숫자로만 구성된 ID 쉽게 생성 가능
• [ 장점 2 ] 구현하기 쉽고, 중소 규모 애플리케이션에 적합
• [ 단점 ] 티켓 서버가 SPOF(Single-Point-of-Failure)가 됨. 이 서버에 장애가 발생하면, 모든 시스템이 영향을 받음

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

• 생성해야 하는 ID의 구조를 여러 절(section)로 분할하는 것
  [사진]

* 사인(sign) 비트: 1비트 할당. 음수 양수 구별하는 곳에 사용
* 타임스탬프(timestamp): 41비트 할당. 기원 시각(epoch) 이후로 몇 밀리초가 경과했는지를 나타내는 값. 
* 데이터 센터 ID: 5비트 할당. 데이터센터당 32개의 서버 사용 가능.
* 서버 ID: 5비트 할당. 데이터 센터당 32개의 서버 사용 가능
* 일련번호: 12비트 할당. 각 서버에서는 ID를 생성할 때마다 이 일련번호를 1씩 증가. 이 값은 1밀리초 경과 마다 0으로 초기화(reset)

3. 상세 설계

[사진]
데이터센터 ID와 서버 ID는 시스템이 시작될 때 결정. 일반적으로 시스템 운영 중에는 바뀌지 않음.
타임스탬프나 일련번호는 ID 생성기가 돌고 있는 중에 만들어지는 값

타임스탬프
[사진]
41비트로 표현할 수 있는 타임스탬프의 최댓값은 대략 69년에 해당
-> ID생성기는 69년 동안만 정상 동작 : 이후에는 기원 시각을 바꾸거나, ID 체계를 다른 것으로 이전(migration)해주어야 함

4. 마무리

추가 논의 point

시계 동기화(clock synchronization)
- ID 생성 서버들이 전부 다른 시계를 사용한다고 가정할 시..
- 하나의 서버나 여러 코어에서 실행될 경우
- 여러 서버가 물리적으로 독립된 여러 장비에서 실행되는 경우
- NTP(Network Time Protocol)이 문제를 해결하는 가장 보편적 방법

각 절(section)의 길이 최적화
- 동시성이 낮고 수명이 긴 앱 같은 경우 일련번호 절 길이 줄이고
  타임스탬프 길이 늘리는 것이 효과적

고가용성(high availability)
ID 생성기는 필수 불가결 컴포넌트 이므로 아주 높은 고가용성을 제공해야 함.