가상 면접 사례로 배우는 대규모 시스템 설계 기초 - 14장 ) 유튜브 설계

 

 

유튜브 설계

• 규모 
  • 월간 능동 사용자 수 : 20억 
  • 매일 재생되는 비디오 수 : 50억 
  • 미국 성인 가운데 73%가 이용 
  • 5천만 명의 창작자 
  • 광고 수입 2019 기준으로 150억 달러 (전년도보다 36%가 증가한 수치) 
  • 모바일 인터넷 트래픽 가운데 37%를 유튜브가 점유 
  • 80개 언어로 이용 가능 

 

 

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

• 가장 중요한 기능 
• 지원 클라이언트 
• 일간 능동 사용자 수 
• 사용자가 평균적으로 소비하는 시간 
• 다국어 지원 필요 여부 
• 지원하는 비디오 해상도 
• 암호화 여부 
• 비디오 파일 크기 제한 
• 클라우드 서비스 활용 가능 여부 
• 예시 요구 사항 
  • 빠른 비디오 업로드 
  • 원활한 비디오 재생 
  • 재생 품질 선택 기능 
  • 낮은 인프라 비용 
  • 높은 가용성과 규모 확장성, 안정성
  • 모바일 앱, 웹, 웹브라우저, 스마트 TV 지원 
• 개략적 규모 추정 
  • DAU = 500만 
  • 사용자가 하루 시청하는 비디오 수 = 5개 
  • 비디오 업로드 수 = 10% 사용자가 하루 1개 업로드 
  • 비디오 평균 크기 = 300MB
  • 일간 비디오 저장 용량 = 500만 x 10% x 300MB = 150TB
  • CDN 비용 
    • CDN에서 나가는 데이터의 양에 따라 과금 
      • 아마존 클라우드 프론트의 경우 100% 트래픽이 미국에서 발생시 1GB 당 $0.02의 요금 발생 
    • 매일 발생하는 요금 = 500만 x 5개 비디오 x 0.3GB x $0.02 = $150,000 => 비싸다...! 

 

 

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

• 시스템 설계 면접은 모든 것을 밑바닥부터 만드는 것과 관계 없음 
  • BLOB 저장소를 쓸 것이라면 그 사실만 언급해도 충분 
• 규모 확장이 쉬운 BLOB 저장소나 CDN을 만드는 것은 지극히 복잡하고 많은 비용이 듬 
  • 상용화 된 클라우드 서비스를 만드는 것을 고려하자 
• 컴포넌트 
  • 단말 (client) 
    • 컴퓨터, 모바일 폰, 스마트 TV
  • CDN
    • 비디오를 저장 
    • 스트리밍이 이루어지는 저장공간
  • API 서버 
    • 비디오 스트리밍을 제외한 모든 요청 처리 
    • ex) 피드 추천, 비디오 업로드 URL 생성, 메타데이터 데이터베이스와 캐시 갱신, 사용자 가입 등 
