포스팅에 사용된 그림은 책에서 제공하는 그림들 입니다.

유튜브(넷플릭스)와 같은 플랫폼을 설계하는 방법을 알아보자.

유튜브 시스템은 겉 보기에는 간단하다. 콘텐츠 창작자가 비디오를 올리고, 사용자는 재생 버튼을 누르면 영상이 재생된다. 하지만 이게 그렇게 간단할까? 이 겉보기에 단순한 시스템은 엄청나게 복잡한 수많은 기술들이 숨어있다. 유튜브에 대한 통계자료 몇 가지를 살펴보자.

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

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

유튜브에서는 단순히 비디오를 보는 것 말고도 많은 일을 할 수 있다. 댓글을 남길 수도 있고, 비디오를 공유하거나 좋아요 버튼을 누를 수도 있고, 자기 재생목록에 저장을 할 수도 있고, 채널을 골라 구독할 수 도 있다. 이 모두를 설계하는 것 보다는, 적절한 요구사항을 도출해 설계해보자.

요구사항 도출

• 영상을 올리는 것이 가장 중요한 기능이다
• 모바일 앱, 웹 브라우저, 스마트 TV를 지원해야 한다
• 일간 능동 사용자 수는 5백만명 이다
• 5백만명이 평균적으로 30분씩 사용한다
• 다국어 지원이 필요하다
• 현존하는 비디오의 종류와 해상도를 대부분 지원해야한다
• 암호화가 필요하다
• 영상의 크기는 최대 1GB이다
• 다른 제 3자의 서비스(클라우드)와 같은 것을 활용해 만들어도 된다.

개략적 규모 측정

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

위 추정 결과에 따르면 CDN을 통해 영상을 서비스하면 비용이 엄청나다. 클라우드 서비스가 서비스 사업자가 큰 고객에게 비용 할인을 해주는 점을 감안하더라도 만만찮은 비용이기에 이 비용을 줄이는 방법에 대해서는 상세 설계때 이야기 해보겠다.

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

개략적 설계안에서는 제3자 서비스 (CDN과 BLOB 스토리지)를 사용하여 개략적 설계안을 작성할 것이다. 왜 직접 만들지 않고 제3자가 제공해주는 서비스를 이용하는지에 대한 이유는 아래와 같다.

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

개략적으로 보면 이 시스템은 세 개의 컴포넌트로 구성된다

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

자 이제 핵심적인 기능 두가지인 비디오 업로드 절차, 비디오 스트리밍 절차를 개략적으로 설계해보자

비디오 업로드 절차

아래 그림은 비디오 업로드 절차의 개략적 설계안이다.

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

• 사용자: 컴퓨터나 모바일 폰, 혹은 스마트 TV를 통해 유튜브를 시청하는 이용자다.
• 로드밸런서: API 서버 각각으로 고르게 요청을 분산하는 역할을 담당
• API 서버: 비디오 스트리밍을 제외한 다른 모든 요청을 처리
• 메타데이터 데이터베이스: 비디오의 메타데이터를 보관하고 샤딩과 다중화를 적용하여 성능 및 가용성을 충족한다
• 메타데이터 캐시: 성능을 높이기 위해 비디오 메타데이터와 사용자 객체는 캐시한다.
• 원본 저장소: 원본 비디오를 보관할 대형 이진 파일 저장소(BLOB)시스템이다.

💡 BLOB저장소는 “이진 데이터를 하나의 개체로 보관하는 데이터베이스 관리 시스템”이다.

