ch14 유튜브 설계

4/25/2025

#시스템 디자인

유튜브 설계

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

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

비디오 스트리밍 서비스 설계에 초점을 둔 기능들

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

개략적 규모 추정

규모는 아래와 같이 가정한다.

일간 능동 사용자(DAU: Daily Active User) 수 : 5백만(5million)
한 사용자는 하루에 평균 5개의 비디오 시청
10% 사용자가 하루에 1비디오 업로드
비디오 평균 크기는 300MB
비디오 저장을 위해 매일 새로 요구되는 저장 용량 = 5백만 X 10% X 300MB = 150TB
CDN 비용 : 아마존 클라우드프론트(CloudFront) 기준, 100% 트래픽 미국 기준, 1GB 당 0.02달러
매일 발생하는 요금 : 5백만 X 5비디오 X 0.3GB X 0.02 달러 = 150,000달러

이러한 비용을 줄이는 방법에 대해 상세 설계를 진행하기위해 자세히 알아보겠다.

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

직접 만들지 않고 기존 클라우드 서비스를 이용하는 이유

시스템 설계 면접은 적절한 기술을 골라 설계를 마치는 것이 더 중요하다.

ex) BLOB 저장소를 쓸 것이라면 쓸거라는거 언급하는 정도로 충분 어떻게 BLOB 저장소를 구현할지 상세한 설계를 제시하는 건 바람직X

BLOB 저장소, CDN을 만드는 것은 비용이 너무 많이 들고 복잡함

넷플릭스 -> 아마존 클라우드 페이스북 -> 아카마이 라는 CDN을 사용함

Client(단말) : 컴퓨터, 모바일, 폰, 스마트 TV 등 CDN : 비디오 저장, 재생 버튼 누르면 스트리밍 제공 API Server : 비디오 스트리밍을 제외한 모든 요청을 처리 (피드 추천, 비디오 업로드 URL 생성, 메타데이터 베이스, 캐시 갱신, 사용자 가입)

면접관이 아래와 같은 두 영역을 설계해줄것을 요청하였다.

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

비디오 업로드 절차

** 트랜스코딩 : 비디오 인코딩이라고도 부름, 비디오 포맷 변환(단말, 대역폭 요구사항에 맞춰서)

User(사용자) : 유튜브 시청하는 사용자
Load balancer : API 서버에게 요청 분산
API Servers : 비디오 스트리밍 제외 다른 모든 요청 처리
Metadata DB(메타데이터 데이터베이스) : 비디오 메타데이터 보관
- 샤딩, 다중화 고려 가능(성능, 가용성 요구사항에 맞춰서)
Metadata Cache(메타데이터 캐시) : 비디오 메타데이터, 사용자 객체 캐싱
Original Storage(원본 저장소) : 대형 이진 파일 저장소(BLOB, Binary Large Object Storage)
Transcoding Server(트랜스코딩 서버) : 비디오 포맷을 변환
TransCoded Storage(트랜스코딩 비디오 저장소) : 트랜스코딩된 비디오 저장(BLOB)
CDN : 비디오를 캐싱, 사용자가 재생버튼 누르면 비디오 스트리밍 제공
Completion Queue(트랜스코딩 완료 큐) : 비디오 트랜스코딩 완료 이벤트 보관, 메시지큐
Completion Handler(트랜스코딩 완료 핸들러) : 이벤트 꺼내서 메타데이터 캐시, 데이터베이스 갱신하는 서버

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

비디오를 원본 저장소에 업로드
트랜스코딩 서버는 원본 저장소에서 비디오를 가져와 트랜스코딩 시작
트랜스코딩 후 병렬로 아래 절차 수행

3a. 완료된 비디오를 트랜스코딩 비디오 저장소로 업로드
3b. 트랜스코딩 완료 이벤트를 트랜스코딩 완료 큐에 넣기
- 3a.1. 트랜스코딩 끝난 비디오를 CDN에 올리기
- 3b.1. 완료 핸들러가 이벤트 데이터를 큐에서 꺼내기
- 3b.1.a, 3b.1.b. 완료 핸들러가 메타데이터베이스와 캐시를 갱신

API 서버가 단말에게 비디오 업로드 완료 후 스트리밍이 준비되었다 알림

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

원본 저장소에 파일이 업도르 되는 동안 병렬로 이루어짐 ( 단말이 메타데이터 갱신 요청을 API 서버에게 보냄)

