유튜브 설계

가상 면접 사례로 배우는 대규모 시스템 설계 기초 "유튜브 설계"을 요약한 내용입니다.

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

• 빠른 비디오 업로드
• 원활한 비디오 재생
• 재생 품질 선택 기능
• 낮은 인프라 비용
• 높은 가용성과 규모 확장성, 그리고 안정성
• 지원 클라이언트: 모바일 앱, 웹브라우저, 그리고 스마트 TV

개략적 규모 추정

• 일간 능동 사용자(DAU) 수는 5백만
• 한 자용자는 하루에 평균 5개의 비디오를 시청
• 10%의 사용자가 하루에 1비디오 업로드
• 비디오 평균 크기는 300MB
• 비디오 저장을 위해 매일 새로 요구되는 저장 용량 = 5백만 X 10% X 300MB = 150TB
• CDN 비용
  • 클라우드 CDN을 통해 비디오를 서비스할 경우 CDN에서 나가는 데이터의 양에 따라 과금
  • 아마존의 클라우드프론트를 CDN 솔루션으로 사용할 경우, 100% 트래픽이 미국에서 발생한다고 가정한다면 1GB당 $0.02의 요금이 발생
  • 문제를 단순화하기 위해 비디오 스트리밍 비용만 계산
  • 매일 발생하는 요금은 5백만 X 5비디오 X 0.3GB X $0.02 = $150,000

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

왜 전부 직접 만들지 않을까?

• 시스템 설계 면접은 모든 것을 밑바닥부터 만드는 것과는 관계가 없음
  • 주어진 시간에 적절한 기술을 골라 설계를 마치는 것이, 그 기술 각각이 어떻게 동작하는지 상세히 설명하는 것보다 중요
  • ex) 비디오를 저장하기 위해 BLOB 저장소를 쓸 것이라면 그 사실만 업급해도 충분
  • BLOD 저장소를 어떻게 구현할지 상세한 설계를 제시하는 것은 지나치다
• 규모 확장이 쉬운 BLOB 저장소나 CDN을 만드는 것은 지극히 복잡할 뿐아니라 많은 비용이 드는일
  • 넷플릭스나 페이스북 같은 회사도 모든 것을 스스로 구축하지는 않는다.
  • 넷플릭스는 AWS를 사용
  • 페이스북은 아카마이의 CDN을 이용

비디오 업로드 절차

[그림 14-4]는 비디오 업로드 절차를 개략적 설계안이다.

• 사용자: 컴퓨터나 모바일 폰, 혹은 스마트 TV를 통해 유튜브를 시청하는 이용자
• 로드밸런서: API 서버 각각으로 고르게 요청을 분산하는 역활을 담당
• API 서버: 비디오 스트리밍을 제외한 다른 모든 요청을 처리
• 메타데이터 데이터베이스: 비디오 메타데이터를 보관, 샤딩과 다중화를 저용하여 성능 및 가용성 요구사항을 충족
• 메타데이터 캐시: 성능을 높이기 위해 비디오 메타데이터와 사용자 객체는 캐시
• 원본 저장소: 원본 비디오를 보관할 대형 이진 파일 저장소(BLOB) 시스템
  • BLOB 저장소는 “이진 데이터를 하나의 객체로 보관하는 데이터베이스 관리 시스템”
• 트랜스코딩 서버: 비디오 트랜스코딩은 비디오 인코딩이라 부르기도 하는 절차로, 비디오의 포멧을 변환하는 절차
  • 단말이나 대역폭 요구사항에 맞는 최적의 비디오 스트림을 제공하기 위해 필요
• 트랜스코딩 비디오 저장소: 트랜스코딩이 완료된 비디오를 저장하는 BLOB 저장소
• CDN: 비디오를 캐시하는 역활을 담당
  • 사용자가 재생 버튼을 누르면 비디오 스트림은 CDN을 통해 이루어진다.
• 트랜스코딩 완료 큐: 비디오 트랜스코딩 완료 이벤트들을 보관할 메시지 큐
• 트랜스코딩 완료 핸들러: 트랜스코딩 완료 큐에서 이벤트 데이터를 꺼내어 메타데이터 캐시와 데이터베이스를 갱신할 작업 서버들이다.

프로세스 a: 비디오 업로드

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

프로세스 b: 메타데이터 갱신

메타데이터에 있는 파일 이름, 크기, 포맷 등의 정보로 메타데이터 캐시와 데이터베이스를 업데이트

비디오 스트리밍 절차

• 스프리밍은 장치가 원격지의 비디오로부터 지속적으로 비디오 스트림을 전송 받아 영상을 재생
• 스프리밍 프로토콜은 비디오 스트리밍을 위해 데이터를 전송할 때 스이는 표준화된 통신 방법
  • MPEG-DASH
  • HLS
  • 마이크로소프트 스무드 스트리밍
  • 어도비 HTTP 동적 스트리밍
