대체키 사용하기

Fastcampus의 The Red 강의 중

The RED : 비즈니스 성공을 위한 Java/Spring 기반 서비스 개발과 MSA 구축 by 이희창

수업을 들으며 대체키와 관련된 내역을 들었고 이것은 나중에 어디서나 사용할 수 있는 지식이다!라고 생각이 들어 호다닥 정리하기로 결심했다.

최근 너무 강의에 대한 피드백 글만 올리는 것 같기도 하고...

---

식별자와 PK

• DDD의 Entity 개념에서 고유한 식별자는 중요 개념 중 하나
• Entity는 자신의 생명주기동안 형태와 내용이 급격하게 변경될 수 있지만 그 엔티티의 성질은 연속적으로 유지되어야 한다.
  • 객체 A의 속성은 서비스 로직이 진행되면서 값이 변경될 수 있지만 객체 A라는 것은 변하지 않고 지속되어야 한다.
  • (도메인 주도 설계의 p93 참고)
• 위와 같이 변화되는 Entity를 추적하기 위해서는 식별성이 부여되어야 하고, 식별자는 해당 시스템 내에서 유일하고 변경되어서는 안된다!
• 보통의 DBMS로 영속성 관리하는 시스템에서는 Entity 식별자를 Table의 PK와 매칭한다.
  • 나도 그렇다. :)
• 대표적으로 MySQL의 경우는 id값으로 AUTO_INCREMENT bigint로 설정한다.

대체키의 정의와 필요성

• 대체키(Surrogate Key)가 무엇?
  • 본래는 자연키와 대칭되는 개념이지만, 강의에서는 Entity의 식별자와 동급의 의미를 가지는 Unique Key의 식별자 정도로 용어를 정의한다고 한다.
• Entity의 식별자는 외부에 오픈하거나 오용되지 않도록 주의하고, 식별자가 아닌 대체키를 오픈하는 것이 다방면에서 유용하다.
• 고유키를 통한 서비스 구현에 대한 문제 예시
  • 예시 1) Entity의
    1. Bigint(Long) 형태의 유저 식별키를 URL Path로 사용하여 유저의 거래내역을 노출하는 GET API가 있었고, 해당 API 호출에 있어 인증과정이 생략되어 있다고 가정
    2. URL에 드러나는 유저 식별키를 임의로 조작하면 다른 유저의 거래내역을 손쉽게 확인할 수 있다.
    3. 위와 같은 실제 사례가 있었고, 이슈 발생 후 랜덤 스트링 형태의 대체키로 변환하여 API를 수정하였다고 한다...
  • 예시 2) 외부 서비스 연동
    1. 외부 협력사와 자사 서비스 간에 상품 데이터 연동 과정에 키 값을 시스템 내부 PK로 사용했다고 가정
    2. 양사 간의 데이터는 자사 시스템의 내부 PK로 강하게 연결됨
    3. 이후 자사 시스템의 DB를 MySQL에서 MongoDB 등으로 변경하게 되는 이슈가 발생한다고 가정
    4. 달라진 PK 체계로 인하여 외부 협력사와의 연동에 많은 공수가 발생

구현은?

• 시스템 내부에서 Entity 식별자는 Long 타입의 id를 사용하고, 외부에 오픈할 때는 대체키를 사용!
• 대체키는 String 기반의 token을 생성하고 Unique Index로 설정하여 사용한다.
• 대체키를 사용할 때에는 성능에 대한 고려가 필요하다.
  • MySQL을 기준으로 하여 1천만 건 이하의 데이터는 Random String으로 사용해도 무방하지만, 성능을 고려한다면 UUID를 Rearranged 하여 사용하는 것을 검토할 수 있다.
  • 예시) Random String으로 사용하여 대체키를 설정하는 경우: saflAWEsdflwEsdfs
    Prefix를 설정하여 대체키를 설정하는 경우: 230315_saflAWEsdflwEsdfs(날짜를 prefix로 설정하고 UUID를 Rearranged 한 경우)
• 함께 보면 좋을만한 글
  • 대충 timestamp 기반의 UUID와 timestamp를 재정렬한 UUID, 그리고 bigint의 키를 가지는 각각의 데이터에 대한 조회 시간과 관련된 글이다.
  • Referenced. https://www.percona.com/blog/store-uuid-optimized-way/