본문 바로가기

소프트웨어-이야기/아키텍처

분산 시스템을 위한 유일 ID 생성기 설계

가상면접 사례로 배우는 대규모 시스템 설계 기초 책의 7장을 보면, 분산 시스템을 위한 유일 ID 생성기 설계 패턴에 대해 나온다. 최근에 고민했던 것들이 모두 정리되어있어 블로그에도 남겨본다.

이 책에서는 유일 ID 생성 패턴은 크게 4가지이다.

 

1. 데이터베이스 별로 pk 생성 규칙을 나눠갖기

DB 별로 사용할 수 있는 pk 생성 규칙을 나눠가지는 안이다.

 

후보1: pk 증분 기준을 각각 다르게 설정하기 

예를 들어, pk를 auto_increment를 데이터베이스 별로 증가시키는 기준을 다르게 가져가는 안이 있다.

갈레라 클러스터 처럼 분산 DB 구조에서는 이런 패턴을 사용하고 있다.

그러나 DB 서버를 증설하거나 삭제하는 작업이 쉽지 않다는 단점이 있다.

 

후보2: pk 시작값을 다르게 설정하기 

대신 pk가 중복될 수 있다는 리스크가 있고, 관리가 어렵다는 단점이 있다.

 

2. 티켓 서버

티켓 서버는 중앙화된 increment pk를 관리하는 서버를 의미한다.

사례로는 플리커가 있다. 

플리커에서는 숫자형의 PK를 사용하면서, 데이터의 크기를 줄이고자 티켓 서버를 운영하고 있다.

플리커는 increment id를 티켓 서버에서 채번하고, 대량의 데이터를 저장해야하는 곳은 별도의 저장소에 저장하고 있다.

그러나 이 기능은 SPOF를 일으킬 수 있다는 단점이 있다.

https://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/

 

3. 대체키 생성 규칙 관리하기

문자열로 된 대체키에 접두사를 다르게 관리하여, 키가 중복되지 않도록 할 수 있다.

식스샵, eqlstore 상품 상세 링크를 보면, 상품 상세 번호가 문자열의 대체키로 구성되어 있다. 이를 통해 실제로 대체키를 적용했을 때, 어떤 형태가 되는지 감을 잡을 수 있다. 

예시.

 

4. UUID

UUID를 사용하여 식별자를 만드는 것이다. 애플리케이션 서버에서 각자 유일 키를 생성하기 때문에, 시스템 확장과 성능적 이점이 있다.

그러나 ID가 숫자형에 비해 데이터가 크고, ID를 시간순으로 정렬할 수 없다는 단점이 있다.

예시로 디즈니 영상 상세 링크가 있다. https://www.disneyplus.com/ko-kr/video/b25bef87-bfac-40c4-9c9e-c62729b088fe

 

5. 트위터 스노우플레이크

각 애플리케이션에서 키를 생성하기 때문에 확장성이 좋다. 그리고 앞단에 타임스탬프를 기반으로 만들어서, 대체키를 시간순으로 정렬하기도 용이하다.

비슷한 사례로 instagram id, ULID, 타임플레이크 등이 있다.

https://medium.com/double-pointer/system-design-interview-scalable-unique-id-generator-twitter-snowflake-or-a-similar-service-18af22d74343

나라면 ulid를 사용할 것이다. 그 중, 이 자바 코드를 복사해서 사용할 것이다.

github 소스를 확인해보니, ulid spec이 가볍게 사용하기 좋아보이고, 스타도 높다. 그리고 자바 코드로 구현한 오픈 소스 중, 위에 언급한 레파지토리가 가장 스타가 높다. (22.03.19 기준. 109개이다.) 스노우플레이크는 오픈소스 지원을 종료한걸 보면, 믿음직하지 않다. 타임플레이크는 스타가 적어서, 자료를 찾거나 유지보수하기 어려워보인다.

(ulid -> star 4.1k, snowflake-> github 지원 종료, timeflake -> star 776)

 

참고

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

broadleafcommerce opensource

broadleafcommerce opensource에서도 ulid를 key으로 사용하고 있다.