［독서기록］ 가상 면접 사례로 배우는 대규모 시스템 설계 기초 7장

📖 제목 : 가상 면접 사례로 배우는 대규모 시스템 설계 기초 : 7장
🙋‍♂️ 저자 : 알렉스 쉬
7장에서는 분산 시스템을 위한 유일 ID 생성기 설계에 대해 다루고 있다. 단일 서버, 단일 DB 환경에서는 AutoInc방식을 사용하면 되겠지만 분산 환경에서는 다른 대안이 필요하다. 어떤 대안들이 있고, 장단점은 무엇인지 정리해보았다.

📌문제 정의

• 목표: 분산 환경에서도 충돌 없이 유일한 ID를 빠르게 생성할 수 있는 시스템을 설계한다.
• 전제 조건
  • ID는 전역적으로 고유해야 한다.
  • 생성 속도는 매우 빨라야 한다(초당 10,000건 이상)
  • ID는 64비트로 표현 될 수 있는 값이어야 하고, 숫자로만 구성되어야 한다.
  • 분산된 여러 노드에서 생성되더라도 중복되면 안 된다.
  • ID는 발급 날짜에 따라 정렬이 가능해야 한다.

이제 여러가지 선택지를 확인해보면서 가장 적합한 방법을 찾아보기로 하자.

📌다중 마스터 복제 (Multi-Master Replication)

각 서버가 독립적인 ID 생성 범위를 가짐으로써 충돌을 방지하는 방식이다.
데이터베이스를 여러 인스턴스로 복제(Master A, B, C)하고 각 마스터에게 고유한 ID범위 또는 증가 간격을 부여하게 된다.

• Master A: 1, 4, 7, 10, …
• Master B: 2, 5, 8, 11, …
• Master C: 3, 6, 9, 12, …

✅ 장점

• 간단한 구조로 병렬 ID 생성 가능, 정렬 가능

❌ 단점

• 마스터 간 충돌 발생 시 해결 어려움
• 간격(step) 설정을 잘못하면 ID 소모 비효율
• 복제 지연 시 데이터 정합성 문제 가능
• 서버를 추가하거나 삭제할 때에도 잘 동작하도록 만들기 어렵다.

📌티켓 서버 방식(Ticker Server)

중앙의 티켓 서버가 ID를 발급하고, 분산 서버는 이를 받아 사용하는 방식이다. ID 발급을 위한 전용 서버(티켓 서버)를 두고, 애플리케이션 서버들은 필요할 때 마다 ID를 요청한다.

✅ 장점

• ID 생성 로직을 중앙 집중 → 관리 용이
• 정렬 가능, 단순한 ID 구조 유지

❌ 단점

• 중앙 서버 장애 시 전체 ID 발급 불가
• 네트워크 병목 발생 가능
• 수평 확장이 어려움

이 방식은 강력한 고가용성(HA) 구성 없이는 위험하다는 점을 알아두자.

📌UUID 사용(Universally Unique Identifier)

UUID는 유일성이 보장되는 ID를 만드는 또 하나의 간단한 방법이다. UUID값은 충돌 가능성이 지극히 낮으므로 서버 간 조율 없이 독립적으로 생성이 가능하다.

✅ 장점

• 충돌 위험이 거의 없음 (128비트 무작위 값)
• 중앙 서버 없이도 각 노드가 ID 생성 가능

❌ 단점

• ID가 너무 길다 (32자 이상)
• 정렬 불가능: 시간 순 정렬이 어려워 로그, DB 인덱싱에 불리

📌Twitter의 Snowflake 알고리즘

실제 서비스에서 정렬 가능하고 충돌 없는 ID가 필요할 때 사용하는 대표적인 솔루션이다.
64비트 정수형 ID로 구성되어 있고, 아래와 같은 구조를 가지고 있다.

1비트	41비트	10비트	12비트
예약	타임스탬프	머신ID(노드ID)	시퀀스 번호

📌 각 필드 설명

• 1비트: 부호 비트 (항상 0)
• 41비트: 시간 정보 (1970년 이후 경과된 밀리초)
• 10비트: 노드 ID (서버 번호 + 데이터 센터 번호 등)
• 12비트: 같은 밀리초 내에서 순번 (동일 밀리초에 최대 4096개 생성 가능)

✅ 장점

• 전역 고유성 보장
• 정렬 가능 (시간 기반) → 로그 정렬, 메시지 정렬 등에 유리
• 빠름: DB 접근 없이 ID 생성 가능

❌ 단점

• 시스템 시간이 밀리면 ID가 중복되거나 순서가 꼬일 수 있음
• ID를 재생성하면 동시성 제어 필요 (같은 밀리초에 4096개 초과 시 블로킹 또는 대기 필요)

---

이 책의 저자는 스노우 플레이크 방식을 가장 나은 답으로 채택했다. 다른 방식들에 비해 전제 조건을 대부분 만족하고, 단점도 덜 치명적으로 보이지만 Snowflake 방식을 사용할 때 추가로 고려해야 할 점들도 있다.

1. 시간 동기화 문제 : 시간 역행 시 충돌 발생 가능성이 있다.
   • 해결 방법: NTP를 사용하여 주기적으로 시간을 동기화하거나, 시간이 역행하면 시퀀스를 초기화 또는 대기
2. 노드 ID 충돌 방지 : 노드 ID가 중복되면 유일성이 깨진다.
   • 해결 방법: 배포 시 설정 파일에 노드 ID 고정, Zookeeper 등으로 동적으로 할당/관리