7 - 1 유일 ID 생성기 예시 찾아보기
스터디 진행 간 7장의 유일 ID 생성기에 대한 실제사례를 찾아보고 예상질문을 도출해보는 시간을 가졌다.
실제사례 중 티켓서버 설명에서 언급된 플리커(Flickr)에 궁금증을 가지게 되어 찾아보았다.
fkickr기술블로그 에서 티켓서버 관련 내용을 찾을 수 있었다.
해당 글을 아는만큼 정리해보자면
-
왜? 티켓 서버를 사용하는가? Flickr은 데이터 저장소를 확장하는데 샤딩을 사용하기 때문에 mysql auto_increment을 사용할 수 없다.
-
GUID는?(=UUID) GUID가 길고 MySQL에서 색인이 잘못?되었기 때문
-
SPOF해결은?
두개의 티켓서버를 운영하며 고가용성을 달성
두 서버간에 라운드 로빈을 수행 짝수가 더 많지만 운영에 큰 영향을 주진않음
-
티켓서버
실제 사용된 테이블을 보여줌 -
마무리
우아하진 않지만 2006년 출시부터 잘작동하고 있다.
정리해 보았을때
- 많은 양의 요청이 발생할때도 감당이 어떻게 가능한지
위의 궁금증을 해결하지는 못했다. 간단한 방식으로 많은 양의 요청을 감당할 수 있다라고 예상하고 있다.
하지만 유일 ID 생성에 대한 설계 면접에 대해 경우에 따라 대답가능한 선택지가 될 수 있지않을까 생각을 하였고 티켓서버를 바탕으로 질문을 작성해봤다.
- 시스템 규모가 너무 많이 필요하지 않을떄
- 새로운 레코드에 붙일 ID는 항상 1만큼 큰 값을 가져야할 때
- 스토플레이크보다 적은 비용을 이용해서 유일 id 생성기를 설계하여야 할때
스노플레이크 id가 세분화 되어있어 관리(고려)하는데 많은 인적 비용이 들어감