2021-03-13 JK

들어가면서

Database design 에서 Auto increment ID 와 UUID 가운데, 어느 것을 Primary key 로 사용하는 것이 좋은가라는 질문이 있다. FAQ 라고 할만한, 자주 접하며 고민하게 되고, 여러 사람이 겪는 문제인데, 다루기 어려운 문제이다. 소프트웨어 디자인 문제가 보통 그러한데, 명쾌하게 무엇이 더 우월한지 구분하기 어렵고, Pros, Cons 의 각 항목도 평가하기 어렵다.

그래도, 살펴보고 고민해 보면 좋은 문제이니, 몇글자 적어서 주장해 본다.

Natural Key vs Surrogate Key

이 두 가지 Key 가 각각 무엇인지에 대해서부터 이해하고 가면 좋겠다. 구글에서 검색하고 레퍼런스 찾아보면, 반복해서 사람들이 질문하고 있고, 답을 정리하고 있는데, 이 부분은 보통 사람들이 답하는 내용이 썩 와닿지는 않는다.

http://www.agiledata.org/essays/keys.html

• Natural key. A key that is formed of attributes that already exist in the real world. For example, U.S. citizens are issued a Social Security Number (SSN) that is unique to them (this isn't guaranteed to be true, but it's pretty darn close in practice). SSN could be used as a natural key, assuming privacy laws allow it, for a Person entity (assuming the scope of your organization is limited to the U.S.).
• Surrogate key. A key with no business meaning.

위와 같은 설명이 많다.

이 질문에 다르게 답을 하고 싶다. 누가 만들어서 나한테 알려준 것이라면 natural key, 내가 새로 만들었으면 surrogate key. 핵심적 구분은 나와 너 또는 내부와 외부의 구분이다.

https://en.wikipedia.org/wiki/Surrogate_key

• Surrogate (1) – Hall, Owlett and Todd (1976)
  A surrogate represents an entity in the outside world. The surrogate is internally generated by the system but is nevertheless visible to the user or application.[2]
• Surrogate (2) – Wieringa and De Jonge (1991)
  A surrogate represents an object in the database itself. The surrogate is internally generated by the system and is invisible to the user or application.

비즈니스 의미가 있냐 없냐, 이런 것이 중요하지 않아 보인다. 비즈니스 의미가 있다는 것은 남들이 이미 쓰고 있다는 것의 다른 표현일 뿐이다.

시스템의 내부와 외부를 구분하는 것은 간단하지 않다. 보통 소프트웨어 시스템은 결함이 있기도 하고, 경계가 불명확하거나 혼동이 있기도 하다. 몇가지 기준이 있긴 하지만,

• 소프트웨어 생명 주기를 같이 하는 덩어리
• 하나의 개발팀의 범위와 그 개발팀이 담당하는 시스템의 범위
• Git repository 의 단위

등을 생각할 수 있는데, 적당한 것으로 Software Development Life Cycle 을 꼽을 수 있다. Development, Test, QA, Deployment, Rollback 의 주기를 같이 따라가느냐이다. 소프트웨어 엔지니어링팀의 조직, 개발팀의 범위도 중요하다.

개발언어, 프레임워크 구분이 결정하지 않을 것이다. 예를 들어 Java Spring 애플리케이션과 React application 이 한번에 패키징되어 배포된다면 또는 패키징은 별도이더라도, 빌드/QA/배포/롤백 주기가 동기화되어 있다면, 하나의 시스템인 것으로 간주하면 된다.

이렇게 natural key, surrogate key 의 개념을 살펴보는 것은, natural key 가 처음 어떻게 만들어졌을까 따져보면, 결국 surrogate key 생성 문제로 환원된다는 것을 보여주기 위해서이다. 어느 시스템은 Key를 새로 만들기 마련이고, 그것을 다른 시스템에 전파하게 된다. 넘겨 받은 쪽에서는 그것을 natural key 로 간주하면 되고, 처음 만드는 쪽에서는 surrogate key 를 어떻게 잘 만들 것인지를 고민하는 것과 동일한 문제가 된다.

