15장 : 구글 드라이브 설계
1단계 : 문제 이해 및 설계 범위 확정
기능 설계
파일 추가. 가장 쉬운 방법은 파일을 구글 드라이브 안으로 떨구는 것이다.
파일 다운로드
여러 단말에 파일 동기화. 한 단말에서 파일을 추가하면 다른 단말에도 자동으로 동기화되어야 한다.
파일 갱신 이력 조회(revision history)
파일 공유
파일이 편집되거나 삭제되거나 새롭게 공유되었을 때 알림 표시
비-기능적 요구사항 이해
안정성
빠은 동기화 속도
네트워크 대역폭
규모 확장성
높은 가용성
개략적 추정치
가입 사용자는 오천만(50milion) 명이고 천만 명의 DAU 사용자가 있다고 가정
모든 사용자에게 10GB의 무료 저장공간 할당
매일 각 사용자가 평균 2개의 파일을 업로드한다고 가정. 각 파일의 평균 크기는 500KB
읽기 : 쓰기 비율은 1 : 1
필요한 저장공간 총량 = 5천만 사용자 x 10GB = 500페타바이트(Petabyte)
업로드 API QPS = 1천만 사용자 x 2회 업로드/24시간/3600초 = 약 240
최대 QPS = QPS x 2 = 480
2단계 : 개략적 설계안 제시 및 동의 구하기
우선 아래와 같은 구성의 서버 한 대로 시작해보자.
파일을 올리고 다운로드 하는 과정을 처리할 웹 서버
사용자 데이터, 로그인 정보, 파일 정보 등의 메타데이터를 조관할 데이터베이스
파일을 저장할 저장소 시스템. 파일 저장을 위해 1TB의 공간을 사용할 것이다.
API
파일 업로드 API
단순 업로드
이어 올리기
이어 올리기 URL을 받기 위한 최초 요청 전송
데이터를 업로드하고 업로드 상태 모니터링
업로드에 장애가 발생하면 장애 발생시점부터 업로드를 재시작
파일 다운로드 API
파일 갱신 히스토리 제공 API
한 대 서버의 제약 극복
개선 할 부분
로드밸런서
웹 서버
메타데이터 데이터베이스
파일 저장소
동기화 충돌
여기서는 다음 전략을 사용할 것이다. 먼저 처리되는 변경은 성공한 것으로 보고, 나중에 처리되는 변경은 충돌이 발생한 것으로 표시하는 것이다.
개략적 설계안
3단계 : 상세 설계
이번 절에서는 블록 저장소 서버, 메타데이터 데이터베이스, 업로드 절차, 다운로드 절차, 알림 서비스, 파일 저장소 공간 및 장애 처리 흐름에 대해 자세히 알아볼 것이다.
블록 저장소 서버
정기적으로 갱신되는 큰 파일들은 업데이트가 일어날 때마다 전체 파일을 서버로 보내면 네트워크 대역폭을 많이 잡아먹게 된다. 이를 최적화하는 방법으로는 두 가지 정도를 생각해 볼 수 있다.
델타 동기화
압축
높은 일관성 요구사항
캐시에 보관된 사본과 데이터베이스에 있는 원본(master)이 일치한다.
데이터베이스에 보관된 원본에 변경이 발생하면 캐시에 있는 사본을 무효화 한다.
관계형 데이터베이스는 ACID를 보장하므로 강한 일관성을 보장하기 쉽다. 하지만 NoSQL 데이터베이스는 이를 기본으로 지원하지 않으므로, 동기화 로직 안에 프로그램해 넣어야 한다.
메타데이터 데이터베이스
업로드 절차
다운로드 절차
알림 서비스
롱 폴링(long polling)
웹소켓(WebSocket)
롱 폴링 채택 이유
채팅 서비스와는 달리, 본 시스템의 경우에는 알림 서비스와 양방향 통신이 필요하지 않다.
웹소켓은 실시간 양방향 통신이 요구되는 채팅 같은 응용에 적합하다.
저장소 공간 절약
중복 제거
지능적 백언 전략을 도입한다.
자주 쓰이지 않는 데이터는 아카이빙 저장소로 옮긴다.
장애 처리
로드밸런서 장애
블록 저장소 서버 장애
클라우드 저장소 장애
API 서버 장애
메타데이터 캐시 장애
메타데이터 데이터베이스 장애
주 데이터베이스 서버 장애
부 데이터베이스 서버 장애
알림 서비스 장애
오프라인 사용자 백업 큐 장애
Last updated
