본문 바로가기

기술서적으로 배우는 기술

가상 면접 사례로 배우는 대규모 시스템 설계 기초 (feat. 7장 분산 시스템을 위한 유일 ID 생성기 설계)

들어가기 앞서 

책내용과는 무관한 이야기를 해보려 합니다. 아마 서비스를 개발하다 보면 유일 ID가 필요한 경우가 많이 있을 거라고 생각합니다. 가장 쉬운 예제로 회원 정보를 생성할때 아이디를 제외한 유일 ID를 많이 사용합니다. 제가 다녔던 이전 회사에서는 아이디가 생성할때 마다 1씩 증가하는 숫자 형태로 사용하였습니다. (지금은 사용하지 않습니다.)

 

하지만 이렇게 1씩 증가하는 값들은 보안에 취약하다는 단점이 있습니다. 제가 만약 회원가입 이후 4389라는 고유한 값을 받았다면, 다음사람은 4390가 될 것입니다. 혹여나 사용자의 회원 정보 조회 API의 URL이 "GET /user/{member-number)" 라면 어떻게 될까요? 저는 모든 사람들의 회원정보를 조회할 수 있습니다. 

 

https://news.mt.co.kr/mtview.php?no=2024060616461482486

 

"오픈채팅 일련번호도 개인정보" - 머니투데이

개인정보위, 식별 못해도 '유추' 가능…'카카오 소송' 재반카카오톡 오픈채팅 채팅방 참가자들을 구분하기 위해 부여한 회원일련번호가 그 자체로는 개인을 식별하지 못해도 해킹 등 다른 수단

news.mt.co.kr

실제로 우리나라 대표 빅테크 회사인 카카오톡도 이러한 방식으로 인해 개인정보가 유출된 사례가 있습니다. 실제 카카오톡 오픈채팅방 번호가 1씩 증가하는 일련번호 였는지는 잘 모릅니다. 하지만 아마 해커가 유추하기 쉬운 형태 였을 거라고 생각합니다. 

 

유명 강의 사이트 역시 이러한 일련번호를 사용하고 있는데요. 아마 해당 URL은 개인정보와 상관없는 커뮤니티 질문 게시판이라 노출되어도 상관이 없을 겁니다. 

 

이번 장에서 공부할 내용은 이 일련번호에 대해서 알아보려고 합니다. 일련 번호는 회원 정보 뿐만 아니라 시스템 곳곳에서 식별의 용도로 많이 사용 되는 만큼 중요한 부분이라고 생각합니다. 이번 장에서는 이 일련번호를 암호화에 대해 알아 보는 것은 아니며 분산 환경에서 어떻게 유일한 ID를 생성할 수 있는지에 대해 알아보려 합니다. (왜 내용과 상관 없는 예시를 들었냐 생각하실수 있지만 유일ID와 관련하여 생각나는 예시가 저거 뿐이였습니다.. :) )

 

 

https://www.yes24.com/Product/Goods/102819435

 

가상 면접 사례로 배우는 대규모 시스템 설계 기초 - 예스24

“페이스북의 뉴스 피드나 메신저, 유튜브, 구글 드라이브 같은 대규모 시스템은 어떻게 설계할까?”IT 경력자라도 느닷없이 대규모 시스템을 설계하려고 하면 막막하다고 느낄 수 있다. 특히나

www.yes24.com


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

분산 시스템에서 유일한 ID를 생성하는 문제는 많은 시스템에서 중요한 과제입니다. 단일 데이터베이스에서 auto_increment를 사용하면 간단하게 해결할 수 있지만, 분산 환경에서는 성능과 확장성 면에서 한계가 있습니다. 이번 글에서는 분산 시스템에서도 유일하고 정렬 가능한 ID를 생성할 수 있는 다양한 방법과 최적의 해결책에 대해 알아보겠습니다.


1단계 : 문제이해 및 설계 범위 확정

분산 시스템에서 ID 생성기는 다음과 같은 조건을 충족해야 합니다.

  1. 유일성: 생성된 모든 ID는 시스템 전체에서 고유해야 합니다.
  2. 정렬 가능성: 시간 흐름에 따라 정렬이 가능해야 합니다.
  3. 숫자로만 구성: ID는 순수 숫자로 이루어져야 합니다.
  4. 64비트 제한: ID는 64비트 내에서 표현 가능해야 합니다.
  5. 성능: 초당 10,000개의 ID를 안정적으로 생성할 수 있어야 합니다.

2단계 : 개략적 설계안 제시 및 동의 구하기

분산 시스템에서 유일성이 보장되는 ID를 만드는 방법과 각 방법의 특징을 살펴 보겠습니다.

 

1. 다중 마스터 복제

다중 마스터 복제는 데이터베이스의 auto_increment 기능을 활용하여 여러 서버가 서로 다른 간격으로 ID를 생성하는 방식입니다. 예를 들어, 서버가 3대라면 첫 번째 서버는 1, 4, 7..., 두 번째 서버는 2, 5, 8... 식으로 ID를 생성합니다.

  • 장점:
    • 비교적 간단하게 유일성을 보장.
  • 단점:
    • ID의 유일성은 보장되지만 시간순 정렬은 불가능 하다.
    • 서버 추가/삭제 시 복잡하다.
    • 대규모 분산 시스템에는 적합하지 않다.

 

2. UUID

