Database PK 생성 전략 (without DB, Mysql)

가장 손쉽게 테이블에서 사용할 PK를 생성하는 방법은 테이블을 생성할 때 PK가 될 수치 칼럼에 AUTO_INCREMENT(MySql 기준)를 걸어주는 것이다.

이를 통하면, 개발자는 레코드를 생성할 때 PK 칼럼을 신경 쓸 필요가 없으며 DB가 알아서 순차적으로 증가시킨 값이 레코드에 포함되게 된다.

인덱스는 결국 DB에서 사용하기 위한 개념이고, 그 값을 DB가 직접 생성해주어 개발자가 신경 쓸 필요가 없다면 그걸로 된 것 아닌가? 라고 생각할 수 있으나 이러한 방식에도 결국 특정 관점에서는 한계가 존재한다.

이번 글에서는 이 한계들에 대해 알아보고 이를 극복할 수 있는 또다른 방식들에 대해 살펴보겠다.

 

 

DB가 직접 관리하는 PK의 문제점

1. 분산처리 환경에서 PK 값 채번의 어려움

최근에는 대규모 데이터를 감당하기 위해 서버와 DB 인스턴스를 동시에 여러개를 실행시켜 부하를 분배하는 분산처리 방식이 대두되고 있다. 이러한 상황 속에서 AUTO_INCREMENT를 걸어둔 칼럼에 들어갈 값을 DB가 정상적으로 채번할 수 있을까? 물론 가능은 하나, 결국 이에 대한 싱크를 위해 DB 간 지속적인 네트워크 통신이 요구되기 때문에 꽤 큰 성능 저하 요인이 될 수 있다.

 

2. AUTO_INCREMENT를 위한 추가적인 테이블 락 소요

Mysql 내부에서 AUTO_INCREMENT를 처리할 때 사용하는 락의 모드 설정 값으로 줄 수 있는 종류는 0, 1, 2 총 3가지이다. (0: traditional, 1: consecutive, 2: interleave) 이 때 0의 경우엔 매번 테이블 락을, 1의 경우엔 간단한 INSERT는 뮤텍스를 통한 경량락을 사용하고 Bulk INSERT와 같은 경우엔 테이블 락을 사용하게 된다. 물론 Mysql 8버전부터는 기본 설정이 interleave가 되어 테이블 락을 활용하지 않지만, 다른 요구사항 때문에 0, 1 모드를 사용해야 한다면 이는 성능 저하 요인이 될 수 있다.

 

3. (JPA 사용 시) 쓰기 지연 활용도 저하

JPA에는 쓰기 지연이라는 개념이 존재한다. 어플리케이션과의 상호작용으로 발생하는 레코드의 추가, 수정 등의 작업 결과를 영속성 컨텍스트라고 하는 일종의 캐시에 저장해두고 트랜잭션이 끝날 때 한번 적용하는 형태인데, 이를 잘 활용할 경우 애플리케이션과 DB의 통신 횟수와 쿼리 횟수를 줄일 수 있어 성능 향상에 도움이 된다.

그런데 이러한 쓰기 지연은 Mysql의 AUTO_INCREMENT 방식과는 궁합이 좋지 못하다. JPA에서 영속성 컨텍스트에 데이터를 임시로 적재해두기 위해서는 반드시 해당 데이터의 ID(PK) 값이 필요하다. (데이터에 접근하기 위한 키로 사용하기 위함) 그런데 AUTO_INCREMENT는 결국 DB에서 관리하는 값이고 이를 알아내기 위해서는 결국 DB 레벨에서 INSERT 쿼리를 직접 실행시켜야 한다. 즉, 영속성 컨텍스트에 적재하기 위해서는 쓰기를 지연하는 것이 아니라 그 즉시 DB에 쿼리를 날려서 ID 값을 받아와야 한다는 것이다. 이러한 문제는 Mysql이 사용하는 AUTO_INCREMENT 방식 뿐 아니라, 오라클 등에서 활용되는 SEQUENCE 방식에서도 나타난다. 물론 ID 값을 알기 위해 직접 INSERT 쿼리까지 실행시켜야해서 쓰기 지연 자체가 불가능한 Mysql의 상황보다는 나으나, 그 또한 DB와의 즉각적인 통신이 필요한 것은 동일하다. (쓰기 지연은 활용 가능)

 

4. 보안상의 문제

