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

가영·2022년 11월 30일

가상 면접 사례로 배우는 대규모 시스템 설계 기초 1

목록 보기

9/10

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

유튜브의 기능은 단순 비디오 시청 말고도 많은 기능이 있으므로, 면접관과 조율해 범위를 좁혀보도록 한다.

개략적 규모 추정

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

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

기존 클라우드 서비스를 이용하려는 것에대한 근거는 어떻게 제시할 수 있을까?

규모 확장이 쉬운 BLOB저장소나 CDN을 만드는 것은 지극히 복잡할 뿐 아니라 많은 비용이 드는 일이다.
넷플릭스나 페이스북 같은 큰 회사도 모든 것을 스스로 구축하지는 않는다. 넷플릭스는 아마존의 클라우드 서비스를 사용하고, 페이스북은 아카마이(Akamai)의 CDN을 이용한다.

개략적인 시스템의 컴포넌트들

• 단말(client): 컴퓨터, 모바일 폰, 스마트 TV를 통해서 유튜브를 시청할 수 있다.
• CDN: 비디오는 CDN에 저장힌다. 재생 버튼을 누르면 CDN으로부터 스트리밍이 이루어진다.
• API 서버: 비디오 스트리밍을 제외한 모든 요청은 API 서버가 처리한다. ~~피드 추천(feed recommendation), 비디오 업로드 URL 생성, 메타데이터 데이터베이스와 캐시 갱신, 사용자 가입 등~~

우리는 이제 다음 두 흐름을 설계할 것이다

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

비디오 업로드 절차

이 설계안은 다음의 컴포넌트들로 구성되어 있다.

사용자: 컴퓨터나 모바일 폰, 혹은 스마트 TV를 통해 유튜브를 시청하는 이용자다.
로드밸런서(load balancer): API 서버 각각으로 고르게 요청을 분산하는 역할을 담당한다.
API 서버: 비디오 스트리밍을 제외한 다른 모든 요청을 처리한다. 메타데이터 데이터베이스(metadata db): 비디오의 메타데이터를 보관한다.
메타데이터 캐시(metadata cache): 성능을 높이기 위해 비디오 메타데이터 와 사용자 객체 (user object)는 캐시 한다.
원본 저장소(original storage): 원본 비디오를 보관할 대형 이진 파일 저장소 (BLOB, 즉 Binary Large Object storage) 시스템이다.
트랜스코딩 서버(transcoding server): 비디오의 포맷(MPEG, HLS 등)을 변환하는 절차다. 단말이나 대역폭 요구사항에 맞는 최적의 비디오 스트림을 제공하기 위해 필요하다.
트랜스코딩 비디오 저장소(transcoded storage): 트랜스코딩이 완료된 비디오를 저장하는 BLOB 저장소다.
CDN: 비디오를 캐시하는 역할을 담당한다. 사용자가 재생 버튼을 누르면 비디오 스트리밍은 CDN을 통해 이루어진다.

비디오 업로드는 다음 두 프로세스가 병렬절으로 일어난다고 할 수 있다.

a. 비디오 업로드
b. 비디오 메타데이터 갱신

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

비디오를 원본 저장소에 업로드한다.
트랜스코딩 서버는 원본 저장소에서 해당 비디오를 가져와 트랜스코딩을

시작한다.

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

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

원본 저장소에 파일이 업로드되는 동안, 단말은 병렬적으로 비디오 메타데이 터 갱신 요청을 API 서버에 보낸다. 이 요청에 포함된 메타데이터에는 파일 이름, 크기, 포맷 등의 정보가 들어 있다. API 서버는 이 정보로 메타데 이터 캐시와 데이터베이스를 업데이트한다.

비디오 스트리밍 절차

비디오 스트리밍이 이루어지는 절차를 논하기에 앞서 우리는 먼저 스트리밍 프로토콜(streaming protocol)이라는 개념을 알아야한다. 스트리밍 프로토콜은 비디오 스트리밍을 위해 데이터를 전송할 때 쓰이는 표준이다.

