TIL

15장 구글 드라이브 설계

설계 범위 예시

기능 요구 사항
- 파일 추가
- 파일 다운로드
- 여러 단말에 파일 동기화
- 파일 갱신 이력 조회
- 파일 공유
- 파일이 편집되거나 삭제되거나 새롭게 공유되었을 때 알림 표시
비기능 요구사항
- 안정성: 데이터 손실 방지
- 빠른 동기화 속도: 동기화에 시간이 많이 걸리면 사용자가 불편함을 느낌
- 네트워크 대역폭: 네트워크를 많이 사용하면 사용자는 좋아하지 않을 것
- 규모 확장성: 많은 트래픽 처리
- 높은 가용성: 일부 서버에 장애가 발생해도 시스템은 계속 사용 가능해야 한다.

개략적 추정치

가입 사용자는 오천만 명, DAU는 천만 명
모든 사용자에게 10GB 무료 저장공간 할당
메일 각 사용자가 평균 2개 파일 업로드, 각 파일 평균 크기는 500KB
읽기:쓰기 비율 - 1:1
필요한 저장공간 춍량 = 5천만 X 10GB = 500페타바이트(Petabyte)
업로드 API QPS = 1천만 X 2회 업로드 / 24시간 / 3600초 = 약 240
최대 QPS = QPS X 2 = 480

구글 드라이브 개략적 설계안

우선 아래와 같은 구성의 서버 한 대로 구성
- 웹 서버 - 파일 업로드 및 다운로드 처리
  - 아파치 웹 서버 사용
- 데이터베이스 - 사용자 데이터, 로그인 정보, 파일 메타데이터 보관
  - MySQL 서버 사용
- 파일 저장소 시스템 - 파일 저장을 위한 1TB의 공간 사용
  - 서버 내에 drive/라는 디렉터리 생성
  - 네임스페이스라 불리는 하위 디렉터리를 둔다. (사용자별 파일 공간)

파일 업로드 API

파일 업로드 API
- 단순 업로드: 파일 크기가 작을 때 사용
- 이어 올리기: 파일 사이즈가 크고 네트워크 문제가 예상될 때 사용
이어 올리기 api 예) api.example.com/files/upload?uploadType=resumable
- uploadType: resumable
- data: 업로드할 로컬 파일
이어올리기 절차
- 이어올리기 URL을 받기 위한 최초 요청 전송
- 데이터를 업로드하고 업로드 상태 모니터링
- 업로드 중 장애가 발생하면 장애 발생 시점부터 업로드 재시작

파일 다운로드 API

예) api.example.com/files/download

인자

path: 다운로드할 파일 경로

  {
    "path": "/recipes/soup/best_soup.txt"
  }

파일 갱신 히스토리 API

예) api.example.com/files/list_revisions
인자
- path: 갱신 히스토리를 가져올 파일 경로
- limit: 히스토리 길이 최대치
```
  {
    "path": "/recipes/soup/best_soup.txt",
    "limit": 20
  }
```

한 대 서버의 제약 극복

AWS S3 이용
- 파일 시스템 용량 한계 극복
- AWS Simple Storage Service: 규모 확장성, 가용성, 보안을 제공하는 객체 저장소 서비스
- 서로 다른 지역에 데이터를 다중화할 수 있다.
로드 밸런서 도입
- 네트워크 트래픽 분산
- 웹 서버 증설 가능
메타데이터 데이터베이스
- DB를 파일 저장소 서버에서 분리하여 SPOF를 회피
- 다중화 및 샤딩 정책을 적용하여 가용성과 확장성 확보

동기화 충돌

두 명 이상의 사용자가 같은 파일이나 폴더를 수정하려는 경우
충돌 해소 전략
- 사용자1의 먼저 처리되는 변경은 성공으로 처리
- 사용자2의 나중에 처리되는 변경은 충돌이 발생한 것으로 표시
충돌이 발생했을 경우 이 시스템에는 같은 파일의 두 버전이 존재
- 서버에 있는 최신 버전
- 사용자2 로컬에 있는 최신 버전
두 파일을 하나로 합칠지, 하나를 다른 파일로 대체할지 결정해야 한다.

