- 유투브에는 단순 비디오 시청 이외에 많은 일이 있음
- 댓글, 공유, 좋아요, 구독, 플레이리스트 등
- 적절한 질문 통해 설계 범위 좁힐 것
- 기능: 비디오 업로드, 시청
- 지원 클라이언트: 모바일 앱, 웹 브라우저, 스마트 TV
- DAU: 5 백만
- 유저 평균 소비 시간: 30분
- 다국어 지원 유무: Y
- 지원 해상도: 현존하는 대부분 비디오 종류와 해상도 지원
- 암호화 필요 유무: Y
- 비디오 파일 크기 제한: 1GB
- 클라우드 서비스 활용 유무: Y
- 본 챕터에선 아래와 같은 기능에 집중
- 빠른 비디오 업로드
- 원활한 비디오 재생
- 재생 품질 선택 가능
- 낮은 인프라 비용
- 고가용성, 규모확장성, 안정성 보장
- DAU: 5백만
- 한 사용자는 하루 평균 5개 시청
- 10% 사용자가 하루에 1개의 비디오 업로드
- 비디오 평균 크기는 300MB
- 비디오 저장을 위해 매일 요구되는 저장 용량 = 5백만 * 10% * 300MB = 150TB
- CDN 비용 (아마존 CloudFront 기준 1GB 당 $0.02): 5백만 * 5개 * 0.3GB * $0.02 = $150,000
- 비용이 매우 높기에 상세 설계에서 비용 최적화 살펴볼 예정
- CDN 과 BLOB Storage 는 기존 클라우드 서비스 활용
- 시스템 설계 면접은 모든것을 직접 만드는 것과는 무관
- 주어진 시간 내 적절한 기술을 골래 설계하는 것이 더 중요
- 개략적으로 보면 아래와 같이 3개의 컴포넌트로 구성
- client: 컴퓨터, 모바일, 스마트 TV 로 유투브 시청 가능
- CDN: 비디오는 CDN 에 저장. 재생 버튼 클릭 시 CDN 에서 스트리밍 이뤄짐
- API 서버: 비디오 스트리밍을 제외한 모든 요청 처리. 피드 추천, 비디오 업로드 URL 생성, 메타데이터 DB 와 캐시 갱신, 회원가입 등
- 면접관이 아래의 2개 영역 설계 요구했다 가정
- 비디오 업로드 절차
- 비디오 스트리밍 절차
- LB: API 서버로의 요청 분산
- API 서버: 비디오 스트리밍 이외의 모든 요청 처리
- Metadata DB: 비디오의 메타데이터를 보관하며 Sharding 과 replication 적용하여 성능 및 고가용성 보장
- Metadata Cache: 성능향상을 위해 비디오 메타데이터와 사용자 객체 캐싱
- 원본 저장소: 원본 비디오를 보관할 대형 이진 파일 저장소 (BLOB; Binary Large Object Storage)
- 트랜스코딩 서버: 비디오 트랜스코딩은 비디오 인코딩과 같은 말로, 비디오의 포맷 (mpeg, hls 등) 을 변환하는 절차. 단말이나 대역폭 요구사항에 맞는 최적의 비디오 스트림 제공하기 위해 필요
- 트랜스코딩 비디오 저장소: 트랜스코딩이 완료된 비디오를 저장하는 BLOB 저장소
- CDN: 비디오 캐싱을 담당하며, 비디오 스트리밍은 CDN 을 통해 이뤄짐
- 트랜스코딩 완료 큐: 비디오 트랜스코딩 완료 이벤트를 보관할 메시지 큐
- 트랜스코딩 완료 핸들러: 트랜스코딩 완료 큐에서 이벤트 데이터 꺼내 metadata cache 와 metadata db 를 갱신할 작업 서버들
- 비디오 업로드는 아래의 두 프로세스가 병렬적으로 수행된다고 보면 됨
- 비디오 업로드
- 비디오 metadata 갱신. metadata 에는 video url, 크기, 해상도, 포맷, 사용자 정보 등이 포함
- 비디오를 원본 저장소에 업로드
- 트랜스코딩 서버는 원본 저장소에서 비디오 가져와 인코딩 시작
- 트랜스코딩 완료 후 아래 두 절차가 병렬 실행
- 3a. 완료된 비디오를 트랜스코딩 비디오 저장소에 업로드
- 3b. 트랜스코딩 완료 이벤트를 트랜스코딩 완료 큐에 추가
- 3a. 트랜스코딩 완료 비디오를 CDN 에 업로드
- 3b. 완료 핸들러가 이벤트 데이터를 큐에서 꺼냄
- 3b.1.a, 3b.1.b. 완료 핸들러가 metadata db 와 cache 를 갱신
- API 서버가 client 에게 동영상 업로드가 끝나서 스트리밍 준비가 되었음을 알림
- 원본 저장소에 파일이 업로드되는 동안, client 는 병렬적으로 비디오 metadata 갱신 요청을 api 서버에 보냄
- 이 요청에 포함된 meatadata 로는 파일명 크기, 포맷 등의 정보가 있음
- API 서버는 이 정보로 metadata cache 와 DB 를 업데이트
- 스트리밍 프로토콜: 비디오 스트리밍을 위해 데이터를 전송할 때 쓰이는 표준화된 통신방법으로 MPEG-DASH, HLS 등이 많이 쓰임
- 프로토콜마다 지원하는 비디오 인코딩이 다르고 플레이어도 다르기 때문에 비디오 스트리밍 서비스 설계 시 서비스 용도에 맞는 프로토콜 잘 선택해야 함
- 비디오는 CDN 에서 바로 스트리밍되며, client 에 가장 가까운 CDN edge server 가 비디오 전송을 담당하게 되기에 전송지연은 매우 낮음
- 비디오 업로드 / 스트리밍 부분의 최적화 방안과 오류 처리 메커니즘 소개할 예정
- 비디오를 녹화하면 단말은 비디오를 특정 포맷으로 저장함
- 이 비디오가 타 단말에서도 잘 재생되려면 다른 단말과 호환되는 bitrate 와 포맷으로 저장되야 함
- 비트레이트는 비디오를 구성하는 비트가 얼마나 빨리 처리되야 하는지를 나타내는 단위
- 비트레이트가 높은 비디오는 일반적으로 고화질 비디오
- 비디오 트랜스코딩은 아래와 같은 이유로 중요
- 가공되지 않은 비디오는 저장 공간 많이 차지
- 상당수의 단말과 브라우저는 특정 종류의 비디오 포맷만 지원하기에 호환성 문제 해결 위해 하나의 비디오를 여러 포맷으로 인코딩해 두는 것이 좋음
- 유저에게 끊김없는 고화질 비디오 재상을 보장하려면 네트워크 대역폭이 충분하지 않은 사용자에겐 저화질 영상을, 대역폭이 충분한 유저에겐 고화질 영상을 보내는 것이 바람직
- 모바일 단말의 경우 네트워크 상황이 수시로 달라질 수 있으며, 비디오의 끊김없는 재생을 위해서 비디오 화질을 자동 / 수동으로 변경할 수 있도록 하는것이 바람직
- 인코딩 포맷은 아주 다양하지만 크게 두 부분으로 구성
- 컨테이너: 비디오 파일, 오디오, 메타데이터를 담는 바구니 같은 것으로 컨테이너 포맷은 .avi, .mp4 등의 파일 확장자를 보면 알 수 있음
- 코덱: 비디오 화질은 보존하면서 파일 크기를 줄일 목적으로 고안된 압축 및 압축 해제 알고리즘으로 H.264, HEVC 등이 널리 사용됨
-
비디오 트랜스코딩은 컴퓨터 자원 많이 소모하고 시간도 많이 걸리며 컨텐츠 창작자는 각자 자기만의 비디오 프로세싱 요구사항이 있음 (워터마크, 커스텀 썸네일 등)
-
이런 각기 다른 유형의 비디오 프로세싱 파이프라인을 지원하는 한편, 처리과정의 병렬성 향상을 위해선 적절한 수준의 추상화를 도입해 client 프로그래머로 하여금 실행할 task 들을 손수 정의할 수 있도록 해야 함
- ex) 페북 스트리미이 비디오 엔진은 DAG 모델을 도입해 작업을 단계별로 배열할 수 있도록 하여 해당 작업들이 순차적/병렬적으로 실행될 수 있도록 하고 있음
- 본 설계에서도 유사한 DAG 모델을 도입해 유연성과 병렬성을 달성할 수 있도록 할 것
-
- 원본 비디오는 비디오, 오디오, 메타데이터의 3부분으로 나뉘어 처리됨
- 비디오 작업
- 비디오 인코딩: 비디오를 다양한 해상도, 코덱, 비트레이트 조합으로 인코딩
- 썸네일: 사용자가 업로드한 이미지나 비디오에서 자동 추출된 이미지로 썸네일 생성하는 작업
- 워터마크: 비디오에 대한 식별정보를 이미지 위에 오버레이 형태로 띄워 표시하는 작업
- 비디오 인코딩: 비디오를 다양한 해상도, 코덱, 비트레이트 조합으로 인코딩
- 클라우드 서비스를 활용한 비디오 트랜스코딩 아키텍쳐로, 5개의 주요 컴포넌트로 구성됨
- 비디오 분할: 비디오 스트림을 GOP (Group Of Pictures) 라 불리는 단위로 분할. GOP 는 특정 순서로 배열된 프레임 그룹. 하나의 GOP 는 독립적으로 재생이 가능하며, 보통 몇 초 정도의 길이
- DAG 생성: 클라이언트 프로그래머가 작성한 설정 파일에 따라 DAG 생성
- 데이터 캐시: 전처리기는 분할된 비디오의 캐시이기도 함. 안정성 향상을 위해 전처리기는 GOP 와 메타데이터를 임시 저장소에 보관. 인코딩 실패 시 시스템은 이 임시 저장소에 보관된 데이터 활용해 인코딩 재개
- DAG 스케줄러는 DAG 를 몇개의 stage 로 분할한 뒤 그 각각을 자원 관리자의 작업 큐에 넣음
- 위 그림은 하나의 DAG 그래프를 2개 작업 stage 로 쪼갠 사례
- 첫 단계에선 비디오, 오디오, 메타데이터를 분리
- 두번째 단계에선 해당 비디오 파일을 인코딩, 썸네일 추출, 오디오 파일 인코딩 진행
- 자원 배분을 효과적으로 수행하는 역할을 담당하며 3개의 큐와 작업 스케줄러로 구성
- 작업 큐: 실행할 작업이 보관될 우선순위 큐
- 작업 서버 큐: 작업 서버의 가용 상태 정보가 보관된 우선순위 큐
- 실행 큐: 현재 실행중인 작업 및 작업 서버 정보가 보관된 큐
- 작업 스케줄러: 최적의 작업/서버 조합을 골래 해당 서버가 작업을 수행하도록 지시하는 역할 담당
- 작업 관리자 동작 순서
- 작업 관리자는 작업 큐에서 가장 높은 우선순위 작업 꺼냄
- 작업 관리자는 해당 작업을 수행하기 적절한 서버 선택
- 작업 스케줄러는 해당 작업 서버에게 작업 실행 지시
- 작업 스케줄러는 해당 작업이 어떤 서버에 할당됐는지에 관한 정보를 실행 큐에 넣음
- 작업 스케줄러는 작업이 완료되면 해당 작업을 실행 큐에서 제거
- 작업 서버는 DAG 에 정의된 작업을 수행하며 아래 그림처럼 작업 종류에 따라 작업 서버도 구분해서 관리
- 임시 저장소 구현엔 여러 저장소 시스템 활용 가능
- 저장할 데이터 유형, 크기, 이용빈도, 데이터 유효기간 등에 따라 적절히 선택
- 메타데이터는 작업 서버가 빈번히 참조하며 데이터 크기도 작음 -> 메모리 캐싱
- 비디오/오디오 데이터 -> BLOB
- 임시 저장소에 보관한 데이터는 비디오 프로세싱 완료시 삭제
- 인코딩 된 비디오는 인코딩 파이프라인의 최종 결과물
- 속도, 안정성, 비용 측면에서 시스템 최적화 진행
- 비디오 전체를 한번에 업로드하는 것은 비효울적이기 때문에 하나의 비디오를 아래와 같이 작은 GOP 들로 분할해서 업로드 가능
- 이렇게 분할한 GOP 를 병렬적으로 업로드하면 일부 실패시에도 빠르게 재개 가능
- 비디오를 GOP 경계에 맞춰 분할하는 작업을 단말이 수행하면 아래와 같이 업로드 속도 향상 가능
- 업로드 센터를 여러곳에 두는 방법
- 본 설계안 기준으로는 미국 거주자의 경우 북미 CDN 에 업로드, 한국은 아시아 CDN 으로 업로드 하는 등의 방식 가능
- 느슨하게 결합된 시스템을 만들어 병렬성 향상
- 비디오를 원본 저장소에서 CDN 으로 옮기는 절차를 보면 전 단계 결과를 가지고 처리하기 때문에 의존성 높으며, 이런 경우 병렬성 높이기 어려움
- 이 시스템 결합도를 낮추기 위해 MQ 도입
- MQ 도입 이후 각 보듈들은 이전 모듈 작업 끝나기를 기다릴 필요가 없으며, 메시지 큐에 보관된 이벤트 각각을 병렬 처리 가능
- 허가받은 사용자만 올바른 장소에 비디오 업로드가 가능하도록 pre-signed 된 URL 을 이용
- 이를 적용한 업로드 절차
- client 는 http 서버에 post 요청해서 pre-signed url 받음. 해당 url 이 가리키는 객체에 대한 접근 권한이 이미 주어진 상태임
- pre-signed url 은 S3 에서 쓰이는 용어로 타 서비스에선 명칭 다를 수 있음
- API 서버는 pre-signed url 을 돌려줌
- client 는 해당 url 이 가리키는 위치에 비디오 업로드
- client 는 http 서버에 post 요청해서 pre-signed url 받음. 해당 url 이 가리키는 객체에 대한 접근 권한이 이미 주어진 상태임
- 저작권 보호를 위해 아래 세가지 정책 중 하나를 채택 가능
- DRM (Digital Rights Management) 도입: Apple 의 FairPlay, Google의 Widevine, MS의 PlayReady 가 많이 쓰임
- AES 암호화 (Encryption): 비디오 암호화하고 접근 권한을 설정. 암호화된 비디오는 재생 시에만 복호화. 허락된 사용자만 암호화된 비디오 시청 가능
- 워터마크
- CDN 이 스트리밍의 핵심이지만 값비쌈
- 연구 결과에 따르면 유투브의 비디오 스트리밍은 long tail 분포를 따름
- 즉, 인기있는 비디오는 자주 재생되는 반면, 나머지는 거의 안본다는 사실에 착안해 몇가지 최적화 시도 가능
- 인기있는 비디오는 CDN 을 통해 재생 / 나머지는 Video server 를 통해 재생
- 인기가 별로 없는 비디오는 인코딩할 필요 자체가 없을 수도 있음. 또한 짧은 비디오라면 필요 시 인코딩해서 재생 가능
- 어떤 비디오는 특정 지역 내에서만 인기가 높은 경우도 있음. 이런 비디오는 다른 지역에 옮길 필요가 없음
- CDN 을 직접 구축하고 ISP (Internet Service Provider) 와 제휴
- 인기있는 비디오는 CDN 을 통해 재생 / 나머지는 Video server 를 통해 재생
- 대형 시스템에서 오류는 불가피하기에 highly fault-tolerant 한 시스템을 만들려면 오류를 깔끔하게 처리하고 빠르게 회복해야 함
- 시스템 오류엔 2가지가 있음
- 회복 가능 오류: 특정 비디오 세그먼트 트랜스코딩 실패 등이 그 예이며 대부분 몇번 재시도하면 되지만, 계속 실패하는 경우 client 에 적절한 오류 코드 반환해야 함
- 회복 불가능 오류: 비디오 포멧 에러 등이 그 예이며, 시스템은 해당 비디오에 대한 작업을 중단하고 client 에 적절한 오류 코드 반환해야 함
- 시스템 컴포넌트마다 발생가능한 오류와 전형적인 해결법
- 업로드 오류: 재시도
- 비디오 분할 오류: 낡은 버전의 클라이언트가 GOP 경계에 따라 비디오를 분할하지 못하는 경우, 전체 비디오를 서버로 전송하고 서버가 비디오 분할 처리
- 트랜스코딩 오류: 재시도
- 전처리 오류: DAG 그래프 재생성
- DAG 스케줄러 오류: 작업 재 스케줄링
- 자원 관리자 큐에 장애 발생: replica 이용
- 작업 서버 장애: 다른 서버에서 재시도
- API 서버 장애: API 서버는 stateless 이므로 신규 요청은 타 API 서버로 우회될 것
- metadata cache 서버 장애: 데이터는 다중화되어있으므로 타 노드에서 데이터를 여전히 가져올 수 있음. 장애 난 캐시 서버는 새로운 서버로 교체
- metadata database 서버 장애: 주 서버가 죽은경우 부 서버중 하나를 주 서버로 교체, 부 서버가 죽은 경우 다른 부 서버를 통해 읽기 연산 처리 후 죽은 서버 교체
- 설계 후 시간 남으면 다음 내용 추가 논의해보면 좋음
- API 계층의 규모 확장성 확보: API 서버의 수평적 규모 확장
- DB 계층의 규모 확장성 확보: DB 다중화 / 샤딩
- 라이브 스트리밍: 일반 비디오 스트리밍과 큰 차이는 라이브 스트리밍의 경우 응답 지연이 더 낮아야 하기에 프로토콜 선정에 유의해야 한다는 점과, 라이브 스트리밍의 경우 병렬화 필요성은 떨어지는데 이는 작은 단위의 데이터를 실시간으로 빨리 처리해야 하기 때문
- 비디오 삭제