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

 

 

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

• 주요하게 지원해야 할 기능 
• 지원 환경 
• 파일 암호화 여부 
• 파일 크기 제한 
• 사용자 
• 예시 설계 범위 
  • 파일 추가 기능 
    • drag and drop 
  • 파일 다운로드 
  • 여러 단말에 파일 동기화 
  • 파일 갱신 이력 조회 (revision history)
  • 파일 공유 
  • 파일 편집, 삭제, 공유 알림 표시 
• 비 기능적 요구사항
• 안정성 
  • 데이터 손실 방지 
• 빠른 동기화 속도 
• 네트워크 대역폭 
  • 모바일 데이터 플랜을 사용하는 경우 네트워크 사용량이 많으면 사용자의 선호도가 감소됨 
• 규모 확장성 
  • 많은 양의 트래픽 처리가 가능해야 함 
• 높은 가용성 
• 개략적 추정치 
  • 가입 사용자 = 5000만 
  • DAU = 1000만 
  • 인당 무료 저장 공간 할당 = 10GB
  • 사용자가 업로드하는 하루 평균 파일 수 = 2개
  • 업로드 파일의 크기 = 500KB
  • 읽기 : 쓰기의 비율 = 1:1
  • 필요한 저장공간 총량 = 5000만 x 10GB = 500페타바이트 
  • 업로드 API QPS = 1000만 사용자 x 2회 업로드 / 24시간 / 3600초 = 약 240
  • 최대 QPS = 240 x 2 = 480

 

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

• 서버 구성 
  • 파일을 올리고 다운로드 하는 과정을 처리할 웹 서버 
  • 파용자 데이터, 로그인 정보, 파일 정보 등의 메타데이터를 보관할 데이터 베이스 
  • 파일을 저장할 저장소 시스템
    • 파일 저장을 위해 1TB의 공간을 사용할 것 
  • 데이터 베이스의 업로드 파일 저장 폴더(drive)하위에 namespace라 불리는 사용자의 디렉터리 구성 
• 제공해야 할 API
  • 모든 API는 사용자 인증이 필요하고 HTTPS 프로토콜을 사용 
    • SSL(Secure Socket Layer)를 지원하는 프로토콜을 이용하는 이유는 클라이언트와 백엔드 서버가 주고받는 데이터를 보호하기 위함 
  • 파일 업로드 API
    • 단순 업로드 
      • 팡리 크기가 작을 때 사용 
    • 이어올리기 (resumable upload)
      • 파일 사이즈가 크고 네트워크 문제로 업로드가 중단될 가능성이 높다고 생각되면 사용 
      • 인자 
        • uploadType = resumable
        • data : 업로드할 로컬 파일 
      • 절차 
        • 1) 이어 올리기 URL을 받기 위한 최초 요청 전송 
        • 2) 데이터를 업로드하고 업로드 상태 모니터링 
        • 3) 업로드에 장애가 발생하면 장애 발생 시점부터 업로드를 재시작 
  • 파일 다운로드 API
    • 인자 
      • path : 다운로드할 파일의 경로 
  • 파일 갱신 히스토리 제공 API
    • 인자 
      • path : 갱신 히스토리를 가져올 파일의 경로  
      • limit : 히스토리 길이의 최대치 
• 한대 서버의 제약 극복 
  • 데이터 샤딩을 통해 여러 서버에 저장 
  • 저장소로 s3를 사용 
    • 업계 최고 수준의 규모 확장성, 가용성, 보안 성능을 제공하는 객체 저장 서비스 
    • s3는 다중화를 지원 
      • 여러 지역에 걸쳐 다중화 하면 데이터 손실을 막고 가용성을 최대 보장 가능 
  • 로드밸런서 
    • 네트워크 트래픽 분산 
    • 서버 장애시 장애서버를 우회할 수 있음 
  • 웹 서버 
    • 로드밸런서를 추가하고 나면 웹 서버의 추가가 용이하여 트래픽이 폭증해도 쉽게 대응 가능 
  • 메타데이터 데이터베이스 
    • 데이터베이스를 파일 저장 서버에서 분리하여 SPOF 를 회피 
    • 가용성과 규모 확장성 요구사항에 대응 
  • 파일 저장소 
    • s3파일 저장소를 사용하고 가용성과 데이터 무손실을 보장하기 위해 두개 이상의 지역에 데이터 다중화 