프로토콜은 여러가지가 있는데, 각 프로토콜의 동작 원리를 정확하게 이해하거나 그 이름들을 외울 필요는 없다. 구현 디테일에 해당하는 부분이기 때문이다. 다만 기억해야 하는 것은 프로토콜마다 지원하는 비디오 인코딩이 다르고 플레이어도 다르다는 것이다. 따라서 비디오 스트리밍 서비스를 설계할 때는 서비스의 용례에 맞는 프로토콜을 잘 골라야 한다.

비디오 스트리밍은 CDN을 통해서 이루어진다. 각 단말기마다 가장 가까운 CDN 에서 스트링밍이 이뤄지니 전송지연에대한 문제는 크게 일어나지 않는다.

3단계 - 상세 설계

개략적 설계안에서는 전체 시스템을 비디오 업로 드를 담당하는 부분과 비디오 스트리밍을 담당하는 부분으로 나눠 살펴봤다. 이번 절에서는 그 두 부분에 대한

최적화 방안
오류 처리 메커니즘
에 대해서 알아본다.

비디오 트랜스코딩

비디오를 생성하면, 생상한 단말에 따라 특정 포맷으로 동영상이 저장된다. 이 비디오가 다른 단말에서도 문제없이 재생되려면,

다른 단말과 호환되는 비트레이트(bitrate, 비디오를 구성하는 비트가 얼마나 빨리 처리되어야 하는지를 나타내는 단위) 로 저장되어야한다.

비트레이트가 높은 비디오 스트림을 정상 재생하려면 보다 높은 성능의 컴퓨팅 파워가 필요하고, 인터넷 회선 속도도 빨라야 한다.

그런데, 상당수의 단말과 브라우저는 특정 종류의 비디오 포맷만 지원한다. 따라서 호환성 문제를 해결하려면 하나의 비디오를 여러 포맷으로 인코딩해 두는것이 바람직하다.

이 외에도,

가공되지 않은 원본 비 디오(raw video)는 저장 공간을 많이 차지한다.
사용자에게 끊김 없는 비디오 재생을 보장하려면, 네트워크 대역폭에 따라 화질을 다르게 제공할 수 있어야한다.
모바일 단말의 경우 네트워크 상황이 수시로 달라질 수 있다. 비디오가 끊김 없이 재생되도록 하기 위해서는 비디오 화질을 자동으로 변경하거나 수동으로 변경할 수 있도록 하는 것이 바람직하다.

이런 특징들 때문에 트랜스코딩이 중요해진다.

인코딩 포맷

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

컨테이너(container): 비디오 파일, 오디오, 메타데이터를 담는 바구니 같은 것이다. 컨테이너 포맷은 파일 확장자로 구분할 수 있다.
코덱(codec): 비디오 화질은 보존하면서 파일 크기를 줄일 목적으로 고안된 압축 및 압축 해제 알고리즘이다.

Directed Acyclic Graph

비디오를 트랜스코딩할 때, 사용자마다 요구사항이 다양할 수 있다. 예를 들어

어떤 사람은 비디오 위에 워터마크(watermark)를 표시하고 싶어 할 수 있고
어떤 사람은 섬네일 이미지를 자기가 손수 만들어 쓰고 싶어 할 수 있고
어떤 사람은 고화질 비디오를 선호하는 반면 또 다른 어 떤 이는 저화질 비디오도 충분하다고 생각할 것 이다.

이처럼 각기 다른 유형의 비디오 프로세싱 파이프라인을 지원할 수 있어야한다.

그러면서도 처리 과정의 병렬성을 높이기 위해서는 적절한 수준의 추상화를 도입하여 클라 이언트 프로그래머로 하여금 실행할 작업(task)을 손수 정의할 수 있도록 해야 한다.