Key 내부에 code system 을 embed 하였냐 여부는 natural vs surrogate key 구분과 무관한 다른 주제이다. 예를 들어 한국의 주민등록번호는 앞부분 6글자가 생년월일이고, 뒷부분 첫글자가 성별/내국인/외국인 구분 등 의미를 갖는다. 그러나, 이런 code system 을 갖고 있는지 여부는, natural vs surrogate key 구분과 무관하다. surrogate key 를 생성할 때, 편의를 위해 code system 을 적용하는 것이 장점이 있으면, 도입할 수 있다. 이러한 예시를 이후에 제시해 보겠다.

Auto increment id vs UUID

구글 검색하면, 많은 글이 나온다. 첫페이지의 글 가운데 몇개 링크한다.

그래서 UUID 가 더 낫다.

https://mareks-082.medium.com/auto-increment-keys-vs-uuid-a74d81f7476a

이 글 저자의 의견은 각 key 의 Pros, Cons 에서 내 의견과 같거나 비슷하다. 그런데, 마지막 결론은 UUID 가 더 낫다는 것으로 달라진다.

Auto increment id 가 더 낫다.

https://stackoverflow.com/questions/4642695/how-to-choose-between-uuids-autoincrement-sequence-keys-and-sequence-tables-for

https://tomharrisonjr.com/uuid-or-guid-as-primary-keys-be-careful-7b2aa3dcb439

이 글 저자의 의견이 나와 비슷하다.

그 외

https://www.reddit.com/r/django/comments/fxfehw/uuid_vs_incremental_ids_pros_cons/g4xh3v9?utm_source=share&utm_medium=web2x&context=3

이 댓글도 Pros, Cons 를 잘 요약하고 있다.

그래서 내 의견은,

결론만 간단히 이야기한다면, 나는 대체로 auto increment id 쪽이다.

UUID의 장점과 단점이 무엇인가?

일단 UUID가 무엇인지부터 알아야 하겠다. 아주 간단히 말해, 128 bit 막수이다. https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_(random)

https://en.wikipedia.org/wiki/Birthday_problem 을 풀어보면, 128 bit UUID 가 동일한 값이 나올 확률은 없고, 보통 경우에는 충돌하지 않는다고 보면 된다. 일부러 random seed 를 동일하게 맞추지 않는다면. 막수라는 것은 중요한 특징이고, 장점이 되기도 하지만, 단점이 되기도 한다.

추측할 수 없다는 것, 그래서 내부에 존재하는 id 아무거나 하나라도, 외부에서는 찍어 맞힐 수가 없다는 것을 장점으로 손에 꼽는 사람들이 있다. 이런 특성은 엄청 큰 막수라는 것에서 비롯된 당연한 특성인데, 그것이 security 관점에서 장점이 된다는 것은, "별로..?"라고 본다. Security 를 여기에 의존하면 안 된다. User ID 추측하는 것은 어차피 다른 식으로 수집해서 찍어 맞힐 수도 있다.

나의 관점에서 UUID의 장점은, 분산 시스템에 적합하다는 것이다. 중앙 집중된 Online Key Generator 가 아니라는 것이다. UUID는 Globally unique key 를 만들어내기 때문에,

• 여러 마이크로서비스 또는 따로 떨어져서 작동하는 instance 가 각각 key 를 생성할 수 있다. Single Point of Failure 가 사라진다. 성능/대역폭의 병목을 없애기 좋다.
• 각각 만들어지고 저장된 데이터를 하나로 병합하더라도, key 충돌이 없다. 미국 서부의 시스템이 생성한 key, 미국 동부 시스템이 생성한 key, 서울에서 생성한 key, 일본에서 생성한 key, 각각을 모두 병합해서 BigQuery 에 데이터를 모으더라도, 충돌이 없다.

