유일키 생성 전략

분산 환경에서 똑같은 ID로 데이터를 저장하면 무슨 일이 발생할까?

데이터에 접근할 때마다 노드에서 다른 결과를 받거나 업데이트 시에 충돌이 일어나는 등 여러 곤란한 문제가 생길 것이다. 따라서 여러 데이터베이스를 사용하는 샤딩 환경에선 해당 데이터의 ID가 유일성을 가진다는 것을 보장해야 한다.

 

1. 샤딩스피어 중복 ID 테스트

이전 포스팅에서 다뤘던 샤딩스피어에선 중복ID로 데이터를 저장하면 어떻게 처리될까??

 

다음과 같이 ID 생성 전략을 쓰지 않고 임의의 ID 값으로 Order를 저장해보도록 하겠다.

@Transactional
public Order createOrder() {
	Order order = new Order();
    order.setOrderId(12405L);
    return orderRepository.save(order);
}

 

첫 시도에는 insert가 이루어지지만..

 

 

이후에는 다음과 같이 upadte가 되는 것을 확인할 수 있다.

 

 

로그에서 확인할 수 있듯이 샤딩스피어는 insert 이전에 모든 노드들로부터 해당 ID를 가진 데이터가 있는지 확인하고 그 여부에 따라 삽입과 업데이트를 진행한다. 즉, 중복 ID를 가진 데이터를 허용하지 않는다는 것을 알 수 있다.

 

---

 

2. 다양한 유일키 생성 전략

앞서 분산 환경에서 중복 ID를 갖는 것은 시스템의 안정성을 해치는 문제를 일으키며,  ID 값이 유일함을 보장해줘야 한다는 것을 확인했다. 

 

이제 이러한 유일키를 생성하는 방법은 어떤 것이 있는지 알아보자.

 

2.1. UUID

UUID는 컴퓨터 시스템에 저장되는 정보를 유일하게 식별하기 위한 128비트짜리 수다. UUID 값은 충돌 가능성이 지극히 낮다. 자료에 의하면 UUID가 중복이 1번 발생할 확률을 50%로 끌어 올리려면 초당 10억 개의 UUID를 100년 동안 계속해서 만들어야 한다고 한다. 그만큼 유일성 보장은 확실하다고 할 수 있다.

 

 

UUID의 형식은 다음과 같이 하이픈 4개, 16진수 문자열 32개가 합쳐져 총 36자리를 가진다.

 

Java에선 UUID.randomUUID()를 통해 간단하게 생성할 수 있으며,
엔티티의 ID에 @GeneratedValue(strategy = GenerationType.UUID)를 추가하면 UUID를 기본키로 사용할 수 있다.

 

장점

• 구현이 간단하다.
• 규모 확장이 쉽다.

단점

• 128비트로 저장공간을 많이 차지한다.
• 시간순 정렬이 불가능하다.
• 숫자가 아닌 값이 포함된다.

 

추가로 B-트리 기반의 데이터베이스 사용 시에는 UUID의 사용은 정수형 ID에 비해 인덱스 성능이 떨어진다는 단점 또한 존재한다.

 

2.2. 티켓 서버

 

티켓 서버는 다음과 같이 auto_increment 기능을 갖춘 데이터베이스 서버를 중앙 집중형으로 하나만 사용하는 방식이다.

 

장점

• 구현이 간단하다.
• 숫자로 구성된 유일성이 보장되는 ID를 제공한다.

단점

• 티켓 서버가 SPOF가 된다.

 

당연하게도 서버 자체가 단일 실패 지점이 되며, 이를 보완하기 위해 서버를 여러 대 준비하면 이번엔 데이터 동기화 문제가 생기게 된다.

 

2.3. SnowFlake

SnowFlake는 트위터에서 고안한 유일 ID 생성기법이다.

 

ID의 구조는 다음과 같이 다섯 부분으로 나뉜다.

 

• 사인 비트: 1비트 할당. 음수 양수 구별
• 타임스탬프: 41비트를 할당. 기원 시각 이후로 몇 밀리초가 경과 했는지 나타냄
• 데이터센터 ID: 5비트 할당. 32개까지 지원
• 서버 ID: 5비트 할당. 32개까지 지원
• 일련번호: 12비트 할당. 각 서버는 ID를 생성할 때마다 1씩 증가. 1밀리초 경과 시에 0으로 초기화.

 

41비트를 차지하는 타임스탬프에 의해 대략 69년 동안의 ID유일성을 보장한다고 한다.

 

장점

• 숫자로 구성된 유일성이 보장되는 ID를 제공한다.
• 시간에 따른 정렬이 가능하다.

단점

• ID에 시간 정보가 포함되어 시간 의존성이 존재한다.

 

2.4. SonyFlake

SonyFlake는 스노플레이크 기법에 영감을 받아 개발되었고, 공식 레포지토리는 다음과 같으며 GO 언어로 개발됨을 확인할 수 있다.

 

https://github.com/sony/sonyflake

GitHub - sony/sonyflake: A distributed unique ID generator inspired by Twitter's Snowflake

 

 

소니플레이크 ID의 구조는 다음과 같다.

 

• 타임스탬프: 39비트 할당. 10밀리초 단위의 경과 시간 표현.
• 머신 ID: 각 노드에 고유 식별자 할당. 최대 65,536대 지원
• 시퀀스 번호: 동일 10ms 구간 내에서 한 노드가 최대 256개의 ID 생성 가능

 

스노플레이크에 비해 적은 수의 비트를 사용하지만 효율적인 타임스탬프 활용으로 약 174년의 수명을 가지며, 더 많은 노드 수를 지원한다는 장점이 있다. 하지만 스노우플레이크는 밀리초당 최대 4,096개의 ID를 생성할 수 있는 반면, 소니플레이크는 10밀리초당 최대 256개의 ID만 생성할 수 있는 만큼 고부하 환경에선 상대적으로 불리하다.