ex) 페이스북의 스트리밍 비디오 엔진은 유향 비순환 그래프 (DAG: Directed Acyclic Graph) 프로그래밍 모델을 도입,
작업을 단계별로 배열할 수 있도록 하여 해당 작업들이 순차적으로 또는 병렬적으로 실행될 수 있도록 하고 있다.

본 설계안에서도 이와 유사한 DAG 모델을 도입하여 유연성과 병렬성을 달성할 수 있도록 할 것이다!

비디오 작업

검사(inspection): 좋은 품질의 비디오인지, 손상은 없는지 확인하는 작업 이다.
비디오 인코딩(video encoding): 비디오를 다양한 해상도, 코덱, 비트레이트 조합으로 인코딩하는 작업이다.
썸네일(thumbnail): 사용자가 업로드한 이미지나 비디오에서 자동 추출된 이미지 썸네일을 만드는 작업
워터마크(watermark): 비디오에 대한 식별정보를 이미지 위에 오버레이 (overlay) 형태로 띄워 표시하는 작업이다.

아무튼 이런식으로 DAG 를 도입할 수 있다.

를 적용한 비디오 트랜스코딩 아키텍처

이 아키텍처는 다섯 개의 주요 컴포넌트로 구성된다.

전처리기(preprocessor)
DAG 스케줄러
자원 관리자(resource manager)
작업 실행 서버(resource worker)
임시 저장소(temporary storage)

이 아키텍처가 동작한 결과로 인코딩 된 비디오가 만들어진다.

전처리기

전처리기는 다음과 같은 일을 한다.

비디오 분할: 비디오 스트림을 GOP로 나누는 일. 오래된 단말이나 브라우저는 GOP 단위의 비디오 분할을 지원하지 않는데, 그런 경우 전처리기가 비디오 분할을 담당한다.
DAG 생성: 클라이언트 프로그래머가 작성한 설정 파일에 따라 DAG를 만들어낸다.
데이터 캐시: 전처리기는 GOP와 메타데이터를 임시 저장소에 저장해둔다. 비디오 인코딩이 실패하면 시스템은 이렇게 보관된 데이 터를 활용해 인코딩을 재개한다. (안정성 높아짐)

DAG 스케줄러

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

위의 그림에서는

첫 스테이지에서 비디오, 오디오, 메타데이터를 분리한다.
두 번째 스테이지에서는 해당 비디오 파일을 인코딩하고 썸네일을 추출하며, 오디오 파일 또한 인코딩한다.

자원 관리자

작업관리자는 어떤 작업을 어떤 서버에 할당할지를 결정하고 실행까지 관리하는 역할을 한다. 세 개의 큐와 작업 스케줄러(task scheduler)로 구성된다.

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

작업 서버

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

임시 저장소

임시 저장소 구현에는 여러 저장소 시스템을 활용할 수 있다. 어떤 시스템을 선택할 것이냐는 저장할 데이터의 유형, 크기, 이용 빈도, 데이터 유효기간 등 에 따라 달라진다.

ex)

메타데이터는 작업 서버가 빈번히 참조하는 정보 이고 그 크기도 작은 것이 보통이다. 따라서 메모리에 캐시
비디오/오디오 데이터는 BLOB 저장소에 두는 것이 바람직하다. (?!)

시스템 최적화

이제 속도, 안전성, 그리고 비용 측면에서 이 시스템을 최적화해보도록 하겠다.

속도

병렬 업로드 : 분할한 GOP를 병렬적으로 업로드하면 설사 일부가 실패해도 빠르게 업로드를 재개할 수 있다.
업로드 센터를 사용자 근거리에 지정 : 이를 위해서 본 설계안은 CDN을 업로드 센터로 이용한다.
모든 절차를 병렬화! : 이전에 우리가 설계한 절차에서는 이전 단계의 결과물을 입력으로 사용하여 만들어진다는 것을 알 수 있다. 이런 의존성이 있으면 병렬성을 높이기 어렵다.
이렇게 모듈 간 결합도를 낮추기 위해 메시지 큐를 도입할 수 있다.
-> 다운로드 모듈의 작업을 기다리는 대신, 메시지 큐에 보관된 이벤트 각각을 인코딩 모듈은 병렬적으로 처리할 수 있다.