• 동기화 충돌 
  • 두명 이상의 사용자가 같은 파일이나 폴더를 동시에 업데이트 시도 
  • 먼저 처리되는 변경은 성공한 것으로 보고 나중에 처리되는 변경은 충돌이 발생한 것으로 표시하여 해결 가능 
    • 오류가 발생한 시점에 이 시스템에는 같은 파일의 두가지 버전이 존재하게 됨 
• 개략적 설계안 
  • 구성
    • 사용자 단말 
    • 블록 저장소 서버 
      • 파일 블록을 클라우드 저장소에 업로드하는 서버 
        • 블록 저장소 
          • 블록 수준 저장소 (block level storage)
          • 클라우드 환경에서 데이터 파일을 저장하는 기술 
          • 파일을 여러개의 블록으로 나눠 저장 
          • 각 블록에는 고유한 해시값이 할당됨 
          • 해시값은 메타데이터 데이터베이스에 저장됨 
          • 각 블록은 독립적인 객체로 취급되며 클라우드 저장소 시스템에 보관됨 
          • 파일을 재구성하려면 블록들을 원래 순서대로 합쳐야 함 
        • 클라우드 저장소 
          • 블록 단위로 나눠져 클라우드 저장소에 보관됨 
        • 아카이빙 저장소 
          • 오랫동안 사용되지 않은 비활성 데이터를 저장하기 위한 컴퓨터 시스템 
        • 로드밸런서 
          • 요청을 모든 API 서버에 고르게 분산하는 구실 
        • API 서버 
          • 파일 업로드 외에 거의 모든 것을 담당 
            • 사용자 인증, 사용자 프로파일 관리, 파일 메타데이터 갱신 등 
        • 메타데이터 데이터베이스 
          • 사용자, 파일, 블록, 버전 등의 메타데이터 정보를 관리 
          • 실제 파일은 클라우드에 보관 
        • 메타데이터 캐시 
          • 성능을 높이기 위해 자주 쓰이는 메타데이터를 캐시 
        • 알림 서비스 
          • 특정 이벤트가 발생했음을 클라이언트에게 알리는 발생 / 구독 프로토콜 기반 시스템 
        • 오프라인 사용자 백업 큐 
          • 클라이언트가 접속중이 아니라서 파일의 최신 상태를 확인할 수 없을 때는 해당 정보를 이 큐에 두어 나중에 클라이언트가 접속했을 때 동기화 될 수 있도록 함 

 

 

3단계 상세 설계 

• 블록 저장소 서버 
  • 델타 동기화 
    • 파일에 수정이 일어나면 파일 대신 수정이 일어난 블록만 동기화 
  • 압축 
    • 블록 단위로 압축해 두면 데이터 크기를 많이 줄일 수 있음 
    • 파일 유형에 따라 압축 알고리즘 설정 
      • ex) 텍스트 파일 : gzip, bzip2
  • 파일 업로드에 관계된 힘든 일을 처리하는 컴포넌트 
  • 클라이언트가 보낸 파일을 블록 단위로 나누고 각 블록에 압축 알고리즘을 적용하고, 암호화까지 해야함 
  • 전체 파일을 저장소 시스템으로 보내는 대신 수정된 블록만 전송해야 함 
  • 이를 통해 네트워크 대역폭 사용량을 절감할 수 있음 
