15장. 구글 드라이브 설계
- 아래의 드라이브 설계에 대해서 다음과 같은 내용을 이야기합니다.
1단계 문제 이해 및 설계 범위 확정#
- 다음의 기능 설계에 집중합니다.
- 파일 추상화가파일 다운로드
- 여러 단마렝 파일 동기화
- 파일 갱신 이력 조회
- 파일 공유
- 파일이 편집되거나 새롭게 공유될 때 알림을 표시합니다.
- 아래의 사항에 대해서는 논의하지 않습니다.
- 구글 문서 편집 및 협업 기능
- 기능적 요구사항 이외, 비-기능적 요구사항
- 안정성 : 저장소 시스템에서 안정성은 아주 중요합니다.
- 빠른 동기화 속도 : 파일 동기화에 시간이 너무 많이 걸리면 사용자는 인내심을 잃습니다.
- 네트워크 대역폭 : 이 제품이 네트워크 대역폭을 크게 쓰면 안좋습니다.
- 규모 확장성 : 아무 많은 양의 트래픽도 처리 가능해야합니다.
- 높은 가용성 : 일부 서버에 장애가 발생하거나, 느려지거나, 네트워크 일부가 끊겨도 시스템은 계속 사용 가능해야합니다.
개략적 추정치#
- 가입 사용자는 오천만 명이고 천만 명의 DAU 사용자가 있다고 가정합니다.
- 모든 사용자에게 10GB의 무료 저장공간 할당
- 매일 각 사용자가 평균 2개의 파일을 업로드한다고 가정합니다.
- 읽기:쓰기 비율은 1:1
- 필요한 저장공간 총량 = 5천만 * 10 GB = 500 페타바이트(Petabyte)
- 업로드 API QPS = 1천만 사용자 * 2회 업로드/24시간/3600초 = 약 240
- 최대 QPS = QPS * 2 = 480
2단계 개략적 설계안 제시 및 동의 구하기#
API#
- 파일 업로드 API
- 단순 업로드
- 이어 올리기
- 파일 다운로드 API
- 파일 갱신 히스토리 API
한 대 서버의 제약 극복#
- 로드밸런서
- 웹 서버
- 메타데이터 데이터베이스
- 파일 저장소
동기화 충돌#
- 동시에 같은 파일이나 업데이트하는 경우, 발생하는 문제를 해소해야 합니다.
개략적 설계안#
- 사용자 단말: 사용자가 이용하는 웹브라우저나 모바일 앱 등의 클라이언트
- 블록 저장소 서버(block server): 파일 블록을 클라우드 저장소에 업로드하는 서버
- 클라우드 저장소
- 아카이빙 저장소: 비활성 데이터
- 로드밸런서
- API 서버
- 메타데이터 데이터베이스
- 알림 서비스
- 오프라인 사용자 백업 큐
3단계 상세 설계#
블록 저장소 서버에#
- 델타 동기화 : 파일이 수정되면 전체 파일 대신 수정이 일어난 블록만 동기화
- 압축 : 블록 단위로 압축해 두면 데이터 크디를 많이 줄일 수 있습니다.
높은 일관성 요구사항#
- 강한 일관성을 지원해줘야합니다.
메타데이터 데이터베이스#
업로드 절차#
다운로드 절차#
알림 서비스#
- 두 가지 정도의 서비스가 있습니다.
- 롱 폴링(long polling): 드롭박스가 이 방식을 채택하고 있습니다.
- 웹 소켓(WebSocket): 클라이언트와 서버 사이에 지속적인 통신 채널을 제공, 양방향 통신이 가능합니다.
저장소 공간 절약#
- 중복 제거
- 지능적 백업 전략
- 한도 설정
- 중요한 버전만 보관
- 자주 쓰지 않는 데이터는 아카이빙 저장소
장애 처리#
- 로드밸런서 장애
- 블록 저장소 서버 장액
- 클라이언트 저장소 장애
- API 서버 장애
- 메타데이터 캐시 장애
- 메타데이터 데이터베이스 장애
- 알림 서비스 장애
- 오프라인 사용자 백업 큐 장애
4단계 마무리#
- 설계에는 답이 없습니다.
- 아래의 내용에 대해 더 이야기해볼 수 있습니다.
- 블록 저장소 서버가 없는 경우
- 접속상태를 관리하는 로직을 새로 분리