• 설계 영역 
  • 비디오 업로드 
    • 컴포넌트 
      • 사용자 (이용자)
      • 로드밸런서 
        • API 서버로 각각 고르게 요청 분산 
      • API 서버 
        • 비디오 스트리밍을 제외한 다른 모든 요청을 처리 
      • 메타데이터 데이터베이스 (metadata db) 
        • 비디오의 메타데이터를 보관 
        • 샤딩과 다중화를 적용하여 성능 및 가용성 요구사항을 충족 
      • 메타데이터 캐시 (metadata cache)
        • 성능을 높이기 위해 비디오 메타데이터와 사용자 객체를 캐시 
      • 원본 저장소 (original storage)
        • 원본 비디오를 보관할 대형 이진 파일 저장소 (BLOB, Binary Large Object storage)
      • 트랜스코딩 서버 (transcoding server)
        • 비디오 인코딩 
        • 비디오의 포맷 등을 변환하는 절차 
        • 단말이나 대역폭 요구사항에 맞는 최적의 비디오 스트림을 제공 
      • 트랜스코딩 비디오 저장소 (transcoded storage)
        • 트랜스 코딩이 완료된 비디오를 저장하는 BLOB 저장소 
      • CDN
        • 비디오를 캐시 
        • 비디오 스트리밍 영역 
      • 트랜스코딩 완료 큐 (completion queue) 
        • 비디오 트랜스 코딩 완료 이벤트를 보관할 메시지 큐 
      • 트랜스코딩 완료 핸들러 (completion handler)
        • 완료 큐에서 이벤트 데이터를 꺼내어 메타데이터 캐시와 데이터베이스를 갱신할 작업 서버들 
    • 프로세스 
      • 1) 비디오 업로드 
        • 1) 비디오를 원본 저장소에 업로드 
        • 2) 트랜스 코딩 서버가 원본 저장소에서 해당 비디오를 가져와 트랜스 코딩을 시작 
        • 3) 트랜스 코딩이 완료되면 다음의 두작업을 병렬 진행 
          • 완료된 비디오를 트랜스 코딩 비디오 저장소에 업로드
          • 트랜스코딩 완료 이벤트를 트랜스 코딩 완료 큐에 넣음 
            • 완료 핸들러가 메타 데이터 데이터베이스와 캐시를 갱신 
        • 4) API서버가 단말에게 비디오 업로드가 끝나서 스트리밍 준비가 되었음을 알림 
      • 2) 메타데이터 갱신 
        • 원본 저장소에 파일이 업로드 되는 동안 단말은 병렬적으로 비디오 메타데이터 갱신 요청을 API 서버에 보냄 
          • 메타데이터에는 파일 이름, 크기, 포맷 등의 정보 포함 
          • 메타데이터 캐시와 데이터 베이스를 업데이트 
  • 비디오 스트리밍 
    • 스트리밍 프로토콜 
      • 비디오 스트리밍을 위해 데이터를 전송할 때 쓰이는 표준화된 통신방법 
        • 예시 
          • MPEG-DASH (Moving Picture Experts Group, Dynamic Adaptive Streaming over HTTP)
          • 애플 HLS (HTTP Live Streaming) 
          • 마이크로소프트 스무드 스트리밍 (Microsoft Smooth Streaming)
          • 어도비 HTTP 동적 스트리밍 (Adobe HTTP Dynamic Streaming, HDS) 
        • 프로토콜 마다 지원하는 비디오 인코딩이 다르고 플레이어도 다름 
      • 비디오는 CDN에서 바로 스트리밍 됨 
        • 사용자의 단말에서 가장 가까운 CDN 에지 서버가 비디오 전송을 담당 
        • 전송지연이 매우 낮음 

 

3단계 상세 설계 

• 비디오 트랜스코딩 
  • 비디오를 저장하면 해당 비디오를 특정 포맷으로 저장 
    • 다른 단말과 호환되는 비트레이트(bitrate)와 포맷으로 저장되어야 함 
    • 비트레이트 
      • 비디오를 구성하는 비트가 얼마나 빨리 처리되어야 하는지를 나타내는 단위 
      • 높으면 고화질 비디오 
      • 비트레이트가 높은 비디오 스트림을 정상 재생하려면 보다 높은 성능의 컴퓨팅 파워와 빠른 인터넷 회신이 필요 
  • 중요성 
    • 가공되지 않은 원본 비디오는 저장공간을 많이 차지함 
    • 상당수의 단말과 브라우저는 특정 종류의 비디오 포맷만 지원 
      • 하나의 비디오를 여러 포맷으로 인코딩 해두는 것이 바람직 
    • 끊김없는 고화질 비디오 재생을 위해 네트워크 대역폭이 충분하지 안흥ㄴ 사용자에게는 저화질 비디오를, 대역폭이 충분한 사용자에게는 고화질 비디오를 보내야 함 
    • 모바일 단말의 경우 네트워크 상황이 수시로 달라질 수 있음에 유의 
      • 비디오가 끊김 없기 위해서는 비디오 화질을 자동으로 변경하거나 수동으로 변경할 수 있어야 함 
  • 인코딩 포맷 
    • 컨테이너 (container)
      • 비디오, 파일, 오디오, 메타데이터를 담는 바구니 
      • 파일 확장자를 보면 알 수 있음 
        • ex) .avi, .mov, .mp4 등 
    • 코덱 (codec)
      • 비디오 화질을 보존하면서 파일 크기를 줄일 목적으로 고안된 압축 및 압축 해제 알고리즘 
      • H.264, VP9, HEVC 가 가장 많이 사용되는 비디오 코덱 