UUID(Universally Unique Identifier)는 128비트로 유일성을 보장하는 방식입니다. 서버 간 동기화 없이도 독립적으로 생성 가능하며, 충돌 가능성이 매우 낮습니다. 중복 ID가 생길 확률을 50% 올리기 위해서는 초당 10억 개의 UUID를 100년 동안 계속해서 만들어야 합니다.

  • 장점:
    • 다중 서버 사이의 조율이 필요 없으며, 동기화 이슈도 없다.
    • 분산 환경에서 확장성이 뛰어나다. 
  • 단점:
    • ID가 128비트로 길어 저장 및 전송 비용 증가.
    • 시간순 정렬이 불가능.
    • 숫자가 아닌 문자도 포함될 수 있음.

 

 

3. 티켓 서버

중앙에서 auto_increment 기능을 가진 티켓 서버를 운영하여 ID를 발급하는 방식입니다. 중앙 서버가 모든 ID를 관리하므로 유일성과 정렬 가능성을 보장합니다.

  • 장점:
    • 구현이 쉬우며 유일성을 확실히 보장.
    • ID가 숫자로만 구성됨.
  • 단점:
    • 중앙 서버가 장애(SPOF, Single Point of Failure)에 취약.
    • SPOF를 피하기 위해 다중 서버를 구성하면 데이터 동기화 문제가 발생.

 

 

4. 트위터 스노플레이크 접근법

스노우플레이크는 트위터에서 설계한 ID 생성 방식으로, 64비트를 여러 구간으로 나누어 사용합니다. 각 구간은 고유한 역할을 담당하며, 유일성과 정렬 가능성을 모두 충족합니다.

  • ID 구조:
    • 1비트: 예약된 부호 비트 (양수/음수 구분).
    • 41비트: 타임스탬프(밀리초 단위).
    • 5비트: 데이터센터 ID (최대 32개 데이터센터 지원).
    • 5비트: 서버 ID (데이터센터당 최대 32대 서버 지원).
    • 12비트: 일련번호 (1밀리초 내 최대 4,096개의 ID 생성).
  • 장점:
    • 유일성 보장과 시간 정렬 가능.
    • 분산 환경에서 확장성 우수.
    • 64비트로 효율적이며 숫자로만 구성됨.
  • 단점:
    • 시스템 시계의 정확성이 중요.
    • 데이터센터 ID와 서버 ID 변경 시 충돌 위험.

 


3단계 상세설계

스노플레이크의 각 구역에 대해 조금만 더 살펴 보겠습니다.

타임스탬프

타임스탬프는 ID구조에서 가장 중요한 41비트를 차지하고 있습니다. 타임스탬프는 시간이 흐름에 따라 점점 큰 값을갖게 되므로, 결국 ID는 시간이 흐름에 따라 점점 큰 값을 갖게 되므로, 시간순으로 정렬이 가능하게 됩니다. 41비트로 표현할 수 있는 타임스탬프의 최대값은 2^41-1밀리초로 대략 68년에 해당합니다. 따라서 69년이 지나면 기원 시각을 바꾸거나 ID체계를 다른 것으로 이전해야 합니다.

 

일련번호

일련번호는 12비트 이므로, 2^12 = 4096개의 값을 가질 수 있습니다. 어떤 서버가 같은 밀리초 동안 하나 이상의 ID를 만들어 낸 경우에만 0보다 큰 값을갖게 된다. 즉, 1밀리초가 지나면 다시 리셋이 되며, 1밀리초 동안 4096개의 값을 하나의 서버에서 만들 수 있다는 의미 입니다.

 

데이터센터 ID와 서버 ID

데이터센터 ID(5비트)와 서버 ID(5비트)는 시스템 초기화 시 고정됩니다. 이를 통해 최대 32개의 데이터센터와 각 데이터센터당 32대의 서버를 지원할 수 있습니다. 데이터센터 ID나 서버 ID를 잘못 변경하게 되면 ID충돌이 발생할 수 있으므로, 그러 작업을 해야 할 떄는 신중해야 합니다.

 


4단계 : 마무리

스노우플레이크는 모든 요구사항을 만족하면서도 분산 환경에서 규모 확장이 가능했다. 조금 더 고도화를 한다면 다음 내용들을 논의할 수 있을 것이다. 

 

시계 동기화 :

  • 이번 설계를 진행하면서 ID생성 서버들이 전부 같은 시계를 사용한다고 가졍하였다. 하지만 하나의 서버가 여러 코어에서 실행될 경우 유효하지 않을 수 있다. 여러 서버가 물리적을 독립된 여러 장비에서 실행되는 경우에도 마찬가지이다. 이러한 문제를 해결하는 방법중 NTP(Network Time Protocol)이라는 방법이 있다.

각 절의 길이 최적화:

  • 동시성이 낮고 수명이 긴 애플리케이션이라면 일련번호 절의 길이를 줄이고 타임스탬프 절의 길이를 늘리는 것이 효과 적일 수 있다. 즉, 각 영역을 적절히 조절하여 효율을 극대화 할 수 있다.

고가용성 :

  • ID생성기는 필수 불가결 컴포넌트 이므로 아주 높은 가용성을 제공 해야 한다.

앞 부분이 궁금하신 분들은 링크 참고해 주시면 감사하겠습니다.

가상 면접 사례로 배우는 대규모 시스템 설계 기초 (feat. 1장 사용자 규모에 따른 규모 확장성)

가상 면접 사례로 배우는 대규모 시스템 설계 기초 (feat. 4장 처리율 제한 장치의 설계)

가상 면접 사례로 배우는 대규모 시스템 설계 기초 (feat. 7장 부산 시스템을 위한 유일 ID 생성기 설계)