<div id="readability-page-1" class="page"><div><figure data-origin-width="500" data-origin-height="658" data-ke-mobilestyle="alignCenter"><img src="https://blog.kakaocdn.net/dn/doCFeg/btrwps5B63y/ZuiM2YZKFJei7L7WNk3DX0/img.jpg" width="300" height="395" data-filename="8966263151_1.jpeg" data-ke-mobilestyle="alignCenter"></figure>
가상면접 사례로 배우는 대규모 시스템 설계 기초 책의 7장을 보면, 분산 시스템을 위한 유일 ID 생성기 설계 패턴에 대해 나온다. 최근에 고민했던 것들이 모두 정리되어있어 블로그에도 남겨본다.
이 책에서는 유일 ID 생성 패턴은 크게 4가지이다.&nbsp;
1. DB를 여러대 사용한다. 
그리고 auto_increment를 1씩 증가시키는게 아니라, 데이터베이스 수만큼 증가시킨다.
갈레라 클러스터 처럼 분산 DB 구조에서는 이런 패턴을 사용하고 있다.&nbsp;
그러나 DB 서버를 증설하거나 삭제하는 작업이 쉽지 않다는 단점이 있다.

2. UUID
UUID를 사용하여 식별자를 만드는 것이다. 애플리케이션 서버에서 각자 유일 키를 생성하기 때문에, 시스템 확장과 성능적 이점이 있다.
그러나 ID가 숫자형에 비해 데이터가 크고, ID를 시간순으로 정렬할 수 없다는 단점이 있다.&nbsp;

3. 티켓 서버
플리커에서는 숫자형의 PK를 사용하면서, 데이터의 크기를 줄이고자 티켓 서버를 운영하고 있다.
티켓 서버는 중앙화된 increment pk를 관리하는 서버를 의미한다.
플리커는 increment id를 티켓 서버에서 채번하고, 대량의 데이터를 저장해야하는 곳은 별도의 저장소에 저장하고 있다.&nbsp;
그러나 이 기능은 SPOF를 일으킬 수 있다는 단점이 있다.
<a href="https://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/" target="_blank" rel="noopener">https://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/</a>
<figure id="og_1647660216402" contenteditable="false" data-ke-type="opengraph" data-ke-align="alignCenter" data-og-type="website" data-og-title="Ticket Servers: Distributed Unique Primary Keys on the Cheap | code.flickr.com" data-og-description="This is the first post in the Using, Abusing and Scaling MySQL at Flickr series. Ticket servers aren’t inherently interesting, but they’re an important building block at Flickr. They are core to topics we’ll be talking about later, like sharding and " data-og-host="code.flickr.net" data-og-source-url="https://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/" data-og-url="https://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/" data-og-image=""><a href="https://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/" target="_blank" rel="noopener" data-source-url="https://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/">

<div>
Ticket Servers: Distributed Unique Primary Keys on the Cheap | code.flickr.com
This is the first post in the Using, Abusing and Scaling MySQL at Flickr series. Ticket servers aren’t inherently interesting, but they’re an important building block at Flickr. They are core to topics we’ll be talking about later, like sharding and
code.flickr.net
</div>
</a></figure>


4. 트위터 스노우플레이크
각 애플리케이션에서 키를 생성하기 때문에 확장성이 좋다. 그리고 앞단에 타임스탬프를 기반으로 만들어서, 대체키를 시간순으로 정렬하기도 용이하다.&nbsp;
비슷한 사례로 <a href="https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c" target="_blank" rel="noopener">instagram id</a>,&nbsp; <a href="https://velog.io/@injoon2019/UUID-vs-ULID" target="_blank" rel="noopener">ULID</a>, <a title="timeflake" href="https://github.com/anthonynsimon/timeflake" target="_blank" rel="noopener">타임플레이크</a> 등이 있다.
<a href="https://medium.com/double-pointer/system-design-interview-scalable-unique-id-generator-twitter-snowflake-or-a-similar-service-18af22d74343" target="_blank" rel="noopener">https://medium.com/double-pointer/system-design-interview-scalable-unique-id-generator-twitter-snowflake-or-a-similar-service-18af22d74343</a>

