[스터디9] 15장. 구글 드라이브 설계

목차

15장. 구글 드라이브 설계

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

구글 드라이브는 파일 저장 및 동기화 서비스로, 사용자가 파일을 클라우드에 저장하고 여러 디바이스에서 동기화할 수 있게 해준다.

 

주요 기능

• 파일 추가: 파일을 업로드하거나 drag-and-drop으로 추가
• 파일 다운로드
• 파일 동기화: 한 디바이스에서 파일을 수정하면 다른 디바이스에도 자동으로 반영
• 파일 이력 조회(revision history)
• 파일 공유
• 알림: 파일이 편집, 삭제, 새롭게 공유되면 알림 전송

요구사항

• 모바일 앱과 웹 앱 모두 지원
• 파일은 암호화되어 저장
• 파일 크기는 10GB 이하로 제한
• 1천만 명의 DAU(일간 능동 사용자) 지원

제한사항

• 구글 문서 편집 및 협업 기능

2단계 개략적 설계안 제시

서버

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

API

• 파일 업로드 API: 단순 업로드, 이어 올리기(resumable upload)
• 다운로드 API
• 파일 갱신 히스토리 제공 API

한 대 서버의 제약 극복

• 데이터 샤딩(sharding)하여 여러 서버에 나누어 저장
• 저장소로 아마존 S3를 사용

동기화 충돌

• 먼저 처리되는 변경은 성공한 것으로 보고, 나중에 처리되는 변경은 충돌이 발생한 것으로 표시

개략적 설계안

• 사용자 단말: 웹브라우저나 모바일 앱 등의 클라이언트
• 블록 저장소 서버(block server): 파일 블록을 클라우드 저장소에 업로드하는 서버
• 클라우드 저장소: 파일은 블록 단위로 나눠져 클라우드 저장소에 보관
• 아카이빙 저장소(cold storage): 비활성 데이터를 저장하기 위한 컴퓨터 시스템
• 로드밸런서: 요청을 모든 API 서버에 고르게 분산
• API 서버: 파일 업로드 외에 거의 모든 것을 담당하는 서버
• 메타데이터 데이터베이스: 사용자, 파일, 블록, 버전 등의 메타데이터 정보를 관리
• 메타데이터 캐시: 성능을 높이기 위해 자주 쓰이는 메타데이터는 캐시
• 알림 서비스: 특정 이벤트가 발생했음을 클라이언트에게 알리는데 쓰이는 발생/구독 프로토콜 기반 시스템
• 오프라인 사용자 백업 큐(offline backup queue): 클라이언트가 접속 중이 아니어서 파일의 최신 상태를 확인할 수 없을 때, 해당 정보를 이 큐에 두어 나중에 클라이언트가 접속했을 때 동기화 가능

3단계 상세 설계

블록 저장소 서버

파일을 블록 단위로 나누어 저장하는 방식으로, 대용량 파일의 업로드 최적화를 가능하게 한다.

• 델타 동기화(delta sync): 파일의 변경된 부분만 동기화하여 네트워크 트래픽을 절약한다. 파일을 작은 블록으로 분할하고, 수정된 블록만 업로드한다.
• 압축(compression): 블록 단위로 압축하여 저장 공간과 네트워크 대역폭을 절약한다.

높은 일관성 요구사항

여러 클라이언트가 동시에 같은 파일을 수정할 때 발생할 수 있는 충돌을 해결해야 한다.

• 강한 일관성(strong consistency): 메타데이터 캐시와 데이터베이스 계층은 강한 일관성을 보장해야 한다.
• 메모리 캐시는 보통 최종 일관성(eventyal consistency)을 지원한다.
  • 캐시에 보관된 사본과 데이터베이스에 있는 원본(master)이 일치한다.
  • 데이터베이스에 보관된 원본에 변경이 발생하면 캐시에 있는 사본을 무효화한다.

메타데이터 데이터베이스

메타데이터 데이터베이스는 파일 시스템의 메타데이터를 관리한다.

• user 테이블: 사용자 정보 (이름, 이메일, 프로필 사진 등)
• device 테이블: 디바이스 정보
• namespace 테이블: 사용자의 루트 디렉터리 정보
• file 테이블: 파일의 최신 정보
• file_version 테이블: 파일의 갱신 이력
• block 테이블: 파일 블록에 대한 정보

업로드 절차

파일 업로드는 두 가지 요청으로 나뉜다.

