TIL

14장 유튜브 설계

설계 범위 예시

• 유튜브의 모든 기능을 면접 시간에 설계하는 것은 불가능
• 적절한 질문을 통해 설계 범위를 좁혀야 한다.
• 비디오 스트리밍 서비스 설계에 초점을 맞춘 개략적 기능
  • 빠른 비디오 업로드
  • 원활한 비디오 재생
  • 재생 품질 선택 가능
  • 낮은 인프라 비용
  • 높은 가용성과 규모 확장성, 그리고 안정성
  • 지원 클라이언트: 모바일 앱, 웹 브라우저, 스마트 TV

개략적 규모 추정

• DAU 5백만
• 한 사용자는 하루에 평균 5개 비디오 시청
• 10% 사용자가 하루에 1 비디오 업로드
• 비디오 평균 크기는 300MB
• 비디오 저장을 위해 매일 새로 요구되는 저장 용량 = 5백만 x 10% x 300MB = 150TB
• CDN 비용
  • 클라우드 CDN을 사용하면 나가는 데이터 양에 따라 과금
  • 아마존 클라우드프론트를 사용할 경우 1GB당 $0.02 요금 발생 (트래픽 100% 미국에서 발생한다 가정)
  • 즉 매일 발생하는 비용은 5백만 x 5비디오 x 0.3GB x $0.02 = $150,000

비디오 스트리밍 개략적 설계안

• CDN과 BLOB 스토리지의 경우 클라우드 서비스를 활용해도 무관
  • 시스템 설계 면접에서 모든 것을 밑바닥부터 만드는 것과는 관계가 없다.
  • ex) 비디오를 저장하기 위해 BLOB 저장소를 사용한다는 사실만 언급해도 충분
  • 규모 확장이 쉬운 BLOB 저장소나 CDN을 직접 만드는 것은 너무 복잡하고 비용도 크다.
  • 넷플릭스도 아마존 클라우드 서비스를 이용하고 페이스북도 아카마이(Akamai)의 CDN을 이용
• 개략적으로 시스템은 다음 세 컴포넌트로 구성
  • 단말: 컴퓨터, 모바일 폰, 스마트 TV 등을 통해 유튜브 시청
  • CDN: 비디오는 CDN에 저장, 재생 버튼을 누르면 CDN으로부터 스트리밍이 이루어진다.
  • API 서버: 비디오 스트리밍을 제외한 모든 요청을 처리
    • 피드 추천, 비디오 업로드 URL 생성, 메타데이터 DB와 캐시 갱신, 사용자 가입 등

비디오 업로드 절차

• 비디오 업로드에 필요한 컴포넌트

  

  • 사용자: 유튜브를 시청하는 이용자
  • 로드밸런서: API 서버 각각으로 요청을 분산
  • API 서버: 비디오 스트리밍을 제외한 모든 요청 처리
  • 메타데이터 데이터베이스: 비디오의 베타데이터를 보관
    • 샤딩과 다중화를 적용하여 성능 및 가용성 충족
  • 메타데이터 캐시: 성능을 위해 메타데이터와 사용자 객체를 캐시
  • 원본 저장소: 원본 비디오를 보관할 대형 이진 파일 저장소(BLOB, Binary Large Object storage)
  • 트랜스코딩 서버: 비디오 트랜스코딩을 수행
    • 비디오 인코딩이라 부르는 절차로 비디오의 포맷(MPEG, HLS)을 변환
    • 단말이나 대역폭 요구사항에 맞는 최적의 비디오 스트림을 제공하기 위해 필요
  • 트랜스코딩 비디오 저장소: 트랜스코딩이 완료된 비디오를 저장하는 BLOB 저장소
  • CDN: 비디오를 캐시하는 역할 담당하고 비디오 스트리밍이 이루어지는 곳
  • 트랜스코딩 완료 큐: 비디오 트랜스코딩 완료 이벤트를 보관할 메시지 큐
  • 트랜스코딩 완료 핸들러: 트랜스코딩 완료 이벤트 데이터로 메타데이터 캐시와 데이터베이스를 갱신할 작업 서버들

• 비디오 업로드는 다음 두 프로세스가 병렬적으로 수행된다.

  • 비디오 업로드
  • 비디오 메타데이터 갱신
    • 메타데이터: 비디오 URL, 크기, 해상도, 포멧, 사용자 정보 등

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

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

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

