[면접 스터디] 개념정리: 14. 유튜브 설계

이번 스터디 주제는 유튜브 설계이다.

저번 세미 프로젝트로 넷플릭스와 같은 스트리밍 서비스 설계를 했었다.

유튜브 설계는 거기다 사용자가 업로드 할 수 있게 한 서비스 같다.

문제 이해 및 설계 범위 확정

• 업로드 및 스트리밍
• 앱, 웹, 스마트 TV 지원
• DAU 500만명, 평균 소비 시간 30분
• 해상도는 대부분 지원
• 암호화 필수
• 파일크기 1GB 최대
• 클라우드 서비스 쓰면 좋음

이러한 상황에서 설계 시 중요한 점은

• 빠른 비디오 업로드
• 원활한 비디오 재생
• 재생 품질 선택 가능
• 낮은 인프라 비용
• 높은 가용성과 규모 확장성, 안정성

개략적 규모 추정

• DAU: 500만명
• 평균 1명당 5개 비디오 시청
• 평균 10% 사용자가 하루에 1개의 비디오 업로드
• 평균 영상 크기 300MB
• 500만 * 1/10 * 300MB = 150 TB
• 하루 CDN 비용은 아마존 미국 리전 기준 스트리밍 비용
  • 500만 * 5 * 0.02 * 0.3GB = $150

개략적 설계안

여기서 Blob 스토리지(Binary Large Object), CDN은 클라우드 서비스를 이용할 것이다.

크게 두 영역을 설계하면 된다.

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

비디오 업로드 절차

필요 컴포넌트

• 사용자
• 로드밸런서
• API서버: 스트리밍 이외 요청 처리
• 메타데이터 DB: 샤딩과 다중화
• 메타데이터 캐시
• 원본 저장소
• 트랜스코딩 서버: 다양한 해상도로 변환
• 트랜스코딩 비디오 저장소
• 트랜스코딩 완료 큐: 변환 완료 이벤트 저장
• 트랜스코딩 완료 핸들러: 변환 완료 상태 DB, 캐시에 갱신
• CDN: 트랜스코딩 된 영상 캐시역할

[1] 사용자
     │
     ▼
[2] 로드밸런서
     │
     ▼
[3] API 서버
     │
     ├─▶ [4] 메타데이터 DB         ← 사용자, 제목, 태그 등 저장
     │
     ├─▶ [5] 메타데이터 캐시       ← 업로드 완료 후 빠른 조회용 (ex. Redis)
     │
     └─▶ [6] 원본 저장소 (S3/Blob) ← 업로드된 비디오 원본 저장
     │
     ▼
[7] 트랜스코딩 서버
     ▲        │
     │        └─▶ [8] 트랜스코딩 비디오 저장소 ← 여러 해상도로 변환 후 저장 (e.g. 1080p, 720p)
     │
     ▼
[9] 트랜스코딩 완료 큐 (e.g. SQS, Kafka)
     │
     ▼
[10] 트랜스코딩 완료 핸들러
      │
      ├─▶ [4] 메타데이터 DB 업데이트
      │
      └─▶ [5] 메타데이터 캐시 업데이트
      │
      ▼
[11] CDN에 등록 (e.g. CloudFront, Akamai)

비디오 스트리밍 절차

사용자가 비디오를 클릭한 순간 빠르게 비디오를 출력해줘야한다.

여기서 스트리밍이란 영상 전부가 아닌 영상 데이터를 스트림으로 지속적으로 받는 것이다.

이걸 위한 프로토콜들이 있다.

• MPEG-DASH
• HLS
• 마이크로소프트 스무드 스트리밍
• 어도비 HTTP 동적 스트리밍

비디오는 CDN에서 바로 스트리밍된다. 지역적으로 가까운 CDN 에지 서버가 담당할 것이다.

상세 설계

비디오 트랜스코딩

모두가 다 다른 포맷으로 저장한다. 이걸 통일 다른 단말에도 재생하기 위해서 호환되는 비트레이트와 포맷으로 저장해야 한다.

즉 다양한 화질로 인코딩이 필요하고, 이걸 사용자가 선택, 혹은 사용자의 환경에 맞춰 자동 설정해줘야 한다.

