Portfolio

문제 이해 및 설계 범위 확정 개략적 규모 추정 개략적 설계안 제시 및 동의 구하기 비디오 업로드 절차 비디오 업로드 메타데이터 갱신 비디오 스트리밍 절차 상세 설계 비디오 트랜스코딩 유향 비순환 그래프(DAG) 모델 비디오 트랜스코딩 아키텍처 전처리기 DAG 스케줄러 자원 관리자 작업 서버 임시 저장소 시스템 최적화 속도 최적화 : 비디오 병렬 업로드 속도 최적화 : 업로드 센터를 사용자 근거리에 지정 속도 최적화: 모든 절차를 병렬화 안전성 최적화 : 미리 사인된 업로드 URL 안전성 최적화 : 비디오 보호 비용 최적화 오류 처리

문제 이해 및 설계 범위 확정

중요한 기능 : 비디오 업로드 & 비디오 시청

지원하는 클라이언트 : 모바일 앱, 웹 브라우저, 스마트 TV

월간 능동 사용자 수 : 5백만

사용자가 평균적으로 이 제품에 소비하는 시간 : 30분

다국어 지원 필요 여부 : 어떤 언어로도 이용 가능해야 함

어떤 비디오 해상도 지원 ? : 현존하는 비디오 종류와 해상도를 대부분 지원해야 함

암호화 필요

비디오 파일 크기 제한은 1GB

개략적 규모 추정

일간 능동 사용자(DAU) 수: 5백만

한 사용자는 하루에 평균 5개의 비디오를 시청

10%의 사용자가 하루에 1비디오 업로드

비디오 평균 크기는 300MB

비디오 저장을 위해 매일 새로 요구되는 저장 용량 = 5백만 X 10% X 300MB = 150TB

CDN 비용 : 5백만 X 5비디오 X 0.3GB X $0.02 = $150,000

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

CDN과 blob 스토리지는 기존 클라우드 서비스를 활용하는 이유

시스템 설계 면접은 모든 것을 밑바닥부터 만드는 것과 관계 x. 주어진 시간 안에 적절한 기술을 골라 설계를 마치는 것이, 그 기술 각각이 어떻게 동작 하는지 상세히 설명하는 것보다 중요함

규모 확장이 쉬운 BLOB 저장소나 CDN을 만드는 것은 지극히 복잡할 뿐 아니라 많은 비용이 드는 일임

비디오 업로드 절차

컴포넌트 구성

사용자 : 컴퓨터나 모바일 폰, 혹은 스마트 TV를 통해 유튜브를 시청하는 이용자

로드밸런서 : API 서버 각각으로 고르게 요청을 분산하는 역할을 담당

API 서버 : 비디오 스트리밍을 제외한 다른 모든 요청을 처리

메타데이터 데이터베이스 : 비디오의 메타데이터를 보관. 샤딩과 다중화를 적용하여 성능 및 가용성 요구사항 충족

메타데이터 캐시 : 성능을 높이기 위해 비디오 메타데이터와 사용자 객체는 캐시

원본 저장소 : 원본 비디오를 보관할 대형 이진 파일 저장소(BLOB) 시스템. 이진 데이터를 하나의 개체로 보관하는 데이터베이스 관리 시스템

트랜스코딩 서버 : 비디오 트랜스코딩은 비디오 인코딩이라 부르기도 하는 절차로, 비디오의 포맷(MPEG, HLS 등)을 변환하는 절차. 단말이나 대역폭 요구사항에 맞는 최적의 비디오 스트림을 제공하기 위해 필요

트랜스코딩 비디오 저장소 : 트랜스 코딩이 완료된 비디오를 저장하는 BLOB 저장소

cdn : 비디오를 캐시하는 역할. 비디오 스트리밍이 이를 통해 이루어짐

트랜스코딩 완료 큐 : 비디오 트랜스코딩 완료 이벤트들을 보관할 메시지 큐

트랜스코딩 완료 핸들러 : 트랜스코딩 완료 큐에서 이벤트 데이터를 꺼내어 메타데이터 캐시와 데이터베이스를 갱신할 작업 서버들

비디오 업로드

비디오를 원본 저장소에 업로드

트랜스코딩 서버는 원본 저장소에서 해당 비디오를 가져와 트랜스코딩 시작

트랜스코딩 완료 시, 아래 두 절차가 병렬적으로 수행

완료된 비디오를 트랜스코딩 비디오 저장소로 업로드
트랜스코딩 완료 이벤트를 트랜스코딩 완료 큐에 넣음

트랜스코딩이 끝난 비디오를 CDN에 올림
완료 핸들러가 이벤트 데이터를 큐에서 꺼냄
완료 핸들러가 메타데이터 DB와 캐시를 갱신