나라면... ulid를 사용할 것이다. 그 중, <a href="https://github.com/huxi/sulky/blob/master/sulky-ulid/src/main/java/de/huxhorn/sulky/ulid/ULID.java" target="_blank" rel="noopener">이 자바 코드</a>를 복사해서 사용할 것이다.&nbsp;
github 소스를 확인해보니, ulid spec이 가볍게 사용하기 좋아보이고, 스타도 높다. 그리고&nbsp; 자바 코드로 구현한 오픈 소스 중, 위에 언급한 레파지토리가 가장 스타가 높다. (22.03.19 기준. 109개이다.) 스노우플레이크는 오픈소스 지원을 종료한걸 보면, 믿음직하지 않다. 타임플레이크는 스타가 적어서, 자료를 찾거나 유지보수하기 어려워보인다.&nbsp;
(<a href="https://github.com/ulid/spec#monotonicity" target="_blank" rel="noopener">ulid</a> -&gt; star 4.1k, snowflake-&gt; github 지원 종료, <a href="https://github.com/anthonynsimon/timeflake" target="_blank" rel="noopener">timeflake</a> -&gt; star 776)
</div></div>

복세편살

가상면접 사례로 배우는 대규모 시스템 설계 기초 책의 7장을 보면, 분산 시스템을 위한 유일 ID 생성기 설계 패턴에 대해 나온다. 최근에 고민했던 것들이 모두 정리되어있어 블로그에도 남겨본다.
이 책에서는 유일 ID 생성 패턴은 크게 4가지이다. 
1. DB를 여러대 사용한다. 
그리고 auto_increment를 1씩 증가시키는게 아니라, 데이터베이스 수만큼 증가시킨다.
갈레라 클러스터 처럼 분산 DB 구조에서는 이런 패턴을 사용하고 있다. 
그러나 DB 서버를 증설하거나 삭제하는 작업이 쉽지 않다는 단점이 있다.
 
2. UUID
UUID를 사용하여 식별자를 만드는 것이다. 애플리케이션 서버에서 각자 유일 키를 생성하기 때문에, 시스템 확장과 성능적 이점이 있다.
그러나 ID가 숫자형에 비해 데이터가 크고, ID를 시간순으로 정렬할 수 없다는 단점이 있다. 
 
3. 티켓 서버
플리커에서는 숫자형의 PK를 사용하면서, 데이터의 크기를 줄이고자 티켓 서버를 운영하고 있다.
티켓 서버는 중앙화된 increment pk를 관리하는 서버를 의미한다.
플리커는 increment id를 티켓 서버에서 채번하고, 대량의 데이터를 저장해야하는 곳은 별도의 저장소에 저장하고 있다. 
그러나 이 기능은 SPOF를 일으킬 수 있다는 단점이 있다.
https://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/
 
 
4. 트위터 스노우플레이크
각 애플리케이션에서 키를 생성하기 때문에 확장성이 좋다. 그리고 앞단에 타임스탬프를 기반으로 만들어서, 대체키를 시간순으로 정렬하기도 용이하다. 
비슷한 사례로 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 생성기 설계  (0)
12:26:02
<셰릴 샌드버그> Lean In  (0)
2022.02.27
<마르티네즈> 카오스 멍키 - 혼돈의 시대, 어떻게 기회를 낚아챌 것인가  (2)
2022.02.05
<나루세 마사노부> 도메인 주도 설계 철저입문  (0)
2020.12.25
<이동욱> 스프링 부트와 AWS로 혼자 구현하는 웹 서비스  (0)
2020.10.05
<이미예> 달러구트 꿈 백화점  (0)
2020.10.05

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

댓글