인코딩 포맷은 크게 두가지로 이뤄져있다.

• 컨테이너: 비디오 파일, 오디오, 메타데이터를 담는 바구니(.avi, .mov, .mp4)
• 코덱: 비디오 압축 및 압축 해제 알고리즘(H.264, VP9, HEVC)

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

트랜스코딩은 컴퓨팅 자원을 많이 소모할 뿐만 아니라 시간도 많이 소요되는 작업이다.

그리고 다양한 사용자의 요구사항도 충족시켜야한다.

• 워터마크 넣기
• 썸네일 추출
• 검사
• 인코딩

이렇게 다양한 비디오 프로세싱 파이프라인을 지원하면서, 병렬적으로 처리할 수 있게하려면 사용자에게 작업을 손수 정의할 수 있도록 해야 한다.

원본에서 비디오, 오디오, 메타데이터를 추출하고

각 형식에 맞는 정의된 작업들을 수행하고 병합하면 된다.

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

5가지 컴포넌트로 이뤄져있다.

• 전처리기
  • 비디오 분할: 비디오 스트림을 GOP(Group of Pictures)라는 단위로 쪼갠다.
  • DAG 생성: 클라이언트 프로그래머가 작성한 설정파일에 따라 DAG를 만든다.
  • 데이터 캐시: 안정성을 위해 GOP들과 메타데이터를 임시 저장소에 보관한다. 실패 시 다시 꺼내서 시도할 수 있다.
• DAG 스케줄러
  • 만들어진 DAG를 몇 단계로 나눠 작업관리자의 작업 큐에 넣는다.
  • 1단계: 비디오 오디오 메타데이터 추출
  • 2단계: 인코딩과 같은 작업들
• 자원 관리자
  • 자원 배분을 위해 세 개의 큐와 작업 스케줄러로 구성됨
  • 작업 큐: 실행해야할 작업
  • 작업 서버 큐: 작업 서버의 가용 상태 정보가 보관된 큐
  • 실행 큐: 현재 실행 중인 작업 및 작업 서버 정보가 보관된 큐
  • 동작
    1. 작업 큐에서 작업 꺼내기
    2. 적절한 작업 서버 고르기
    3. 작업 서버에 지시
    4. 해당 정보 실행 큐에 넣기
    5. 완료 시 실행 큐에서 제거
• 작업 실행 서버
  • 각 작업에 맞는 그룹으로 서버를 만들어 놓는다.
• 임시 저장소
  • 메타데이터나 GOP를 캐시해두고, 작업 실패 시나 작업 시 이걸 참조해서 작업

시스템 최적화

• 속도 최적화
  • 비디오 병렬 업로드
    • GOP로 분할
    • 업로드 센터를 사용자 근거리로 지정
  • 모든 절차를 병렬화: 분할된 영상 단위로 처리할 수 있게 또한 메시지 큐를 통한 결합도 낮추기
• 안정성 최적화
  • 미리 사인된 업로드 URL
  • 비디오 보호
    • 디저털 저작권 관리
    • AES 암호하
    • 워터마크
• 비용 최적화
  • 인기 비디오만 CDN 나머지는 비디오 서버를 통해
  • 인기 없는 건 인코딩 안하고 있다가 요청 시 인코딩(짧은 경우)
  • 특정 지역에만 인기 있는 비디오와 아닌걸 다르게 처리
  • CDN 직접 구축

오류 처리

• 회복 가능 오류: 트랜스코딩 중 GOP 하나가 실패 시 임시 저장소에서 꺼내서 다시 하는 것 등
• 회복 불가능 오류: 사용자가 이상한 파일 올렸을 경우 등

최대한 재시도 해보고 안되면 적절하게 안내를 해줘야 한다.

마무리

스트리밍 같은 경우는 CDN을 통해 쉽게 구현했다.

반면 업로드 부분은 트랜스코딩이라는 중요한 작업 때문에 DAG와 같은 모델을 사용해 작업해야했다.

오류가 생긴다면 트랜스코딩 부분이 가장 많을 것 같다.

추가 논의 사항

• 무상태성 API 서버 확장
• DB 계층 샤딩과 다중화 방안
• 라이브 스트리밍 추가 논의
• 비디오 삭제 로직