[System Design Interview] 14장 유튜브 설계

콘텐츠 창작자가 비디오를 올리고, 시청자가 재생 버튼을 누르는 이 시스템의 이면에는 엄청나게 복잡한 수많은 기술이 숨어있음 유튜브는 DAU 20억명, 매일 재생되는 비디어 50억개, 모바일 인터넷 트래픽의 37% 점유 등 엄청난 규모를 가지고 있음

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

기능 명세

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

개략적 규모 추정

• 일간 능동 사용자(DAU: Daily Active User) 수는 5백만(5 million)
• 한 사용자는 하루에 평균 5개의 비디오를 시청
• 10%의 사용자가 하루에 1 비디오 업로드
• 비디오 평균 크기는 300MB
• 비디오 저장을 위해 매일 새로 요구되는 저장 용량 = 5백만 X 10% X 300MB = 150TB
• 매일 발생하는 CDN 비용 (AWS CloudFront 기준 1GB당 $0.02 요금) = 5백만 X 5비디오 X $0.02 = $150,000

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

CDN과 BLOB 스토리지

CDN과 BLOB 스토리지는 기존 클라우드 서비스 이용 (직접 CDN을 구현하는 것은 복잡할 뿐만 아니라 많은 비용이 듬, 일례로 넷플릭스 또한 AWS를 사용함)

개략적인 시스템 구성

• 단말: 유튜브를 시청하는 디바이스들
• CDN: 비디오는 CDN에 저장되어, 재생하면 단말에 스트리밍이 이루어짐
• API 서버: 비디오 스트리밍을 제외한 모든 요청을 처리 (피드 추천, 업로드 URL 생성, 사용자 정보 처리 등)

비디오 업로드 절차

비디오 업로드 프로세스 (두 프로세스가 병렬적으로 수행됨)

1. 비디오 업로드
2. 비디오 메타데이터 갱신 (비디오 URL, 크기, 해상도, 포맷, 사용자 정보 등)

비디오 스트리밍 절차

서비스의 용례에 맞게 스트리밍 프로토콜(MPEG-DSH, HLS, HDS 등)을 선택해야 함

3단계: 상세 설계

비디오 트랜스코딩

비디오를 다양한 형태(비트레이트, bitrate, 포맷)로 제공하기 위해 인코딩하는 절차

트랜스코딩이 중요한 이유

• 가공되지 않은 원본 비디오는 저장 공간을 많이 차지함
• 다양한 단말과 브라우저는 특정 정류의 비디오 포맷만 지원함
• 사용자에게 끊김 없는 비디오 재생을 보장하기 위해, 네트워크 대역폭이 충분하지 않은 사용자에게는 저화질 비디오를, 대역폭이 충분한 사용자에게는 고화질 비디오는 보내는 것이 바람직함
• 모바일 단말의 경우 네트워크 상황이 수시로 달라질 수 있기 때문에 비디오 화질을 자동으로 변경하거나 수동으로 변경할 수 있도록 해주는 것이 바람직함

인코딩을 위한 인코딩 포맷 구성요소

• 컨테이너(container): 비디오 파일, 오디오, 메타데이터를 담는 바구니, 컨테이너 포맷은 .avi, .mp4 등이 존재함
• 코덱(codec): 비디오 화질은 보전하면서 파일 크기를 줄일 목적으로 고안된 압축 알고리즘, 비디오 코덱은 H.264, HEVC 등이 존재함

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

비디오를 업로더(사용자)의 선호에 맞게 트랜스코딩할 수 있도록 제공 + 비디오 처리 과정의 병렬성을 높이기 위해 유향 비순환 그래프(DAG) 모델 사용

비디오 처리의 경우, 검사, 비디오 인코딩, 섬네일, 워터마크 등의 작업을 수행한다

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

컴포넌트

