[대규모 시스템 설계 기초] 14장 - 유튜브 설계

728x90

14장에서는 유튜브 시스템 설계를 다룬다.

현 직장에서 영상 시스템을 해당 챕터와 비슷하게 설계되어 있기 때문에 쉽게 이해할 수 있었다. 나는 DAG는 데이터 파이프라인에서만 사용되는 줄 알았는데 DAG를 사용하여 비디오 프로세싱 파이프라인에도 적용할 수 있다는 것을 알게되었다.

요구사항 예시

비디오 업로드 기능과 시청 기능 구현
모바일 앱, 웹 브라우저, 그리고 스마트 TV 지원해야 함
DAU는 5백만명으로 가정
사용자가 머무르는 시간은 30분으로 가정
다국어 지원
비디어 종류와 해상도 모두 지원
암호화 필요
영상 최대 크기는 1GB로 제한
퍼블릭 클라우드 서비스 활용 가능

위 요구사항을 정리하자면 다음과 같다

빠른 비디오 업로드
원할한 비디오 재생
재생 품질 선택 기능
낮은 인프라 비용
높은 가용성과 규모 확장성, 그리고 안정성

개략적 규모 추정

DAU는 5백만
한 사용자는 하루에 평균 5개의 비디오 시청
10%의 사용자가 1 비디오 업로드
비디오 평균 크기는 300MB
비디오 저장을 위해 매일 새로 요구되는 저장 용량 = 5,000,000 * 10% * 300MB = 150TB
CDN 비용
- 클라우드 CDN는 CDN에서 나가는 데이터의 양에 따라 과금
- Amazon CloudFront를 사용할 경우 미국 리전에서 1GB 당 $0.02의 요금 발생
- 따라서 매일 발생하는 요금은 5,000,000 * 10% * 300MB * $ 0.02 = $150,000 이다

개략적 설계

유튜브 시스템은 크게 비디오 업로드와 비디오 스트리밍 로 나눌 수 있다.

비디오 업로드

위 아키텍처의 주요 컴포넌트 설명

로드밸런서: API 요청 분산
API 서버: 비디오 스트리밍을 제외한 다른 모든 요청
메타데이터 DB: 비디오의 메타데이터 저장
메타데이터 캐시: 비디오 메타데이터를 캐시하여 응답 속도 향상
원본 저장소: 크리에이터가 업로드한 영상 원본 저장
트랜스코딩 서버: 시청자가 시청할 영상 트랜스코딩
트랜스코딩 저장소: 트랜스코딩이 끝난 영상 저장
CDN: 비디오 캐시 담당
Completion Queue: 트랜스코딩 완료 이벤트 보관
Completion Handler: 큐에서 데이터를 꺼내 메타데이터 DB나 캐시에 갱신

비디오 스트리밍

유튜브는 비디오를 다운로드하지 않아도 재생할 수 있어야하기 떄문에 스트리밍이 필요하다.

비디오 스트리밍을 하려면 스트리밍 프로토콜이 필요한데 널리 사용되는 프로토콜은 다음과 같다.

MPEG-DASH
애플의 HLS
Mirosoft Smooth Streaming
Adobe HTTP Dynamic Streaming

상세 설계

비디오 업로드와 비디오 스트리밍 기능을 최적화 해보자

비디오 트랜스코딩

비디오를 녹화하면 단말은 해당 비디오를 특정 포맷으로 저장하는데, 이 비디오가 다른 단말에서도 순조롭게 재생되려면 다른 단말과 호환되는 비트레이트(bitrate)와 포맷으로 저장되어야 한다.

bitrate 란?
비디오를 구성하는 비트가 얼마나 빨리 처리되어야 하는지를 나타내는 단위
비트레이트가 높으면 고화질, 낮으면 저화질
비트레이트가 높은 비디오 스트림을 정상 재생하려면 보다 높은 성능의 컴퓨터 파워가 필요하고 인터넷도 빨라야 힘

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