그 외에도 사용자에게 pk 값이 id 등의 형식으로 전달되었을 때 서비스의 규모 등을 유추할 수 있다는 보안 상의 문제가 발생할 수 있다.

 

 

고려 해볼만한 대안

1. UUID

UUID V4 예시

UUID란 범용 고유 식별자라는 의미로 Universally Unique Identifier의 약자이다.

통상 128비트의 크기를 차지하며, 다양한 버전이 있지만 순수하게 랜덤성 만을 갖는 V4를 가장 많이 사용한다.

UUID의 가장 큰 특징은 어떤 인자, 의존성 없이도 언제든지 고유한 식별자를 생성할 수 있다는 것이다.

V4 기준으로 생성된 UUID의 경우의 수는 2^122(340,282,366,920,938,463,463,374,607,431,768,211,456)인데, 너무 큰 수이므로 이해를 쉽게 하기 위해 매 초 10억개의 UUID를 생성한다고 가정하자. 이 경우, 100년동안 해당 작업을 수행해야 겨우 50% 확률로 단 하나의 중복 값이 생성되게 된다.

따라서 중복의 가능성은 거의 배제할 수 있게 된다.

장점

• DB에 의존하지 않은채 사실상 중복 가능성이 없는 유일 식별자를 생성할 수 있다.
• 애플리케이션 레벨에서 ID(PK) 값을 확정지을 수 있기 때문에 JPA의 쓰기 지연을 활용할 수 있다.
• 유저에게 노출되어도 상관없다.
• 널리 알려진 개념이고, 그에 따른 구현체들도 많다. (Java의 경우엔 UUID 타입과 생성을 위한 메서드가 빌트인 util 라이브러리에 존재)

단점

• 일반적으로 사용되는 숫자 칼럼에 비해 크기가 크다. (Integer: 4바이트 < 16바이트 (128비트))
  • 이는 특히 Mysql 환경에서 PK로 사용되는 칼럼이기 때문에 성능 상 큰 영향을 미칠 수 있다. 왜냐하면 Mysql의 세컨더리 인덱스들은 모두 리프 노드에 PK값을 저장하고 있기 때문에 중복 저장이 많이 발생하기 때문
• 완전한 랜덤 값이 생성되기 때문에 데이터의 유사성을 나타낼 수 없다.
  • 이는 특히 PK를 이용하여 클러스터링 인덱스를 구성하는 Mysql에서 성능 체감이 될 수 있다. 그 이유는 유사한 성질의 데이터를 유사한 물리적 공간에 저장할 수 있어 이러한 성질을 이용한 조회 시 적은 페이지만을 읽을 수 있는 클러스터링 인덱스의 이점이 하나 사라지는 것이기 때문(실질적인 클러스터링 팩터의 저하로 볼 수 있음)
  • 이는 또한 INSERT 쿼리의 성능 저하로 이어질 수 있다.

 

2. ULID

GitHub - ulid/spec: The canonical spec for ulid

출처:&nbsp;https://blog.tericcabrel.com/discover-ulid-the-sortable-version-of-uuid/

ULID란 기존 UUID가 갖고 있던 문제들을 개선하기 위해 등장한 개념이다. UUID와 동일한 128비트의 크기를 가지며, 앞선 48비트는 타임스탬프(밀리초 단위까지)를 의미하고 나머지 80비트는 랜덤값이 포함된다.

대표적인 ULID의 특징은 다음과 같다.

• 128비트를 갖기 때문에 기존 UUID와의 호환성 존재
• 각 ms당 2^80의 고유식별자 생성 가능
• ULID에 포함되는 타임스탬프를 생성시간으로 취급할 경우 UUID V4와 달리 정렬 가능

ULID의 스펙 중에서는 Monotonicity(단조성)이라는 스펙이 존재하는데, 이는 동일한 ms에서 중복으로 ULID 생성 요청이 들어오는 경우 뒤에 80비트를 랜덤하게 생성하는 것이 아니라, 직전 생성한 ULID의 80비트에서 딱 1을 증가시킨만큼의 값을 갖도록 하는 방식이다. 이를 활용할 경우 후위 80비트를 완전 랜덤하게 생성하는 경우와 비교해서 더 중복 가능성이 줄어들고, 생성 성능 상의 이점도 있다고 한다. 또한 ULID 생성 순서를 기준으로 완전한 정렬이 가능해진다.

