구글 드라이브 설계 (대시설기)

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

기능적 요구사항

• 파일 추가
• 파일 다운로드
• 여러 단말에 파일 동기화
• 파일 갱신 이력 조회
• 파일 공유
• 파일이 편집되거나 삭제되거나 새롭게 공유되었을 때 알림 표시

비기능 요구사항

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

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

서버 한대에서 시작

• 파일을 올리고 다운로드 하는 과정을 처리할 웹 서버
• 사용자 데이터, 로그인 정보, 파일 정보 등의 메타데이터를 보관할 데이터베이스
• 파일을 저장할 저장소 시스템

API

1. 파일 업로드 API

• 단순 업로드
• 이어 올리기
  • 인자: uploadType=resumable, data: 업로드할 로컬 파일
  1. 이어 올리기 URL을 받기 위해 최초 요청 전송
  2. 데이터를 업로드하고 업로드 상태 모니터링
  3. 장애가 발생하면 장애 발생시점부터 업로드 재시작

1. 파일 다운로드 API
2. 파일 갱신 히스토리 API

한 대 서버의 제약 극복

샤딩하여 파일을 여러 서버에 나누어 저장하는 것. 그래도 고가용성 확보에 걱정이 된다.

→ AWS S3 서비스 사용

동기화 충돌

두 명 이상의 사용자가 같은 파일이나 폴더를 동시에 업데이트하려고 하는 경우

3단계 상세 설계

블록 저장소 서버

정기적으로 갱신되는 큰 파일들은 업데이트가 일어날 때마다 전체 파일을 서버로 보내면 네트워크 대역폭을 많이 잡아먹는다.

최적화하는 방법 2가지

1. 델타 동기화: 파일이 수정되면 전체 파일 대신 수정이 일어난 블록만 동기화
2. 압축: 블록 단위로 압축, 압축 알고리즘은 파일 유형에 따라 정한다.

높은 일관성 요구사항

데이터베이스에 보관된 원본에 변경이 발생하면 캐시에 있는 사본을 무효화한다. 관계형 데이터 베이스는 ACID를 보장하므로 강한 일관성을 보장하기 쉽다.

업로드 절차

1. 파일 메타데이터 추가
2. 파일을 클라우드 저장소에 업로드

다운로드 절차

파일이 새로 추가되거나 편집되면 자동으로 시작된다.

다른 클라이언트가 파일을 편집하거나 추가했다는 사실을 감지하는 방법 2가지

1. 변경 시 알림 서비스를 통해 새 버전을 끌어가야 한다고 알린다.
2. 클라이언트 A가 네트워크에 연결된 상태가 아닐 경우에는 데이터는 캐시에 보관될 것. 해당 클라이언트의 상태가 접속 중으로 바뀌면 그때 해당 클라이언트는 새 버전을 가져갈 것이다.

알림 서비스

2가지 선택지

1. 롱 폴링
2. 웹소켓

현재 설계안의 경우에는 롱 폴링을 이용할 것

이유 → 양방향 통신이 필요하지 않다.

저장소 공간 절약

3가지 방법

1. 블록 해시 값 비교해서 중복 제거
2. 백업 전략
   1. 한도 설정
   2. 중요한 버전만 보관
3. 자주 쓰이지 않는 데이터는 아카이빙 저장소(cold storage)로 옮긴다.