1. 파일 메타데이터 추가
   • 클라이언트가 새 파일의 메타데이터를 추가하는 요청을 보낸다.
   • 메타데이터 데이터베이스에 새 파일 정보를 저장하고 업로드 상태를 '대기(pending)'로 설정한다.
   • 클라이언트에게 알림을 보내 다른 클라이언트에 파일이 추가되고 있음을 알린다.
2. 파일을 클라우드 저장소에 업로드
   • 클라이언트가 파일을 블록으로 분할하여 블록 서버에 업로드한다.
   • 블록 서버는 블록을 클라우드 저장소에 저장한다.
   • 업로드가 완료되면 클라우드 저장소는 '완료 콜백(callback)'을 호출하여 API 서버에 알린다.
   • 메타데이터 데이터베이스의 파일 상태를 '완료(uploaded)'으로 변경한다.
   • 클라이언트에게 알림을 보내 파일이 완전히 업로드되었음을 알린다.

다운로드 절차

파일 다운로드는 다음과 같이 진행된다.

1. 알림 서비스가 클라이언트 A에게 파일이 변경했음을 알린다.
2. 클라이언트 A가 새로운 메타데이터를 요청한다.
3. API 서버가 메타데이터 데이터베이스에서 메타데이터를 가져온다.
4. 클라이언트 A가 새 블록을 다운로드하기 위해 블록 서버에 요청을 보낸다.
5. 블록 서버가 클라우드 저장소에서 블록을 다운로드한다.
6. 클라우드 저장소가 블록 데이터를 블록 서버에 반환한다.
7. 블록 서버가 블록을 클라이언트에게 반환한다.

알림 서비스

파일 변경사항을 클라이언트에게 실시간으로 알리기 위해 알림 서비스를 사용한다. 양방향 통신이 필요하지 않으므로 롱 폴링을 사용한다.

• 롱 폴링(long polling): 클라이언트가 서버에 연결을 유지하고 이벤트가 발생하면 응답을 받는 방식
• 웹소켓(WebSocket): 클라이언트와 서버 사이에 지속적인 통신 채널을 제공하고 양방향 통신이 가능

저장소 공간 절약

저장소 비용을 절감하기 위한 전략들이다.

• 중복 제거 (de-dupe): 동일한 블록이 여러 번 저장되지 않도록 한다. 해시 값으로 블록을 비교하여 중복을 제거한다.
• 지능적 백업 전략:
  • 한도 설정: 파일 버전을 일정 개수만 유지
  • 중요 버전만 보관: 자주 접근하지 않는 이전 버전은 콜드 스토리지로 이동
• 자주 쓰이지 않는 데이터는 아카이빙 저장소(cold storage)로: 아마존 S3 글래시어 같은 아카이빙 저장소를 활용하여 오래된 데이터를 저렴하게 보관

장애 처리

시스템의 안정성과 가용성을 보장하기 위한 장애 처리 방법이다.

• 로드밸런서 장애: 부 로드밸런서(secondary load balancer)가 활성화되어 트래픽을 인계받는다.
• 블록 저장소 장애: 다른 서버가 미완료 작업 또는 대기 중인 작업을 이어받는다.
• 클라우드 저장소 장애: S3 버킷은 여러 지역(region)에 다중화(replicate)되어 있다.
• API 서버 장애: API 서버는 무상태 서버이므로 로드밸런서가 장애가 발생한 서버로 트래픽을 보내지 않도록 한다.
• 메타데이터 캐시 장애: 메타데이터 캐시 서버도 다중화되어 있다. 한 노드에 장애가 발생하면 다른 노드에서 데이터를 가져온다.
• 메타데이터 데이터베이스 장애
  • 주 데이터베이스 서버 장애: 부 데이터베이스 서버 중 하나가 주 데이터베이스 서버로 승격된다.
  • 부 데이터베이스 서버 장애: 다른 부 데이터베이스가 읽기 연산을 처리하고, 새로운 부 데이터베이스 서버가 추가된다.
• 알림 서비스 장애: 온라인 상태의 모든 사용자는 알림 서버와 롱 폴링 연결을 맺고 있다. 한 서버에 장애가 발생하면 연결되어 있던 모든 클라이언트가 다른 서버와 재연결한다.
• 오프라인 백업 큐 장애: 큐는 다중화되어 있어 한 큐에 장애가 발생하면 구독 클라이언트가 백업 큐로 재연결된다.

 

이 글은 『 가상 면접 사례로 배우는 대규모 시스템 설계 기초』 책을 학습한 내용을 정리한 것입니다.