• 트랜스코딩 서버: 영상 트랜스코딩은 비디오 인코딩이라 부릑도 하는 절차로, 비디오의 포맷을 변환하는 절차다. 단말이나 대역폭 요구사항에 맞는 최적의 영상 스트림을 제공하기 위해 필요하다
• 트랜스코딩 비디오 저장소: 트랜스코딩이 완료된 영상을 저장하는 BLOB 저장소다.
• CDN: 영상을 캐시하는 역할을 답당한다. 사용자가 재생 버튼을 누르면 영상 스트리밍은 CDN을 통해 이루어진다
• 트랜스코딩 완료 큐: 영상 트랜스코딩 완료 이벤트들을 보관할 메시지 큐다
• 트랜스코딩 완료 핸들러: 트랜스코딩 완료 큐에서 이벤트 데이터를 꺼내어 메타데이터 캐시와 데이터베이스를 갱신할 작업 서버들이다.

각 컴포넌트가 무슨 일을 하는지느 살펴보았으니, 영상 업로드가 어떻게 처리되는지를 들여다보자. 다음의 두 프로세스가 병렬적으로 수행된다고 보면 된다.

1. 영상 업로드
2. 영상 메타데이터 갱신. 메타데이터에는 영상 URL, 크기, 해상도, 포맷, 사용자 정보가 포함된다.

프로세스 a: 영상 업로드

아래 그림은 영상 업로드가 어떻게 이루어지는지를 보여준다. 요약하면 아래와 같다.

1. 영상을 원본 저장소에 업로드한다.
2. 트랜스코딩 서버는 원본 저장소에서 해당 영상을 가져와 트랜스코딩을 시작한다.
3. 트랜스코딩이 완료되면 아래 두 절차가 병렬적으로 수행된다.
   1. 완료된 영상을 트랜스코딩 영상 저장소로 업로드
   2. 트랜스코딩 완료 이벤트를 트랜스코딩 완료 큐에 넣는다
      1. 트랜스코딩이 끝난 비디오를 CDN에 올린다
      2. 완료 핸들러가 이벤트 데이터를 큐에서 꺼낸다
      3. 완료 핸들러가 메타데이터 데이터베이스와 캐시를 갱신한다.

4. API 서버가 단말에게 영상 업로드가 끝나서 스트리밍 준비가 되었음을 알린다.

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

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

비디오 스트리밍 절차

유튜브에서 영상 재생버튼을 누르면 스트리밍은 바로 시작되며 영상 다운로드가 완료디어야 영상을 볼 수 있다거나 하는 불편함은 없다. 여기서 다운로드라 함은 영상을 단말로 내려 받는 것을 말하며, 스트리밍은 여러분의 장치가 원격지의 영상으로부터 지속적으로 영상 스트림을 전송 받아 영상을 재생하는 것을 말한다.

글너데 영상 스트리밍이 이루어지는 절차를 논하기에 앞서, 우리는 먼저 스트리밍 프로토콜이라는 중요한 개념을 알아두어야 한다.

💡 스트리밍 프로토콜이란? 영상 스트리밍을 위해 데이터를 전송할 때 쓰이는 표준화된 통신방법이다. 널리 사용되는 스트리밍 프로토콜로는 다음과 같은 것이 있다.

• MPEG-DASH. MPEG는 “Moving Picture Experts Group”의 약자이며, DASH는 “Dynamic Adaptive Streaming over HTTP”의 약어이다.
• 애플 HLS. HLS는 “HTTP Live Streaming”의 약어이다.
• 마이크로소프트 스무스 스트리밍(Microsoft Smooth STreaming).
• 어도비 HTTP 동적 스트리밍(Adobe HTTP Dynamic Streaming, HDS).

이 프로토콜의 동작 원리를 정확하게 이해하거나 이름들을 외울 필요는 없다. 중요한 점은, 프로토콜마다 지원하는 영상 인코딩이 다르고 플레이어도 다르다는 것이다. 따라서 영상 스트리밍 서비스를 설계할 때는 서비스의 용례에 맞는 프로토콜을 잘 골라야한다.

영상은 CDN에서 바로 스트리밍된다. 사용자의 단말에 가장 가까운 CDN 에지 서버가 영상 전송을 담당할 것이다. 따라서 전송시간은 아주 낮다. 아래그림은 이 부분의 개략적 설계안이다.

