"가상 면접 사례로 배우는 대규모 시스템 설계 기초"를 알게된 Building for Scale 3편이다. 뒤에 부분 부터는 전반적인 지식 이야기보단 각 케이스 마다의 사례를 이야기해서 분산 시스템을 위한 유일 ID 생성기 까지 이야기를 하고 Building for Scale에 대한 포스팅은 일단 마치도록 하겠다. 읽게 되면서 클론 프로젝트가 정말 많이 부족했다는 것을 느껴 실습할 수 있는 부분을 찾아보려고한다.
분산 시스템을 위한 유일 ID 생성기
: 단일 서버에서는 auto_increment를 이용하여 객체가 생겨날때마다 ID를 1씩 증가시켜 유일성을 지킬 수 있다. 하지만, 분산환경에서는 이와 같은 방법으로는 유일성을 보장 할 수 없다. 분산 환경에서 유일성을 보장하는 방법은 다중 마스터 복제, UUID, 티켓 서버, 트위터 스노플레이크법이 대표적이다.
다중 마스터 복제는 다음 ID를 auto_increment를 1씩 증가가 아닌 서버의 갯수인 k만큼 증가시켜 생성하는 것이다. 하지만, 이후에 서버를 추가 및 삭제하였을때 유일성을 보장하기가 어렵고 ID의 유일성은 보장되지만 시간이 많이 흐르게 되면 유일성이 지켜지지 않을 수 있다. UUID는 128비트 수로 서버간 조율 없이 독립적으로 만들어낼 수 있는 ID이다. 따라서, 단순하고 규모 확장에도 강점을 가진다. 하지만, 비트가 128비트로 큰편에 속하고 ID를 통해서 알 수 있는 부가적 정보(생성 시간)는 없다는 점과 숫자가 아닌 문자가 포함 될 수 있다는 단점이 있다. 티켓 서버는 모든 웹서버가 중앙 집중형으로 ID를 생성할때 사용된다. 즉, 모든 서버의 데이터를 auto_increment를 통해서 숫자로만 이루어진 ID로 시스템을 관리 할 수 있다. 하지만, 티켓 서버가 SPOF가 되는 문제가 있다. 트위터 스노플레이크는 64비트의 ID 구조로, 사인비트(1비트), 타임스탬프(41비트), 데이터센터 ID(5비트), 서버 ID(5비트), 일련번호(12비트)와 같이 여러 절로 비트를 나눠 ID에 관련한 정보 또한 담음으로서 일관성을 유지하는 방법이다.
추가적으로, 시계 동기화 부분, 절의 분배, 고가용성을 고려해야한다. 시계 동기화는 서버가 분산 시스템이 되면 같은 시계가 아닐 수 있다. 이러한 문제는 NTP를 활용하여 해결 할 수 있다. 절의 분배는 상황에 맞추어 ID를 구성하는 절을 최적화 시키는 부분이다. 고가용성은 ID 생성기가 필수 불가결한 컴포턴트이기 때문에 높은 가용성을 제공해야 한다는 부분이다.
