[가면대설] 7장. 분산 시스템을 위한 유일 ID 생성기 설계

유일 ID가 필요한 이유

유일 ID가 쓰이는 곳

• 많은 양의 데이터가 갑자기 생성될 때 (채팅 앱)
• 데이터의 중복을 방지하고 싶을 때

토스 페이먼츠의 객체 ID 생성

https://yozm.wishket.com/magazine/detail/2161/

좋은 객체 ID(Object ID) 만들기 | 요즘IT

https://jaeseo0519.tistory.com/415

[Java] 분산 시스템에서 다양한 유일 ID 생성 전략 탐색 및 테스트

 

ID를 생성할 때 밑의 요구사항을 해결해야 한다고 가정한다.

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

 

SQL의 auto_increment

auto_increment는 관계형 데이터베이스에서 테이블에 새로운 레코드가 추가될 때 자동으로 유일한 숫자를 부여하는 SQL 필드다.

작은 프로젝트에서는 잘 쓰일 수 있으나 분산 환경에서는 쓰이기가 힘든데, 이는 auto_increment를 사용해 유일 ID를 생성하는 방법인 티켓 서버에서 설명하겠다.

 

https://www.w3schools.com/sql/sql_autoincrement.asp

W3Schools.com

 

 

다중 마스터 복제

다중 마스터 복제는 유일 ID 생성 방법은 아니고, DB를 복제하는 방법이다. 1장에서 배운 주(Master) - 부 (Slave) 구조에서 여러 개의 주 DB를 두는 방법이다. (쓰기 연산을 담당하는 주 DB가 여러 개 있고 모든 주 DB 서버는 쓰기 요청을 받을 수 있다.)

데이터베이스의 auto_increment 기능을 활용해 각 주 DB가 받는 ID를 나눈다. 말로만 설명하면 어려우니 예시를 보자.

 

PostgreSQL를 활용한 다중 마스터 복제

 

• 노드 A, B, C, D 모두 쓰기 연산이 가능한 주 DB다.
• 다른 노드로부터 쓰기 요청이 오면 주 DB 중 한 개가 쓰기 연산을 수행한다.
• 특정 시점이 지난 뒤 각 주 DB들은 다른 주 DB가 쓴 내용을 자기한테로 복제한다.

이때 서로 쓴 데이터를 구별하기 위해 auto_increment를 이용해 ID를 부여한다. 

• A는 0부터 시작해 4씩 증가 : 0, 4, 8 ...
• B는 1부터 시작해 4씩 증가 : 1, 5, 9 ...
• ...

이런식으로 서로 다른 주 DB가 받을 요청의 유일한 ID를 정하는 것이다. 다만 이 방법은 유일 ID 서버가 추가될 경우 ID의 유일성을 유지하지 못한다는 단점이 있다.

 

• 여러 데이터 센터에 걸쳐 규모를 늘리기 어려우며, 서버를 추가하거나 삭제할 때도 잘 동작하도록 만들기 어렵다.
• ID의 유일성은 보장되나, 그 값이 시간의 흐름에 맞춰 커지도록 보장할 수 없다.

 

UUID

UUID는 유일성이 보장되는 ID를 만드는 간단한 방법이다. UUID는 컴퓨터 시스템에 저장되는 정보를 유일하게 식별하기 위한 128비트짜리 수이다. 랜덤 문자열을 생성하지만, 충돌 가능성이 매우 낮다고 여겨진다.

 

장점

• UUID를 만드는 것은 단순하다. 서버의 조율이 필요없다.
• 각 서버가 자기가 쓸 ID를 알아서 만드는 구조이므로 규모 확장도 쉽다. 

단점

• ID가 128비트로 길다.
• 시간순으로 정렬할 수 없다.
• 숫자가 아닌 다른 값이 포함될 수 있다.

 

UUID의 단점을 보완하기 위해 여러 가지 버전을 출시했다. 

https://github.com/f4b6a3/uuid-creator?tab=readme-ov-file

GitHub - f4b6a3/uuid-creator: UUID Creator is a Java library for generating Universally Unique Identifiers. It generates all sta

 

그리고 UUID를 계승한 업그레이드 ID 생성 방법인 ULID, TSID도 있다.

• ULID : UUID에 timestamp 추가
• TSID : Twitter Snowflake와 ULID 합침

https://github.com/vladmihalcea/hypersistence-tsid

GitHub - vladmihalcea/hypersistence-tsid: A Java library for generating Time-Sorted Unique Identifiers (TSID).

 

 

티켓 서버

티켓서버는 유일 ID를 생성하기 위해 auto_increment 기능을 갖춘 데이터베이스 서버를 중앙 집중형으로 하나만 사용하는 것이다. 이 방법은 분산환경에서 사용하기 힘든데, 이유는 다음과 같다.

 

• ID 생성 서버의 성능 저하
  • ID를 생성해야 하는 데이터가 많다면 DB 서버의 I/O 연산이 증가해 ID 생성 서버의 성능이 저하된다.
  • ID 생성 서버가 한 개일 경우 SPOF 문제가 발생한다. 

그러면 ID 생성 서버를 늘리면 되겠다고 생각할 수 있다. 만약 ID 생성 서버가 여러 개일 경우 ID의 동기화 문제를 생각해야 한다.

(데이터 동기화를 위한 인메모리 DB를 설치하고... 배보다 배꼽이 더 커질 수 있다!)

 

 

트위터 스노우플레이크

생성하는 ID의 구조를 여러 절로 분할해 다양한 정보를 채워 ID를 만드는 방법이다.

 

• 사인(Sign)
  • 1비트
  • 나중을 위해 유보 중
• 타임스탬프(Timestamp)
  • 41비트
  • 기원 시각을 기준으로 몇 밀리초가 경과했는지 나타내는 값 (ID가 밀리초 단위로 생성됨)
• 데이터 센터 ID
  • 5비트
  • ID가 사용될 데이터 센터 번호
  • 32개의 데이터 센터 ID 사용 가능
• 서버 ID
  • 5비트
  • ID가 사용될 데이터 센터 내 서버 번호
  • 32개 서버 ID 사용 가능
• 일련번호
  • 12비트
  • ID가 생성할 때마다 1비트 증가 
  • 1밀리초가 경과할 때마다 0으로 초기화

 

스노우플레이크 방법의 핵심은 타임스탬프와 일련번호이다. 두 절은 ID가 생성될 때 부여된다는 특징을 가지고 있다.

타임스탬프를 이용하면 ID가 생성된 UTC 시각을 알 수 있다. 그리고 ID를 시간순으로 정렬할 수 있다.

 

 

추가로 생각해 볼 내용

• 시계 동기화
  • ID를 생성할 때 서버들이 전부 다 같은 시계를 사용하고 있는가?
  • NTP(Network Time Protocol)을 알아보자
• 각 절 길이 최적화
  • 동시성이 낮고 수명이 긴 앱이라면 일련번호 절을 줄이고 타임스탬프 절을 늘린다.
  • 비즈니스 로직에 맞게 절을 최적화하자.
• 고가용성
  • ID 생성 서버에 장애가 발생할 경우 어떻게 하겠는가?
  • ID 생성 서버의 인프라를 어떻게 구성할 것인가?