3단계 상세설계

지금까지 살펴본 개략적 설계안에서는 전체 시스템을 두 부분, 즉 영상 업로드를 담당하는 부분과 영상 스트리밍을 담당하는 부분으로 나눠 살펴봤다. 상세 설계에서는 최적화 방안과 함께 좀 더 상세히 다듬고 오류 처리 매커니즘에 대해서도 알아보자.

비디오 트랜스코딩

영상을 녹화하면 해당 영상을 특정 포맷으로 저장한다. 이 영상은 다른 단말에서도 순조롭게 재생되려면 다른 단말과 호환되는 비트레이트와 포맷으로 저장되어야 한다.

💡 비트레이트란? 영상을 구성하는 비트가 얼마나 빨리 처리되어야 하는지를 나타내는 단위다. 비트레이트가 높은 비디오는 일반적으로 고화질 비디오이다.

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

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

• 가공되지 않은 원본 영상은 저장 공간을 많이 차지한다. 가령 초당 60프레임으로 녹화된 HD 영상은 수백 GB의 저장공간을 차지하게 될 수 있다.
• 상당수의 단말과 브라우저는 특정 종류의 비디오 포맷만 지원한다. 따라서 호환성 문제를 해결하려면 하나의 영상을 여러 포맷으로 인코딩해 두는 것이 바람직하다.
• 사용자에게 끊김 없는 고화질 영상 재생을 보장하려면, 네트워크 대역폭이 충분하지 않은 사용자에게는 저화질 영상을, 대역폭이 충분한 사용자에게는 영상을 보내는 것이 바람직하다.
• 모바일 단말의 경우 네트워크 상황이 수시로 달라질 수 있다. 영상이 끊김 없이 재생되도록 하기 위해서는 영상 화질을 자동으로 변경하거나 수동으로 변경할 수 있도록 하는 것이 바람직하다.

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

• 컨테이너: 영상 파일, 오디오, 메타데이터를 담는 바구니 같은 것이다. 컨테이너 포맷은 .avi, .mov, .mp4같은 파일 확장자를 보면 알 수 있다.
• 코덱: 영상 화질은 보존하면서 파일 크기를 줄일 목적으로 고안된 압축 및 압축 해제 알고리즘이다. 가장 많이 사용되는 영상 코덱으로는 H.264, VP9, HEVC가 있다.

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

영상을 트랜스코딩하는 것은 컴퓨팅 자원을 많이 소모할 뿐 아니라 시간도 많이 드는 작업이다. 게다가 콘텐츠 창작자는 각자 자기만의 영상 프로세싱 요구사항을 갖고 있다. 가령 어떤 사람은 영상 위에 워터마크를 표시하고 싶어 할 것이고, 어떤 사람은 섬네일 이미지를 스스로 만들어 쓰고 싶어 할 것이고, 어떤 사람은 고화질 영상을 선호하는 반면 또 다른 어떤 이는 저화질 영상도 충분하다고 생각할 것이다.

이처럼 각기 다른 유형의 영상 프로세싱 파이프라인을 지원하는 한편 처리 과정의 병렬성을 높이기 위해서는 적절한 수준의 추상화를 도입하여 클라이언트 프로그래머로 하여금 실행할 작업을 손수 정의할 수 있도록 해야 한다. 예를 들어 페이스북의 스트리밍 영상 엔진은 유향 비순환 그래프(DAG)를 도입하여 작업을 단계별로 배열할 수 있도록 하여 해당 작업들이 순차적 또는 병렬적으로 실행될 수 있도록 하고 있다. 아래 설계안에서도 이와 유사한 DAG모델을 도입하여 유연성과 병렬성을 달성할 수 있도록 하겠다. 아래 그림이 설계안이다.