• 단말은 비디오 메타데이터 갱신 요청을 API 서버로 전송
  • 병렬적으로 원본 저장소에 비디오 파일이 업로드 중에 수행
• 메타데이터: 파일 이름, 크기, 포멧 등
• 메타데이터 데이터베이스와 캐시에 업데이트

비디오 스트리밍 절차

• 스트리밍 - 단말이 원격지의 비디오로부터 지속적으로 비디오 스트림을 전송 받아 영상을 재생하는 것
  • 비디오 다운이 완료되어야 영상을 볼 수 있다거나 하는 불편함은 없다.
• 스트리밍 프로토콜: 비디오 스트리밍을 위해 쓰이는 표준화된 통신 방법
  • MPEG-DASH
    • MPEG - Moving Picture Experts Group
    • DASH - Dynamic Adaptive Streaming over HTTP
  • 애플(Apple) HLS (HTTP Live Streaming)
  • 마이크로소프트 스무드 스트리밍 (Microsoft Smooth Streaming)
  • 어도비 HTTP 동적 스트리밍 (Adobe HTTP Dynamic Streaming, HDS)
• 프로토콜의 동작 원리를 정확히 이해할 필요는 없지만 용례에 맞는 프로토콜을 잘 골라야 한다.
  • 프로토콜마다 지원하는 비디오 인코딩이 다르고 플레이어도 다르기 때문
• 비디오는 CDN에서 바로 스트리밍된다.
  • 사용자 단말에 가장 가까운 CDN 에지 서버가 비디오를 전송

비디오 스트리밍 상세 설계

비디오 트랜스코딩

• 비디오는 녹화되면 단말은 해당 비디오를 특정 포맷으로 저장한다.
• 다른 단말에서도 잘 재생되려면 다른 단말과 호환되는 비트레이트와 포맷으로 저장되어야 한다.
  • 비트레이트: 비디오를 구성하는 비트가 얼마나 빨리 처리되어야 하는지 나타내는 단위
  • 비트레이트가 높은 비디오는 일반적으로 고화질 비디오
• 비디오 트랜스코딩이 중요한 이유
  • 가공되지 않은 원본 비디오는 저장 공간을 많이 차지
  • 상당수 단말과 브라우저는 특정 종류의 포맷만 지원하기에 여러 포맷으로 인코딩해 두는 것이 좋다.
  • 끊김 없는 고화질 비디오 재생을 위해선 네트워크 대역폭에 따라 저화질, 고화질 비디오를 각각 보내는 것이 바람직
  • 모바일 단말의 경우 네트워크 상황이 수시로 달라지기에 비디오 화질을 자동으로 변경하거나 수동으로 변경할 수 있도록 해야한다.
• 인코딩 포맷은 다양하지만 대부분 다음 두 부분으로 구성된다.
  • 컨테이너: 비디오 파일, 오디오, 메타에이터를 담는 바구니 같은 것
    • .avi, .mov, .mp4 같은 확장자
  • 코덱(codec): 비디오 화질은 보존하면서 파일 크기를 줄일 목적으로 고안된 압축 및 압축 해제 알고리즘
    • H.264, VP9, HEVC 등

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

• 비디오 트랜스코딩은 컴퓨팅 자원과 시간을 많이 소모한다.
• 콘텐츠 창작자는 자기만의 비디오 프로세싱 요구사항을 가진다.
  • 비디오에 워터마크를 표시하고 싶은 경우
  • 섬네일 이미지를 손수 만들고 싶은 경우
  • 고화질 비디오를 선호하는 반면 저화질 비디오도 충분한 경우
• 비디오 프로세싱에는 적절한 수준의 추상화가 필요
  • 각기 다른 유형의 비디오 프로세싱 파이프라인을 지원하기 위해
  • 처리 병렬성을 높이기 위해
  • 클라이언트 프로그래머로 하여금 실행 작업을 손수 정의할 수 있도록 해야한다.
• 유향 비순환 그래프 프로그래밍 모델 (Directed Acyclic Graph)
  • 페이스북의 스트리밍 비디오 엔진
  • 각 작업들이 순차적 또는 병렬적으로 실행될 수 있도록 한다.

