요구사항
- ID는 유일해야 한다.
- ID는 숫자로만 구성되어야 한다.
- ID는 64비트로 표현될 수 있는 값이어야 한다.
- ID는 발급 날짜에 따라 정렬 가능해야 한다.
- 초당 10,000개의 ID를 만들 수 있어야 한다.
개략적 설계
- 다중 마스터 복제 (multi-master replication)
- UUID (universally unique identifier)
- 티켓 서버 (ticket server)
- 트위터 스노플레이크 (twitter snowflake) 접근법
다중 마스터 복제 (multi-master replication) :
다음 id값을 구할때 k(데이터베이스 서버의 수) 만큼 증가
- 장점 : 규모 확장성 문제를 해결할 수 있다.
- 단점
ㄴ 여러 데이터 센터에 걸쳐 규모를 늘리기 어렵다.
ㄴ ID의 유일성은 보장 되겠지만 그 값이 시간 흐름에 맞추어 커지도록 보장할 수는 없다.
ㄴ 서버를 추가하거나 삭제할 때도 잘 동작하도록 만들기 어렵다.
UUID :
컴퓨터 시스템에 저장되는 정보 유일하게 식별하기 위한 128비트짜리 수
- 장점
ㄴ UUID 를 만드는 것은 단순하다. 서버 사이의 조율이 필요 없으므로 동기화 이슈도 없다.
ㄴ 각 서버가 자기가 쓸 ID를 알아서 만드는 구조이므로 규모 확정도 쉽다.
- 단점
ㄴ ID가 128비트로 길다. 이번 장에서 다루는 문제의 요구사항은 64비트이다.
ㄴ ID를 시간 순으로 정렬할 수 없다.
ㄴ ID에 숫자(numeric) 아닌 값이 포함될수 있다.
티켓 서버 :
플리커(Flicker)에서 사용되는 기술로 중앙 집중형으로 하나만 써서 유일성이 보장되는 ID를 만들어 내는법.
- 장점
ㄴ 유일성이 보장되는 오직 숫자로만 구성된 ID를 쉽게 만들 수 있다.
ㄴ 구현하기 쉽고, 중소 규모 애플리케이션에 적합하다.
- 단점
ㄴ 티켓 서버가 SPOF(Single-Point-Of-Failure)가 된다.
트위터 스노플레이크 접근법 :
| 1비트 | 41비트 | 5비트 | 5비트 | 12비트 |
| 0 | 타임스탬프 | 데이터센터 ID | 서버ID | 일련번호 |
- 사인비트 : 1비트 할당.
- 타임스탬프 : 41비트 할당
- 데이터센터ID 5비트 할당. 따라서 2^5 = 32개의 데이터 센터 사용
- 서버 ID : 5비트 할당. 따라서 2^5 = 32개의 서버 사용
- 일련번호 : 각서버마다 1만큼 증가. 1밀리초가 경과할 때마다 0으로 초기화
추가 논의사항
- 시계 동기화 : ID생성 서버들이 서로 다른 시계를 사용한다면 ?
ㄴ NTP(Network Time Protocol)이 해결하는 가장 보편적 수단
- 각 절(section) 길이 최적화 : 동시성이 낮고 수명이 긴 어플리케이션의 경우 ?
ㄴ 일련번호 길이를 줄이고 타임스탬프 길이를 늘리는 것이 효율적
- 고가용성 : 필수 컴포넌트이므로 높은 가용성을 제공해야함.
'모음 > [가상면접 사례로 배우는 대규모 시스템 설계 기초]' 카테고리의 다른 글
| [가상면접 사례로 배우는 대규모 시스템 설계 기초] ch12. 채팅 시스템 설계 (0) | 2024.06.15 |
|---|---|
| [가상면접 사례로 배우는 대규모 시스템 설계 기초] Ch10. 알림 시스템 설계 (0) | 2024.05.30 |