• 비디오는 CDN에서 바로 스트리밍 된다.
• 사용자의 단말에 가장 가까운 CDN에지 서버가 비디오 전송을 담당할 것

3단계 상세 설계

비디오 트랜스코딩

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

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

인코딩 포맷은 다양하지만 대부분은 두부분으로 구성되어 있다.

• 컨테이너: 비디오 파일, 오디오, 메타데이터를 담는 바구니 같은 것
  • 포맷은 .avi, .mov, .mp4 같은 파일 확장자를 보면 알수 있다
• 코덱: 비디오 화질은 보존하면서 파일 크기를 줄일 목적으로 고안된 압축 및 압축 해제 알고리즘
  • 가장 많이 사용되는 비디오 코덱으로는 H.264, VP9, HEVC가 있다.

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

• 콘텐츠 창작자는 각자 자기만의 비디오 프로세싱 요구사항을 갖고 있다.
  • 비디오 위에 워터마크를 표시
  • 썸네일 이미지를 자기가 만들어 쓰고 싶어 할 수 있음
  • 고화질 비디오를 선호
  • 저화질 비디오를 선호
• 각기 다른 유형의 비디오 프로세싱 파이프라인을 지원하는 한편 처리 과정의 병렬성을 높이기 위해서는 적절한 수준의 추상화를 도입하여 클라이언트 프로그래머로 하여금 실행할 작업을 손수 정의할 수 있도록 해야한다.
• 페이스북의 스트리밍 비디오 엔진은 유향 비순환 그래프(DAG) 프로그래밍 모델을 도입, 작업을 단계별로 배열할 수 있도록 하여 해당 작업들이 순차적으로 또는 병렬적으로 실행될 수 있도록 하고 있다.
• [그림 14-8]에서 원본 비디오는 일단 비디오, 오디오, 메타데이터의 세부분으로 나눠어 처리된다.
  • 검사: 좋은 품질의 비디오인지, 손상은 없는지 확인하는 과정
  • 비디오 인코딩: 비디오를 다양한 해상도, 코덱, 디트레이트 조합으로 인코딩하는 작업
• 섬네일: 사용자가 업로드한 이미지나 비디오에서 자동 추줄된 이미지로 섬네일을 만드는 작업
• 워터마크: 비디오에 대한 식별정보를 이미지 위에 오버레이 형태로 띄워 표시하는 작업

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

전처리기

1. 비디오 분활
   1. 비디오 스트림을 GOP라고 불리는 단위로 쪼갠다.
   2. GOP는 특정 순서로 배열된 프레임 그룹
   3. 하나의 GOP는 독립적으로 재생 가능하며, 길이는 보통 몇 초 정도
   4. 오래된 단말이나 브라우저는 GOP 단위의 비디오 분활을 지원하지 않는다.
      1. 전처리기가 비디오 분활을 대신한다.
2. DAG 생성
   1. 클라이언트 프로그래머가 작성한 설정 파일에 따라 DAG를 만들어 낸다.
3. 데이터 캐시
   1. 전처리기는 분활된 비디오의 캐시이기도 하다.
   2. 안정성을 높이기 위해 전처리기는 GOP와 메타 데이터를 임시 저장소에 보관
   3. 비디오 인코딩이 실패하면 시스템은 보관된 데이터를 활용해 인코딩을 재개

DAG 스케줄러

• DAG 스캐줄러는 DAG 그래프를 몇개 단계로 분활한 다음 그 각각을 자원 관리자의 작업 큐에 집어넣는다.
• [그림 14-15]는 DAG 스케줄러가 어떻게 동작하는지 보여주는 하나의 사례

자원 관리자

자원 관리자는 자원 배분을 효과적으로 수애한느 역활을 담당

[그림 14-17]과 같이, 세 개의 큐와 작업 스케줄러로 구성된다.

• 작업 큐: 실행할 작업이 보관되어 있는 우선순위 큐
• 작업 서버 큐: 작업 서버의 가용 상태 정보가 보관되어 있는 우선순위 큐
• 실행 큐: 현재 실행 중인 작업 및 작업 서버 정보가 보관되어 있는 큐
• 작업 스케줄러: 최적의 작업/서버 조합을 골라, 해당 작업 서버가 작업을 수행하도록 지시하는 역활을 담당

작업 관리자는 아래와 같이 동작

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

작업 서버

• DAG에 정의된 작업을 수행
• 작업 종류에 따라 작업 서버도 구분하여 관리

임시 저장소

• 임시 저장소는 어떤 시스템을 선택할 것이냐에 따라 달라진다.
  • 데이터의 유형, 크기, 이용 빈도, 데이터 유효기간 등