장점

• UUID와 마찬가지로 중복의 가능성이 매우 희박한 식별자를 DB에 의존하지 않은 채 획득할 수 있다.
• JPA 쓰기 지연 활용이 가능하다.
• 유저에게 노출되어도 괜찮다.
• UUID 만큼은 아니지만 ULID도 구현체가 많은 편이다.
  • https://github.com/f4b6a3/ulid-creator?tab=readme-ov-file
• (Monotonicity 스펙을 차용할 경우) 생성되는 모든 ULID를 생성 시점을 기준으로 정렬이 가능해진다. 

단점

• UUID와 마찬가지로 데이터를 담기 위해 큰 타입을 할당해야하고 그로 인한 성능 저하가 나타날 수 있다.

 

3. TSID

GitHub - f4b6a3/tsid-creator: A Java library for generating Time-Sorted Unique Identifiers (TSID).

TSID의 구조

TSID란 64비트의 길이를 가지는 형태로 이루어져 있으며 전위 42비트는 시간을 나타내고, 후위 22비트는 랜덤 값을 나타낸다.

TSID가 갖는 특징은 아래와 같다.

• 64비트의 크기를 가짐
• 생성 시점 기준으로 정렬 가능

위 특징들을 보면 ULID의 특징과 굉장히 유사하다. 그러면서도 크기는 그 절반을 갖는다. 이게 어떻게 가능한 것일까?

우선 시간 비트를 보면 42비트를 갖는다. 여기에서 기존 ULID와 비교하여 6비트를 아낀 것을 알 수 있다. 시간 비트를 줄였다는 것의 의미는 결국 TSID가 커버하는 시점이 ULID에 비해 적다는 것이다.

이로 인해, TSID의 시간 값은 일반적으로 사용되는 Unix-time 단위의 1970-01-01T00:00를 시작점으로 사용하지 않고, 2020-01-01T00:00을 시작점으로 하는 ms 값이 된다. 또한 42비트로 나타낼 수 있는 기간은 대략 139년 정도이다. (Unsigned Integer를 활용한다는 가정 하에. Signed Integer라면 절반 수준으로 줄어듦) 이후에 알게된 내용이지만, 시간 스케일을 42비트로 줄여서 다루는 것은 Twitter의 Snowflakes에서 활용하는 방식이라고 한다.

우리는 서비스에 PK로 사용하기 위해 이를 고려하고 있기 때문에 개인적으로는 이정도 기간이라면 충분하다고 생각된다.

나머지 22비트는 또다시 node와 counter 파트로 나뉘는데, 이 때 node는 0 ~ 20 비트까지 조정 가능한 값이다. 여기서 node란, 기기나 인스턴스의 ID 값을 나타내어 이를 통한 근본적 중복 방지를 위해 존재한다고 한다. 만약 2개의 인스턴스에서 생성되는 Tsid 값이 중복에서 완전히 자유로워야 한다면, 이 값을 2로 줄 수 있는 것이다. 

node로 사용된 비트를 제외하고나면 남은 비트들은 전부 counter로 취급되며 랜덤 값을 생성하는데 이용된다. 이 때 동일 ms에 생성되는 값들에 대해서는 ULID의 Monotonicity 스펙과 동일하게 동작한다.

장점

• UUID 정도는 아니지만 중복의 가능성이 희박한 식별자를 DB에 의존하지 않은 채 획득할 수 있다.
• UUID 스펙에 비해 크기가 절반 수준이다.
• JPA 쓰기 지연 활용이 가능하다.
• 유저에게 노출되어도 괜찮다.
• TSID를 구현하는 Java 구현체가 존재한다.
  
  • https://vladmihalcea.com/tsid-identifier-jpa-hibernate/
• 생성되는 모든 TSID를 생성 시점을 기준으로 정렬이 가능해진다. 

단점

• (개인적으로는 충분하다고 생각되나) 나타낼 수 있는 시점의 기간이 상대적으로 짧다.
• UUID, ULID와 비교했을 때 중복 가능성이 상대적으로 높다.

 

 

참조

MySQL :: MySQL 8.3 Reference Manual :: 17.6.1.6 AUTO_INCREMENT Handling in InnoDB

 

LINE 오픈챗 서버가 100배 급증하는 트래픽을 다루는 방법

 

UUID가 겹치면 어쩌지?