안정성

미리 사인된 업로드 URL
허가받은(authorized) 사용자만이 올바른 장소에 비디오를 업로드할 수 있도록 하기 위해 미리 사인된(pre-signed) 업로드 URL을 이용한다.
비디오 저작권 관리: 다음 세 가지 선택지 가운데 하나를 채택할 수 있다.
1. 디지털 저작권 관리(DRM: Digital Rights Management) 시스템 도입
2. AES 암호화(encryption): 비디오를 암호화하고 접근 권한을 설정하는 방식 이다. 암호화된 비디오는 재생 시에만 복호화한다. 허락된 사용자만 암호화 된 비디오를 시청할 수 있다.
3. 워터마크

비용 최적화

CDN은 비싸다. 데이터가 클수록 더 비싸진다. 이 비용은 어떻게 낮출 수 있을까?

인기비디오만 CDN을 통해 재생하고, 그렇지 않은 비디오들은 비디오 서버에서 직접 재생한다.
인기가 없는 비디오는 인코딩 해둘 필요가 없을 수도 있다.
짧은 비디오라면 필요할 때 인코딩해서 재생해도 된다.
어떤 비디오는 특정 지역에서만 인기가 있으므로 해당 지역에서만 가지고 있어도 된다.
CDN을 직접 구축하고 인터넷 서비스 제공자(ISP: Internet Service Provider) 와 제휴한다.

이 모든 최적화는

콘텐츠 인기도
이용 패턴
비디오 크기

등의 데이터에 근거 한 것이다. 최적화를 시도하기 전에 시청 패턴을 분석하는 것은 중요하다.

오류 처리

회복 가능 오류(recoverable error): 몇 번 재시도(retry)하면 보통 해결된다. 하지만 계속해서 실패하고 복구가 어렵다 판단되면 클라이언트에게 적절한 오류코드를 반환한다.
회복 불가능 오류(non-recoverable error): 시스템은 해당 비디오에 대한 작업을 중단하고 클라이언트에게 적절한 오류 코드를 반환한다.

시스템 컴포넌트 각각에 발생할 수 있는 오류에 대한 전형적 해결 방법

업로드 오류: 몇회 재시도한다.
비디오 분할 오류: 낡은 버전의 클라이언트가 GOP 경계에 따라 비디오를

분할하지 못하는 경우라면 전체 비디오를 서버로 전송하고 서버가 해당 비

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

4단계 마무리

더 논의할 수 있는 이야기

API 계층의 규모 확장성 확보 방안: API 서버는 무상태 서버이므로 수평적 규모 확장이 가능하다는 사실을 언급
데이터베이스 계층의 규모 확장성 확보 방안: 다중화, 샤딩에 대해
라이브 스트리밍(live streaming)
우리가 한 건 라이브 스트리밍 시스템은 아니다. 차이점을 꼽자면
- 라이브 스트리밍의 경우에는 웅답지연이 좀 더 낮아야 한다. 따라서 스 트리밍 프로토콜 선정에 유의해야 한다.
- 라이브 스트리밍의 경우 병렬화 필요성은 떨어질 텐데, 작은 단위의 데이 터를 실시간으로 빨리 처 리해야 하기 때문이다.
- 라이브 스트리밍의 경우 오류 처리 방법을 달리해야 한다. 너무 많은 시 간이 걸리는방안은사용하기 어렵다.
비디오 삭제(takedown) 정책

가영

이전 포스트

[대규모 시스템 설계 기초] 9장. 웹 크롤러 설계

다음 포스트