15장

1단계 문제 이해 및 설계

• 파일 업로드/다운로드, 파일 동기화, 알림 지원

• 모바일앱과 웹앱 둘다 지원

• 파일 암호화 필요

• 파일 크기 제한 10GB

• DAU 천만명

비-기능정 요구사항

• 안정성

• 빠른 동기화 속도

• 네트워크 대역폭

• 규모 확장성

• 높은 가용ㅇ성

개략적 추정치

• 매일 각 사용자가 평균 2개의 파일을 업로드한다고 가정. 각 파일의 평균 크기는 500KB

• 읽기:쓰기 비율은 1:1

• 필요한 저장공간 총량 = 5천만 * 10GB = 500페타바이트

• 업로드 API QPS = 1천만 사용자 * 2회 업로드 / 24시간 / 3600 = 약 240

• 최대 QPS = QPS *2 = 480

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

• API

  • 파일 업로드 API

    • https://api.example.com/files/upload?uploadType=resumable

    • 단순 업로드 - 파일 크기가 작을 때 사용

    • 이어 올리기 - 파일 사이즈가 크고 네트워크 문제로 중단될 가능성이 높을 때 사용

      • 이어 올리기 URL을 받기 위한 최초 요청 전송

      • 데이터를 업로드하고 업로드 상태 모니터링

      • 업로드에 장애가 발생하면 장애 발생시점부터 업로드를 재시작

  • 파일 다운로드

    • https://api.example.com/files/download

  • 파일 갱신 히스토리 api

    • https://api.example.com/files/list_revisions

Untitled

• 사용자 단말

• 블록 저장소 서버: 파일 블록을 저장소에 업로드하는 서버

  • 파일을 여러 블록으로 나눠 저장하며 각 블록에는 고유한 해시값이 할당됨

  • 드롭박스의 경우 한 블록당 4MB라고 함

• 로드 밸런서: 요청을 모든 API 서버에 고르게 분산하는 구실을 한다.

• API 서버: 파일 업로드 외에 거의 모든 것을 담당 - 사용자 인증, 사용자 프로파일 관리, 파일 메타데이터 갱신 등

• 메타데이터 데이터베이스: 사용자, 파일, 블록, 버전 등 메타데이터 정보를 관리한다.

• 메타데이터 캐시: 자주 쓰이는 메타 데이터를 캐시

• 알림 서비스

• 오프라인 사용자 백업 큐: 파일의 최신 상태를 확인할 수 없을 때 해당 정보를 큐에 두어서, 클라이언트가 접속했을 때 동기화될 수 있도록 한다.

3단계 상세 설계

• 블록 저장소 서버 최적화 방법

  • 델타 동기화: 파일이 수정되면 수정된 블록만 동기화한다.

  • 압축: 블록 단위로 압축해둔다. 파일 유형에 따라 다른 압축을 한다.

• 높은 일관성 요구사항

  • 강한 일관성 모델을 기본으로 지원해야함

  • 캐시는 보통 최종 일관성 모델을 지원함. 강한 일관성을 지원하려면 다음을 보장해야함

    • 캐시에 보관된 사본과 데이터베이스에 있는 원본이 일치한다.

    • 데이터베이스에 보관된 원본에 변경이 발생하면 캐시에 있는 사본을 무효화한다.

• 업로드 절차

  • 메타데이터 추가

    1. 클라이언트 1이 새 파일의 메타데이터를 추가하기 위한 요청 전송

    2. 새 파일의 메타데이터를 데이터베이스에 저장하고 업로드 상태를 대기중으로 변경

    3. 새 파일이 추가되었음을 알림 서비스에 통지

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

    1. 클라우드 1이 파일을 블록 저장소 서버에 업로드

    2. 블록 저장소 서버는 파일을 블록 단위로 쪼갠 다음 압축하고 암호화 한 다음에 클라우드 저장소에 전송

    3. 업로드가 끝나면 클라우드 스토리지에 완료 콜백 호출

    4. 메타데이터 DB에 해당 파일의 상태를 완료로 변경

    5. 알림 서비스에 파일 업로드가 끝났음을 통지

• 다운로드 절차

  1. 알림 서비스가 클라이언트 2에게 누군가 파일을 변경했음을 알림

  2. 알림을 확인한 클라이언트 2는 새로운 메타데이터를 요청

  3. API 서버는 메타데이터 데이터베이스에게 새 메타데이터 요청

  4. API 서버에게 새 메타데이터가 반환됨

  5. 클라이언트 2에게 새 메타데이터가 반환됨

  6. 클라이언트 2는 새 메타데이터를 받는 즉시 블록 다운로드 요청 전송

  7. 블록 저장소 서버는 클라우드 저장소에서 블록 다운로드

  8. 클라우드 저장소는 블록서버에 요청된 블록 반환

  9. 블록 저장소 서버는 클라이언트에게 요청된 블록 반환

• 알림 서비스

  • 롱풀링, 웹소캣이 가능하나 롱 풀링을 사용함

    • 양방향 통신이 필요하지 않음

    • 알림을 보내야 하는 일이 자주 발생하지 않고 많은 양의 데이터를 보낼 일도 없다

    • 롱풀링을 맺어놨다가 변경이 생기면 연결을 끊고, 다운로드 시작. 다운로드가 끝나면 다시 롱풀링 복원

• 저장소 공간 절약

  • 중복 제거: 중복된 파일 블록을 계정 차원에서 제거하는 방법 - 해시 값을 비교하여 판단 가능

  • 지능적 백업 전략

    • 한도 설정

    • 중요한 버전만 보관

  • 자주 쓰이지 않는 데이터는 아카이빙 저장소로 옮긴다 (aws glacier)

• 장애 처리

  • 로드밸런서 장애 - 부 로드밸런서를 활성화하여 받아야 한다.

  • 블록 저장소 서버 - 다른 서버가 미완료 상태 혹은 대기 상태인 작업을 이어받는다

  • 클라우드 저장소 장애 - 여러 지역에 다중화해놓고, 장애가 생기면 다른 지역에서 가져온다

  • API 서버 장애: API 서버에 장애가 발생하면 트래픽을 해당 서버로 보내지 않는 것으로 장애 서버를 격리한다.

  • 메타데이터 캐시 장애: 메타데이터 캐시 서버를 다중화한다.

  • 메타데이터 데이터베이스 장애

    • 주 데이터베이스 서버 장애 - 부 서버를 주로 바꾸고 부 서버를 하나 추가한다.

    • 부 서버 장애 - 장애 서버를 새 것으로 교체한다.

  • 알림 서비스 장애

    • 복구하는 게 느릴 수 있음

  • 오프라인 사용자 백업 큐 장애: 큐도 다중화해놓고, 장애가 발생하면 백업 큐로 구독 관계를 재설정한다.

4 단계 마무리

• 블록 저장소 서버를 거치지 않고 바로 클라우드 저장소에 업로드한다면?

  • 분할, 압축, 암호화 로직을 클라이언트에 두어야 하므로 플랫폼별로 따로 구현해야 한다.

  • 클라이언트가 해킹당할 수 있는데 암호화 로직을 클라이언트에 두는건 좋지 않다

• 접속 상태를 관리하는 로직을 별도 서비스로 옮길 수 있다. 그러면 다른 서비스에서도 쉽게 활용할 수 있을 것이다.