14. 유튜브 설계

• 유튜브 시스템은 언뜻 보기에는 간단 (창작자가 비디오를 올리고, 시청자는 재생 버튼을 누름)

• 하지만 이면에는 매우 복잡함.

• DAU : 20억
• 매일 재생되는 비디오 수 : 50억
• 미국 성인 73% 사용
• 5천만명의 크리에이터
• 광고수입은 19년 기준 150억 달러
• 모바일 인터넷 트래픽 중 37%를 유튜브가 점유
• 80개 언어로 이용 가능

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

• 댓글
• 비디오 공유
• 좋아요 버튼
• 재생목록
• 채널 구독

→ 설계 범위를 좁혀야함.

• 빠른 비디오 업로드
• 원활한 비디오 재생
• 재생 품질 선택 기능
• Infrastructure cost
• 높은 가용성과 규모확장성, 안정성
• 모바일 앱, 웹, 스마트 TV

개략적 규모 추정

• DAU : 5백만
• 한 사용자는 하루에 평균 5개의 비디오 시청
• 10%의 사용자가 하루에 1개의 비디오 업로드
• 비디오 평균 크기 300MB
• 비디오 매일 저장 용량 → 5백만 _ 10% _ 300MB = 150TB
• CDN (Content Delivery Network)
  • aws 사용
  • 5백만 _ 5비디오 _ 0.3GB * $0.02 = $150,000

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

• BLOB 이나 CDN 상세설계는 지나침
• Client
  • 컴퓨터, 모바일, 스마트 TV
• CDN
  • 비디오는 CDN에 저장. 재생누르면 CDN으로부터 스트리밍
• API Server
  • 비디오 스트리밍을 제외한 모든 요청을 처리함.
  • 피드 추천, 비디오 업로드 URL 생성, 메타데이터 데이터베이스와 캐시 갱신, 사용자 가입 등

비디오 업로드 절차

• 사용자
  • 컴퓨터나 모바일 폰 을 통해 유튜브를 시청하는 이용자
• 로드 밸런서
  • API 서버 각각으로 고르게 분산
• API 서버
  • 비디오 스트리밍을 제외한 모든 요청 처리
• 메타데이터 데이터베이스
  • 비디오의 메타데이터를 보관
  • 샤딩과 다중화를 적용해서 성능 및 가용성 충족
• 메타데이터 캐시
  • 성능을 위해 비디오 메타데이터와 사용자 객체 캐싱
• Original Storage
  • 원본 비디오를 보관한 대형 BLOB 시스템
  • BLOB
    • 이진 데이터를 하나의 개체로 보관하는 DB관리 시스템
• 트랜스 코딩 서버
  • 비디오 트랜스 코딩은 비디오 인코딩이라 불리는 절차
  • 비디오의 포맷(MPEG, HLS) 을 변환하는 절차
  • 단말이나 대역폭 요구사항에 맞는 최적의 비디오 스티림을 제공
• 트랜스 코딩 비디오 저장소
  • 트랜스 코딩이 완료된 비디오를 저장하는 BLOB 저장소
• CDN
  • 비디오를 캐싱
• Completion Queue
  • 비디오 트랜스 코딩 완료 이벤트들 보관 메시지 큐
• Competion Handler
  • 트랜스 코딩 완료 큐에서 이벤트 데이터를 꺼내어 메타데이터 캐시와 디비를 갱신할 작업 서버들

프로세스 A. 비디오 업로드

1. 비디오를 원본 저장소에 업로드
2. 트랜스 코딩 서버는 원본 저장소에서 해당 비디오를 가져와 트랜스코딩을 시작
3. 트랜스 코딩 완료되면 아래의 절차 병렬 수행
   1. 완료된 비디오를 트랜스 코딩 비디오 저장소로 업로드
   2. 완료 핸들러가 이벤트 데이터를 큐에서 꺼냄
   3. 완료 핸들러가 메타데이터 디비와 캐시를 갱신
4. API 서버가 단말에게 비디오 업로드가 끝나서 스트리밍 준비가 되었음을 알린다.

프로세스 B. 비디오 메타데이터 갱신. (비디오 URL, 크기, 해상도, 포맷, 사용자 정보가 포함)

• 원본 저장소에 파일이 업로드되는 동안, 단말은 병렬적으로 비디오 메타데이터에 갱신 요청을 API서버에 보낸다.

비디오 스트리밍 절차

• 스트리밍 프로토콜
  • 비디오 스트리밍을 위해 데이터를 전송할 때 쓰이는 표준화 된 통신 방법
    • MPEG-DASH
      • Moving Picture Experts Group / Dynamic Adaptive Streaming over HTTP
    • HLS
      • HTTP Live Streaming
    • Microsoft Smooth Streaming
    • Adobe HTTP Dynamic Streaming. HDS
