유튜브 설계

14장 유튜브 설계

유튜브는 엄청난 규모의 전 지구적 서비스

문제 이해 및 설계 범위 확정

다음의 기능을 포함한다.

• 댓글 남기기
• 비디오 공유
• 좋아요 누르기
• 재생목록에 저장
• 구독

일간 능동 사용자가 5백만이고, 10%의 사용자가 하루에 1비디오 업로드 한다고 가정하자.

비디오의 평균 크기가 300MB라면, 매일 요구되는 저장 용량 150TB이다.

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

CDN을 새롭게 구축할 필요는 없다. (기존 클라우드 서비스 활용)

• 시스템 설계 면접은 모든 것을 밑바닥부터 만드는 것과는 관계가 없다. ** 저장소를 사용한다, 라고 언급만 해도 충분하다.
• 규모 확장이 쉬운 CDN을 만드는 것은 지극히 복잡하고, 많은 비용이 드는 일이다.

비디오 업로드 절차

• 사용자 : 유튜브를 시청하는 이용자
• 로드밸런서 : API 요청을 분산하는 역할 담당
• API 서버 : 스트리밍 제외 요청 처리
• 메타데이터 데이터베이스 : 비디오의 메타데이터 보관, 샤딩,다중화 적용
• 메타데이터 캐시
• 원본 저장소 : BLOB 시스템, 이진 파일 저장소
• 트랜스코딩 서버 : 비디오의 포맷을 변환하는 절차, 단말이나 대역폭 요구사항에 맞는 최적의 비디오 스트림을 제공
• 트랜스코딩 비디오 저장소 : 트랜스코딩이 완료된 비디오를 저장하는 BLOB 저장소
• 트랜스코딩 완료 큐 : 비디오 트랜스코딩 완료 이벤트를 보관
• 트랜스코딩 완료 핸들러 : 완료 큐에서 데이터를 꺼내어서 메타데이터 캐시와 데이터베이스를 갱신할 작업 서버

비디오 업로드 프로세스

1. 비디오를 원본 저장소에 업로드
2. 트랜스코딩 서버가 트랜스코딩 시작
3. 비디오를 트랜스코딩 비디오 저장소로 업로드
4. 완료 이벤트를 트랜스코딩 완료 큐에 넣는다.
5. 메타데이터 데이터베이스와 캐시를 갱신한다.
6. 업로드가 끝났음을 알린다.

메타데이터 갱신 프로세스

• 파일이 업로드되는 동안 비디오 메타데이터 갱신 요청은 API 서버에 보낸다.

비디오 스트리밍 절차

스트리밍 프로토콜을 사용한다.

프로토콜마다 지원하는 비디오 인코딩과 플레이어가 다르다.

사용자의 단말에서 가장 가까운 CDN 에지 서버가 비디오 전송을 담당한다.

상세 설계

비디오 트랜스코딩이 중요한 이유

• 가공되지 않은 원본 비디오는 저장 공간을 많이 차지한다.
• 상당수의 단말과 비디오는 특정 종류의 비디오 포맷만 지원한다. 따라서 호환성을 위해서 여러 포맷으로 인코딩해 두는 것이 바람직하다.
• 네트워크 대역폭이 충분하지 않은 사용자에게는 저화질을, 충분한 사용자에게는 고화질 비디오를 보내는 것이 좋다.
• 모바일의 경우에는 수동/자동으로 끊김없이 재생되도록 비디오 화질을 변경하도록

인코딩 포맷

• 컨테이너 avi, mov, mp4
• 코덱 화질은 보존하면서 압축 알고리즘이 있는 거,, H.264, vp9 hevc

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

• 트랜스코딩은 컴퓨팅 자원을 많이 소모하고 시간도 많이 드는 작업이다.
• 적절한 수준의 추상화를 도입하여 클라이언트 프로그래머로 작업을 정의할 수 있도록 한다.
• 작업을 단계별로 배열할 수 있도록, 해당 작업이 순차적/병렬적으로 실행될 수 있도록 해야 한다.

검사 손상이 없는 비디오인지 확인한다.