위 그림에서 원본 영상은 일단 영상, 오디오, 메타데이터의 세 부분으로 나뉘어 처리된다. 영상 부분에 적용되는 작업은 다음과 같다.

• 검사: 좋은 품질의 영상인지, 손상은 없는지 확인하는 작업이다.
• 영상 인코딩: 비디오를 다양한 해상도, 코덱, 비트레이트 조합으로 인코딩 하는 작업이다. 아래 그림을 봐보자.

• 섬네일: 사용자가 업로드한 이미지나 비디오에서 자동 추출된 이미지로 섬네일을 만드는 작업
• 워터마크: 영상에 대한 식별정보를 이미지 위에 오버레이 형태로 띄워 표시하는 작업

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

아래 설계안에서는 클라우드 서비스를 활용한 영상 트랜스코딩 아키텍처를 다음과 같이 정의했다.

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

• 전처리기
• DAG 스케줄러
• 자원 관리자
• 작업 실행 서버
• 임시 저장소

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

전처리기

전처리기가 하는 일은 아래 처럼 3가지 이다.

1. 비디오 분할: 비디오 스트림을 GOP라고 불리는 단위로 쪼갠다. GOP는 특정 순서로 배열된 프레임(frame) 그룹이다. 하나의 GOP는 독립적으로 재생 가능하며, 길이는 보통 몇 초 정도이다. 어떤 종류의 오래된 단말이나 브라우저는 GOP 단위의 영상 분할을 지원하지 않는다. 그런 단말의 경우에는 전처리기가 영상 분할을 대신한다.
2. DAG 생성: 클라이언트 프로그래머가 작성한 설정 파일에 따라 DAG를 만들어낸다. 아래그림은 2개 노드와 1개 연결선으로 구성된 DAG의 사례와 설정 파일이다.

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

DAG 스케줄러

DAG 스케줄러는 DAG 그래프를 몇 개 단계로 분할한 다음에 그 각각을 자원 관리자의 작업 큐에 집어넣는다. 아래그림은 DAG 스케줄러가 어떻게 동작하는지를 보여주는 하나의 사례다.

1. 첫번째 단계에서는 영상, 오디오, 메타데이터를 분리한다
2. 영상 파일을 인코딩하고, 섬네일을 추출하고, 오디오 파일 또한 인코딩한다.

자원 관리자

자원 관리자는 자원 배분을 효과적으로 수행하는 역할을 담당한다. 아래그림과 같이 세 개의 큐와 작업스케줄러로 구성된다.

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

작업 관리자는 다음과 같이 동작한다.

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

작업 서버는 DAG에 정의된 작업을 수행한다. 아래 그림처럼, 작업 종류에 따라 작업 서버도 구분하여 관리한다.

임시 저장소

임시 저장소 구현에는 여러 저장소 시스템을 활용할 수 있다. 어떤 시스템을 선택할 것이냐는 저장할 데이터의 유형, 크기, 이용 빈도, 데이터 유효기간 등에 따라 달라진다. 예를 들어 메타데이터는 작업 서버가 빈번히 참조하는 정보이고 그 크기도 작은 것이 보통이다. 따라서 메모리에 캐시해 두면 좋을 것이다. 그러나 영상/오디오 데이터는 BLOB 저장소에 두는 것이 바람직하다. 임시 저장소에 보관한 데이터는 영상 프로세싱이 완룐되면 삭제한다.

인코딩된 비디오

인코딩된 영상은 닌코딩 파이프라인의 최종 결과물이다.

시스템 최적화

영상을 업로드하는 과정, 스트리밍하고 트랜스코딩하는 절차에 대해서는 충분히 알것이다. 이제 속도, 안전성, 그리고 비용 측면에서 이 시스템을 최적화 해보자.

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

영상 전부를 한 번의 업로드로 올리는 것은 비효율적이다. 하나의 영상은 아래 그림과 같은 작은 GOP들로 분할할 수 있다.