• 높은 일관성 요구사항 
  • 같은 파일이 단말이나 사용자에 따라 다르게 보이는 것은 허용할 수 없음 
  • 메타데이터 캐시와 데이터 베이스 계층에도 같은 원칙이 적용되어야 함 
  • 메모리 캐시는 보통 최종 일관성 모델을 지원 
    • 캐시에 보관된 사본과 데이터베이스에 있는 원본이 일치 
    • 데이터 베이스에 보관된 원본에 변경이 발생하면 캐시에 있는 사본을 무효화 
  • 관계형 데이터 베이스는 ACID(Atomicity, Consistency, Isolation, Durability)를 보장하므로 강한 일관성을 가지기 쉬움 
    • NoSQL 데이터베이스는 기본으로 지원하지 않으므로 동기화 로직 안에 프로그램해 넣어야 함 
• 메타데이터 데이터베이스 
  • 저장 데이터 
    • user
    • device
      • 사용자의 단말 정보 보관 
      • 한사용자가 여러 단말 정보를 가질 수도 있음 
    • namespace
      • 사용자의 루트 디렉터리 정보가 보관 
    • file
      • 파일의 최신 정보가 보관 
    • file_version
      • 파일의 갱신 이력이 보관 
      • 전부 읽기 전용 
      • 갱신 이력이 훼손되는 것을 막기 위한 조치 
    • block
      • 파일 블록에 대한 정보를 보관하는 테이블 
      • 특정 버전의 파일은 파일 블록을 올바른 순서로 조합하기만 하면 복원할 수 있음 
• 업로드 절차 
  • 두개의 요청이 병렬적으로 전송될 수 있음
  • 1. 파일 메타데이터 추가 
    • 1) 클라이언트 1이 새 파일의 메타데이터를 추가하기 위한 요청 전송 
    • 2) 새 파일의 메타데이터를 데이터베이스에 저장 및 업로드 상태를 대기중으로 변경 
    • 3) 새 파일이 추가되었음을 알림 서비스에 통지 
    • 4) 알림 서비스는 관련된 클라이언트(클라이언트 2)에게 파일이 업로드 되고 있음을 알림 
  • 2. 파일을 클라우드 저장소에 업로드 
    • 1) 클라이언트 1이 파일을 블록 저장소 서버에 업로드 
    • 2) 블록 저장소 서버는 파일을 블록 단위로 쪼갠 다음 압추가혹 암호화 한 다음 클라우드 저장소에 전송 
    • 3) 업로드가 끝나면 클라우드 스토리지는 완료 콜백을 호출
      • 콜백 호출은 API서버로 전송됨 
    • 4) 메타데이터 DB에 기록된 해당 파일의 상태를 완료로 변경 
    • 5) 알림 서비스에 파일 업로드가 끝났음을 통지 
    • 6) 알림 서비스는관련된 클라이언트(클라이언트 2) 에게 파일 업로드 완료 알림 
• 다운로드 절차 
  • 다른 클라이언트가 파일을 편집하거나 추가했다는 사실 감지 방법 
    • 다른 클라이언트가 파일을 변경했을때 
      • 1. 클라이언트 A가 접속중이라면 변경이 발생했으니 새 버전을 끌어가야한다고 알림 
        • API서버를 통해서 메타데이터를 새로 가져가고 블록들을 다운받아 파일을 재구성 해야함 
      • 2. 접속중이 아니라면 데이터를 캐시에 보관하고 접속중으로 바뀌면 해당 클라이언트가 새 버전을 가져가게 함 
• 알림 서비스 
  • 클라이언트는 로컬에서 파일이 수정되었음을 감지하는 순간 다른 클라이언트에 그 사실을 알려 충돌 가능성을 줄여야 함 
  • 알림 방안 
    • 1. 롱 폴링 
      • ex) 드롭 박스 
        • 양방향 통신이 필요하지 않은 경우 
          • 파일 변경 사실을 클라이언트에게 알려주지만 다른 방향은 필요하지 않음 
        • 알림을 보낼일이 채팅처럼 많이 발생하지 않는 경우 
        • 단시간에 많은 양의 데이터를 보낼일이 없는 경우 
      • 롱폴링을 유지하다가 특정 팡리에 대한 변경을 감지하면 해당 연결을 끊어 클라이언트가 반드시 메타데이터 서버와 연결해 파일의 최신 내역을 다운로드 하게 함 
        • 다운로드 작업이 끝났거나 연결 타임아웃 시간이 끝난 경우 즉시 새요청을 보내 롱 폴링 연결을 복원하고 유지
    • 2. 웹 소켓
      • 클라이언트와 서버 사이에 지속적인 통신 채널을 제공하여 양방향 통신 가능
        • 채팅 서버에 적합 