단점은 너무 길다는 것이다. 소규모 시스템에서는 이 단점이 다른 장점을 모두 가린다고 본다. 내가 보기엔 거의 유일한 분명한 이유이다.

• 사람이 인지하고, 부르고, 복붙하고, 다루기 어렵다. 로그에 찍으면 읽을 수 없다. Hexdigit 6글자도 읽기 어려워하는데, 32글자 못 읽고 못 외운다. 화면에 출력할 땐 보통 - 포함하여 36글자이다.
• 로봇의 터치스크린에 출력하면 어쩌려고? 화면 폭 내에 출력이 가능한가? 보여준다고 해서, 전화통화하면서 읽어줄 수 있나?

예) 카카오톡의 카카오 계정 ID 가 있는데, 64bit integer 를 사용하고, hexadigit 도 아닌 decimal 10진수로 화면에 출력해 준다. 고객지원 받으려고 하면, 이 카카오 계정 ID 를 읽어줘야 할 수 있다. 또는 내부 개발자가 디버깅할 때, 이 8 byte integer 를 API의 주요 파라미터로 쓰기 때문에, 이걸 읽고 전달해야 한다. 매우 곤란하다.

JavaScript 에서 별 생각없이 이 ID 를 number 로 다루면, precision 문제 때문에, 뒷부분 자리수 대여섯개가 조용히 날아간다. 버그 있는 줄 모르고, 한참 진행하다 뒤늦게 실수 발견하고 삽질을 하게 된다.

또다른 단점으로 성능에 불리하다. 길이가 너무 길다는 것, random value 라는 것, 두 가지 이유 때문에, 저장소가 효율적으로 작동하는데 불리하다. 소규모에서는 성능에 별 이슈가 없지만, large system 에서 UUID 를 key index 로 사용하는 건, 페널티가 크다. 그래서 효율을 위해 다시 incremental number 의 surrogate key 를 내부에 만들어 사용하게 된다.

내가 UUID를 쓴다면, 언제 쓰게 될까?

• multi-region 에서 독립적으로 작동하는 서비스를 빨리 만들어야 할 때.
• key system design 이슈에 대해 논의하고 준비할 여력이 안 될 때.

Auto increment id의 장점과 단점이 무엇인가?

UUID를 살펴보고 나니, auto increment id 의 장단점을 꼽기 쉬워졌다.

첫번째 장점. 짧다. 짧은 key 가운데 구현이 제일 쉬운 방법이다. 더 짧은 key 를 만들기 어렵다. 꽉 채워 사용한 auto increment id 보다 더 짧은 key 를 만드는 것은 불가능하다.

두번째 장점. Sequential 하기 때문에, range 로 set 을 표현하는데 유리하다. 보통 다루게 되는 resource의 subset 이 어느 id 부터 어느 id 사이, 이런 range 로 표현 가능해진다.

예) 공장에서 불량이 생기면, 대부분 sequential number range 를 지정해서 recall 하면 된다.

세번째 장점. time locality 가 있어서, 보통 시간순 정렬 목록을 만들 때, 저절로 cache hit ratio 가 올라간다.

몇가지 단점이 있다.

첫번째. Key generator 가 online 으로 작동해야 한다. 네트워크 장애가 나면 모두 멈춘다는 의미이다. Single Point of Failure 가 된다. 이것은 치명적 단점 중 하나이다. 소규모 온라인 시스템에선 보통 상관이 없지만. 그런데, multi-region 이거나, offline system 과 뭔가를 하려고 하면 치명적이게 된다.

두번째. RDBMS 의 incremental id 를 쓰면, 데이터를 넣어보아야 key 를 알 수 있게 된다.

DB table 에 데이터를 넣어보아야 key 를 알 수 있다는 것은, 애플리케이션에서 auto increment id 를 직접 생성하는 것으로 해결할 수도 있다. 고성능의 Key generator 가 필요한 경우, mysql 등 DBMS가 제공하는 auto increment id 가 아닌, application 에서 직접 생성한 key 를 사용하면서, bulk/batch processing 하는 기술을 적용할 수 있다. 또는 redis 같은 cache storage 에서 id 를 생성하는 방법도 좋다.