비디오 인코딩 다양한 해상도, 코덱, 비트레이트 조합으로 인코딩한다.

섬네일 자동 추출 이미지로 섬네일을 만든다.

워터마크 식별정보를 오버레이 형태로 띄워 표시하는 작업

 

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

개략적 순서 : 전처리기 → DAG 스케줄러 → 자원 관리자 → 작업 실행 서버 → 인코딩된 비디오

• 전처리기
  • 비디오 분할 : 비디오 스트림을 GOP 단위로 쪼개고, 각 단위는 독립적으로 재생 가능하다.
  • DAG 생성
  • 데이터 캐시 : GOP와 메타데이터를 임시 저장소에 보관
• DAG 스케줄러
  • DAG 그래프를 몇 단계로 분할한 다음에 작업 큐에 직업넣는다.
• 자원 관리자
  • 자원 배분을 효과적으로 수행하는 역할
  • 우선순위 큐를 사용하여 작업
• 작업 서버
  • DAG에 정의된 작업 수행
  • 임시 저장소를 사용해서 메모리 캐시
• 인코딩된 비디오 : 최종 결과물

시스템 최적화

• 속도 최적화
  • 비디오 병렬 업로드: GOP를 병렬적으로 업로드한다.
  • 업로드 센터를 사용자 근거리에 지정
  • 모든 절차를 병렬화
• 안전성 최적화
  • 허가받은 사용자만 비디오 업드하기 위해 pre-signed upload url 이용
  • 비디오 보호를 위해 저작권 관리 시스템 도입, aes 암호화, 워터마크 사용
• 비용 최적화
  • 롱테일 분포 : 인기 있는 비디오는 빈번히 재생되는 반면, 나머지는 거의 보는 사람이 없다.
    • 인기 비디오는 CDN을 통해 재생하되, 다른 비디오는 비디오 서버를 통해 재생한다.
    • 특정 지역에서만 인기가 높다면 다른 지역에 옮길 필요가 없다.
    • CDN을 직접 구축한다.

오류 처리

• 회복 가능 오류 : 트랜스코딩 실패, 재시도하면 해결된다.
• 해복 불가능 오류 : 비디오 포맷이 잘못되었다 → 적절한 오류 코드 반환
• 비디오 오류는 몇 회 재시도한다.
• 비디오 분할 오류: 낡은 버전의 클라이언트가 비디오 분할 못한다면 전체를 서버가 비디오 분할 처리하도록 한다.
• 트랜스코딩 오류 : 재시도
• 전처리오류 : DAG 그래프를 재생성한다.
• DAG 스케줄러 오류 : 다시 스케줄링한다.
• 자원 관리자 큐에 장애 발생 : 사본 이용
• 작업 서버 장애 : 다른 서버에서 작업 재시도
• API 서버 장애 : 무상태 서버이므로 신규 요청은 다른 API 서버로 우회
• 메타데이터 캐시 서버 장애 : 데이터가 다중화되어있으므로, 다른 노드 데이터를 가져올 수 있다.
• 메타데이터 데이터베이스 서버 장애 : 주 서버가 죽없다면 부서버로 교체, 부서버가 죽었다면 다른 부서버로 읽기 연산 처리

마무리

아래와 같은 내용을 추가적으로 언급하면서 마무리할 수 있다.

• API 계층의 규모 확장성 확보 방안: 무상태 서버이므로 수평적 규모확장 가능성에 대해 언급한다.
• 데이터베이스 게층의 규모 확장성 확보 방안: 데이터베이스의 다중화와 샤딩 방법에 대해 언급한다.
• 라이브 스트리밍은 실시간으로 녹화하고 방송하는 절차이므로, 스트리밍 프로토콜 선정에 유의해야 한다. 최대한 응답지연이 낮아야 한다.
• 비디오 삭제 : 저작권 위반, 선정적 비디오는 내려야한다.

 

 

* 위 글은 가상 면접 사례로 배우는 대규모 시스템 설계 기초 14장 유튜브 설계에 대해 정리한 글입니다.