유튜브 설계 (가상 면접 사례로 배우는 대규모 시스템 설계)

유튜브 시스템을 설계하는 것은 넷플릭스와 같은 비디오 플랫폼을 설계하는 문제에도 적용 가능하다.

아래는 2020년에 조사된 결과 데이터이다.

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

유튜브는 단순 비디오를 보는 것 말고도 댓글을 남길 수 있고, 비디오를 공유하거나 좋아요 버튼을 누를 수도 있고, 자기 재생목록에 저장하기, 구독 등 다양한 기능이 있다. 때문에 이번 설계에서는 어느정도 설계 범위를 좁혀 진행해보도록 하자.

상황

• 빠른 비디오 업로드
• 원활한 비디오 재생
• 재생 품질 선택 기능
• 낮은 인프라 비용(infrastructure cost)
• 높은 가용성과 규모 확장성, 그리고 안정성
• 지원 클라이언트: 모바일 앱, 웹브라우저, 그리고 스마트 TV
• 일간 능동 사용자(DAU: Daily Active User) 수는 5백만(5million)
• 한 사용자는 하루에 평균 5개의 비디오를 시청
• 10%의 사용자가 하루에 1비디오 업로드
• 비디오 평균 크기는 300MB
• 비디오 저장을 위해 매일 새로 요구되는 저장 용량=5백만 X 10% x 300MB = 150TB
• CDN 비용
  • 클라우드 CDN을 통해 비디오를 서비스할 경우 CDN에서 나가는 데이터 의 양에 따라 과금한다.
  • 아마존의 클라우드프론트(CloudFront)를 CDN 솔루션으로 사용할 경 우, 100% 트래픽이 미국에서 발생한다고 가정하면 1GB당 S0.02의 요금 이 발생한다(그림 14-2). 문제를 단순화하기 위해 비디오 스트리밍 비용 만 따지도록 하겠다.
  • 따라서 매일 발생하는 요금은 5백만×5비디오 x0.3GB X S0.02=$150,000 이다.

개략적 설계

• 비디오 업로드 절차
• 비디오 스트리밍 절차

비디오 업로드 절차

비디오 업로드 절차에는 다음과 같은 컴포넌트들로 구성되어 있다.
사용자 : 컴퓨터나 모바일, 스마트tv를 통해 유튜브를 시청한다
로드밸런서 : API서버 각각으로 요청을 분산한다
API 서버 : 비디오 스트리밍을 제외한 다른 모든 요청을 처리한다.
메타데이터DB : 비디오의 메타데이터를 보관한다. 샤딩과 다중화를 적용하여 성능 및 가용성 요구사항을 충족
메타데이터 캐시 : 성능을 높이기 위해 비디오 메타데이터와 사용자 객체는 캐시한다.
원본 저장소 : 원본 비디오를 보관할 대형 저장소

[원본 저장소]
       ▲
       │
       │
[사용자 단말 (TV / 셋탑 / 모바일 / PC)]
       │
       ▼
  [로드밸런서]
       │
       ▼
   [API 서버]
     ├────────────► [메타데이터 캐시]
     │
     └────────────► [메타데이터 데이터베이스]
                            ▲
                            │
             [트랜스코딩 완료 핸들러]
                            ▲
                            │
               [트랜스코딩 완료 큐] 
                            ▲
                            │
                    [트랜스코딩 서버] ◄────[원본 저장소(위 저장소와 같은 것)]
                            │
                            ▼
                [트랜스코딩 비디오 저장소]
                            │
                            ▼
                            [CDN]

비디오 트랜스코딩은 비디오 인코딩이라 부르기도 하는 절차로, 비디오의 포맷을 변환하는 절차다. 단말이나 대역폭 요구사항에 맞는 최적의 비디오 스트림을 제공하기 위해 필요하다.

비디오 스트리밍 절차

비디오 스트리밍이 이루어지는 절차를 논하기전에 스트리밍 프로토콜에 대해 알아보자.

