[39일차] | 대규모 시스템 설계 기초2 | 책너두

메타데이터 데이터모델

스키마

• 메타데이터를 통해 아래와 같은 질의를 지원해야 한다.

  • 객체 이름으로 객체 ID 찾기
  • 객체 이름을 기반으로 삽입, 또는 삭제 처리
  • 같은 접두어를 갖는 버킷 내의 모든 객체 찾기

• 이러한 요구사항을 만족하기 위한 메타데이터 테이블 구조는 다음과 같다:

테이블명	컬럼	설명
Buckets	bucket_name	버킷의 이름
	bucket_id(PK)	버킷의 고유 식별자
	owner_id	버킷 소유자 ID
	enable_versioning	버전 관리 활성화 여부
Objects	bucket_name	객체의 이름
	object_name	객체의 이름
	object_version	객체의 버전
	object_id	객체의 고유 식별자

bucket 테이블의 규모 확장

• 버킷 테이블의 규모 산정

  • 고객은 백만 명
  • 고객당 평균 10개의 버킷을 보유
  • 버킷의 레코드는 10kb라고 가정하면,
  • 전체 크기는 (100만 10 10kb) = 10GB

• 하나의 데이터베이스로 처리 가능한 크기이지만, 모든 읽기/쓰기를 감당하기에는 대역폭이 부족할 수 있음.

• 따라서 데이터베이스 사본을 활용하는 것이 적절함.

object 테이블의 규모 확장

• 객체는 당연하게도 버킷에 비해 훨씬 많은 데이터를 저장함.
• 이를 단일 데이터베이스에 저장하는 것은 불가능함.
• 따라서 이는 샤딩(sharding)을 통해 분할하여 저장함.
  • bucket_id를 기준으로 샤딩한다면, 헤비 유저의 버킷이 핫스팟이 되므로 부하가 분산되지 않음.
  • object_id를 기준으로 샤딩한다면, 핫스팟은 줄일 수 있지만 앞서 이야기한 1, 2번 질의를 효과적으로 처리하기 어렵다. 이는 두 질의는 URI를 기준으로 처리되기 때문임.
  • 결과적으로 여기에서는 bucket_id와 object_name을 결합하여 샤딩에 활용할 수 있음.

Q. URI를 기준으로 처리하는것과 object_id를 기준으로 샤딩하는것이 무슨 관계가 있지?

두 질의는 모두 URI를 기준으로 처리되기 때문에, 객체의 이름이 문자열로 제공됨.
따라서 이 문자열을 object_id(UUID)로 변환하기 위해 메타데이터가 필요한데, 이는 결국 모든 샤드를 탐색해야 알 수 있음.
반면 bucket_id와 object_name을 결합하여 샤딩하면, 이는 두 문자열을 결합하여 하나의 샤드를 특정할 수 있으므로 효율적임.

버킷 내 객체 목록 확인

• 객체 저장소는 파일 시스템처럼 객체를 계층적으로 보관하지 않는다.
• 우리가 디렉토리로 알고있는것도 결국은 객체 이름의 프리픽스(prefix)일 뿐이다.

단일 데이터베이스 서버

• 단일 데이터베이스 서버에서 객체를 조회하는 방식은 아래와 같다.

  # 사용자의 모든 버킷 조회
  SELECT * FROM bucket WHERE owner_id={id}
  
  # 버킷 내의 특정 디렉토리 내의 모든 객체 선택(접두어)
  SELECT * FROM object
    WHERE bucket_id = "123" AND object_name LIKE `abc/%`

• 이 작업에서 abc이하의 디렉토리 처리는 어플리케이션에서 처리한다.

분산 데이터베이스 서버

• 분산 데이터베이스에서는 우리가 찾는 데이터가 어떤 샤드에 있는지 모른다.

• 가장 쉬운 방법은 모든 샤드에 검색을 하고, 이 결과를 종합하는 것이다.

  # 모든 샤드에 아래 쿼리 실행 및 결과 취합
  SELECT * FROM object
    WHERE bucket_id = "123" AND object_name LIKE `a/b/%`

  • 이 방식은 동작하지만 페이지네이션 적용이 어렵다.
    • 모든 데이터를 취합 후 재정렬 해야 하는 소요가 있다.
    • 또한, 다음 페이지를 위한 커서 등을 사용할 때 각 샤드마다 기준이 달라질 수 있다.
      • 따라서 샤드 수 만큼 각각 개별적인 오프셋(커서)을 관리해야 한다.