• 비디오 트랜스코딩을 위해 채택한 DAG 모델 예시

  

  • 원본 비디오는 비디오, 오디오, 메타데이터 세 부분으로 나뉘어 처리된다.
  • 비디오 부분에 적용되는 작업
    • 검사: 비디오 품질 검사, 손상은 없는지 확인
    • 비디오 인코딩: 다양한 해상도, 코덱, 비트레이트 조합으로 인코딩하는 작업
    • 섬네일: 사용자가 업로드한 이미지나 비디오에서 자동 추출된 이미지로 섬네일을 만드는 작업
    • 워터마크: 비디오에 대한 식별정보를 이미지 위에 오버레이 형태로 띄어 표시하는 작업

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

• 전처리기
  • 비디오 분할: 비디오 스트림을 GOP(Group of Pictures) 단위로 쪼갠다.
    • GOP - 특정 순서로 배열된 프레임 그룹이며 한 GOP는 독립적으로 재생 가능하다. (보통 몇 초)
  • DAG 생성: 설정 파일에 따라 DAG를 만들어 낸다.
  • 데이터 캐시: GOP와 메타데이터를 임시 저장소에 보관
    • 전처리기는 분할된 비디오의 캐시이기도 하다.
    • 비디오 인코딩이 실패하면 시스템은 보관된 데이터로 인코딩을 재개한다.
• DAG 스케줄러
  • DAG 그래프를 몇 개 단계로 분할하여 각각을 작업 큐에 넣는다.
• 자원 관리자
  • 자원 배분을 효과적으로 수행하는 역할을 담당
  • 3 개 큐(작업 큐, 작업 서버 큐, 실행 큐)와 작업 스케줄러로 구성된다.
    • 작업 큐: 실행할 작업을 가지는 우선순위 큐
    • 작업 서버 큐: 작업 서버의 가용 상태 정보가 있는 우선순위 큐
    • 실행 큐: 현재 실행 중인 작업 및 작업 서버 정보가 보관된 큐
    • 작업 스케줄러: 최적의 작업/서버 조합을 골라 작업을 수행하도록 지시 1. 작업 관리자는 작업 큐에서 가장 높은 우선순위의 작업을 꺼내고 작업 서버 큐에서 가장 높은 우선순위의 작업 서버를 골라 작업 실행을 지시 2. 작업 스케줄러는해당 작업이 어떤 서버에게 할당되었는지에 관한 정보를 실행 큐에 넣는다. 3. 작업 스케줄러는작업이 완료되면 실행 큐에서 해당 작업 제거
• 작업 서버
  • DAG에 정의된 작업을 수행
• 임시 저장소
  • 저장소 구현체 선택은 데이터 유형, 크기, 이용 빈도에 따라 달라진다.
  • ex) 메타 데이터는 빈번히 참조되고 크기도 작으니 메모리에 캐시해도 된다.
  • ex) 비디오/오디오 데이터는 BLOB 저장소에 두는 것이 바람직
  • 임시 저장소에 보관한 데이터는 비디오 프로세싱이 완료되면 삭제
• 인코딩된 비디오
  • 인코딩 파이프라인의 최종 결과물

시스템 최적화

• 속도, 안정성, 비용 측면에서 이 시스템을 최적화하는 방법이 있다.

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

• 하나의 비디오는 작은 GOP들로 분할할 수 있다.
• 분할한 GOP를 병렬적으로 업로드하면 일부가 실패해도 빠르게 재업로드할 수 있다.

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

• 업로드 센터를 여러 곳에 두면 속도를 개선할 수 있다.
• CDN을 업로드 센터로 사용할 수도 있다.

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

• 느슨하게 결합된 시스템을 만들어 병렬성을 높일 수 있다.
• 이전 단계의 결과물을 입력으로 사용하는 의존성이 존재하면 병렬성을 높이기 어렵다.
• 메시지 큐를 도입하면 시스템 결합도를 낮출 수 있다.
  • 메시지 큐를 도입하기 전에 인코딩 모듈은 다운로드 모듈 작업이 끝나기를 기다려야 함
  • 메시지 큐를 도입하면 인코딩 모듈은 다운로드 모듈을 기다릴 필요가 없고 큐의 이벤트 각각을 인코딩 모듈이 병렬적으로 처리할 수 있다.

  

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