• 프로토콜마다 지원하는 비디오 인코딩이 다르고 플레이어도 다름.
• CDN Edge Server가 비디오 전송을 담당할 것이기 때문에 latency가 아주 낮음.

3단계. 상세 설계

비디오 트랜스 코딩

• 비디오가 다른 단말에서도 순조롭게 재생되려면 다른 단말과 호환되는 Bitrate와 Format으로 저장되어야 함.
• Bitrate
  • 비디오를 구성하는 비트가 얼마나 빨리 처리되어야 하는지를 나타내는 단위
  • 높으면 일반적으로 고화질 비디오
• 트랜스코딩의 중요성
  • Raw video는 사이즈가 큼.
  • 호환성 문제
  • 네트워크 대역폭에 따라 화질이 달라져야 사용자에게 끊김이 없음.
  • 모바일 단말의 경우 네트워크 상황에 따라 비디오 화질을 자동 변경
• 인코딩 포맷
  • 컨테이너
    • .avi, .mov, .mp4
  • 코덱
    • 압축 및 압축 해제 알고리즘
    • H.264, VP9, HEVC

유향 비순환 그래프 (DAG) 모델

• 크리에이터 각자 자기만의 비디오 프로세싱 요구사항이 있는데 (썸네일, 워터마크, 화질… ) 이 부분을 파이프라인을 지원함으로써 클라이언트가 직접 task 정의가 가능
• 원본 비디오
  • 비디오
    • 검사
    • 비디오 인코딩 : 해상도, 코덱, 비트레이트 인코딩 조합
    • 섬네일
    • 워터마크 : 오버레이 형태로 표시
  • 오디오
    • 오디오 인코딩
  • 메타데이터
• 병합

비디오 트랜스 코딩 아키텍쳐

• 전처리기
  1. 비디오 분할 : 비디오 스트림을 Group Of Pictures라고 불리는 단위로 쪼갬.
  2. DAG 생성 : 클라이언트 프로그래머가 작성한 설정 파일에 따라 DAG를 만듬.
  3. 데이터 캐시 : 안정성을 높이기 위해 GOP와 메타데이터를 임시 저장소에 보관
• DAG 스케줄러
  • DAG 그래프를 stage로 분할한 다음 각각 자원 관리자의 Queue에 넣음.
• 자원 관리자
  • 자원 배분을 효과적으로 수행
  • 세 개의 큐와 작업 스케줄러
  • 작업 큐
    • 실행할 작업이 보관되어 있는 우선순위 큐
  • 작업 서버 큐
  • 실행 큐
  • 작업 스케줄러
• 작업 서버
  • DAG에 정의된 작업을 수행
• 임시 저장소
  • 메타데이터는 캐시 / 비디오,오디오는 BLOB
• 인코딩된 비디오
  • 인코딩 파이프라인의 최종 결과물

시스템 최적화

• 속도 최적화 : 비디오 병렬 업로드
  • 하나의 비디오는 작은 GOP들로 분할 가능.
  • 분할한 GOP를 병렬적으로 업로드
• 속도 최적화 : 업로드 센터를 사용자 근거리에 지정
  • Region Center 이용
• 속도 최적화 : 모든 절차를 병렬화
  • 느슨하게 결합된 시스템을 만들어서 병렬성을 높이는 것
  • 각 작업 사이에 메시지 큐 도임
    • Async하게 진행 가능
• 안전성 최적화 : 미리 사인된 업로드 URL
  • Pre-signed 업로드 URL을 사용해서 authorized 사용자만 업로드할 수 있게 수행
    1. POST 요청시 미리 사인된 URL을 받음.
    2. 클라이언트는 해당 URL으로 비디오 업로드 진행
• 안전성 최적화 : 비디오 보호
  • Digital Rights Management 도입
  • AES 암호화
  • Watermark
• 비용 최적화
  • CDN 은 비쌈.
  • 비디오 스트리밍은 롱케일 분호를 따름.
    • 인기있는 비디오는 빈번, 나머지는 거의 보는 사람이 없음. 1. 인기비디오는 CDN, 다른 비디오는 비디오 서버 2. 인기없으면 인코딩 안함 3. 지역별로 구분 4. CDN직접 구축

오류 처리

• Highly Fault Tolerant 시스템을 만들어야 함.
• Recoverable Error
  • 비디오 세그먼트 트랜스코딩 실패
    • → retry
    • 혹은 오류 코드 반환
• Non Recoverable Error
  • 비디오 포맷이 잘못됨.
  • 중단 후 오류 코드 반환

4단계. 마무리

• API 서버 규모 확장성 : 수평적 스케일 아웃
• 디비 규모 확장성 : 다중화 , 샤딩
• 라이브 스트리밍
  • 레이턴시 낮아야함. 스트리밍 프로토콜
• 비디오 삭제