• 유향 비순환 그래프 (DAG) 모델 
  • 각기 다른 유형의 비디오 프로세싱 파이프라인을 지원하는 한편 처리 과정의 병렬성을 높이기 위해 적절한 수준의 추상화를 도입해 클라이언트 프로그래머로 하여금 실행할 작업을 손수 정의할 수 있도록 해야함 
    • ex) 페이스북의 스트리밍 비디오 엔진 
      • 유향 비순환 그래프 (Directed Acyclic Graph) 프로그래밍 모델 도입 
      • 작업을 단계별로 배열하여 해당 작업들이 순차적으로 또는 병렬적으로 실행될 수 있도록 함 
  • 병행 처리 대상 
    • 비디오 
      • 작업
        • 검사
          • 비디오 품질, 손상여부 검사
        • 인코딩 
          • 비디오를 다양한 해상도, 코덱, 비트레이트 조합으로 인코딩
        • 섬네일 추출 
          • 사용자가 업로드한 이미지나 비디오에서 자동 추출된 이미지로 섬네일을 생성 
        • 워터마크 
          • 비디오에 대한 식별 정보를 이미지 위에 오버레이 형태로 띄워 표시 
    • 오디오 
    • 메타데이터 
• 비디오 트랜스코딩 아키텍처 
  • 전처리기 
    • 비디오 분할 (video splitting) 
      • 비디오 스트림을 GOP(Group of Pictures)라고 불리는 단위로 쪼갬 
        • GOP 
          • 특정 순서로 배열된 프레임 그룹 
          • 하나의 GOP는 독립적 재생이 가능 
          • 보통 몇초 정도의 단위 
      • 어떤 종류의 오래된 단말이나 브라우저는 GOP 단위의 비디오 분할을 지원하지 않음 
        • 전처리기가 비디오 분할을 대신 
    • DAG 생성 
      • 클라이언트 프로그래머가 작성한 설정 파일에 따라 DAG를 만듬 
        • ex) 다운로드 -> 트랜스코딩 
    • 데이터 캐시 
      • 전처리기는 분할된 비디오의 캐시 
      • 전처리기는 GOP와 메타데이터를 임시 저장소에 보관 
      • 비디오 인코딩이 실패하면 시스템은 보관된 데이터를 활용해 인코딩을 재개 
  • DAG 스케줄러 
    • DAG 그래프를 몇 단계로 분할한 뒤 각각을 자원 관리자의 작업 큐에 집어넣음 
  • 자원관리자 
    • 자원 배분을 효과적으로 수행하는 역할을 담당 
    • 작업 큐와 작업 스케줄러로 구성 
      • 작업 큐 (task queue)
        • 실행할 작업이 보관되어 있는 우선순위 큐 (priority queue)
      • 작업 서버 큐 (worker queue) 
        • 작업 서버의 가용 상태 정보가 보관되어 있는 우선 순위 큐 
      • 작업 스케줄러 
        
        • 최적의 작업 / 서버 조합을 골라 해당 작업 서버가 작업을 수행하도록 지시하는 역할 담당 
    • 실행 방식 
      • 1) 작업 관리자가 작업 큐에서 가장 높은 우선 순위의 작업을 꺼냄 
      • 2) 작업 관리자는 해당 작업을 실행하기 적합한 작업 서버를 선정 
      • 3) 작업 스케줄러는 해당 작업 서버에게 작업 실행을 지시 
      • 4) 작업 스케줄러는 해당 작업이 어떤 서버에게 할당되었는지에 관한 정보를 실행 큐에 넣음 
      • 5) 작업 스케줄러는 작업이 완료되면 해당 작업을 실행 큐에서 제거 
  • 작업 실행 서버 
    • DAG에 정의된 작업을 수행 
  • 임시 저장소 
    • 여러 저장소 시스템을 활용 가능 
      • 저장할 데이터의 유형, 크기, 이용 빈도, 데이터 유효기간에 따라 달라짐 
        • ex) 메타데이터는 작업 서버가 빈번히 참조하는 정보이면서 크기가 작아 메모리에 캐시 
        • ex) 비디오 / 오디오 데이터는 BLOB 저자소에 두는 것이 바람직 
  • 인코딩된 비디오 
    • 인코딩 파이프라인의 최종 결과물 
      • ex) funny_720p.mp4
