SnowFlake 적용기 - Unique한 값

어떤 프로젝트를 진행하던 지금까지 DB의 PK에 대해서 생각해본적은 없었다.

왜냐하면 JPA에 설정해준 전략에 따라서 자동으로 생생해주었고, 항상 유니크한 값을 가지고 있다고 생각했기 때문이다.

 

하지만 서비스가 커질 수록, 트래픽도 많아지고 분산처리를 해야할 일도 생긴다. 이 말을 들을때도 별로 와닿지는 않았었다.

사실 그만큼의 서비스를 경험해본적도 없고.... 어쨌든!

 

이러한 요구사항이 생겼다.

"기간제로 사용중인 서비스의 이용자의 이용빈도가 적고 사용하지 않기 때문에, 해당 이용자는 데이터 이관을 통해 다른 장비에서 모아서 관리하도록 해야한다."

 

계속해서 잘 사용하는 이용자에게 좀 더 원할한 서비스... 이를테면 처리도 빠르고 성능도 좋은 그런 서비스를 제공해야하기에 장비의 스펙도 올라가게 되는데, 이 장비에 사용하지 않는 이용자도 관리가 되고 있는게 문제가 되는 것이다.

 

그렇기 때문에, 이러한 이용자들의 데이터를 다른장비에 이관하여 서비스를 제공하도록 하게 만들어야 하는 일이 생긴 것이다.

 

언제든지 Unique한 값을 가져야 한다

기존에 Identity 전략이나 Sequence 전략을 사용한다면, 자동으로 값이 생성된다. 

같은 서비스를 제공하는 두 장비의 같은 테이블

두 장비 기본적으로 정해진 PK 생성 규칙을 통해서 서비스를 제공하고 있다. 이 때, A라는 장비에 특정 데이터를 이관하려고 한다면 문제가 발생할 수 있다.

 

Duplicate entry ~~ for key

분리되어 있는 장비지만, 위와 같이 중복 ID 에러가 발생할 수 있다. 결국, Identity나 Sequence를 그대로 사용한다면, 서비스를 제공하는 장비에 대해서 Unique한 값이며, 전체 서비스를 바라봤을 때는 반드시 Unique한 값이라고는 할 수 없다.

 

그래서 언급된 자료가 Twitter에서 만든 SnowFlake라는 규칙이다.

 

SnowFlake? 그게 뭔데?

Announcing Snowflake

SnowFlake는 Unique한 값을 64비트로 구성하여, 구성하는 비트마다 의미하는 바를 다르게 적용하여 Unique한 값을 생성하는 전략이다. 아래 이미지를 보면,

 

비트생성 방법

시간, Worker ID, Process ID, Sequence 를 확인할 수 있다.

이는 64비트를 구성하는 항목들이며, 64비트 내에서 어떤항목에 몇비트를 부여할지를 모두 커스텀하여 정의함으로 써, Id를 채번하는 방식이다. 즉, 64비트만 맞다면 위와 다르게 아래처럼 정의해도 되며, 서비스 구성과 구분값을 어떻게할지에 따라서 결정되게 된다.

Time	Device	Type	Sequence
41	10	4	9

 

솔직히 비트연산은 학교다닐때 시험보려고 잠깐하고 그랬었는데, 실제 실무에서 사용할줄은 몰랐다.....

이걸 어떻게 만들면 좋을까 싶었지만, Twitter에서 오픈소스로 제공해주고 있기 때문에 수월했다....!

 

다음글에서는 SnowFlake의 구현코드를 보고 실제 Entity에 적용해보려고 한다.