@GeneratedValue IDENTITY를 벗어나 UUID/ULID 전략 사용해보기

디프만 14기에서 참여 중인 프로젝트에서 백엔드 리드 분이 엔티티의 id를 UUID, ULID로 설정한 것을 보았다. 늘 IDENTITY로 설정하여 MySQL이 AUTO_INCREMENT로 관리하도록 위임했기 때문에 기존 방식과 대비해서 어떤 장점이 있길래 사용하는지 알아보았다.

 

---

AUTO_INCREMENT 전략의 단점

외부에서 예측하기 쉬운 PK

PK가 선형적으로 증가하는 정수이기 때문에, 특정 데이터의 PK를 예측하기 쉬워진다. 실제로 request들의 파라미터를 테스트할 때 종종 느꼈던 것이다. 현재 유저의 id 2000이면 1 ~ 1999까지의 id를 가진 유저가 존재할 확률도 높은 것이다. 이는 단순히 노출된다의 문제를 넘어 SQL Injection 공격에도 취약해진다.

 

DB에 의존적인 PK

개발 편의성을 위해 PK 생성 책임을 DB에 위임하는 것이지만, 반대로 DB에 의존적이기 때문에 여러 제약이 발생한다. 중앙 집중식으로 새로운 id 값을 생성하는 방식이기 때문에, DB를 2개 이상 사용하는 분산 환경에서는 id의 중복을 막기 힘들고 DB를 변경하기 위해 AUTO_INCREMENT 설정을 동기화시켜야 하는 등 확장과 변경에 제한이 많다.

 

ID 고갈

BIGINT 최대 값은 42억이고, unsigned BIGINT라면 1,844경이다. 엄청나게 큰 값이라 고갈될 일이 없다고 생각할 수 있지만, 서비스가 급성장한다면 그런 것만은 아니다. 배달의 민족은 한 달에 1억3천만 건의 주문이 발생한다. 금전적 거래가 발생하는 주문이 이 정도인데, 댓글이라면? 댓글에 달리는 좋아요라면? 로깅 테이블이라면? 어떨까. 장애가 발생하면 큰 금전적 손해가 발생하는 상용 서비스에서 이런 가능성을 간과해서는 안될 것이다.

 

 

---

UUID v4 전략

UUID 값 예시 : 4dfc6b14-7213-3363-8009-b23c56e3a1b1

 

숫자와 알파벳 128bit 로 이루어진다. (대소문자 구별 x) 최대값은 340,282,366,920,938,463,463,374,607,431,768,211,456 개이고, 충돌 확률은 0.00000000006%에 불과하기 때문에, 테이블에 중복 여부를 확인할 필요없이 그냥 생성함으로써 서버 간 조율 없이 독립적으로 생성 가능해진다. 버전 별로 UUID 스펙이 다소 다르지만, DB PK에는 주로 v4를 사용한다고 한다.

 

👍  장점

• 동기화 이슈 X
• 규모 확장 쉬움

👎  단점

• ID 값이 128bit 로 길며 용량도 큼
  • 대규모 테이블에서 많은 저장공간을 차지
• 시간순 정렬 X
  • InnoDB 인덱스는 B-Tree 구조이며 늘 Clusterd index 구성하기 때문에, 순차성 없이 랜덤하게 생성되는 UUID는 성능 저하가 크게 발생 (정렬된 상태로 차례로 추가하면 트리 구성이 크게 변하지 않지만, 무작위로 추가되면 매번 구성이 변함)
• 숫자가 아닌 값 포함
  • 문자 단위로 비교되기 때문에, 정수 ID와 비교하면 성능이 느림
• 충돌가능성이 희박하지만 존재

 

 

---

ULID 전략

ULID 값 예시 : 01ARZ3NDEKTSV4RRFFQ69G5FAV

https://github.com/ulid/spec

 

UUID의 단점을 해결하기 위해 만들어졌다. 똑같이 128bit로 이루어져 있지만, 앞 48bit는 기원시간인 Epoch(밀리초)로 인코딩해 생성하고 뒤 80bit 는 무작위로 생성한다. 따라서 밀리초의 정밀도를 가지며 단순하게 증가하며, 밀리초 내에 동시 생성되면 무작위성에 따라 순서가 달라짐.

 

👍  장점

• UUID의 36문자와 달리 ULID는 26문자로 인코딩
  • UUID는 Base16 + 대쉬바, ULID는 Base32를 사용하기 때문에, ULID가 더 짧은 문자열을 가짐 (Base16: 16진수로 각 문자가 4비트를 표현, Base32: 32진수로 각 문자가 5비트)
• 특수 문자가 포함되지 않아, URL로 사용하기 안전
  • UUID의 "-"(대쉬바)가 없음
• 시간순 정렬 가능
  • 성능 저하가 적고, 충돌 확률이 거의 없음
• 효율성과 가독성을 위해 Crockford의 Base32 사용
  • "I", "L", "O", "U" 제외됨

👎  단점

• 128bit로 여전히 용량이 큼
• 기본적으로 Java 문법에서 지원하는 UUID와 달리, ULID generator를 정의해야 함

 

 

---

TSID (Time-Sorted Unique Identifier)

https://github.com/f4b6a3/tsid-creator

 

요런 끝판왕도 있었다. twitter의 snowflake와 ULID의 아이디어를 결합한 것으로, ULID의 장점을 더 향상시키면서도 단점들을 해결했다. 2020-01-01 00:00:00 UTC 이후의 밀리초 42bit와 nodeId + counter로 구성된 랜덤값 12~22bit로 이루어진다. 부호가 있다면 69년 동안 사용가능하고, 부호가 없다면 139년 동안 사용가능하다. 관계형 데이터베이스가 1970년에 정의되었으니까 53년 지났다. 69년 이내에 프로젝트가 개편되거나 회사가 망하지 않을까?

 

👍  장점

• UUID/ULID보다 64bit로 더 적은 용량이고, 13자 문자로 더 짧은 길이
• 효율성과 가독성을 위해 Crockford의 Base32 사용
• 특수 문자가 포함되지 않아, URL로 사용하기 안전
• 시계열 정렬이 가능해, 성능 저하가 적고 충돌 확률이 거의 없음
• JPA, Hibernate에서 구현되어 있어, 간단히 사용 가능

👎  단점

• 69년 또는 139년 동안만 사용 가능
• hibernate > 6

 

적용법

implementation 'io.hypersistence:hypersistence-utils-hibernate-60:3.5.1'

import io.hypersistence.utils.hibernate.id.Tsid;
import jakarta.persistence.Id;

public class Member {

    @Id @Tsid
    private Long id;
}

 

 

---

결론

• 성능이 중요하거나, 소규모 프로젝트이거나, 많은 데이터가 쌓이지 않는 데이터 구조라면, 기존의 AUTO_INCREMENT를 사용해도 문제 없음.
• 왠만하면 TSID/ULID를 사용 (단, Hibernate > 6 만 TSID 사용 가능)
  • 추측가능한 ID 방지
  • 분산 환경