파일 이름, 크기, 포맷 등의 정보를 업데이트 -> 메타데이터 캐시, 데이터베이스

비디오 스트리밍 절차

유튜브에서 재생버튼을 누르면 단말에 비디오 모두 내려 받아서 영상을 볼 수 있다거나 하는게 아니라 지속적으로 비디오 스트림을 전송 받아 재생된다.

스트리밍 프로토콜

스트리밍 절차를 보기 앞서, 비디오 스트리밍을 위해 데이터를 전송할 때 쓰이는 표준화된 통신방법을 알아본다.

ex)

MGEG-DASH, MPEG(Moving Picture Experts Group)
애플 HLS(HTTP Live Streaming)
마이크로소프트 스무드 스트리밍(Smooth Streaming)
어도비 HTTP 동적 스트리밍(HTTP Dynamic Streaming, HDS)

프로토콜마다 지원하는 비디오 인코딩, 플레이어가 다르다 서비스 용례에 맞는 프로토콜을 잘 골라야한다. [7] 참고

3단계 상세 설계

비디오 업로드, 스트리밍을 최적화 해보기 위해 상세 설계를 진행해본다. 후에 오류 처리 메커니즘도 살펴본다

비디오 트랜스코딩

비디오를 녹화하면 단말기는 특정 포맷으로 저장하게 되는데 이걸 다른 단말에서 재생되게 할려면 호환되는 비트레이트와 포맷으로 저장되어야 한다.

** 비트레이트 : 비디오를 구성하는 비트가 얼마나 빨리 처리되어야 하는지를 나타내는 단위

트랜스 코딩이 중요한 이유

원본 비디오는 용량을 너무 많이 차지함
단말, 브라우저는 특정 종류의 비디오 포맷만 지원함 -> 호환성 문제를 위해 여러 포맷으로 인코딩해주는게 좋음
네트워크 대역폭이 좋지 않은 사용자는 저화질 비디오로, 대역폭이 충분한 사용자는 고화질 비디오를 보내주는게 바람직함
모바일 단말은 네트워크 상황이 수시로 달라질 수 있음. 비디오가 끊기지 않도록 하려면 화질을 자동으로 변경하거나 수동으로 변경할 수 있도록 해야함

인코딩 포맷

컨테이너(Container) : 비디오, 오디오, 메타데이터를 담는 바구니
- .avi .mov .mp4
코덱(Codec) : 화질은 보존하면서 크기는 줄어들게 하기위한 압축 / 압축 해제 알고리즘
- H.264 , VP9 , HEVC

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

어떤 사람은 비디오 위에 워터마크 표기하고 싶어하고 어떤 사람은 썸네일 이미지를 만들어 넣기 어떤 사람은 고화질 비디오를 선호 어떤 사람은 저화질 비디오로 보고싶어할 수 있음

DAG (Directed Acyclic Graph) : 방향이 있고 사이클이 없는 그래프

복잡한 작업 순서나 데이터 흐름을 표현할 수 있다.

작업을 단계별로 배열할 수 있도록 하여 해당 작업들이 순차적으로 또는 병렬적으로 실행될 수 있도록

Inspection(검사) : 비디오 품질, 손상이 없는지 확인 Video Transcoding(비디오 인코딩) : 다양한 해상도, 코덱, 비트레이트 조합으로 인코딩 Thumbnail(썸네일) : 사용자가 업로드한 이미지나 비디오에서 추출된 이미지로 썸네일 만듬 Watermark(워터마크) : 비디오 식별정보를 오버레이 형태로 띄워 표시

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

전처리기(Preprocessor)

** GOP : 효율적으로 압축하기 위해 프레임들을 그룹으로 묶어서 관리

비디오 분할
- GOP(Group of Pictures) 라는 단위로 쪼갬
DAG 생성
데이터 캐시
- GOP, 메타데이터를 임시 저장소(Temporary Storage)에 보관, 비디오 인코딩이 실패하면 시스템은 보관된 데이터를 활용해서 인코딩을 다시 진행

DAG 스케줄러(DAG scheduler)

DAG 그래프를 몇 단계로 분할하여 각각 자원관리자의 작업 큐에 넣음

Stage1 비디오, 오디오, 메타데이터 분리

Stage2 비디오 인코딩, 섬네일 추출, 오디오 인코딩

자원 관리자(Resource manager)

작업큐(Task queue) 가장 높은 우선순위 작업 선택

작업 서버 큐 (Worker queue) 최적 작업 서버 선택