개략적 설계 아키텍처

사용자 단말: 클라이언트
블록 저장소 서버
- 파일 블록을 클라우드 저장소에 업로드하는 서버
- 블록 저장소란 클라우드 환경에 데이터 파일을 저장하는 기술
- 한 파일을 여러 블록으로 나눠 저장하며 각 블록은 독립적인 객체로 취급
- 블록은 고유 해시값이 할당되며 해시값은 메타데이터 데이터베이스에 저장
- 파일을 재구성하려면 블록들을 원래 순서대로 합쳐야 한다.
클라우드 저장소: 블록 단위로 나눠진 파일을 보관
아카이빙 저장소: 오래 사용되지 않은 비활성 데이터를 보관
로드 밸런서: 요청 분산
API 서버: 파일 업로드 외에 거의 모든 것을 담당
메타데이터 데이터베이스: 사용자, 파일, 블록, 버전 등 정보 보관
메타데이터 캐시: 성능을 위해 자주 쓰이는 메타데이터 보관
알림 서비스: 특정 이벤트를 클라이언트에 통지
- 발생/구독 프로토콜 기반
오프라인 사용자 백업 큐
- 클라이언트가 접속 중이 아니라 파일 최신 상태를 확인 못할 때
- 최신 정보를 이 큐에 두어 나중에 동기화될 수 있도록 조치

구글 드라이브 상세 설계

블록 저장소 서버

큰 파일을 보낼 때 최적화 방법
- 델타 동기화: 파일이 수정되면 전체 파일 대신 수정이 일어난 블록만 동기화
- 압축: 블록 단위로 압축해 두어 크기를 줄일 수 있다.
블록 저장소 역할
- 주어진 파일을 작은 블록들로 분할
- 각 블록 압축
- 클라우드 저장소로 보내기 전에 암호화
- 클라우드 저장소로 전송
- 델타 동기화 적용 가능

높은 일관성 요구사항

이 시스템은 강한 일관성 모델을 기본으로 지원해야 한다.
- 같은 파일을 여러 단말이나 사용자에 따라 다르게 보이는 것을 허용하지 않음
- 메타데이터 캐시와 데이터베이스에도 같은 원칙 적용
메모리 캐시는 보통 최종 일관성 모델을 지원하기에 강한 일관성을 지키려면 다음이 필요
- 캐시의 사본과 DB의 사본이 일치한다.
- DB 원본에 변경이 발생하면 캐시에 있는 사본을 무효화
RDBMS는 ACID를 보장하기에 강한 일관성을 보장하기 쉽다.

업로드 절차

파일 메타데이터 추가

클라이언트가 새 파일 메타데이터 추가 요청 전송
새 파일 메타데이터를 DB에 저장하고 업로드 상태를 대기 중으로 변경
새 파일이 추가되었음을 알림 서비스에 통지
알림 서비스는 관련 클라이언트에게 파일이 업로드되고 있음을 알림

파일을 클라우드 저장소에 업로드

클라이언트 1이 파일을 블록 저장소 서버에 업로드
블록 저장소 서버는 파일을 블록 단위로 분할, 압축, 암호화 후 클라우드 저장소에 전송
업로드 후 클라우드 저장소는 완료 콜백을 호출하고 콜백을 API 서버로 전송
메타데이터 DB에 기록된 해당 파일 상태를 완료로 변경
알림 서비스에 파일 업로드 완료 통지
알림 서비스는 관련 클라이언트에게 파일 업로드 완료를 알림

다운로드 절차