• 저장소 공간 절약
  • 모든 버전을 자주 백업하면 저장 용량이 너무 빨리 소진될 수 있음
  • 중복 제거 
    • 중복된 파일 블록을 계정 차원에서 제거하는 방법
    • 두 블록이 같은 블록인지 해시 값을 비교해서 판단 
  • 지능적 백업 전략 도입 
    • 한도 설정 
      • 보관할 수 있는 파일 버전 개수에 상한을 두기 
      • 상한에 도달하면 제일 오래된 버전은 버림
    • 중요한 버전만 보관 
      • 불필요한 버전과 사본이 만들어지는 것을 피하려면 그 가운데 중요한 것만 골라내야 함 
  • 자주 쓰이지 않는 데이터는 아카이빙 저장소로 옮김 
    • 아마존 S3 글래시어같은 아카이빙 저장소 이용료는 S3보다 훨씬 저렴 
• 장애 처리 
  • 로드밸런서 장애 
    • 부 로드밸런서를 활성화 하여 트래픽을 이어받아야 함 
    • 로드밸런서 끼리는 보통 박동 신호를 주기적으로 보내 신호를 모니터링 
  • 블록 저장소 서버 장애 
    • 다른 서버가 미완료 상태 또는 대기 상태인 작업을 이어받아야 함 
  • 클라우드 저장소 장애 
    • S3 버킷을 다중화 하여 한 지역에서 장애가 발생했다면 다른 지역에서 파일을 가져와야 함
  • API 서버 장애 
    • API 서버는 무상태 서버 
    • 로드밸런서는 API 서버에 장애가 발생하면 트래픽을 해당 서버로 보내지 않음으로써 장애 서버를 격리 
  • 메타데이터 캐시 장애 
    • 메타데이터 캐시 서버도 다중화 
    • 장애가 발생한 서버는 새 서버로 교체 
  • 메타데이터 데이터베이스 장애 
    • 주 데이터베이스 장애
      • 부 데이터 베이스 서버중 가운데 하나를 주 데이터베이스 서버로 바꾸고 부 데이터서비스 하나를 새로 추가 
    • 부 데이터베이스 장애 
      • 다른 부 데이터베이스 서버가 읽기 연산을 처리하고 그동안 장애 서버는 새 것으로 교체 
  • 알림 서비스 장애 
    • 접속중인 모든 사용자는 알림 서버와 롱 폴링 연결을 하나씩 유지 
    • 많은 사용자와의 연결을 유지하고 관리해야 함 
    • 서버가 롱폴링 연결을 백만명 이상의 사용자와 연결할 수 있지만 동시에 백만개 접속을 시작하는 것은 불가능하기 때문에 롱 폴링 연결을 복구하는 것은 상대적으로 느릴 수 있음
  • 오프라인 사용자 백업 큐 장애 
    • 큐를 다중화

 

 

4단계 마무리 

• 블록 저장소 서버를 거치지 않고 파일을 클라우드 저장소에 직접 업로드 하는 방식 
  • +) 
    • 업로드 시간이 짧아짐 
  • -) 
    • 분할, 압축, 암호화 로직을 클라이언트에 두어야 하므로 플랫폼 별로 따로 구현해야 함
      • IOS, 안드로이드, 웹 등 
      • 기존 설계안에서는 이 모두를 블록 저장소 서버가 담당 
    • 클라이언트가 해킹 당할 가능성이 있어 암호화 로직을 클라이언트 안에 두는 것은 적절하지 않은 선택 
• 접속 상태를 관리하는 로직을 별도 서비스로 옮길 수도 있음 
  • 관련 로직을 알림 서비스에서 분리하면 다른 서비스에서도 쉽게 활용 가능