가공되지 않은 원본 비디오는 저장 공간을 많이 차지함
상당수의 단말과 브라우저는 특정 종류의 비디오 포맷만 지원함 -> 하나의 비디오를 여러 포맷으로 인코딩하는 것이 좋음
사용자에게 끊김 없는 비디오 재생을 보장하려면 네트워크 대역폭에 따라 비트레이트가 유연하게 변경되어야 함

DAG

트랜스코딩은 컴퓨팅 자원을 많이 소모할 뿐 아니라 시간도 많이 드는 작업이다. 그리고 크리에이터에 따라 각자 다른 비디오 프로세싱 요구사항을 갖고 있다.

따라서 각기 다른 유형의 비디오 프로세싱을 병렬적으로 처리하기 위해 비디오 프로세싱 파이프라인 태스크를 손수 정의할 수 있게 해야한다.

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

전처리기

전처리기는 다음과 같은 세 가지 역할을 맡는다.

비디오 분할: 비디오 스트림을 GOP(Group of Pictures)라 불리는 단위로 쪼갬
DAG 생성: 클라이언트 프로그래머가 작성한 job에 따라 DAG를 만듦
데이터 캐시: 안정성을 높이기 위해 GOP와 메타데이터를 임시 저장소에 보관 -> 인코딩이 실패하면 시스템은 임시 저장소에 보관된 데이터를 활용해 재 인코딩함

DAG 스케줄러

DAG 스케줄러는 DAG 그래프를 몇 개 단계로 분할한 다음 각각을 자원 관리자의 작업 큐에 집어넣는다.

자원 관리자

자원 관리자는 자원 배분을 효과적으로 수행하는 역할을 담당한다.

자원 관리자는 다음 세 개의 큐와 작업 스케줄러로 구성된다.

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

워커

워커는 DAG에 정의된 태스크를 수행한다.

시스템 최적화

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

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

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

업로드 속도를 올리기 위해 업로드 센터를 여러 곳에 둔다.

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

낮은 응답지연을 달성하기 위해 느슨하게 결합된 시스템을 만들어서 병렬성을 높인다.

안정성 최적화: pre signed 업로드 URL

인가받은 사용자만이 올바른 장소에 비디오를 업로드할 수 있도록 pre-signed 업로드를 URL을 이용한다.

pre signed URL는 Amazon S3에서 제공하는 기능으로 MS Azure는 Shared Access Signature 라고 부른다.

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

DRM(Digital RIghts Management)
AES 암호화: 비디오를 암호화하고 인가된 사용자만 암호화된 비디오를 복호화되며 재생할 수 있음
워터마크: 비디오에 이미지 오버레이를 올림

비용 최적화

CDN은 세계 어디서도 끊김 없이 빠르게 비디오를 시청할 수 있도록 해주지만, 비용이 매우 비싸다. 따라서 CDN 비용 최적화를 하기 위해 인기 비디오는 CDN을 통해 재생시키고, 다른 비이도는 서버를 통해 재생시킨다.

오류 처리

시스템 오류는 대형 시스템에서 불가피하다. 장애를 아주 잘 간매하는 시스템을 만들려면 이런 오류를 우아하게 처리하고 빠르게 회복해야한다.

회복 가능 오류(recoverable error): 회복 가능한 오류면 몇 번 재시도하고, 계속 실패한다면 DLQ(Dead Letter Queue)에 넣고 클라이언트에게 적절한 오류 코드를 반환한다.
회복 불가능 오류(non-recoverable error): 회복이 불가능한 오류는 해당 작업을 중단하고 클라이언트에게 적절한 오류 코드를 반환한다.

시간이 남은다면 추가적으로 다음 내용도 논의한다.

API 계층의 규모 확장성 확보 방안
데이터베이스 계층의 규모 확정성 확보 방안
라이브 스트리밍
비디오 삭제