[keyword] 15장 - 구글 드라이브 설계

1. 문제 이해 및 설계 범위 확정

기능적 요구사항

파일 추가 (drag-and-drop)
파일 다운로드
여러 단말에 파일 동기화
파일 갱신 이력 조회
파일 공유
파일 편집, 삭제, 공유 시 알림

비기능적 요구사항

안정성
빠른 동기화 속도
네트워크 대역폭
규모 확장성
높은 가용성

개략적 추정치

가입 사용자는 오천만. DAU는 천만
모든 사용자에게 10GB 무료 저장소 제공
매일 각 사용자가 평균 2개의 파일을 올린다고 가정
- 각 파일의 평균 크기는 500KB
읽기 : 쓰기 비율은 1 : 1
필요한 저장공간 총량
- 오천만 x 10GB = 500 페타바이트
업로드 API QPS
- 1천만 x (2회 업로드 / 24시간 / 3600) = 약 240
최대 QPS = 480

2. 개략적 설계안 제시 및 동의 구하기

파일 저장소 서비스는 크게 세 가지 파트로 나눠볼 수 있다.

API 서버
메타데이터 데이터베이스
파일 저장소

API 서버

API서버가 제공해야할 기능은 다음과 같다.

파일 업로드
- 파일 크기에 따라 단순 업로드, 이어 올리기 두 가지 방법을 제공한다.
  - 단순 업로드 파일 크기가 작을 때.
  - 이어 올리기 파일 크기가 크거나, 네트워크 상태가 좋지 않아 업로드 중단이 발생할 확률이 높다면 이 방법을 사용해야 한다. 아래 세 단계 절차로 이루어진다.
    - 이어 올리기 URL을 받기 위한 요청
    - 데이터 업로드 & 업로드 상태 모니터링
    - 업로드가 중단되면, 중단된 지점부터 재시도
파일 다운로드
- 다운로드할 파일의 path를 담아 요청하는 방식
파일 갱신 이력 히스토리 조회
- 히스토리 조회할 파일의 path와 히스토리 크기(limit? size?) 를 담아 요청하는 방식

위에서 언급한 모든 API는 반드시 “사용자 인증”과 “https를 통한 암호화”가 동반되어야 한다.

파일 저장소

한 대의 서버에 모든 사용자 파일들을 저장하면 언젠간 용량 부족에 직면한다.

따라서 파일 저장소는 샤딩을 통해 여러 서버로 존재해야하며, 여러 지역 데이터센터에 다중화하여 높은 가용성을 갖춰야한다.

AWS S3는 높은 확장성과 가용성, 안정성을 갖춘 파일 저장소이다. 이러한 클라우드 서비스를 활용하면 개발 생산성을 높이는 동시에 안정적인 파일 저장소를 갖추게 될 것이다.

메타데이터 데이터베이스

사용자 파일 자체는 파일 저장소에 저장하지만, 그 파일을 설명할 수 있는 데이터들은 별개의 데이터베이스에 저장하여 SPOF를 방지해야 한다.

이 외에도 “동기화 충돌” 같은 이슈를 어떻게 해결할지 고민해보아야 한다.

개략적으로 설계한 결과는 아래 그림과 같다.

블록 저장소 서버
- 사용자 파일을 블록 단위로 나누고, 이를 클라우드 저장소 (AWS S3) 에 저장하는 서버
- 사용자 파일을 블록 단위로 나눌 때 각 블록의 해시값을 메타데이터 데이터베이스에 저장해둔다.
- 사용자 파일을 사용자에게 제공하려면, 파일을 구성하는 모든 블록들을 모아 재구성해야한다.
클라우드 저장소
- 사용자 파일 블록들을 저장하는 서버
아카이빙 저장소
- 오랫동안 사용되지 않은 비활성 데이터를 저장하기 위한 컴퓨터 시스템
알림 서비스
- 사용자 파일이 생성, 삭제, 편집되면, 그 파일의 상태를 구독한 사용자들에게 알림을 보내주는 서비스
- 알림 서비스를 통해 빠른 파일 동기화가 가능하다.
오프라인 사용자 백업 큐
- 클라이언트가 접속중이 아니라면, 해당 정보를 이 큐에 저장하여 이후 사용자가 접속했을 때 제공한다.

3. 상세 설계

블록 저장소 서버

크기가 큰 파일을 자주 클라우드 저장소로 업로드하면 네트워크 대역폭에 부담이 될 수 있다.

이를 위한 방법으로는 아래 두 가지가 있다.

델타 동기화
- 파일 중 수정된 블록만 클라우드 저장소에 저장
블록 압축
- 파일 유형별로 적당한 압축 알고리즘을 활용해 압축

블록 저장소 서버는 파일 업로드와 관련된 무거운 작업들을 도맡아 수행하는 서버라고 보면 된다.

파일을 블록 단위로 나누기
수정된 블록들만 걸러내기
각 블록 압축
각 블록 암호화
각 블록을 클라우드 저장소로 전송

높은 일관성 요구사항

구글 드라이브 서비스는 강한 일관성 모델을 따라야 한다.

즉, 디바이스별로 다른 파일 상태를 보여주면 안되고, 메타데이터 캐시 혹은 데이터베이스 또한 강한 일관성을 유지해야 한다.

(= 캐시와 데이터베이스의 내용이 항상 일치해야 하며, 데이터베이스의 내용에 변경사항이 생기면 캐시의 해당 데이터를 무효화한다.)

파일 업로드 절차

파일 다운로드 절차

알림 서비스

웹소켓
- 실시간 양방향 통신에 어울리는 프로토콜
- 구글 드라이브 시스템은 서버 → 클라이언트로의 통신이 대다수이므로, 웹소켓은 적절치 않다.
롱 폴링
- 클라이언트가 요청을 보내두고, 서버는 클라이언트가 구독한 메타데이터에 변경사항이 있을 때 까지 응답하지 않는다.
- 메타데이터DB에 변경이 있다면, 서버는 클라이언트와의 연결을 의도적으로 끊는다.
- 사용자는 이 즉시 서버에 새로운 메타데이터 정보를 요청하고, 변경사항이 있다면 해당 파일의 다운로드를 요청한다.
- 위 과정이 이루어졌거나 타임아웃으로 인해 연결이 끊겼다면, 다시 서버에 롱 폴링 요청을 보내어 변경사항을 listen한다.

저장소 공간 절약

사용자가 파일 수정과 같은 작업을 자주 하고, 서버가 그때마다 버저닝을 한다면 저장소의 용량은 빠르게 부족해질 것이다. 이러한 상황을 방지할 방안이 필요하다.

블록 중복 제거
- 블록의 해시값으로 중복인 블록을 계정 차원에서 제거한다.
한도 설정
- 사용자 당 저장 가능한 최대 파일 버전 개수를 설정한다.
- 개수를 넘으면, 가장 오래된 버전을 지운다.
중요한 버전만 저장
- 어떤 버전이 중요한 버전인지를 걸러내는 로직이 필요하다.
아카이빙 저장소
- 사용자에 의해 오랫동안 접근되지 않은 파일은 AWS S3 glacier와 같은 아카이빙 저장소에 따로 보관한다. (저장소 가격이 훨씬 저렴함)

caffeine-library / system-design-interview