[가상 면접 사례로 배우는 대규모 시스템 설계 기초] 15장 구글 드라이브 설계

 

구글 드라이브 : 파일 저장, 동기화 서비스

🔗 https://drive.google.com/drive/home

• 문서, 사진, 비디오, 기타 파일을 클라우드에 보관할 수 있다.
• 파일은 컴퓨터, 스마트폰, 태블릿 등 어떤 단말에서도 이용 가능해야 한다.
• 보관된 파일은 친구, 가족, 동료들과 손쉽게 공유할 수 있어야 한다.

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

📝요구사항

• 가장 중요한 기능 : 파일 업로드/다운로드, 파일 동기화, 알림
• 앱, 웹 모두 지원
• 파일 암호화해야 함
• 파일 크기 : 10GB 이하
• 일간 능동 사용자(DAU) : 1000만 명(10M)

집중할 기능

• 파일 추가
• 파일 다운로드
• 여러 단말에 파일 동기화
• 파일 갱신 이력 조회(revision history) : 누가, 무엇을 갱신했는지 조회가 가능해야 함
• 파일 공유
• 파일이 편집,삭제되거나 새롭게 공유되었을 떄 알림 표시

집중하지 않을 기능

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

📝비기능적 요구사항

• 안정성 : 데이터 손실이 발생하면 안 됨
• 빠른 동기화 속도(사용자 이탈이 일어날 수 있음)
• 네트워크 대역폭(특히, 모바일 데이터를 쓰고 있다면 사용자 이탈이 일어날 수 있음)
• 규모 확장성 : 아주 많은 양의 트래픽도 처리 가능해야 함
• 높은 가용성 : 일부 서버에 장애가 발생하거나, 네트워크 일부가 끊기는 등의 문제가 있어도 시스템은 계속 사용 가능해야 함

개략적 추정치

1. 가입 사용자 : 5000만 명
2. DAU : 1000만 명
3. 모든 사용자에게 10GB의 무료 저장공간 할당
4. 매일 각 사용자가 평균 2개의 파일을 업로드한다고 가정할 때, 각 파일의 평균 크기는 500KB
5. 읽기 : 쓰기 = 1:1

💥필요한 저장공간 총량 = 5000만 사용자 X 10GB = 500페타바이트(PB) 💥업로드 API QPS = 1000만 사용자 2회 업로드/24시간/3600초 = 약 240 💥최대 QPS = QPS * 2 = 480 (통상적으로 Peek QPS는 QPS에 2를 곱한다.)

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

우선, 서버 한 대로 시작한 뒤 점진적으로 천만 사용자 지원이 가능한 시스템으로 발전시켜 나가는 것을 가정

• 파일을 업로드. 다운로드를 처리할 웹 서버
• 사용자, 로그인, 파일 정보 등의 메타데이터를 보관할 DB
• 파일을 저장할 저장소 시스템(1TB)

파일 업로드 API

1. 단순 업로드 : 파일 크기가 작을 때 사용
2. 이어 올리기(resumable upload) : 파일 크기가 크고, 네트워크 문제로 업로드가 중단될 가능성이 높다고 생각될 때 사용
   • 이어 올리기 절차
     1. 이어 올리기 URL을 받기 위한 최초 요청 전송
     2. 데이터를 업로드하고 업로드 상태 모니터링
     3. 업로드에 장애가 발생하면 장애 발생시점부터 업로드를 재시작
   • API Example
     • https://api.example.com/files/upload?uploadType=resumable
     • 인자
       • uploadType = resumable
       • data : 업로드할 로컬 파일

파일 다운로드 API

API example

• https://api.example.com/files/download
• 인자
  • path : 다운로드할 파일 경로

파일 갱신 히스토리 API

API example

• https://api.example.com/files/list_revisions
• 인자
  • path : 갱신 히스토리를 가져올 파일의 경로
  • limit : 히스토리 길이의 최대치

🚫한 대 서버의 제약 극복🚫

위의 파일 시스템은 1TB밖에 용량이 없으므로 서버를 확장해야 한다.

해결책

1️⃣ 데이터를 샤딩(sharding)해 여러 서버에 나누어 저장하자!

 

2️⃣ S3 사용

• S3(Simple Storage Service) : 업계 최고 수준의 규모 확장성, 가용성, 보안, 성능을 제공하는 객체 저장소 서비스
• 다중화 지원 (한 리전, 다른 리전 모두 가능)
• 여러 리전에 걸쳐 다중화하면 데이터 손실을 막고 가용성을 최대한 보장할 수 있음

 

3️⃣ 기타 요소

• 로드밸런서 : 네트워크 트래픽 분산, 특정 웹 서버에 장애 발생 시 우회
• 웹 서버 : 웹 서버를 추가하면 트래픽이 폭증해도 쉽게 대응 가능
• 메타데이터 DB : 파일 저장 서버에서 데이터베이스를 분리해 SPOF(Single Point Of Failure) 회피

🔆수정된 설계안

동기화 충돌

두 명 이상의 사용자가 같은 파일이나 폴더를 동시에 업데이트하려고 할 때 동기화 충돌이 발생할 수 있음

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

이때, 시스템에 사용자2가 가지고 있는 로컬 사본과 서버에 있는 최신 버전, 이렇게 한 개의 파일에 두 개의 버전이 존재하게 됨

➡️ 두 파일을 하나로 합칠지, 둘 중 하나를 다른 파일로 대체할지 결정해야 함

개략적 설계안

• ✨블록 저장소 서버(block server)
  • 파일 블록을 클라우드 저장소(S3)에 업로드하는 서버
  • 파일을 여러 개의 블록으로 나누어 저장하고, 각 블록에는 고유한 해시값이 할당됨
    • 이 해시값은 메타데이터 DB에 저장됨
    • 각 블록은 독립적인 객체로 취급되고, 클라우드 저장소에 저장됨
  • 파일을 재구성하려면 블록들을 원래 순서대로 합쳐야 함
• ✨클라우드 저장소
  • 파일은 블록 단위로 나누어져(한 블록에 4MB)클라우드 저장소에 보관됨
• ✨아카이빙 저장소(cold storage)
  • 오랫동안 사용되지 않은 비활성 데이터 저장
• ✨로드밸런서
  • 요청을 모든 API 서버에 고르게 분산
• ✨API 서버
  • 파일 업로드 외의 거의 모든 것 담당(사용자 인증, 파일 메타데이터 갱신 등)
• ✨메타데이터 데이터베이스
  • 사용자, 버전 등의 메타데이터 정보 관리
  • ⚠️ 실제 파일은 클라우드에 보관하고, 이 DB에는 블록의 해시값이 저장됨
• ✨메타데이터 캐시
  • 자주 쓰이는 메타데이터 캐시
• ✨알림 서비스
  • 특정 이벤트가 발생했음을 Client에게 알리는 발생/구독 프로토콜 기반 시스템
• ✨오프라인 사용자 백업 큐
  • 사용자가 접속 중이 아니어서 최신 상태를 확인할 수 없을 때 정보를 큐에 두고, 나중에 접속하면 동기화