wooyounggggg commented 2 years ago

질문

책 7장에서는 ID 생성기가 필수 불가결한 컴포넌트이므로 높은 가용성을 요구한다고 합니다. 그런데 경험상 ID 생성기라는 시스템은 생소하기도 하고, 필수 불가결한 정도는 아니라고 생각하는데 어떤 곳에 ID 생성기를 사용하기에 저렇게 언급하는 것인지 궁금합니다.

연관 챕터

21

@caffeine-library/readers-system-design-interview

ngwoon commented 2 years ago

책 전반적인 맥락을 봤을 때 분산 환경에서의 내용을 다루고 있는 것으로 보아 분산 환경에서는 ID생성기가 필수 불가결한 컴포넌트라고 말하고 싶었던 것 같습니다.

use case로는 분산 RDB를 생각해 봤습니다. 분산 RDB는 6장에서 다뤘던 안정 해시 구조라고 가정해 보겠습니다. 지속성, 가용성을 위해 레플리카 서버 개수를 3개로 잡는다면, 해시 링 위에서 3개의 가상 노드는 동일한 데이터들을 관리하게 됩니다. (이 가상 노드들을 각각 A, B, C라고 하겠습니다.) 이러한 분산 RDB에 유저 테이블이 존재하고, 백엔드 애플리케이션 (이하 클라이언트) 에서 회원가입 서비스를 제공한다는 상황을 상상해 보겠습니다.

서로 다른 두 클라이언트에서 거의 동시에 분산 RDB에 각각 한 명씩 유저 저장 (남관우, 지우영)을 요청했다면, coordinator에서 그 요청을 A, B, C에 포워딩할 것입니다. 이 때 네트워크 상태에 의해 A에는 남관우, 지우영 순으로 저장 요청이 왔고, B에는 지우영, 남관우 순으로 요청이 왔습니다. 결과적으로 A에는 PK 1 - 남관우, PK 2 - 지우영 이렇게 저장이 될 것이고, B에는 PK 1 - 지우영, PK 2 - 남관우 이렇게 저장이 될 것입니다. 후에 관리자가 유저를 회원가입 순으로 조회하고자 PK 오름차순으로 조회 쿼리를 던진다면, 이 요청이 A에 의해 처리된 결과와 B에 의해 처리된 결과가 다르게 됩니다. 즉, SELECT 쿼리의 멱등성(?)이 지켜지지 않게 됩니다.

이 use case를 생각해보면서, 분산 시스템이 갖는 여러 불안정한 요소 때문에 시간적 순서가 지켜져야 하는 데이터는 클라이언트 측에서 ID를 생성해서 직접 넣어주는 것이 더욱 안정적이므로 ID 생성기가 반드시 필요한 컴포넌트라고 책에서 언급했구나 라는 생각이 들었습니다.

JasonYoo1995 commented 2 years ago

ID의 역할

기본적으로 ID라는 것은 엔티티에 대한 식별자 역할을 합니다.
ID를 통해 특정 엔티티를 찾고자 할 때는
유일하게 식별하기 위해 중복되지 않는 고유한 값을 가져야 하는데
만약 ID가 중복이 된다면, 어떤 엔티티를 찾아야 하는지 결정하지 못하게 됩니다.
Key-Value 저장소에서는 Key가 ID 역할을 하고
RDB에서는 PK(Primary Key, 기본 키) 또는 Unique 제약 조건이 붙은 Column이 ID 역할을 할 수 있습니다.
Key-Value 저장소에서 ID는 필수 불가결하다고 볼 수 있지만
RDB에서는 꼭 그렇지 않을 수도 있습니다.

ID 없이도 운영 가능하다