실행 큐 (Running queue) 큐에 작업/서버 정보 추가

작업관리자

작업 큐에서 가장 높은 우선순위 작업 꺼내기 작업을 실행하기 적합한 작업서버 선택 작업 실행 지시

작업 스케줄러

어떤 서버에게 할당되었는지에 대한 정보를 실행 큐에 넣기 작업이 완료되면 실행 큐에서 제거

작업서버(Task workers)

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

임시 저장소(Temporary Storage)

저장소 시스템을 선택할때, 데이터 유형, 크기, 이용 빈도, 데이터 유효기간 고려해봐야함 ex) 메타데이터는 작업 서버가 빈번히 참조하는 정보 크기도 작은 것이 보통임 -> 메모리에 캐시해두면 좋음 비디오 / 오디오 데이터는 BLOB 저장소에 두는 것이 바람직

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

인코딩된 비디오(Encoded video)

인코딩 파이프라인의 최종 결과물 funnny_720p.mp4

시스템 최적화

속도, 안정성, 비용 측면에서 최적화를 진행해보겠다.

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

하나의 비디오를 작은 GOP들로 분할

일부가 실패해도 빠르게 업로드를 재개할 수 있음

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

업로드 센터를 근거리에 둔다.(CDN)

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

느슨하게 결합된 시스템을 만들기 -> 메시지 큐

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

클라이언트가 HTTP POST 요청으로 미리 사인된 URL 받기
API 서버는 URL 돌려줌
클라이언트는 URL이 가리키는 위치에 비디오 업로드

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

AES 암호화 : 비디오를 암호화, 접근권한 설정하는 방식
- 암호화된 비디오는 재생 시에만 복호화
- 허락된 사용자만 암호화된 비디오 시청
워터마크 : 이미지 오버레이로 회사 로고, 이름등을 올리기

위 방법 중 하나를 채택할 수 있다.

비용 최적화

CDN은 비싸다. 데이터 크기가 크면 클수록 더 비싸다 인기 있는 비디오는 빈번히 재생되나, 나머지는 거의 보는 사람이 없다.

방법들

인기 비디오는 CDN을 통해서 재생하고, 다른 비디오는 비디오 서버를 통해 재생시키는 것이다.
인기 없는 비디오는 인코딩할 필요가 없을 수도 있다 , 짧은 비디오라면 필요할 때 인코딩하여 재생할 수 있다.
어떤 비디오는 특정 지역에서만 인기가 높다 -> 다른 지역에 둘 필요가 없음
CDN을 직접 구축 하여 인터넷 서비스 제공자(ISP : Internet Service Provider)와 제휴, 직접 구축하는건 초대형 프로젝트,,

인터넷 서비스 제공자(ISP: Internet Service Provider) : 컴캐스트(Comcast) , AT&T , 버라이즌(Verizon) 인터넷 사용비용을 낮출수 있다

오류 처리

시스템 오류에는 두 가지 종류가 있다.

회복 가능 오류(recoverable error)
- ex) 특정 비디오 세그먼트를 트랜스코딩하다 실패
- 몇번 재시도하면 해결됨 하지만 계속해서 실패하고 복구가 어렵다 판단되면 클라이언트에게 적절한 오류 코드를 반환시켜야한다.
회복 불가능 오류(non-recoverable error)
- 비디오 포맷이 잘못되었거나, 회복 불가능한 오류가 발견되면 해당 비디오에 대한 작업을 중단하고 클라이언트에게 적절한 오류 코드를 반환시켜야한다.

발생할 수 있는 오류에 대한 전형적 해결방법

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

4단계 마무리

API 계층의 규모 확장성 확보 방안 : 수평적 규모 확장 고려
데이터베이스 계층의 규모 확장성 확보 방안 : 데이터베이스의 다중화, 샤딩
라이브 스트리밍 : 실시간 녹화, 방송
- 비디오 업로드, 인코딩, 스트리밍이 필요하다는 점이 비슷하다.
- 라이브 스트리밍의 경우, 응답지연이 좀 낮다. 따라서 스트리밍 프로토콜 선정에 유의
- 라이브 스트리밍의 경우, 병렬화 필요성은 떨어질 텐데, 작은 단위의 데이터를 실시간으로 빨리 처리해야하기 때문
- 라이브 스트리밍의 경우 오류 처리 방법을 달리해야함. 너무 많은 시간이 걸리는 방안은 사용하기 어려움

다음 챕터

ch15. 구글 드라이브 설계