다운로드는 파일이 새로 추가되거나 편집되면 자동으로 시작
- 다른 클라이언트가 변경된 버전을 바로 봐야하므로
다른 클라이언트가 파일을 변경하먼 관련 클라이언트에게 새 버전을 끌어가야 한다고 알림
네트워크 연결 상태가 아닌 경우에 데이터는 캐시에 보관되어 연결되면 새 버전을 가져간다.
1. 알림 서비스가 누군가 파일을 변경했음을 통지
2. 새로운 메타데이터 요청
3. API 서버는 DB에게 새 메타데이터 요청
4. API 서버에게 새 메타데이터가 반환됨
5. 클라이언트에게 새 메타데이터가 반환됨
6. 새 메타데이터를 받는 즉시 블록 다운로드 요청 전송
7. 블록 저장소 서버는 클라우드 저장소에서 블록 다운로드
8. 클라우드 저장소는 블록 서버에 요청된 블록 반환
9. 블록 저장소 서버는 클라이언트에게 요청된 블록 반환.
1. 클라이언트는 전송된 블록으로 파일을 재구성

알림 서비스

파일 일관성을 유지하려면 충돌 가능성을 줄여야 한다.
- 파일이 수정되었음을 감지하는 순간 다른 클라이언트에게 통지해야 함
즉 알림 서비스는 이벤트 데이터를 클라이언트들로 보내는 서비스
두 가지 선택지
- 롱 폴링 - 드롭박스가 채택한 방식
- 웹소켓 - 지속적인 양방향 통신 가능
본 설계에서는 롱 폴링을 채택
- 알림 서비스와 양방향 통신이 필요하지는 않다.
- 구글 드라이브의 경우 알림 전송이 자주 발생하지 않는다.
- 단시간에 많은 데이터를 보낼 일도 없다.
롱 폴링을 사용하면 연결을 주기적으로 유지해야 한다.
- 파일 변경 감지하면 연결을 끊고 최신 파일을 다운로드
- 다운로드 작업이 끝나거나 타임아웃에 도달하면 즉시 새 요청으로 롱 폴링을 유지

저장소 공간 절약

파일 여러 버전을 여러 데이터센터에 보관해야 한다.
- 파일 갱신 이력 보존과 안정성을 보장하기 위해
- 자주 백업하면 용량이 부족할 수 있다.
용량 확보와 비용 절감 방법
- 중복 제거: 중복 파일 블록을 계정 차원에서 제거 (해시 값으로 중복 판별)
- 지능적 백업 전략 도입
  - 한도 설정: 보관하는 파일 버전 개수에 상한을 둠
  - 중요한 버전만 보관
- 아카이빙 저장소 활용
  - 자주 쓰이지 않는 데이터를 보관
  - 아마존 S3 클래시어 같은 아카이빙 서비스는 S3보다 훨씬 저렴

장애 처리

로드밸런서 장애
- 부 로드밸런서가 활성화되어 트래픽을 이어 받아야 한다.
- 로드밸런서끼리 박동 신호로 상태를 모니터링
블록 저장소 서버 장애
- 다른 서버가 미완료 상태 또는 대기 상태 작업을 이어받아야 한다.
클라우드 저장소 장애
- S3 버킷은 여러 지역에 다중화 가능
- 다른 지역에서 파일을 가져올 수 있다.
API 서버 장애
- 로드밸런서가 장애 서버에 트래픽을 보내지 않는다.
메타데이터 캐시 장애
- 캐시 서버도 다중화
- 장애 발생 서버는 새 서버로 교체
메타데이터 데이터베이스 장애
- 주 데이터베이스 서버 장애: 부 서버 중 하나를 주 서버로 변경 후 부 서버 하나 추가
- 부 데이터베이스 서버 장애: 다른 부 서버가 읽기 연산을 제공하고 장애 서버는 새 것으로 교체
알림 서비스 장애
- 접속 중인 모든 사용자는 알림 서버와 롱 폴링 연결을 유지
- 따라서 한 서버가 죽으면 많은 사용자가 롱 폴링 연결을 다시 만들어야 한다.
- 한 서버가 백만 롱 폴링을 유지할 순 있지만 백만 롱 폴링 접속을 ‘시작’하는 것은 불가능
- 롱 폴링 복구는 상대적으로 느릴 수 있다.
오프라인 사용자 백업 큐 장애
- 큐 또한 다중화 필요
- 장애 발생 시 구독 중인 클라이언트는 백업 큐로 구독 관계 재설정