세번째. 대용량 분산 시스템을 만드는데 병목이 되어 버린다. 수십대 노드 수준에서, 고속으로 작동하고 싶은데, Key generator 를 auto increment number 로 적용한 경우, 병목이 되어 버린다. 수백대 이상 노드로 늘이지도 못한다. 보통 이런 경우는, 평상시에 대량의 데이터가 유입되고 있기에, 약간의 성능 degradation 이 발생해도, Key generator 시스템의 throughput 이 감소하고, 이곳에 부하가 집중되고, 전체 시스템이 먹통이 되곤 한다. Spinlock 기반의 고성능 key generator 를 구현하느냐 마느냐, redis key 생성기가 충분히 빠르냐 아니냐, 성능 테스트는 어떻게 할 것이며, 어느 정도의 High availability 를 보장할 것이냐, 그 팀에서 장애를 내면 누가 어떻게 책임질 것이냐 등 이슈가 불거진다.

UUID 와 Increment id 가 각각의 장단점이 있는데, 대안이 있는지? 해결책이 있는지?

자, 이제 진짜 본 주제로 들어가자. 어려운 시스템 디자인 문제이다.

첫번째 해결책. Natural key 를 쓰는 것이다.

Surrogate key 는 여러가지 장점이 있지만, 단점도 많다. 시스템 디자인을 할 때, 일단 별 생각없이 incremental id 를 내부에 만들어내는 것은 기본으로 하고 본다. 그래야 보통 시스템이 효율적으로 작동하게 디자인, 구현할 수 있다. 그런데 이 id 를 외부와 데이터 교환할 때 사용하는 것에는 매우 신중해야 하고, 보통 잘 모르겠으면, 안 해야 한다. UUID 이든, Increment ID 이든, Surrogate key 를 외부에 유통시키는 것에 매우 신중해야 한다.

Surrogate key 로서, UUID 를 쓰지 말아야 하는 이유 중 하나와 연결된다. 외부에 유통시키지 않을텐데, Global unique id 라는 장점이 무어에 필요하다는 것인가? 내부에서만 쓰겠다면, Compact 한 Sequential number 가 훨씬 좋다.

Natural Key 를 그냥 쓰는 것이 매우 좋은 대안이다.

만일 아직 Natural Key 가 없다면, 이것은 남에게 그 일을 떠넘기는 것을 전제로 한다. 하하하.

두번째 방법. Natural key 의 hash value 를 사용한다.

Natural Key 가 너무 길거나, 가변길이여서 다루기 힘든 경우가 있다. 대표적으로 url 의 경우, natural key 가 길고 가변길이이다. 이것에 대해, SHA1, MD5, murmur 등 hash function 을 적용하고, 그 hash value 를 natural key 인 것인양, 또는 candidate key 인 것인양 사용하면 된다. human readable representation 으로는 url safe base64 를 사용한다.

길이는 Birthday problem 을 풀어보면 답이 나온다. 저장공간을 아껴쓰고 싶다면, hash value 의 일부를 8 bytes ~ 12 bytes 정도로 끊어서 사용할 수 있다. 8 bytes 사용하는 경우, 2의 64승의 제곱근인 2의 32승 근처, 4G, 40억 정도의 데이터를 다루는데 문제가 없다. 12 bytes 사용한다면, 2의 48승 = 2의 32승 x 2의 16승 = 40억 x 6만 = 240조 정도의 데이터를 다룰 수 있다. 이 정도 선에서 충돌이 없을 것으로 추정할 수 있다. 8 bytes 의 hash value 는 base64 로 표현하면 12글자, 12 bytes 의 hash value 는 base64 로 표현하면 16글자가 된다.