이렇게 분할한 GOP를 병렬적으로 업로드하면 설사 일부가 실패해도 빠르게 업로드를 재개할 수 있다. 따라서 비디오를 GOP 경계에 맞춰 분할하는 작업을 단말이 수행하면 아래그림과 같이 업로드 속도를 높일 수 있다.

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

업로드 속도를 개선하는 또 다른 방법은 업로드 센터를 아래 그림 처럼 여러 곳에 두는 것이다.

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

낮은 응답지연을 달성하는 것은 어려운 일이다. 이를 위해 시도해 볼 수 있는 또 하나의 방법은, 느슨하게 결합된 시스템을 만들어서 병렬성을 높이는 것이다.

이를 위해서는 지금까지의 설계안을 조금 변경해야 한다. 영상을 원본 저장소에서 CDN으로 옮기는 절차를 좀더 자세히 보자. 이 절차는 아래 그림과 같다. 어떤 단계의 결과물은 이전 단계의 결과물을 입력으로 사용하여 만들어진다는 것을 알 수 있다. 이런 의존성이 있으면 병렬성을 높이기 어렵다.

이 시템의 결합도를 낮추기 위해, 아래 그림과 같은 메시지 큐를 도입한다.

이 메시지 큐가 어떻게 시스템 결합도를 낮추는지, 예를 들어 살펴보자.

• 메시지 큐를 도입하기 전에 인코딩 모듈은 다운로드 모듈의 작업이 끝나기를 기다려야 했다
• 메시지 큐를 도입한 뒤에 인코딩 모듈은 다운로드 모듈의 작업이 끝나기를 더 이상 기다릴 필요가 없다. 메시지 큐에 보관된 이벤트 각각을 인코딩 모듈은 병렬적으로 처리할 수 있다.

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

안전성은 모든 제품의 가장 중요한 측면 가운데 하나일 것이다. 허가받은 사용자만이 올바른 장소에 영상을 업도르할 수 있기 있도록 하기 위해, 아래와 같이 미리 사인된 업로드 URL을 이용한다.

이를 위해 업로드 절차는 다음과 같이 변경한다.

1. 클라이언트는 HTTP 서버에 POST 요청을 하여 미리 사인된 URL을 받는다. 해당 URl이 가리키는 객체에 대한 접근 권한이 이미 주어져 있는 상태다. ‘미리 사인된 URL’이라는 용어는 사실 아마존 S3에서 쓰이는 용어다. 다른 클라우드 업체에서는 다른 이름으로 부를 수도 있다. 마이크로소프트 애저가 제공하는 BLOB 저장소는 같은 기능을 “접근 공유 시그니처”라 부른다.
2. API 서버는 미리 사인된 URL을 돌려준다.
3. 클라이언트는 해당 URL이 가리키는 위치에 영상을 업로드한다.

안전성 최적화: 영상 보호

많은 콘텐츠 제작자가 영상을 인터네셍 업로드하기를 주저하는데, 영상 원본을 도난 당할까 우려해서다. 영상의 저작권을 보호하기 위해, 3가지 선택지 가운데 하나를 채택할 수 있다.

• 디지털 저작권 관리(DRM) 시스템 도입: 이 부문에서 가장 널리 사용되는 시스템으로는 애플의 페어플레이, 구글의 와이드바인, 마이크로소프트의 플레이레디가 있다.
• AES 암호화: 영상을 암호화하고 접근 권한을 설정하는 방식이다. 암호화된 영상은 재생 시에만 복호화한다. 허락된 사용자만 암호화된 영상을 시청할 수 있다.
• 워터마크: 영상 위에 소유자 정보를 포함하는 이미지 오버레이를 올리는 것이다. 회사 로고나 이름 등을 이 용도에 사용할 수 있다.

비용 최적화