스트리밍 프로토콜은 비디오 스트리밍을 위해 데이터를 전송할 때 쓰이는 표준화된 통신방법이다.

• MPEG-DASH. MPEG은 “Moving Picture Experts Group"의 약어이며, DASH는 "Dynamic Adaptive Streaming over HTTP"의 약어다.
• 애플(Apple) HLS. HIS는 “HTTP Live Streaming”의 약어다.
• 마이크로소프트 스무드 스트리밍(Microsoft Smooth Streaming).
• 어도비 HTTP 동적 스트리밍(Adobe HTTP Dynamic Streaming, HDs).

기억해야할것은 프로토콜마다 지원하는 비디오 인코딩이 다르고 플레이어도 다르다는것이다.

[사용자 단말 (TV / 셋탑 / 모바일 / PC)]
       │
       ▼
  [CDN]

상세설계

비디오가 다른 단말에서도 순조롭게 재생되려면 다른 단말과 호환되는 비트레이트와 포맷으로 저장되어야 한다. 비트레이트는 비디오를 구성하는 비트가 얼마나 빨리 처리되어야하는지를 나타내는 단위이다. 비트레이트가 높은 비디오는 일반적으로 고화질 비디오다.

비디오 트랜스코딩은 다음과 같은 이유로 중요하다.

• 가공되지 않은 원본 비디오는 저장공간을 많이 차지한다.
• 상당수의 단말과 브라우저는 특정 종류의 비디오 포맷만 지원한다. 따라서 호환성을 위해 미리 여러 포맷으로 인코딩해 두는것이 바람직하다.
• 사용자에게 끊김 없는 고화질 비디오 재생을 보장하려면, 네트워크 대역폭이 충분하지 않은 사용자에게는 저화질 비디오를 보내는것이 바람직하다.
• 모바일 단말의 경우 상황이 수시로 달라질 수 있다. 비디오 화질을 자동으로 변경하거나 수동으로 변경할 수 있도록 하는 것이 바람직하다.

인코딩 포멧은 대부분 두 부분으로 구성되어있다.

• 컨테이너 : 컨테이너 포멧은 비디오파일, 오디오, 메타데이터를 담는 바구니같은것. (.avi, mov, mp4)
• 코덱: 비디오 화질은 보존하면서 파일 크기를 줄일 목적으로 고안된 압축 및 압축 해제 알고리즘. (h.264, vp9, hevc 등)

일단 원본은 비디오, 오디오, 메타데이터의 세부분으로 나누어 처리된다. 검사는 좋은 품질의 비디오인지, 손상이 없는지 확인하는 절차이고, 비디오 인코딩은 비디오를 다양한 해상도, 코텍, 비트레이트 조합으로 인코딩하는 작업이다.

[전처리기]
     │
     ├──────────────►
     ▼               │
[DAG 스케줄러]         │
     │               ▼
     ▼        [임시 저장소]
[자원 관리자]           ▲
     │               │
     ▼               │
[작업 실행 서버] ───────┘
     │
     ▼
[인코딩된 비디오]

전처리기

비디오 분할 : 비디오 스트림을 GOP(group of pictures)라고 불리는 단위로 쪼갠다.
DAG 생성 : 클라이언트 프로그래머가 작성한 설정 파일에 따라 DAG를 만든다.
데이터 캐시 : 전처리기는 분할된 비디오의 캐시이기도 하다(임시 저장소 활용). 비디오 인코딩이 실패하면 시스템은 보관된 데이터를 활용해 인코딩을 재개한다.

DAG스케줄러

[원본 비디오]
   ├──► [비디오] ──► [작업]
   │                     ├─ 검사
   │                     ├─ 인코딩
   │                     ├─ 섬네일 추출
   │                     ├─ ...
   │                     └─ 워터마크
   │
   ├──► [오디오] ──► [오디오 인코딩] 
   │
   └──► [메타데이터]

자원 관리자