첫글자에 구분자를 적절히 정의해 줄 수 있다. File 유형 구분하는 magic number 4~8 bytes 처럼, ID의 앞부분 몇비트에 따라, user_id, message_id, device_id 등 주요 resource 유형을 구분하는 체계를 embed 할 수 있다. 리소스 유형 구분자를 도입하는 것은, hash value 의 key 이든 auto increment key 이든, 생성 방식과 무관하게 유용하다.

실제로 카카오, 네이버 등이 이런 디자인 체계를 갖고 있(었)다. 고민해 보면, 결국 이 체계를 선택하게 된다. 세부 디테일에서 몇 바이트 쓸 것이냐, hash function 무엇을 쓸 것이냐, url 에서 http/https 떼어낸 것을 쓸 것이냐 붙이고 쓸 것이냐 등 이슈가 있긴 하지만.

세번째 방법. Surrogate key 를 직접 잘 만든다.

Natural Key 가 있으면 그것을 사용하는 것이 좋다. 그런데, Natural Key 가 없는 경우가 있다.

회원 가입을 처음 받는 곳, 카카오톡 메신저에서 메시지를 누군가 작성해서 전송하려는 시점 등에는, 회원ID, 메시지ID 가 존재하지 않는다. 회원, 메시지에 대한 Natural Key 가 없는 것이다.

이 경우에는, 엔지니어링 여력이 된다면, 분산된 incremental id 생성기를 구현하면 좋겠다. 예를 들어, 8 bytes 정수로 key 를 생성하는데, 수십~수백개 key 생성기 instance 가 여럿 동시에 작동하는 경우를 가정하고, 각각의 key 생성기가 중앙의 quorum based system 에서 key block 을 할당 받는 방식을 생각할 수 있다.

여러 사람이 비슷한 방식의 디자인과 구현을 시도했었다.

https://betterprogramming.pub/uuid-generation-snowflake-identifiers-unique-2aed8b1771bc

Twitter 에서는 다음과 같이 key 를 만들었다고 한다.

To solve the above project, Twitter developed the Snowflake project as a Thrift Server written in Scala. The generated Ids were composed of:

• Time — 41 bits (millisecond precision)
• Configured machine ID — 10 bits
• Sequence number — 12 bits — rolls over every 4096 per machine

https://stackoverflow.com/questions/18248644/proposed-solution-generate-unique-ids-in-a-distributed-environment

https://sqlblog.iridule.net/index.php/2009/08/30/surrogate-keys-in-distributed-databases/

We have two values to be combined: the database node identifier (DBNodeID), and the row identifier for a particular table on a particular database node (RowID). Let’s assume that both are integer values, which would not be unreasonable in practice. Each integer uses four bytes of storage, so to combine the two values without loss of information, we need eight bytes. We will use bigint as the data type for the combined value, which does require eight bytes of storage. To combine two integer values into one bigint value we will use a technique called bit shifting.

네번째 방법. MySQL 설정을 잘 해서, Auto increment id 를 잘 만든다.

Auto increment id 의 step 을 늘여서 master-master replication 설정을 적용하고, multi-region 구성을 적용하는 것이다. 이 방법은 실제로 작동하는 것을 본 것은 아니다. 작동은 잘 할 것 같은데, 애플리케이션, 플랫폼 구현 과정에서 어떤 문제가 발생할 것인지는, 직접 경험해 보지 않아서 잘 모르겠다. 이 다음에 DB를 새로 구성하게 되면 한번 시도해 봐야겠다.

https://w2.cleardb.net/faqs/

How does ClearDB work?

ClearDB uses a combination of standard MySQL, mixed in with “master-master” replication as well as our own specialized layered software stack to provide a highly available MySQL database environment for your applications and services. Each cluster is geographically separated to ensure your database’s availability, even if an entire network, datacenter, storage, or system failure occurs. Combined with our high availability routing technology, we ensure that your database is always online and fully available, 24/7.

마무리

생각난 김에 간단히 글로 정리하며 검색을 좀 해보니, 다른 사람들도 고민 많이 해서 좋은 방법이 알려진 문제라는 것도 다시 알게 되었다.