• 전처리기: 비디오 스트림을 GOP(Group of Pictures)라고 불리는 단위로 쪼개는 비디오 분할(video splitting)과, 클라이언트가 작성한 설정 파일에 따라 DAG를 생성하는 DAG 생성, 그리고 메타데이터와 GOP를 임시 저장소에 캐싱함, 인코딩 실패시 캐시 데이터를 활용해 인코딩 재개함
• DAG 스케줄러: DAG 그래프를 단계로 분할한 뒤, 그 각각을 자원 관리자의 작업 큐에 넣음
• 자원 관리자: 실행할 작업이 보관된 우선순위 작업 큐(task queue), 작업 서버의 가용 상태 정보가 보관된 우선순위 작업 서버 큐(worker queue), 현재 실행 중인 작업 서버 정보가 보관된 실행 큐(running queue)에서 최적의 작업과 서버 조합을 골라, 해당 작업 서버가 작업을 수행하도록 지시하는 역할을 담당함
• 작업 서버: DAG에 정의된 작업을 수행함. 작업 종류에 따라 작업 서버도 구분하여 관리함
• 임시 저장소: 메타데이터 등은 메모리에 캐싱하고, 비디오 등은 BLOB 저장소에 캐싱해서 작업 서버가 사용할 수 있도록 함
• 인코딩된 비디오: 최종 결과물

시스템 최적화

• 속도 최적화
  • 비디오 병렬 업로드: 비디오를 작은 GOP들로 분할하여 업로드
  • 업로드 센터를 사용자 근거리에 지정: 업로드 센터를 여러 region에 배치
  • 모든 절차를 병렬화: 의존성이 존재하는 시스템 구성요소 사이에 메시지 큐를 도입하여, 각 모듈이 이전 모듈에서 작업이 끝나기를 기다릴 필요 없이 바로 메시지 큐에 보관된 이벤트를 처리할 수 있음
• 안정성 최적화
  • 미리 서명된 업로드 URL: API 서버가 이미 서명된 URL을 만들어 해당 URL로 클라이언트가 업로드 하도록 구성 (Presigned URL: AWS S3 용어)
  • 비디오 보호: 디지털 저작권(DRM) 시스템, AES 암호화, 워터마크 등을 도입
• 비용 최적화: CDN
  • 유튜브의 비디오 스트림은 롱테일(long-tail) 분포를 따름: 인기 있는 비디오는 빈번하게 보지만, 나머지는 거의 보는 사람이 없음

• 인기 비디오는 CDN을 통해 재생하되, 다른 비디오는 비디오 서버를 통해 재생하는 방식
• 인기가 별로 없는 비디오는 필요할 때만 인코딩 할 수도 있음
• 어떤 비디오는 특정 지역에서만 인기가 높음 → 해당 비디오는 다른 지역에 옮길 필요 없음
• CDN을 직접 구축하고 인터넷 서비스 제공자(ISP)와 제휴

오류 처리

장애를 아주 잘 감내하는(highly fault-tolerant) 시스템을 만들기 위해서는 오류들을 우아하게 처리하고 빠르게 회복해야 함

시스템 오류의 종류

• 회복 가능 오류(recoverable error): 재시도(retry) 후 오류 코드 반환
• 회복 불가능 오류(non-recoverable error): 클라이언트에게 적절한 오류 코드 반환\

기타 오류 해결법

• 업로드 오류: 몇 회 재시도
• 비디오분할 오류: 전체 비디오를 서버로 전송 후 서버에서 분할 처리
• 트랜스코딩 오류: 재시도
• 전처리 오류: DAG 그래프 재생성
• DAG 스케줄러 오류: 재스케줄링
• 자원 관리자 큐에 장애 발생: 사본(replica) 이용
• 작업 서버 장애: 다른 서버에서 작업 재시도
• API 서버 장애: 무상태이므로 요청을 다른 서버로 보냄
• 메타데이터 캐시 서버 장애: 다른 노드 사용
• 메타데이터 데이터베이스 서버 장애: 주/부 데이터베이스 failover 전략 사용

4단계: 마무리

추가적으로 논의할 수 있는 내용들

• API 계층의 규모 확장성 확보 방안
• 데이터베이스 계층의 규모 확장성 확보 방안
• 라이브 스트리밍(live streaming): 실시간으로 녹화하고 방송하는 절차. 비-라이브 스트리밍 시스템과의 차이점은
• 비디오 삭제(takedown): 부적절한 비디오는 내려야 함

 

Reference: http://www.yes24.com/Product/Goods/102819435

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