• 인증된 사용자만이 비디오를 업로드할 수 있도록 미리 사인된(pre-signed) 업로드 URL을 이용한다.
• 이를 위해 업로드 절차를 변경해야 한다.
  1. 클라이언트는 HTTP 서버에 POST 요청을 하여 미리 사인된 URL을 받는다.
     1. 해당 URL이 가리키는 객체에 대한 접근 권한이 이미 주어진 상태
  2. API 서버는 미리 사인된 URL을 돌려준다.
  3. 클라이언트는 해당 URL이 가리키는 위치에 비디오를 업로드

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

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

비용 최적화

• CDN 비용을 최적화 하는 것이 중요
• 연구 결과에 따르면 유튜브 스트리밍은 롱테일 분포를 따른다.
  • 인기 있는 비디오는 빈번히 재생되지만 나머지는 거의 안 봄
    1. 인기 비디오는 CDN을 통해 재생하되 나머지 비디오는 비디오 서버를 통해 재생
    2. 인기가 별로 없으면 인코딩할 필요가 없을 수도 있다. 1. 짧은 비디오라면 필요할 때 인코딩하여 재생 가능
    3. 어떤 비디오는 특정 지역에서만 인기가 높기에 다른 지역으로 옮기지 않아도 된다.
    4. CDN을 직접 구축하고 인터넷 서비스 제공자(ISP)와 제휴 1. CDN 직접 구축은 초대형 프로젝트지만 대규모 스트리밍 사업자라면 필요할 수도 있다. 2. 사용자 경험 향상이 가능하고 인터넷 사용 비용도 낮출 수 있을 것이다.
• 위 최적화는 콘텐츠 인기도, 이용 패턴, 비디오 크기 등 데이터에 근거한 것
  • 최적화 시도 전에 시청 패턴을 분석할 필요가 있다.

오류 처리

• 회복 가능 오류
  • 특정 비디오 세그먼트 트랜스코딩 실패 등의 오류는 회복 가능
  • 이런 오류는 몇 번 재시도하면 해결된다.
  • 단 계속해서 하는 실패한다면 복구가 어렵다 판단하고 적절한 오류 코드를 클라이언트에게 반환해야 한다.
• 회복 불가능 오류
  • 비디오 포맷이 잘못되는 경우 등
  • 작업을 중단하고 클라이언트에게 오류 코드를 반환해야 한다.
• 전형적인 오류에 대한 해결 방법
  • 업로드 오류: 몇 회 재시도
  • 비디오 분할 오류: 낡은 버전 클라이언트가 GOP 경계에 따라 분할하지 못한다면 전체 비디오를 전송하고 서버가 비디오 분할을 처리
  • 트랜스코딩 오류: 재시도
  • 전처리 오류: DAG 그래프 재생성
  • DAG 스케줄러 오류: 작업을 다시 스케줄링
  • 자원 관리자 큐에 장애 발생: 사본(replica) 이용
  • 작업 서버 장애: 다른 서버에서 해당 작업 재시도
  • API 서버 장애: 다른 API 서버로 우회
  • 메타데이터 캐시 서버 장애: 데이터는 다중화되어 있기에 다른 노드에서 데이터를 조회, 장애 캐시 서버는 교체
  • 메타데이터 데이터베이스 서버 장애
    • 주 서버가 죽었다면 부 서버 중 하나를 주 서버로 승격
    • 부 서버가 죽었다면 다른 부 서버를 통해 읽기 연산 처리하고 죽은 서버를 새 서버로 교체

더 논의해볼 점

• API 서버는 무상태이므로 규모 확장이 가능
• 데이터베이스의 다중화와 샤딩
• 라이브 스트리밍
  • 응답 지연 시간이 좀 더 낮아야 하므로 스트리밍 프로토콜 선정에 유의해야 한다.
  • 병렬화 필요성은 떨어질텐데 작은 단위의 데이터를 실시간으로 빨리 처리해야 하기 때문
  • 너무 많은 시간이 걸리는 방안은 사용하기 어려워 오류 처리 방법을 달리해야 한다.
• 비디오 삭제
  • 부적절한 비디오는 내려야 한다.
  • 업로드 과정에서 식별하거나 사용자 신고 절차를 통해 관리할 수도 있다.