Primary Key Tsid 도입기

[morenow98]

관련 PR: #50

Auto Increment

팀원들이 보통 Entity의 키를 결정하던 방식은 Auto Increment 였다. 기본 설정도 이와 같다. 이 방법의 장단점을 분석해보았다.

장점

Clustered Index

Primary Key는 MySQL에서 Clustered Index 로 설정된다. Clustered Index로 설정된다는 건, 데이터의 물리적인 위치가 PK의 순서로 결정된다는 것이다. 이 부분에서 Auto Increment는 다음 2가지의 장점을 가지게 된다.

1. 기존 데이터를 건들이지 않고 뒤에 붙이기만 하면 된다.
2. PK가 특별한 의미를 가지지 않기 때문에 수정할 일이 없다. 수정을 하면 물리적인 위치가 모두 수정될 위험이 있다.

WAS가 여러 개 있을 경우

WAS가 여러 개 있고 WAS에서 PK를 결정하게 된다면 DB에 insert시 충돌이 될 수도 있고, 물리적인 위치가 모두 수정될 위험도 있다.

3. 단일 DB 환경이라면, DB에서 Key를 모두 관리하므로 충돌이나 수정의 위험이 없다.

단점

보안

예를 들어, jabiseo.com/members/{memberId} 로 멤버 페이지를 접속하는 경우를 생각해보자.
만약 회원가입시 내게 부여된 memberId 가 30이라면 이 사이트의 회원이 30명이라는 사실을 간접적으로 알 수 있다.
또한, jabiseo.com/members/29 로 간단하게 접속하면 다른 멤버의 페이지에 접속할 수도 있다. 물론 기본적으로 접속할 수 없게 해야 하겠지만 이 허점도 전부 막아야 더욱 좋을 것이다.

성능

만약 많은 인원들이 북마크를 동시에 많이 한다면, 수많은 데이터가 insert 될 것이다. 이 때, PK를 설정하는 과정에서 DB에 더 긴 Lock이 걸리게 된다. 또한 여러 테이블이 외래키로 연결된 경우라면 연쇄적으로 많은 테이블에 Lock을 걸고, 해제하는 과정이 반복될 것이다.
따라서 DB에게 PK를 결정하도록 하는 것은 특정 상황에서 성능에 문제가 생길 수 있다.

충돌

만약, 여러 DB가 Auto Increment하는 대규모 분산 시스템에서는 각 DB가 독립적으로 PK를 생성하기 때문에 충돌이 일어날 가능성이 있다.

---

해결방안

장점은 그대로 가져가되, 단점은 해결할 방법을 찾아보자.

해결방안 1. UUID

DB에게 PK를 결정하지 않게 하고, 보안적인 문제도 해결하기 위해 WAS에서 PK를 결정해 직접 넣어주기로 했다.
따라서 기본적인 UUID를 우선 생각해볼 수 있다.
PK값이 수정될 가능성도 없고, UUID가 충돌될 가능성도 굉장히 적다. 하지만 다음의 단점이 있다.

1. Auto Increment의 장점 1번을 버리게 된다. PK를 랜덤으로 정하게 되니 삽입할 때 물리적인 위치가 제일 뒤가 아니다. 따라서 insert 시 대대적인 위치 수정이 일어나게 된다. 성능에 치명적인 단점을 가져오게 된다.
2. UUID의 크기는 16바이트이다. 기존에 사용하던 자료형보다 2배 큰 크기를 가진다. 마찬가지로 성능에 좋지 않다.

해결방안 2. 티켓 서버

PK만을 생성하는 서버를 둔다. 구현하기 쉬울 수도 있지만, SPOF가 발생한다. 이를 해결하기 위해서 티켓 서버를 여러 대 둔다면 또 다른 동기화 문제가 발생한다.
https://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/

해결방안 3. Tsid

Twitter의 Snowflake와 ULID를 합친 ID 생성기이다.

• ULID는 UUID의 몇 가지 단점을 해결한 랜덤 생성기이다. 다음 Github 참고.
  https://github.com/ulid/spec

Twitter Snowflake

위의 모든 것들을 해결하기 위해 WAS에서 PK를 결정하지만, 다음과 같이 64비트의 값으로 PK를 생성한다.

• 사인(sign) 비트
  • 1비트를 할당한다. 지금으로서는 쓰임새가 없지만 나중을 위해 유보해둔다. 음수와 양수를 구별하는데 사용할 수 있을 것이다.
• 타임스탬프(timestamp)
  • 41비트를 할당한다. 기원시각(epoch) 이후로 몇 밀리초(millisecond)가 경과했는지를 나타내는 값이다.
  • 사인 비트를 제외하고 제일 왼쪽에 있기 때문에, 결국 모든 PK가 밀리초 단위에서는 시간순으로 정렬될 것이다.
• 데이터센터ID
  • 5비트를 할당한다. 따라서 2^5 =32개 데이터센터를 지원할 수 있다. 이 값은 시스템 운영 중에 바뀌지 않는다.
• 서버ID
  • 5비트를 할당한다. 따라서 데이터 센터 당 32개 서버를 사용할 수 있다. 이 값은 시스템 운영 중에 바뀌지 않는다.
• 일련번호
  • 12비트를 할당한다. 각 서버에서는 ID를 생성할 때 마다 이 일련 번호를 1 만큼 증가시킨다. 이 값은 1 밀리초가 경과할 때 마다 0으로 초기화 (reset)된다.
  • 다시 말해, 한 서버에서 1 밀리초에 2개 이상의 ID를 생성할 때만 0이 아니게 된다.

이 원리를 이용해 Tsid는 만들어졌다. 이제 처음의 장점은 모두 취하고, 단점은 모두 해결했다.

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

관련 라이브러리를 설정한 후 다음과 같이 적용하면 된다.

@Id
@Tsid
@Column
private Long id;

주의해야 할 점

JavaScript/ECMAScript 수준의 정밀도에는 정수의 경우 53비트로 제한되어 있다.
기존 Auto Increment의 경우 53비트를 넘을 경우가 거의 없어 괜찮았지만, Tsid는 64비트를 모두 사용해 문제가 생길 수 있다.
따라서 Response해줄 때 Long을 String으로 바꿔서 전달하는 방식을 사용했다.