만약 RDB에서 ID를 사용하지 않고 엔티티를 찾으려면 ID와 같은 역할을 하는 "무언가"를 사용해야 할 것입니다. 1) "select from table_name where column_name=value"에서 where절에 들어가는 컬럼이 ID의 역할을 할 수도 있고 (즉, Unique 제약 조건이 들어간 컬럼) 2) "select from table_name where column_name1=value1 and column_name2=value2"에서 where절에 들어가는 컬럼들의 조합이 ID의 역할을 할 수도 있을 것입니다. (단, 컬럼들의 조합은 유일해야 합니다)

성능이 문제라면 해당 컬럼들을 Indexing하면 됩니다.

그런데 왜 분산 시스템에서 ID를 '필수 불가결'하다고 표현한 걸까?

저는 다음과 같은 순서로 논리를 펼칠 것입니다.

RDB에서 PK는 필수적이다
→ RDB에서 PK의 후보로 ID가 제일 좋다
→ 따라서 RDB에서 ID는 필수적이다
→ 단일 시스템에서 ID가 필수적이라면, 분산 시스템에서도 필수적일 것이다

기본 키(PK)에 대해 알아보자

PK는 한 개의 컬럼으로 지정할 수도 있고, 여러 개의 컬럼의 조합(=Composite Key, 복합 키)으로 지정할 수도 있는데
중요한 것은 '컬럼' 혹은 '컬럼들의 조합'이 해당 테이블 내에서 "유일"해야 하고 "NULL이 아니어야 한다"는 것입니다.
현대의 엔터프라이즈 앱들은 비즈니스 요구사항이 계속해서 바뀌고
시스템의 규모와 기능은 빠르고 끊임 없이 확장되기 때문에
DB의 스키마도 계속해서 수정되거나 추가되므로
'PK가 없는 전략'은 실무적인 측면에서 좋지 않은 전략이 될 수 있습니다.

PK가 없는 전략의 문제점

이 부분은 제 수준에서 잘 이해가 가지 않아서 인터넷의 내용을 복붙하겠습니다
- 데이터 무결성이 깨어질 수 있다.
- 데이터 무결성이 깨어지기 때문에 데이터 전환 작업 시 데이터 정리 작업이 필요하다.
- 데이터 모델과 테이블의 관계가 일치하지 않는다.
- Unique Index는 한 테이블에 여러 개 만들 수 있으므로 테이블만 보고 PK가 무엇인지 구분할 수 없다.
ID 역할을 하는 컬럼에서 NULL 값을 가질 수 있을 때 생길 수 있는 문제점들이 나열된 것 같습니다.
대체로 유지보수 측면에서 관리가 어려워진다는 내용 같습니다.

ID가 아닌 값을 PK로 사용하는 전략의 문제점

그렇다면 PK가 필요한 건 알겠는데, 왜 굳이 ID를 PK로 쓰려고 하는 걸까 의문이 들 수 있습니다.
문제 예시 1
- 기존에 PK로 지정했던 컬럼이 '평문으로 저장한 주민등록번호'였는데
  주민등록번호를 반드시 암호화하여 저장해야 한다는 법 개정이 이루어진다면
  PK의 값을 모두 암호화된 값으로 변경해야 할 것이고
  기존에 해당 PK를 참조하고 있던 다른 테이블의 FK(=Foreign Key)들도 모두 그 값을 암호화된 값으로 바꾸어야 할 것입니다.
  (하나의 변경으로 인해, 많은 것을 동시에 바꾸어야 하는 것은 좋지 않은 설계라고 다들 알고 계실 겁니다)
- 뿐만 아니라, 만약 암호화된 값이 낮은 확률로 충돌한다면 (즉, 다른 input의 암호화된 output이 같다면)
  PK로서의 역할을 할 수 없게 되고, 다른 컬럼을 PK로 새로 지정해야 합니다.
  (애초에 데이터베이스는 중복되는 값이 하나라도 존재하는 컬럼은 PK로 지정할 수도 없습니다(=기본 키 제약 조건))
문제 예시 2
- 기존에 PK로 지정했던 컬럼이 '이메일 주소'나 '전화번호'일 경우
  누군가 해당 이메일의 계정을 탈퇴한 뒤 다른 사람이 우연히 같은 이름의 이메일로 계정을 생성할 수도 있고
  전화번호를 바꾼 뒤 다른 사람이 해당 전화번호를 사용할 수도 있습니다.