자원 배분을 효과적으로 수행하는 역할을 담당한다.
작업 스케쥴러를통해 작업 큐, 작업 서버 큐, 실행 큐로부터 메시지를 받아 작업을 실행한다. 작업 서버 큐는 작업 서버의 가용 상태 정보가 보관되어있는 우선순위 큐다. 실행 큐는 현재 실행중인 작업 및 작업 서버 정보가 보관되어있다.

• 작업 관리자는 작업 큐에서 가장 높은 우선순위의 작업을 꺼낸다.
• 작업 관리자는 해당 작업을 실행하기 적합한 작업 서버를 고른다.
• 작업 스케줄러는 해당 작업 서버에게 작업 실행을 지시한다.
• 작업 스케줄러는 해당 작업이 어떤 서버에게 할당되었는지에 관한 정보를 실행 큐에 넣는다.
• 작업 스케줄러는 작업이 완료되면 해당 작업을 실행 큐에서 제거한다.

작업 서버

[원본 비디오]
   ├──► [비디오] ──► [작업]
   │                     ├─ 검사
   │                     ├─ 인코딩
   │                     ├─ 섬네일 추출
   │                     ├─ ...
   │                     └─ 워터마크
   │                              │
   │                              ▼
   │                          [병합]
   │                             ▲
   ├──► [오디오] ──► [오디오 인코딩] ─┘
   │
   └──► [메타데이터]

작업이 완료되면 병합을 진행한다.

임시 저장소

임시 저장소에 보관한 데이터는 비디오 프로세싱이 완료되면 삭제한다.

시스템 최적화

비디오 전부를 한번에 업로드로 올리는 것은 비효율적이다. 하나의 비디오는 작은 GOP들로 분할할 수 있다. 분할한 GOP병렬적으로 업로드하면 일부가 실패해도 빠르게 업로드를 재개할 수 있다.

속도 최적화는 업로드 센터를 근거리에 지정하여 개선할 수 있다. 이를 위해 CDN을 사용한다.

낮은 응답지연을 달성하는 일은 어려운 일이다. 이를 위해 느슨한 결합을 만들고 병렬성을 높이는 방법이 있다.

안정성으 최적화 하기위해 미리 사인된 업로드 URL을 사용할 수 있다. 허가받은 사용자만이 올바른 저장소에 비디오를 업로드할 수 있도록 presigned URL을 사용한다.

또한 많은 콘텐츠 제작자가 비디오를 인터넷에 업로드하기를 꺼려하는 이유는 원본을 도난당할까봐서 이다. 이를 위해 DRM, AES암호화, 워터마크를 도입하자.

오류 처리

• 업로드 오류: 몇 회 재시도한다.
• 비디오 분할 오류: 낡은 버전의 클라이언트가 GOP 경계에 따라 비디오를 분할하지 못하는 경우라면 전체 비디오를 서버로 전송하고 서버가 해당 비 디오 분할을 처리하도록 한다.
• 트랜스코딩 오류: 재시도한다.
• 전처리 오류: DAG 그래프를 재생성한다.
• DAG 스케줄러 오류: 작업을 다시 스케줄링한다.
• 자원 관리자 큐에 장애 발생: 사본(replica)을 이용한다.
• 작업 서버 장애: 다른 서버에서 해당 작업을 재시도한다.
• API 서버 장애: API 서버는 무상태 서버이므로 신규 요청은 다른 API 서버로 우회될 것이다.
• 메타데이터 캐시 서버 장애: 데이터는 다중화되어 있으므로 다른 노드에서 데이터를 여전히 가져올 수 있을 것이다. 장애가 난 캐시 서버는 새로운 것 으로 교체한다.
• 메타데이터 데이터베이스 서버 장애:
• 주 서버가 죽었다면 부 서버 가운데 하나를 주 서버로 교체한다.
• 부 서버가 죽었다면 다른 부 서버를 통해 읽기 연산을 처리하고 죽은 서 버는 새것으로 교체한다.