개요
유튜브(Youtube)나 넷플릭스(Netflix), 훌루(Hulu) 같은 비디오 플랫폼을 설계해보자. 유튜브 시스템은 콘텐츠 창작자가 비디오를 올리고 시청자는 재생을 누르는 언뜻 보기에는 간단해보이는 시스템이지만, 이면에는 엄청나게 복잡한 기술이 숨어있다.
유튜브의 지표를 살펴보면,
•
월간 능동 사용자 수 : 2십 억 (2 billion)
•
매일 재생되는 비디오 수 : 5십 억 (5 billion)
•
미국 성인 중 73%가 유튜브 이용
•
5천만 (50 million) 명의 창작자
•
광고 수입 150 억 달러 (2019년 기준)
•
모바일 인터넷 트래픽 중 37%를 점유
•
80개 언어로 이용 가능
이와 같은 엄청난 규모의 전 지구적 서비스이다.
1단계 문제 이해 및 설계 범위 확정
설계 범위 좁히기
유튜브는 단순히 비디오를 보는 것 말고도, 댓글을 남기거나, 비디오를 공유하거나, 좋아요 버튼을 누르거나, playlist에 저장하거나, 채널을 구독할 수 있다. 이 모든 기능을 45~60분 짜리 면접에서 설계하는 것은 불가능하다. 그러니 면접관에게 적절한 질문을 던져 설계 범위를 좁히자.
지원자: 어떤 기능이 가장 중요한가요?
면접관: 비디오를 올리는 기능과 시청하는 기능입니다.
지원자: 어떤 클라이언트를 지원해야 하나요?
면접관: 모바일 앱, 브라우저, 스마트 TV 입니다.
지원자: 일간 능동 사용자 수는 몇 명입니까?
면접관: 5백만(5 million) 입니다.
지원자: 사용자가 이 제품군에 평균적으로 소비하는 시간은 얼마인가요?
면접관: 30분입니다.
지원자: 다국어 지원이 필요한가요?
면접관: 네. 어떤 언어로도 이용 가능해야 합니다.
지원자: 어떤 비디오 해상도를 지원해야할까요?
면접관: 현존하는 비디오 종류와 해상도를 대부분 지원해야 합니다.
지원자: 암호화가 필요할까요?
면접관: 네.
지원자: 비디오 파일 크기에 제한이 있습니까?
면접관: 작은 비디오,혹은 중간 크기 비디오에 초점을 맞추도록 합시다. 비디오 크기는 최대 1GB로 제한합니다.
지원자: 아마존이나 구글, 마이크로소프트가 제공하는 클라우드 서비스를 활용해도 될까요?
면접관: 좋은 질문입니다. 모든 걸 바닥부터 쌓아 올리는 것은 대부분 회사에게는 비현실적인 일이죠. 활용할 수 있다면 하는 것이 바람직할 것입니다.
Plain Text
복사
이를 정리하여, 우리가 설계해야할 비디오 스트리밍 기능은 다음과 같다.
•
빠른 비디오 업로드
•
원활한 비디오 재생
•
재생 품질 선택 기능
•
낮은 인프라 비용
•
높은 가용성과 규모 확장성, 안정성
•
모바일 앱, 웹 브라우저, 스마트 TV 클라이언트 지원
개략적 규모 측정
•
일간 능동 사용자(DAU) : 5백만 (5 million)
•
한 사용자는 하루에 평균 5개의 비디오 시청
•
10% 사용자가 하루에 1개의 비디오 업로드
•
비디오 평균 크기는 300MB
•
비디오 저장을 위해 매일 새로 요구되는 저장 용량 : 5백만 명 * 10% * 300MB = 150TB
•
CDN 비용
◦
클라우드 CDN을 통해 비디오를 서비스할 경우, CDN에서 응답되는 데이터의 양에 따라 과금
◦
아마존 클라우드프론트(CloudFront)를 CDN 솔루션으로 사용할 경우, 100% 트래픽이 미국에서 발생하면 1GB당 $0.02의 요금 발생
(문제 단순화를 위해 비디오 스트리밍 비용만 계산)
◦
매일 발생하는 요금 : 5백만 명 * 5 비디오 * 0.3GB * 0.02$/GB = $150,000
추정된 계산 결과를 보면 CDN 비용이 엄청나게 많이 발생한다. 이 비용을 줄이는 방법은 상세 설계 때 자세히 알아보자.
2단계 개략적 설계안 제시 및 동의 구하기
기존 클라우드 서비스를 사용하는게 가능하다면, CDN과 BLOB 스토리지는 기존 클라우드 서비스를 사용할 것이다. 새로 만들지 않는 이유는 다음과 같다.
•
시스템 설계 면접은 모든 것을 밑바닥부터 만드는게 목적이 아니라, 주어진 시간 안에 적절한 기술을 골라 설계를 마치는 것이 중요하다.
•
규모 확장이 쉬운 BLOB 저장소나 CDN을 만드는 것은 상당히 복잡할 뿐만 아니라, 많은 비용이 드는 일이다. 넷플릭스나 페이스북 같은 큰 회사도 스스로 구축하지 않는다.
이런 점을 고려했을 때 우리가 설계할 유튜브 시스템은 개략적으로 다음과 같이 구성된다.
•
사용자 단말 : 컴퓨터, 모바일 폰, 스마트 TV를 통해 유튜브를 시청할 수 있는 클라이언트
•
CDN : 비디오를 CDN에 저장 후, 사용자가 비디오 재생 시 CDN에서 스트리밍 수행
•
API 서버 : 비디오 스트리밍을 제외한 모든 요청은 API가 처리(피드 추천, 비디오 업로드 URL 생성, 메타데이터 저장, 사용자 가입 등)
이런 설계안에서 면접관이 다음의 두 영역을 설계할 것을 요청하였다고 가정하고 설계를 진행하자.
•
비디오 업로드 절차
•
비디오 스트리밍 절차
비디오 업로드 절차
비디오 업로드 절차의 설계안은 위와 같다.
•
사용자 : 컴퓨터나 모바일 폰, 스마트 TV를 통해 유튜브를 시청하는 이용자
•
로드밸런서 : API 서버 각각으로 고르게 요청을 분산하는 역할을 담당
•
API 서버 : 비디오 스트리밍을 제외한 다은 모든 요청을 처리
•
메타데이터 데이터베이스 : 비디오의 메타데이터를 보관
•
메아테이터 캐시 : 성능을 높이기 위해 비디오 메타데이터와 사용자 객체 캐시
•
원본 저장소 : 원본 비디오를 보관할 대형 이진 파일(BLOB) 저장소 시스템
•
트랜스코딩 서버 비디오 트랜스코딩 절차를 수행
•
트랜스코딩 비디오 저장소 : 트랜스코딩이 완료된 비디오를 저장하는 BLOB 저장소
•
CDN : 비디오를 캐시하는 역할
•
트랜스코딩 완료 큐 : 비디오 트랜스코딩 완료 시 이벤트 보관하는 메세지 큐
•
트랜스코딩 완료 핸들러 : 트랜스코딩 완료 큐에서 이벤트를 꺼내어 메타데이터 캐시와 데이터베이스를 갱신할 작업 서버
비디오 트랜스코딩
비디오 인코딩이라고도 불리는 절차로, 비디오의 포맷(MPEG, HLS 등)을 변환하는 절차이다. 단말이나 대역폭 요구사항에 맞는 최적의 비디오 스트림을 제공하기 위해 필요하다.
그러면 이러한 컴포넌트들에서 비디오 업로드가 어떻게 처리되는지를 알아보자. 기본적으로 비디오 업로드는 다음의 두 프로세스가 병렬적으로 수행된다고 보면 된다.
A. 비디오 업로드
B. URL 크기, 해상도, 포맷, 사용자 정보 등의 비디오 메타데이터 갱신
프로세스 A. 비디오 업로드
비디오 업로드하는 프로세스는 다음의 순서대로 이루어진다.
1.
비디오를 원본 저장소에 업로드
2.
트랜스코딩 서버가 원본 저장소에서 해당 비디오를 가져와 트랜스코딩 시작
3.
트랜스코딩 완료 시 다음 두 절차 병렬 수행
a.
트랜스코딩 완료된 비디오를 트랜스코딩 비디오 저장소로 업로드
b.
트랜스코딩 완료 이벤트를 트랜스코딩 완료 큐에 넣음
i.
트랜스코딩이 끝난 비디오를 CDN에 업로드
ii.
완료 핸들러에서 이벤트 데이터를 큐에서 꺼내어 메타데이터 갱신(데이터베이스와 캐시)
4.
API 서버가 단말에게 비디오 업로드가 끝났음을 알림
프로세스 B. 메타데이터 갱신
원본 저장소에 파일이 업로드되는 동안, 단말이 병렬적으로 비디오 메타데이터 갱신 요청을 API 서버에 보낸다. 이 요청에는 파일 이름, 크기, 포맷 등의 메타데이터 정보가 들어있고, API 서버는 이 정보를 통해 메타데이터 캐시와 데이터베이스에 업데이트한다.
비디오 스트리밍 절차
유튜브에서 비디오 재생 버튼을 누르면 단말에 비디오 다운로드하는 과정이 완료되지 않더라도 영상을 볼 수 있다. 이것이 가능한 이유는 원격지의 비디오로부터 지속적으로 비디오 스트림을 전송 받아 영상을 재생하는 스트리밍을 통해 영상을 재생하기 때문이다.
스트리밍
일반적으로 파일은 전체를 내려 받은 후 열어본다. 하지만 용량이 큰 오디오 혹은 비디오를 이런 식으로 처리하면 오래 걸리기 때문에 이를 처리하기 위해 스트리밍이 고안되었다.
스트리밍을 처리하는 과정은, 미디어 파일을 패킷이라 부르는 작은 데이터 조각으로 나누어 순차적으로 클라이언트로 보내는데, 클라이언트는 이를 받아 원래의 미디어 파일로 복원한다.
스트리밍의 용어를 정리하면 다음과 같다.
•
코덱(Codec) : coder와 decoder의 합성어로, 효율적으로 스트리밍을 하기 위해 특정 코덱을 사용해 미디어 파일을 압축하고 수신측에서 같은 코덱으로 복원
◦
오디오 인코딩 : MP3, AAC, Opus, Vorbis 등의 압축 알고리즘으로 오디오 파일의 크기를 줄이는 과정
◦
비디오 인코딩 : H.264/AVC, H.265/HEVC, VP8, VP9, AV1 등의 비디오 압축 알고리즘으로 비디오 파일의 크기를 줄이는 과정
•
스트리밍 프토로콜 : 스트리밍으로 데이터를 전송할 때 사용되는 표준화된 규약
◦
MPEG-DASH(Dynamic Adaptive Streaming over HTTP)
▪
국제 표준(ISO/IEC 23009-1)으로 채택된 스트리밍 프로토콜
▪
코덱 의존적이지 않아, 어떤 인코딩 방식으로 하든 전부 지원
▪
매니페스트 : MPD (XML 형식)
▪
세그먼트 컨테이너 : MP4, WebM, MPEG-2 TS
◦
HLS(HTTP Live Streaming)
▪
Apple이 개발한 스트리밍 프로토콜로 RFC 8216 표준으로 채택
▪
H.264 혹은 H.265 방식으로 인코딩된 비디오만 지원
▪
매니페스트 : M3U8 (텍스트 형식)
▪
세그먼트 컨테이너 : MPEG-2 TS, MP4 (fMP4)
◦
HDS(Hitachi Data System)
▪
어도비에서 개발한 스트리밍 프로토콜
▪
표준으로 채택되지 않았고 거의 사용되지 않음
▪
매니페스트 : F4M (XML 형식)
▪
세그먼트 컨테이너 : F4V/F4F (Flash 컨테이너)
◦
MSS(Microsoft Smooth Streaming)
▪
마이크로소프트에서 만든 스트리밍 프로토콜
▪
표준으로 채택되지 않았고 일부 레거시 시스템에서 사용 중
▪
매니페스트 : ISM (XML 형식)
▪
세그먼트 컨테이너 : ISMV/ISMA (Fragmented MP4)
•
매니페스트(manifest) 파일 : 스트림 데이터를 조립하기 위한 지침 파일로, 동영상 세그먼트의 순서, 오디오 파일 로드 방식, 자막이 저장된 위치 등을 포함하고 있다.
•
버퍼링(buffering) : 스트리밍 클라이언트는 인터넷 연결이 잠시 중단되어도 계속 재생될 수 있도록 몇 초 분량의 스트림을 미리 로드하는데, 이를 버퍼링이라 부른다.
•
비트레이트(bitrate) :
◦
비트레이트는 비디오를 구성하는 비트가 얼마나 빨리 처리되어야 하는 지를 나타내는 단위
◦
비트레이트가 높은 비디오는 일반적으로 고화질이며, 비트레이트가 높은 비디오 스트림을 재생하려면 높은 성능의 컴퓨팅 파워와 빠른 인터넷 속도가 필요
버퍼링이나 해상도 조절, 비트레이트 조절 등 사용자의 환경에 맞춘 최적화를 통해 효율적으로 스트리밍 할 수 있다.
스트리밍은 크게 Live streaming과 on-demand streaming 두 가지로 구분된다.
•
Live streaming
◦
스트리밍을 통해 녹화와 동시에 실시간으로 전송되는 비디오를 말한다.
◦
녹화되고 있는 영상을 스트리밍 가능한 영상으로 변환하는 비디오 캡처 카드가 포함된 카메라를 통해 촬영되어야 한다.
•
on-demand streaming
◦
VOD(Video On-Demand) 라고도 불리며, 사용자가 원하는 시간에 비디오 콘텐츠를 시청할 수 있는 디지털 미디어 배포 시스템을 말한다.
◦
업로드 이후에도 편집이 가능하기 때문에, 트랜스코딩이나 영상 품질에 따른 후 개선 작업이 가능하다.
라이브 스트리밍 vs 실시간 스트리밍
라이브 스트리밍은 녹화하는 내용을 인터넷으로 전송하지만, 기본적으로 인코딩 → CDN → 클라이언트의 스트리밍 과정을 동일하게 진행하기 때문에 지연시간이 존재한다.
반면 실시간 스트리밍은 P2P나 직접 연결을 통해 즉시 데이터를 전송하기 때문에 지연시간이 매우 낮다.
구분 | 라이브 스트리밍 | 실시간 스트리밍 |
지연시간 | 15-45초 | 100ms-1초 |
주요 프로토콜 | HLS, MPEG-DASH | WebRTC, RTMP |
네트워크 | TCP 기반 | UDP 기반 |
주요 용도 | 방송 | 화상통화, 게임 |
품질 우선순위 | 품질 > 속도 | 속도 > 품질 |
예시 | Youtube Live | Zoom 화상회의 |
최근 두 기술을 하이브리드로 사용하기도 하고, 저지연 기술로 두 방식의 경계가 흐려지고 있음
위 설명에서도 알 수 있듯, 각 스트리밍 프로토콜마다 비디오 인코딩과 플레이 방식도 다르다. 때문에 비디오 스트리밍 서비스를 설계할 때는 서비스의 용례에 맞는 프로토콜을 잘 골라야한다.
비디오 스트리밍 절차
우리가 설계한 시스템에서 비디오는 CDN에서 바로 단말로 스트리밍된다.
사용자의 단말에서 가장 가까운 CDN 서버(edge server)에서 비디오를 전송하여, 비디오를 전송할 때의 전송지연은 아주 낮다.
3단계 상세 설계
비디오 업로드 부분과 비디오 스트리밍 부분을 나누어 살펴보았는데, 두 부분에 대한 최적화 방안과 설계를 조금 더 다듬고 오류 처리 매커니즘에 대해서도 살펴보자.
비디오 트랜스코딩
비디오를 녹화한다면 단말(전화나 카메라)에 따라 비디오를 특정 포맷을 저장하게 된다. 이 비디오가 다른 단말에서도 정상적으로 재생되려면, 해당 단말과 호환되는 비트레이트(bitrate)와 포맷으로 저장되어야 한다. 이를 위해 비디오 트랜스코딩을 수행한다.
비디오 트랜스코딩은 다음과 같은 이유로 중요하다.
•
가공되지 않은 원본 비디오(raw video)는 저장 공간을 많이 차지한다.(초당 60프레임으로 녹화된 HD 비디오는 수백 GB 공간을 차지)
•
상당수의 단말과 브라우저는 특정 종류의 비디오 포맷만 지원한다. 호환성 문제가 없으려면, 하나의 비디오를 여러 포맷으로 인코딩해두는 것이 바람직하다.
•
사용자에게 끊김 없은 고화질 비디오 재생을 보장하려면, 네트워크 대역폭이 충분하지 않은 사용자는 저화질 비디오를 제공하고 대역폭이 충분한 사용자에게는 고화질 비디오를 제공할 필요가 있다.
•
모바일 단말의 경우 네트워크 상황이 수시로 달라질 수 있는데, 이런 환경을 위해 비디오 화질을 자동으로 변경하거나 수동으로 변경할 수 있어야 한다.
비디오의 인코딩 포맷은 아주 많지만, 그 대부분은 다음의 두 부분으로 구성되어있다.
•
컨테이너 : 비디오 파일, 오디오, 메타데이터를 담는 저장 공간으로, .avi, .mov, .mp4 등 파일 확장자를 보면 컨테이너 포맷을 알 수 있다.
•
코덱 : 비디오 화질은 보존하면서 파일 크기를 줄이기 위해 고안된 압축 및 압축 해제 알고리즘이다. 비디오 코덱 중에서는 H.264, VP9, HEVC가 가장 많이 사용된다.
유향 비순환 그래프(DAG) 모델
비디오를 트랜스코딩하는 것은 컴퓨팅 자원도 많이 소모하고, 시간도 많이 든다. 추가로 비디오 위에 워터마크를 추가한다던가, 섬네일 이미지를 손수 만든 이미지로 한다던가, 고화질을 선호하거나 등등, 콘텐츠 창작자는 각자만의 비디오 프로세싱 요구사항을 가지고 있다. 이처럼 각기 다른 유형의 비디오 프로세싱 파이프라인을 지원하면서도 처리 과정의 병렬성을 높이기 위해서는, 적절한 수준의 추상화를 도입하여 클라이언트 프로그래머가 실행할 작업(task)를 손수 정의할 수 있도록 해야한다.
예를 들면, 페이스북의 비디오 스트리밍 엔진은 유향 비순환 그래프(DAG, Direct Acyclic Graph) 모델을 도입하여, 작업을 단계별로 배열하여 순차적 혹은 병렬적으로 실행될 수 있도록 한다. 우리도 이와 유사한 DAG 모델을 도입하여 유연성과 병렬성을 달성할 것이다.
위 그림에서 원본 비디오는 비디오, 오디오, 메타데이터의 세 부분으로 나뉘어 처리된다. 그 중 비디오에 적용되는 작업은 다음과 같다.
•
검사(inspection) : 좋은 품질의 비디오인지, 손상은 없는지 확인하는 작업
•
비디오 인코딩 : 비디오를 다양한 해상도, 코덱, 비트레이트 조합으로 인코딩하는 작업
•
섬네일(thumbnail) : 사용자가 업로드한 이미지나 비디오에서 자동 추출된 이미지로 섬네일을 만드는 작업
•
워터마크(watermark) : 비디오에 대한 식별정보를 이미지 위에 오버레이(overlay) 형태로 띄워 표시하는 작업
비디오 트랜스코딩 아키텍처
비디오 트랜스코딩 아키텍처는 이와 같고, 전처리기, DAG 스케줄러, 자원 관리자, 작업 실행 서버, 임시 저장소의 다섯 개의 주요 컴포넌트로 구성된다. 이 아키텍처에 따라 동작하여 인코딩된 비디오가 생성된다.
전처리기(preprocessor)
전처리기는 다음의 3가지 작업을 수행한다.
1.
비디오 분할 : 비디오 스트림을 GOP라고 불리는 단위로 쪼갠다.
GOP(Group of Pictures)
GOP는 특정 순서로 배열된 프레임(frame) 그룹이다. 하나의 GOP는 몇 초정도 길이로, 각각 독립적으로 재생 가능하다. 오래된 단말이나 브라우저는 GOP 단위의 비디오 분할을 지원하지 않아, 그 경우 전처리기가 비디오 분할을 대신한다.
2.
DAG 생성 : 클라이언트 프로그래머가 작성한 설정 파일에 따라 DAG를 만든다. 아래는 두 개의 설정 파일로 생성된 DAG이다.
3.
데이터 캐시 : 안정성을 높이기 위해 분할된 비디오를 캐싱하여, GOP와 메타데이터를 임시 저장소에 보관한다. 비디오 인코딩 실패 시 이렇게 보관된 캐시를 활용해 인코딩을 재개한다.
DAG 스케줄러
DAG 스케줄러가 DAG 그래프를 몇 단계(stage)로 분할하여, 각각의 stage를 자원 관리자의 작업 큐에 넣는다.
위 그림은 하나의 DAG를 2개의 작업 단계(state)로 쪼갠 예시인데, 1단계에서 비디오, 오디오, 메타데이터를 분리하고, 2단계에서 비디오와 오디오를 인코딩하고 섬네일을 추출한다.
자원 관리자(resource manager)
자원 관리자는 세 개의 큐와 작업 스케줄러로 구성되어, 자원을 효과적으로 배분하는 역할을 수행한다.
•
작업 큐 : 실행할 작업이 보관되어 있는 우선순위 큐
•
작업 서버 큐 : 작업 서버의 가용 상태 정보가 보관되어 있는 우선순위 큐
•
실행 큐 : 현재 실행 중인 작업 및 작업 서버 정보가 보관되어 있는 큐
•
작업 스케줄러 : 최적의 작업-서버 조합을 골라, 해당 작업 서버가 작업을 수앻라도록 지시
작업 관리자는 아래의 순서로 동작한다.
1.
작업 큐에서 가장 높은 우선순위의 작업 꺼내기
2.
해당 작업을 실행할 적합한 작업 서버 선택
3.
선택된 작업 서버에 해당 작업을 지시
4.
해당 작업이 어떤 서버에 할당되었는지 실행 큐에 넣기
5.
작업 서버에서 작업이 완료되면 실행 큐에서 제거
작업 서버
작업 서버는 DAG에 정의된 작업을 수행하는데, 작업 종류에 따라 작업 서버도 구분하여 관리한다.
임시 저장소
임시 저장소는 저장할 데이터의 유형, 크기, 이용 빈도, 유효기간 등을 고려하여 여러 저장소 시스템을 활용할 수 있다. 예를 들면, 메타데이터를 작업 서버가 자주 참조하고 정보의 크기가 작기 때문에, 메모리에 캐시해두면 좋다. 하지만 비디오/오디오는 데이터가 크기 때문에 BLOB 저장소에 두는 것이 바람직하다.
임시 저장소에 보관된 데이터는 비디오 프로세싱이 완료되면 삭제한다.
인코딩된 비디오
인코딩 파이프라인의 처리 결과로 인코딩된 비디오가 생성된다.
시스템 최적화
비디오를 업로드하는 과정과 스트리밍, 트랜스코딩 절차를 설계했으니, 이제 속도, 안전성, 비용 측면에서 시스템을 최적화해보자.
속도 최적화 : 비디오 병렬 업로드
비디오 전부를 한 번의 업로드로 올리는 것은 비효율적이니, 작은 GOP로 분할하여 업로드 할 수 있다.
이렇게 분할하여 병렬적으로 업로드하면, 일부가 실패하더라도 빠르게 재개할 수 있다. 따라서 비디오를 GOP 경계에 맞춰 분할하는 작업을 단말이 수행하여 업로드 속도를 높일 수 있다.
속도 최적화: 업로드 센터를 사용자 근거리에 지정
업로드 센터를 세계 곳곳에 두고, 업로드를 가까운 업로드 센터로 요청을 보내도록하면 업로드 속도를 개선할 수 있다.
본 설계안에서는 CDN을 업로드 센터로 이용한다.
속도 최적화: 모든 절차를 병렬화
낮은 응답지연을 달성하는 것은 어려운데, 이를 위해 느슨하게 결합된 시스템으로 변경하여 병렬성을 높이는 시도를 해볼 수 있다.
•
인코딩 모듈의 작업은 다운로드 모듈의 작업이 끝나야 시작됨
•
업로드 모듈의 작업은 인코딩 모듈의 작업이 끝나야 시작됨
위 처리 과정에서 어떤 단계의 결과물은 이전 단계의 결과물을 입력으로 사용해 만들어진다는 것을 알 수 있다. 이런 의존성이 있다면 병렬성을 높이기 어렵다.
메세지 큐를 도입하여 이 시스템의 결합도를 낮추어 보자.
이제 각각의 모듈은 이전의 결과를 기다리지 않아도 분할된 GOP를 각각 처리할 수 있다.
안전성 최적화: 미리 사인된 업로드 URL
허가받은(authorized) 사용자만 올바른 장소에 비디오를 업로드할 수 있도록 만들기 위해, pre-signed 업로드 URL을 이용할 수 있다.
이를 적용하려면 업로드 절차는 다음과 같이 변경된다.
1.
클라이언트는 API 서버에 업로드 요청을 보내고, API 서버는 아마존 S3에 요청하여 해당 URL이 가리키는 객체에 대한 접근권한을 주어진 상태의 pre-signed URL을 받는다.
2.
API 서버는 pre-signed URL을 클라이언트에 응답한다.
3.
클라이언트에서 해당 URL이 가르키는 위치에 비디오를 업로드한다.
pre-signed URL은 Amazon의 S3에서 사용되는 용어로, 다른 클라우드 업체는 다른 이름을 사용할 수 있다. (ex. MS Azure의 BLOB 저장소: Shared Access Signature)
안전성 최적화: 비디오 보호
많은 콘텐츠 제작자가 비디오 원본을 도난 당할까 두려워한다. 비디오의 저작권을 보호하기 위해 다음 세 가지 선택지 중 하나를 채택할 수 있다.
•
디지털 저작권 관리(DRM: Digital Rights Management) 시스템 : 디지털 저작권을 관리해주는 시스템으로, 애플의 페어플레이(FairPlay), 구글의 와이드바인(Widevine), MS의 플레이레디(PlayReady) 등 널리 사용되고 있다.
•
AES 암호화 : 비디오를 암호화하고 접근 권한을 설정하는 방식으로, 허락된 사용자만 재생 시에 암호화된 비디오를 복호화할 수 있다.
•
워터마크 : 비디오 위에 소유자 정보를 포함하는 이미지 오버레이를 올리는 방식이다.
비용 최적화
CDN은 우리가 설계한 시스템에서 핵심적인 부분인데, 개략적인 추정에서 알 수 있듯 그 비용이 매우 비싸다. 연구 결과에 의하면 유튜브의 비디오 스트리밍은 롱테일(long-tail) 분포를 따르는데, 인기 있는 비디오는 빈번하게 재생되지만 나머지는 거의 보는 사람이 없다. 이에 착안하여 몇 가지 최적화를 시도해 볼 수 있다.
1.
인기 있는 비디오는 CDN으로 재생하고, 나머지 비디오는 비디오 서버를 통해서 재생한다.
2.
인기가 별로 없는 비디오는 인코딩 할 필요가 없을 수 있기 때문에, 짧은 비디오라면 인코딩하지 않고 필요할 때 인코딩해 재생한다.
3.
어떤 비디오는 특정 지역에서만 인기가 높은데, 이런 비디오는 다른 지역의 CDN에 옮길 필요가 없다.
4.
CDN을 직접 구축하고 인터넷 서비스 제공자(ISP)와 제휴한다. CDN을 구축하는 것은 초대형 프로젝트지만, 대규모 스트리밍 사업자라면 직접 구축할 필요가 있다. Comcast, AT&T, Verizon 등 여러 ISP와 제휴하면, 사용자 경험을 향상시키고 인터넷 비용을 낮출 수 있을 것이다.
이러한 최적화 방안들은 콘텐츠 인기도, 이용 패턴, 비디오 크기 등의 데이터에 근거하여 최적화를 수행한다. 따라서 최적화를 시도하기 전에 시청 패턴을 분석하는 것이 중요하다.
오류 처리
대형 시스템에서 시스템 오류는 불가피한데, 장애를 아주 잘 감내하는 시스템을 만들기 위해서는 오류를 우아하게 처리하고 빠르게 회복할 수 있어야한다.
시스템 오류에는 회복 가능한 오류와 회복 불가능한 오류가 있다.
•
회복 가능한 오류(recoverable error) : 특정 비디오 세그먼트를 트랜스코딩하다 실패하는 등의 오류는 회복 가능한 오류에 속한다. 일반적으로 몇 번 재시도하면 해결이되고, 계속해서 실패하여 복구가 어렵다 판단되면 클라이언트에 적절한 오류 코드를 반환해야 한다.
•
회복 불가능한 오류(non-recoverable error) : 비디오 포맷이 잘못되었거나 하는 등의 오류는 몇 번을 재시도해도 불가능하다. 이런 회복 불가능한 오류가 발견되면 해당 비디오에 대한 작업을 중단하고 클라이언트에 적절한 오류 코드를 반환해야한다.
시스템 컴포넌트마다 발생할 수 있는 오류에 대한 전형적인 해결방법은 다음과 같다.
•
업로드 오류 : 업로드를 몇 회 재시도한다.
•
비디오 분할 오류 : 낡은 버전의 클라이언트가 GOP에 따라 비디오를 분할하지 못하는 경우라면 전체 비디오를 서버로 전송하여 서버에서 비디오 분할을 처리한다.
•
트랜스코딩 오류 : 몇 회 재시도한다.
•
전처리 오류 : DAG 그래프를 재생성한다.
•
DAG 스케줄러 오류 : 작업을 다시 스케줄링한다.
•
자원 관리자 큐에 장애 발생 : 사본(replica)을 이용한다.
•
작업 서버 장애 : 다른 서버에서 해당 작업을 재시도한다.
•
API 서버 장애 : 멀티 인스턴스를 통한 다른 API 서버로 우회하여 처리한다.
•
메타데이터 캐시 서버 장애 : 데이터는 다중화 되어있을 것이므로, 다른 노드에서 메타데이터를 가져온다. 장애난 캐시 서버는 새로운 것으로 교체한다.
•
메타데이터 데이터베이스 장애 :
◦
주 서버가 죽었다면 부 서버를 승격하여 주 서버로 교체한다.
◦
부 서버가 죽었다면 다른 부 서버를 통해 읽기 연산을 처리하고 죽은 서버를 새 것으로 교체한다.
4단계 마무리
설계를 마치고 시간이 남는다면 다음의 내용들을 논의해봐도 좋다.
•
API 계층의 규모 확장성 확보 : API 서버는 무상태 서버이므로 수평적 규모 확장이 가능하다는 사실을 언급하면 좋다.
•
데이터베이스 계층의 규모 확장성 확보 : 데이터베이스의 다중화와 샤딩 방법에 대해 이야히하자.
•
라이브 스트리밍 : 라이브 스트리밍은 비디오를 실시간으로 녹화하고 방송하는 절차를 말한다. 이번 설계에서는 포함되지 않았지만, 라이브 스트리밍 시스템과 비-라이브 스트리밍 시스템은 비디오 업로드, 인코딩, 스트리밍이 필요하다는 점에서 동일하다. 가장 중요한 차이점은 다음과 같다.
◦
라이브 스트리밍의 응답 지연이 더 낮아야한다. 따라서 스트리밍 프로토콜 선정에 유의해야 한다.
◦
라이브 스트리밍은 작은 단위의 데이터를 실시간으로 빨리 처리해야하므로, 병렬화 필요성이 떨어진다.
◦
라이브 스트리밍은 오류 처리 시 너무 많은 시간이 소요되는 방안은 사용하기 어렵다.
•
비디오 삭제 : 저작권을 위반한 비디오, 선정적인 비디오, 불법적 행위에 관계된 비디오는 내려야한다. 이러한 비디오는 업로드 과정에서 식별 할 수도 있지만, 사용자 신고 절차를 통해 판별할 수도 있다.