문제 예시 3
- 기존에 PK로 지정했던 컬럼이 '이메일 주소'나 '전화번호'일 경우
  원래의 비즈니스 요구사항은 한 사람 당 한 개의 계정만을 만들 수 있었는데
  여러 계정을 가질 수 있다는 요구사항으로 바뀐다면
  그 계정들은 같은 이메일과 같은 전화번호를 사용하게 될 것이고
  해당 컬럼은 중복을 허용해야 해서, 더 이상 PK로서 적합한 컬럼이 되지 않습니다.
해결 방법
1. 기존에 존재하던 다른 컬럼을 새로운 PK로 지정합니다.
2. 혹은 새로운 컬럼을 생성하여 그 컬럼을 새로운 PK로 지정합니다.
추가 비용
- 위 2가지 방법으로 문제를 해결할 수는 있지만 추가적인 비용과 부작용이 생깁니다.
- PK를 바꾸게 되면, DB의 스키마도 변경해야 할 뿐만 아니라, DB의 관련 테이블들을 사용하는 "웹 서버의 로직"도 모두 변경해야 합니다.
- 특히 만약 테이블의 레코드가 수백만 개 이상이라면,
  스키마를 변경하는 작업은 많은 부하와 딜레이, 병목 현상을 유발합니다.

바람직한 PK 전략

비즈니스 내에서 어떠한 의미를 가지는 컬럼(주민등록번호 등과 같은 자연키) 말고,
식별 이외의 아무런 의미를 가지지 않는 컬럼(UUID 등과 같은 대체키)을 만들어 PK로 설정하는 것이 좋습니다.
ID가 바로 그런 대체키입니다. PK의 후보로는 ID가 제일 좋습니다.
현대의 엔터프라이즈 앱들은 애자일하게 빠른 확장 및 변경이 필수적이고, 추후 확장성 및 유지 보수성을 고려해야 하므로, 당장은 ID가 필요 없는 경우에도, 추후 확장성을 위해서 모든 테이블에 미리 만들어 두는 것이 좋습니다.
그렇게 하면 지금까지 언급했던 문제들로 걱정을 하지 않아도 되고, 변경에 의한 영향을 최소화할 수 있는 좋은 설계를 가질 수 있습니다.

분산 시스템에서의 ID Use Case

DB 병합
- GUID(=Global Unique Identifier) : 분산 시스템 전체에서 중복되지 않는 ID
- 여러 개의 Database를 하나의 Database로 병합하고자 할 때, PK가 중복(혹은 충돌) 되어 병합이 불가능한 경우
- 병합하기 전부터 GUID를 PK로 설정했었다면, 병합이 매우 쉬워짐
8장의 URL 단축기 데이터베이스가 샤딩되어 구축되었을 때
- 서로 다른 DB 간에 ID가 중복되면, shortURL이 충돌됨

결론

(PK를 쓰지 않고 UI(=Unique Index)만으로 쓰는 것이 더 좋다고 주장하는 등 일부 논란의 여지는 있지만) RDB를 쓰는 엔터프라이즈 앱에서는 비즈니스 요구사항이 빠르게 바뀌므로 스키마의 변경이 잦고 따라서 모든 테이블에 PK를 미리 만들어두는 편이 장기적으로 볼 때 유리하다. 그런데 이때, ID는 '중복되지도 않고 NULL 값을 가질 수 없어야 한다'는 PK의 조건을 모두 충족하므로 PK는 ID로 구성하는 것이 좋다. 따라서 단일 시스템에서 ID 생성기는 필수 불가결하다고 주장할 수 있고 분산 시스템에서도 역시 ID 생성기는 필수 불가결하다고 주장할 수 있다.

caffeine-library / system-design-interview

[question] ID 생성기의 use case #23

질문