"가상 면접 사례로 배우는 대규모 시스템 설계 기초"를 읽고 - 7장

가상 면접 사례로 배우는 대규모 시스템 설계 기초 | 알렉스 쉬 - 교보문고

---

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

• 다중 마스터 복제 (Multi-Master Replication)
  • 데이터베이스의 auto_increment 기능 활용
  • 다음 ID 값을 구할 때 1만큼 증가시키는 것이 아닌, k만큼 증가시킨다.
  • k는 현재 사용 중인 데이터베이스 서버의 수다.
  • 이렇게 하면 규모 확장성 문제를 어느 정도 해결할 수 있는데, 데이터베이스 수를 늘리면 초당 생산 가능 ID 수도 늘릴 수 있기 때문이다.
  • 단점
    • 여러 데이터 센터에 걸쳐 규모를 늘리기 어렵다
    • ID 유일성은 보장되겠지만, 그 값이 시간 흐름에 맞추어 커지도록 보장할 수 없다.
    • 서버를 추가하거나 삭제할 때도 잘 동작하도록 만들기 어렵다.

---

• UUID (Universally Unique Indetifier)
  • 유일성이 보장되는 ID를 만드는 간단한 방법
  • 컴퓨터 시스템에 저장되는 정보를 유일하게 식별하기 위한 128비트의 수
  • 충돌 가능성이 지극히 낮다.
    • 중복 ID가 1개 생길 확률을 50%로 끌어 올리려면, 초당 10억 개의 UUID를 100년 동안 계속해서 만들어야 한다.
  • UUID 값은 58c76s98-10x9-483w-ag9q-c94l1096pcj2와 같은 형태를 띤다
  • UUID는 서버 간 조율 없이 독립적으로 생성 가능하다.
  • 장점
    • 만들기 단순하다.
    • 서버 사이 조율이 필요 없으므로 동기화 이슈도 없다.
    • 각 서버가 자기가 쓸 ID를 알아서 만드는 구조이므로 규모 확장도 쉽다.
  • 단점
    • ID가 128비트로 길다.
    • ID를 시간순으로 정렬할 수 없다.,
    • ID에 숫자가 아닌 값이 포함될 수 있다.

---

• 티켓 서버 (Ticket Server)
  • 유일성이 보장되는 ID를 만드는 데 쓰일 수 있는 방법
  • 핵심은 auto_increment 기능을 갖춘 데이터베이스 서버, 즉 티켓 서버를 중앙 집중형으로 하나만 사용하는 것
  • 장점
    • 유일성이 보장되는 오직 숫자로만 구성된 ID를 쉽게 만들 수 있다.
    • 구현하기 쉽고, 중소 규모 애플리케이션에 적합하다.
  • 단점
    • 티켓 서버가 SPOF(Single-Point-Of-Failure)가 된다.
    • 티켓 서버에 장애가 발생하면 해당 서버를 이용하는 모든 시스템이 영향을 받는다.
    • SPOF를 피하기 위해 티켓 서버를 여러 대 준비해야 하는데, 이 경우 데이터 동기화 같은 문제가 발생된다.

---

• 트위터 스노플레이크 (Twitter Snowflake) 접근법
  • 트위터에서 사용하는 독창적인 ID 생성 기법
  • ID를 저장하기 위해 64비트를 사용
  • 64비트의 각 부분을 여러 섹션 (타임스탬프, 데이터센터 ID, 서버 ID, 일련번호)로 분할
  • 장점
    • 해당 방식을 사용할 경우 다른 서버와 통신할 필요가 없이 독립적으로 ID 생성이 가능
    • 성능과 확장성에서 이점을 가짐
    • 타임 스탬프가 초반 비트를 차지하기에 시간순으로 ID를 정렬할 수 있음
  • 단점
    • ID를 저장하기 위해 64비트를 사용

---

• 느낀 점
  • 지금껏 프로젝트를 진행하며 일반적인 auto_increment와 UUID 기법을 사용하곤 했다.
  • auto_increment의 경우엔 분산 시스템에서 일관성을 유지할 수 없고, UUID는 최고의 유일성을 제공하지만 너무 큰 비트 수 (128bit)를 가져감으로써 고려 사항이 생기게 된다.
  • 티켓 서버와 트위터 스노플레이크를 새로 알게 되었고, 티켓 서버는 단일 서버를 티켓 서버로 사용할 경우 SPOF 문제가 발생될수 있음을 꺠달았다.
  • 트위터 스노플레이크를 조금 더 깊게 공부하여 개인 프로젝트나 현업에서도 적용할 수 있는지 알아봐야겠다.