• 시스템 최적화 
  • 속도 최적화 
    • 비디오 병렬 업로드 
      • 하나의 비디오를 작은 GOP로 분할 후 병렬적으로 업로드 
      • 일부가 실패해도 빠르게 업로드 재개 가능 
    • 업로드 센터를 사용자 근거리에 지정 
    • 모든 절차를 병렬화 
      • 느슨하게 결합된 시스템을 만들어 병렬성을 증진 
      • 시스템 결합도를 낮추기 위해서 메시지 큐를 도입 
  • 안정성 최적화
    • 미리 사인된 업로드 URL
      • 허가받은 사용자만이 올바른 장소에 업로드할 수 있도록 하기 위해 미리 사인된 업로드 URL을 사용 
        • 업로드 절차 
          • 1) 클라이언트는 HTTP 서버에 POST 요청하여 미리 사인된 URL 획득 
            • 미리 사인된 URL = Amazon S3
            • 접근 공유 시그니처 = 마이크로소프트 애저의 BLOB 저장소 
          • 2) API 서버는 미리 사인된 URL을 돌려줌 
          • 3) 클라이언트는 해당 URL이 가리키는 위치에 비디오를 업로드 
        • 비디오 보호 
          • 비디오의 저작권을 보호하기 위한 방안 
            • 1) 디지털 저작권 관리 
              • DRM(Digital Rights Management) 
                • ex) 애플의 페어플레이(FairPlay), 구글의 와이드바인(Widevine), 마이크로소프트의 플레이레디(PlayReady)
              • AES 암호화 (encryption)
                • 비디오를 암호화하고 접근 권한을 설정하는 방식 
                • 암호화된 비디오는 재생시에만 복호화 
                • 허락된 사용자만 암호화 된 비디오를 시청 
              • 워터마크 
        • 비용 최적화 
          • 유튜브 비디오 스트리밍은 롱테일(long-tail)분포를 따름 
            • 인기있는 비디오는 빈번히 재생되고, 나머지는 거의 보는 사람이 없음 
          • 인기 비디오는 CDN을 통해 재생하되 다른 비디오는 비디오 서버를 통해 재생하여 비용을 최적화 
          • 인기가 별로 없는 비디오는 인코딩 할 필요가 없을 수도 있으므로 짧은 비디오라면 필요할 때 인코딩하여 재생할 수 있음 
          • 특정 지역에서만 인기있는 비디오는 다른 지역에 옮길 필요 없음 
          • CDN을 직접 구축하고 인터넷 서비스 제공자(ISP: Internet Service Provider)와 제휴할 수도 있음 
            • ISP 예시 
              • 컴캐스트, AT&T, 버라이즌 등 
          • 최적화를 시도하기 전에 시청 패턴을 분석해야 함 
  • 오류 처리 
    • 회복 가능 오류 
      • 재시도를 통해 해결 가능 
    • 회복 불가능 오류 
      • 작업을 중단하고 클라이언트에게 적절한 오류를 반환 
    • 예시
      • 업로드 오류
        • 재시도 
      • 비디오 분할 오류
        • 만약 GOP 경계 분할이 어려운 경우 전체 비디오를 서버로 전송하고 서버가 해당 비디오 분할을 처리하도록 구현 
      • 트랜스코딩 오류 
        • 재시도 
      • 전처리 오류 
        • DAG 그래프를 재생성 
      • DAG 스케쥴러 오류 
        • 작업을 다시 스케줄링 
      • 자원관리자 큐에 장애 발생 
        • 사본을 이용 
      • 작업 서버 장애 
        • 다른 서버에 해당 작업을 재시도 
      • API 서버 장애 
        • 무상태 서버이므로 신규 요청을 다른 API 서버로 우회 
      • 메타데이터 캐시 서버 장애 
        • 데이터는 다중화 되어있으므로 다른 노드에서 데이터를 여전히 가져올 수 있음 
        • 장애가 난 캐시 서버는 새로운 것으로 교체 
      • 메타데이터 데이터베이스 서버 장애 
        • 주 서버가 죽었다면 부 서버 가운데 하나를 주 서버로 교체 
        • 부 서버가 죽었다면 다른 부 서버를 통해 읽기 연산을 처리하고 죽은 서버는 새것으로 교체

 

4단계 마무리 

• API 계층의 규모 확장성 확보 방안 
  
  • 무상태 서버이므로 수평적 규모 확장이 가능 
• 데이터 베이스 계층의 규모 확장성 확보 방안 
  • 데이터베이스의 다중화와 샤딩 방법에 대해 논의 
• 라이브 스트리밍 (live streaming) 
  • 응답지연이 낮아야 함 
    • 스트링 프로토콜 선정에 유의 
  • 병렬화 필요성은 떨어지고 작은 단위의 데이터를 실시간으로 빨리 처리해야 함 
  • 너무 많은 시간이 소요되는 오류 처리 방안은 사용이 여러움 
• 비디오 삭제 
  • 저작권을 위반한 비디오, 선정적 비디오 등의 부적절한 비디오는 내려야 함