API 서버가 단말에게 비디오 업로드가 끝나서 스트리밍이 준비가 되었음을 알림

메타데이터 갱신

원본 저장소에 파일이 업로드되는 동안, 단말은 병렬적으로 비디오 메타데이터(파일 이름, 크기, 포맷 등의 정보) 갱신 요청을 API 서버에 보내고 이 정보로 메타데이터 캐시와 데이터베이스 업데이트함

비디오 스트리밍 절차

비디오 재생버튼 누르면 스트리밍은 바로 시작되며 비디오 다운로드가 완료되어야 영상을 볼 수 있다거나 하는 불편함은 없다.

스트리밍 프로토콜 : 비디오 스트리밍을 위해 데이터를 전송할 때 쓰이는 표준화된 통신 방법

MPEG-DASH. MPEG는 “Moving Picture Experts Group”의 약어이며, DASH는 “Dynamic Adaptive Streaming over HTTP”의 약어

애플(Apple) HLS. HLS는 “HTTP Live Streaming”의 약어

마이크로소프트 스무드 스트리밍(Microsoft Smooth Streaming)

어도비 HTTP 동적 스트리밍 (Adobe HTTP Dynamic Streaming, HDS)

비디오는 CDN에서 바로 스트리밍되며, 사용자의 단말에 가장 가까운 CDN 에지 서버가 비디오 전송을 담당함

상세 설계

비디오 트랜스코딩

비디오를 녹화하면 단말(보통 전화나 카메라)은 해당 비디오를 특정 포맷으로 저장함

이 비디오가 다른 단말에서도 순조롭게 재생되려면 다른 단말과 호환되는 비트레이트(bitrate)와 포맷으로 저장되어야 함. 비트레이트는 비디오를 구성하는 비트가 얼마나 빨리 처리되어야 하는지를 나타내는 단위로 비트레이트가 높은 비디오는 일반적으로 고화질 비디오

중요한 이유

가공되지 않은 원본 비디오는 저장 공간을 많이 차지함(초당 60프레임의 HD 비디오는 수백 GB의 저장공간 차지할 수 있음)

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

사용자에게 끊김 없는 고화질 비디오 재생을 보장하려면

네트워크 대역폭 충분치 않은 사용자 → 저화질 비디오
대역폭이 충분한 사용자 → 고화질 비디오

모바일 단말의 경우 네트워크 상황이 수시로 달라질 수 있음. 비디오가 끊김 없이 재생되도록 하기 위해서는 비디오 화질을 자동으로 변경하거나 수동으로 변경할 수 있도록 하는 것이 바람직함

인코딩 포맷의 두 구성요소

컨테이너 : 비디오 파일, 오디오, 메타데이터를 담는 바구니 같은 것. 컨테이너 포맷은 .avi, .mov, .mp4 같은 파일 확장자 보면 알 수 있음

코덱(codec) : 비디오 화질은 보존하며 파일 크기 줄일 목적으로 고안된 압축 및 압축해제 알고리즘 (H.264, VP9, HEVC 가 가장 많이 사용되는 비디오 코덱)

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

각기 다른 유형의 비디오 프로세싱 파이프라인을 지원하며 병렬성을 높이기 위해 적절한 수준의 추상화를 도입함

검사 : 좋은 품질의 비디오인지, 손상은 없는지 확인하는 작업

비디오 인코딩 : 비디오를 다양한 해상도, 코덱, 비트레이트 조합으로 인코딩하는 작업

섬네일 : 사용자가 업로드한 이미지나 비디오에서 자동 추출된 이미지로 섬네일 만드는 작업

워터마크 : 비디오에 대한 식별정보를 이미지 위에 오버레이 형태로 띄워 표시하는 작업

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

전처리기

비디오 분할 : 비디오 스트림을 GOP(Group of Pictures)라고 불리는 단위로 쪼갬. GOP는 특정 순서로 배열된 프레임 그룹

DAG 생성 : 클라이언트 프로그래머가 작성한 설정 파일에 따라 DAG를 만들어냄

eg: 다운로드 → 트랜스코딩

데이터 캐시 : 전처리기는 분할된 비디오의 캐시이기도 함. 안정성을 높이기 위해 전처리기는 GOP와 메타데이터를 임시 저장소에 보관함. 비디오 인코딩이 실패하면 시스템은 이렇게 보관된 데이터를 활용해 인코딩을 재개

DAG 스케줄러

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

자원 관리자

자원 배분을 효과적으로 수행하는 역할을 담당. 세 개의 큐와 작업 스케줄러로 구성됨

작업 큐 : 실행할 작업이 보관되어 있는 우선순위 큐

작업 서버 큐 : 작업 서버의 가용 상태 정보가 보관되어 있는 우선순위 큐