• 비디오/오디오 데이터는 BLOB 저장소에 두는 것이 바람직하다
• 임시 저장소에 보관한 데이터는 비디오 프로세싱이 완료되면 삭제한다.

인코딩된 비디오

• 인코딩된 비디오는인코딩 파이프라인의 최종 결과물이다.
  • ex) funny_720p.mp4

시스템 최적화

속도 최적화: 비디오 병렬 업로드

• 비디오 전부를 한번에 업로드로 올리는 것은 비효율적이다.
  • 하나의 비디오는 작은 GOP들로 분할할 수 있다.
• 분할한 GOP를 병렬적으로 업로드하면 설사 일부가 실패해도 빠르게 업로드를 재개할 수 있다.
• [그림 14-23]과 같이 업로드 속도를 높일 수 있다.

속도 최적화: 업로드 센터를 사용자 근거리에 지정

• 업로드 속도를 개선하는 또 다른 방법은 업로드 센터를 여러 곳에 두는 것
  • 미국 거주자는 비디오를 북미 지역 업로드 센터로 보내도록
  • 중국 거주자는 아시아 업로드 센터로 보내도록 하는 것

속도 최적화: 모든 절차를 병렬화

• 느슨하게 결합된 시스템을 만들어서 병렬성을 높이는 것
• [그림 14-25]와 같이 이전 단계의 결과물을 입력으로 사용하여 만들면 의존성이 있어 병렬성을 높이기 어려움
• 시스템의 결합도를 낮추기위해 메시지 큐를 도입
  • 메시지 큐를 도입하기 전에 인코딩 모듈은 다운로드 모듈의 작업이 끝나기를 기다려야 했다
  • 메시지 큐를 도입하기 뒤에 인코딩 모듈은 다운로드 모듈의 작업이 끝나기를 더이상 기다릴 필요가 없다
  • 메시지 큐에 보관된 이벤트 각각을 인코딩 모듈을 병렬적으로 처리할 수 있다.

안정성 최적화: 미리 사인된 업로드 URL

• 허가 받은 사용자만이 올바른 저장소에 비디오를 업로드할 수 있도록 하기 위해 [그림 14-27]과 같이 미리 사인된 업로드 URL을 이용
  • 클라이언트는 HTTP 서버에 POST 요청을 하여 미리 사인도니 URL을 받는다
  • 해당 URL이 가리키는 객체에 대한 접근 권한이 이미 주어져 있는 상태
  • API 서버는 미리 사인도니 URL을 돌려준다.
  • 클라이언트는 해당 URL이 가리키는 위치에 비디오를 업로드

안정성 최적화: 비디오 보호

• 디지털 저작권 관리 시스템 도입: 가장 널리 사용되는 시스템으로는 애플의 페어플레이, 구글의 와이드바인, 마이크로소프트의 플레이레디가 있다.
• AES 암호화: 비디오를 암호화하고 접근 권한을 설정하는 방식
  • 비디오 재생시에만 복호화한다
  • 허락된 사용자만 암호화된 비디오를 시청할 수 있다.
• 워터마크: 비디오 위에 소유자 정보를 포함하는 이미지 오버레이를 올리는것
  • 회사 로고나 이름 등을 이 용도에 사용할 수 있다.

비용 최적화

CDN은 비싸다. 데이터 크기가 크면 클수록 더 하다.

연구 결과에 따르면 유튜브의 비디오 스트리밍은 롱테일 분포를 따른다

인기 있는 비디오는 빈번하게 재생되는 반면, 나머지는 거의 보는 사람이 없다는 것

1. 인기 비디오는 CDN을 통해서 재생하되 다른 비디오는 비디오 서버를 통해 재생하는 것
2. 인기가 별로 없는 비디오는 인코딩 할 필요가 없을 수도 있다
   1. 짧은 비디오라면 필요할 때 인코딩하여 재생할 수 있다.
3. 어떤 비디오는 특정 지역에서만 인기가 높다
   1. 다른 지역에 옮길 필요가 없다
4. CDN을 직접 구추하고 인터넷 서비스 제공자와 제휴한다.
   1. CDN을 직접 구추하는 것은 초대형 프로젝트이다.

오류 처리

• 회복 가능 오류
  • 특정 비디오 세그먼트를 트랜스코딩 하다 실패했다든가 하는 오류는 회복 가능한 오류에 속한다.
  • 계속해서 실패하고 복구가 어렵다고 판단되면 클라이언트에게 적절한 오류 코드를 반환해야 한다.
• 회복 불가능 오류
  • 비디오 포맷이 잘못되었다거나 하는 회복 불가능한 오류가 발견되면 시스템은 해당 비디오에 대한 작업을 중단하고 클라이언트에게 적절한 오류 코드를 반환해야 한다.

오류에 대한 전형적 해결 방법

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