CDN은 이 시스템의 핵심적인 부분이다. 세계 어디서도 끊김 없이 빠르게 영상을 시청할 수 있도록 해준다. 하지만, 개략적인 추정치에서도 알 수 있듯이, CDN은 비싸다. 데이터 크기가 크면 클수록 더 비싸진다. 어떻게 비용을 낮출 수 있을까?

1. 인기 영상은 CDN을 통해 재생하되 다른 영상은 영상 서버를 통해 재생하는 것이다(아래그림)

2. 인기가 별로 없는 영상은 인코딩 할 필요가 없을 수도 있따. 짧은 영상이라면 필요할 때 인코딩하여 재생할 수 있다.
3. 어떤 영상은 특정 지역에서만 인기가 높다. 이런 영상은 다른 지역에 옮길 필요가 없다.
4. CDN을 직접 구축하고 인터넷 서비스 제공자와 제휴한다. CDN을 직접 구축하는 것은 초대형 프로젝트다. ISP로는 컴캐스트 등이 있다. ISP는 전세계 어디나 있으며 사용자와 가깝다. 이들과 제휴하면 사용자 경험을 향상시킬 수 있고 인터넷 사용 비용을 낮출 수 있을 것이다.
5. 이 모든 최적화는 콘텐츠 인기도, 이용 패턴, 영상 크기 등의 데이터에 근거한 것이다. 최적화를 시도하기 전에 시청 패턴을 분석하는 것은 중요하다.

오류 처리

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

• 회복 가능 오류: 특정 영상 세그먼트를 트랜스코딩하다 실패했다든가 하는 오류는 회복 가능한 오류에 속한다. 일반적으로 보자면 이런 오류는 몇 번 재시도하면 해결된다. 하지만 계속해서 실패하고 복구가 어렵다 판단되면 클라이언트에게 적절한 오류 코드를 반환해야 한다.
• 회북 불가능 오류: 영상 포맷이 잘못되었다거나 하는 회복 불가능한 오류가 발견되면 시스템은 해당 영상에 대한 작업을 중단하고 클라이언트에게 적절한 오류 코드를 반환해야한다.

시스템 컴포넌트 각각에 발생할 수 있는 오류에 대한 전형적 해결 방법을 아래에 요약 했다.

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

4단계 마무리

유튜브와 같은 영상 스트리밍 서비스를 만들기 위해 어떤 설계가 필요한지 살펴보았다. 위에서 다루지 않은 내용 중 다음과 같은 내용을 생각해보면 좋다.

• API 계층의 규모 확장성 확보 방안: API 서버는 무상태 서버이므로 수평적 규모 확장이 가능하다는 사실을 언급하면 좋다
• 데이터베이스 계층의 규모 확장성 확보 방안: 데이터베이스의 다중화와 샤딩 방법에 대해 이야기하자
• 라이브 스트리밍: 라이브 스트리밍은 영상을 실시간으로 녹화하고 방송하는 절차를 말한다. 라이브 스트리밍 시스템과 비-라이브 스트리밍 시스템 간에는 비슷한 점 도 많다. 둘 다 영상 업로드, 인코딩, 스트리밍이 필요하다는 점이 같다. 가장 중요한 차이는 다음과 같다
  • 라이브 스트리밍의 경우에는 응답지연이 좀 더 낮아야 한다. 따라서 스트리밍 프로토콜 선정에 유의해야 한다.
  • 라이브 스트리밍의 경우 병렬화 필요성은 떨어질 텐데, 작은 단위의 데이터를 실시간으로 빨리 처리해야 하기 때문이다.
  • 라이브 스트리밍의 경우 오류 처리 방법을 달리해야 한다. 너무 많은 시간이 걸리는 방안은 사용하기 어렵다.
• 비디오 삭제: 저작권을 위바한 영상, 선정적 영상, 불법적 행위에 관계된 영상은 내려야한다. 내릴 영상은 업로드 과정에서 식별해 낼 수도 있지만, 사용자의 신고 절차를 통해 판별할 수도 있다.