실행 큐 : 현재 실행 중인 작업 및 작업 서버 정보가 보관되어 있는 큐

실행큐가 있는 이유?

작업 스케줄러 : 최적의 작업/서버 조합을 골라, 해당 작업 서버가 작업을 수행하도록 지시하는 역할을 담당

작업 서버

DAG에 정의된 작업을 수행함. 작업 종류(워터마크, 인코딩, 썸네일, 병합,,)에 따라 작업 서버도 구분하여 관리

임시 저장소

어떤 시스템을 선택할 것이냐는 저장할 데이터의 유형, 크기, 이용 빈도, 데이터 유효기간 등에 따라 달라짐

예로, 메타데이터는 작업 서버가 빈번히 참조하는 정보이고 그 크기도 작은 것이 보통임 → 메모리에 캐시
비디오/오디오 데이터는 BLOB 저장소에 두는 것이 바람직

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

시스템 최적화

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

하나의 비디오를 GOP 경계에 따라 분할하고 병렬적으로 업로드하기

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

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

업로드 속도를 개선하기 위해 업로드 센터를 여러 곳에 두는 것

본 설계안에서는 CDN을 업로드 센터로 이용

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

메시지 큐 도입전에는 인코딩 모듈이 다운로드 모듈의 작업이 끝나기를 기다려야 했으나, 도입후에는 병렬적으로 처리가 가능함

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

허가받은 사용자만이 올바른 장소에 비디오를 업로드할 수 있도록 하기 위해, 미리 사인된(pre-signed) 업로드 URL을 이용

API 서버로 POST /upload 요청

미리 사인된 URL(해당 URL이 가리키는 객체에 대한 접근 권한이 주어진 상태) 반환

해당 url의 위치에 비디오 업로드

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

AES 암호화 : 비디오를 암호화하고 접근 권한을 설정하는 방식. 암호화된 비디오는 재생 시에만 복호화. 허락된 사용자만 암호화된 비디오 시청 가능

워터마크 : 비디오 위에 소유자 정보를 포함하는 이미지 오버레이를 올리는 것. 회사 로고나 이름 등을 이 용도에 사용할 수 있음

비용 최적화

CDN 비용 최적화 어떻게??

유튜브의 비디오 스트리밍은 롱테일 분포를 따라서, 인기 있는 비디오는 빈번히 재생되는 반면, 나머지는 거의 보는 사람이 없음. 이에 착안하여 몇 가지 최적화를 시도

인기 비디오는 CDN을 통해 재생하되 다른 비디오는 비디오 서버를 통해 재생

인기가 별로 없는 비디오는 인코딩 할 필요가 없을 수도 있음. 짧은 비디오라면 필요할 때 인코딩하여 재생할 수 있음

어떤 비디오는 특정 지역에서만 인기가 높아, 이런 비디오를 다른 지역에 옮길 필요가 없음

CDN 직접 구축하기

이 모든 최적화는 콘텐츠 인기도, 이용 패턴, 비디오 크기 등의 데이터에 근거한 것. 최적화를 시도하기 전에 시청 패턴을 분석하는 것이 중요함

오류 처리

회복 가능 오류 : 특정 비디오 세그먼트를 트랜스코딩하다 실패했다든가 하는 오류는 회복 가능한 오류에 속함. 몇 번 재시도하면 해결되지만, 계속 실패하고 복구가 어렵다 판단되면 클라이언트에게 적절한 오류 코드를 반환해야 함

회복 불가능 오류 : 비디오 포맷이 잘못되었다거나 하는 회복 불가능한 오류가 발견되면 시스템은 해당 비디오에 대한 작업을 중단 & 클라이언트에 오류 코드 반환해야 함

업로드 오류 : 몇 회 재시도

비디오 분할 오류 : 낡은 버전의 클라이언트가 GOP 경계에 따라 비디오를 분할하지 못하는 경우라면 전체 비디오를 서버로 전송하고 서버가 해당 비디오 분할을 처리

트랜스코딩 오류 : 재시도

전처리 오류 : DAG 그래프 재생성

DAG 스케줄러 오류 : 작업을 다시 스케줄링

자원 관리자 큐에 장애 발생 : 사본을 이용

작업 서버 장애 : 다른 서버에서 해당 작업 재시도

API 서버 장애 : API 서버는 무상태 서버이므로 신규 요청은 다른 API 서버로 우회됨

메타데이터 캐시 서버 장애 : 데이터는 다중화되어 있으므로 다른 노드에서 데이터를 여전히 가져올 수 있음

메타데이터 데이터베이스 서버 장애

주 서버가 죽었다면 부 서버 가운데 하나를 주 서버로 교체
부 서버가 죽었다면 다른 부 서버를 통해 읽기 연산을 처리하고 죽은 서버는 새것으로 교체

14장 유튜브 설계