스트리밍 서비스 구축 (feat. AWS)
많은 숏폼 콘텐츠를 동시에 소비하기 위한 생각들
e커머스 플랫폼이 상품을 소구 하는 방식은 다양하다.
전통적으로는 사진과 텍스트를 통한 방법이 있고, 화려한 CSS를 동반한 신제품 소개도 있으며 (애플의 아이폰 같은), 전문가/인플루언서를 활용하여 간접적으로 상세한 리뷰를 볼 수 있는 영상 콘텐츠도 있다.
그중 우리는, 15초 내로 핵심만 임팩트 있게 전달할 수 있는 숏폼 콘텐츠를 강화하기로 했다.
...
아 맞다.. 우린 동영상 서비스를 위한 인프라가 없다.
Working Backwards
거꾸로 일하라.
Amazon의 일하는 방식에는 고객에서부터 시작하여 기능 단계로 거슬러 올라가는 Working Backwards 접근 방식이 있다. 좋은 상품을 준비하여, 마케팅을 하고, 고객에게 판매하는 것이 아니라, 해결해야 할 문제를 가진 고객을 우선 정의하고, 그들에게 마케팅할, 좋은 제품을 찾는 것을 말한다.
이건 어느 경우에라도 적용 가능한 좋은 방법론인데, 우리는 서비스 자체가 아니라 숏폼 서비스를 위한 동영상 인프라 구축에 활용해보기로 했다.
우선 첫째로, 많은 동영상을 제공할 수 있어야 한다.
매일 올라오는 신상품 중 짧은 영상만으로 고객에게 아하-모먼트를 줄 수 있다면 담당 부서에서는 숏폼 영상 준비에 더 많은 시간을 할애하고, 그만큼 더 많은 영상을 제작할 것이다.
많은 영상을 지속적으로 재생하기 위해서는, 영상 간에 빠른 전환이 가능해야 한다.
숏폼 콘텐츠는 빠르게 소비된다는 특징이 있다. 15초 정도 분량의 영상이 제작되었으나 사용자는 영상 시작 후 임팩트 있는 전개가 없다면 바로 다음 영상으로 넘어갈 것이다. 심지어 손가락 제스처 하나만으로.
많은 영상을 빠르게 재생하려면 개별 동영상의 용량이 적어야 한다. 불가피한 사유로 동영상 용량을 줄일 수 없다면 전송 속도를 개선할 방법도 함께 찾아야 한다.
결국, 원활한 숏폼 서비스 운영을 위해서는 작은 용량, 빠른 로딩 속도, 다량의 처리가 중요하게 되어 영상 콘텐츠는 스트리밍 서비스로 구축하기로 했다.
스트리밍 서비스에서 사용한 가능한 포맷들을 확인한 결과, 국제 표준으로 채택된 MPEG-DASH와 Apple에서 개발한 HLS(HTTP Live Streaming)가 주로 사용되는 것 같은데, 기능/성능면에서는 큰 차이가 없어 보인다.
다만 한 가지가 큰 차이가 있는데.....
MPEG-DASH HLS
HTTP 프로토콜 기반 HTTP 프로토콜 기반
(ABS) 적응형 비트 스트리밍 가능 (ABS) 적응형 비트 스트리밍 가능
모든 코덱 사용 가능 H.264, H.265 사용 가능
iOS, iPadOS, MacOS 사용 불가 모든 장치 사용 가능
*적응형 비트 스트리밍(Adaptive Bitrate Streaming)
사용자의 대역폭과 CPU 사용률 등을 참조하여 스트림의 품질을 자동 조정
MPEG-DASH의 경우, 아이폰을 비롯한 애플의 OS에서는 재생이 되지 않는다.
MPEG-DASH로 개발하는 경우, iOS 사용자를 위해 MP4 등을 추가로 준비해야 하는데, 굳이 이렇게까지 준비해 가며 DASH를 사용할 이유는 없어 보인다.
대부분 이 이유로 HLS를 선택했을 거라 추정하고, 우리도 HLS 포맷으로 채택했다.
HLS 포맷 영상 만들기
우리가 가진 숏폼 콘텐츠의 원본은 MP4인데,
유저(영상 담당자) 입장에서 가장 간편한 방법을 찾아 백오피스 시스템에 파일 업로드하는 것 만으로 HLS포맷 변환도 하고, 규격에 맞게 해상도도 바꾸고, 파일 용량도 줄일 수 있는, 꿩 먹고 알 먹고, 마당 쓸고 돈 줍는 프로세스를 찾아보았고, 좋은 방법을 찾는데 그리 오래 걸리지 않았다.
아래는 AWS에서 제공하는 온디맨드 비디오 제작 가이드인데,
딱 내가 구현하려는 서비스 구성을 가이드해주고 있었고, CloudFormation 템플릿 파일을 통해 마법같이 몇 분만에 구성을 확인해볼 수 있었다.
(템플릿 파일을 통해 구성 구현 시, 워낙 많은 부분의 서비스와 정책이 자동 생성되고 변경되어 향후 장애 대응이나 메인터넌스 측면을 고려했을 때 직접 만드는 게 낫다고 판단했고, 실제 운영 환경에서는 이 파일을 사용하지 않고 모든 서비스를 직접 구축함)
온디맨드 비디오 구현에 대한 AWS 공식 문서
https://aws.amazon.com/ko/solutions/implementations/video-on-demand-on-aws/
AWS Foundation 기반 온디맨드 비디오 솔루션 구현 개요위 구성 중 주요 내용은 다음과 같다.
1. Amazon S3의 source 버킷에 MP4 파일을 업로드
버킷 내 파일 업로드에 대한 S3 트리거가 작동하여 Lambda 호출
2. Lambda(job submit)를 통해 MP4 파일에 대한 HLS 변환 MediaConvert 작업 등록
인코딩 스펙은 job.settings 파일을 통해 결정됨
3. MediaConvert 가 실행되고, HLS 파일이 destination 버킷에 저장
한 개의 MP4는 재생시간 길이에 따라 여러 개의 ts 파일 조각으로 나누어 저장되고,
이들의 재생목록은 m3u8 파일을 통해 관리됨.
8. S3의 m3u8 파일 호출 시, CDN을 통해 ts 파일 전송
HLS 포맷으로의 변환은 job.settings 파일을 통해 세부 스펙이 결정되는데, json 파일에서 컨트롤 가능한 항목이 굉장히 방대하다. 자세한 내용은 아래 링크를 참조.
(우리는 CloudFormation 템플릿에서 얻은 기본 파일을 활용하여 몇몇 설정만 수정해서 사용한다.)
https://docs.aws.amazon.com/ko_kr/mediaconvert/latest/ug/example-job-settings.html
HLS 포맷
너무 쉽게 (AWS 가 다 해주는 바람에) 영상 스트리밍 처리가 완료되었다.
Apple 이 개발한 HLS 포맷은 HTTP 만으로 구현이 가능하고, 긴 영상을 여러 청크 파일로 나누어 저장하는 구조여서 첫 번째 ts 파일만으로도 빠른 재생 시작이 가능하고, 영상의 중간 부분으로의 전환도 빠르게 처리할 수 있다.
50메가 영상 중 첫 번째 ts(1MB)를 통해 재생을 시작하고, 러닝타임에 따라 그다음 ts를 전송받는 것을 볼 수 있다.
HLS 포맷에 대해서는 아래 글에서 잘 설명되어 있으니 참고.
NAVER D2 - HTTP Live Streaming
https://d2.naver.com/helloworld/7122
스트리밍에 대해서는 아래 글에서 잘 설명되어 있으니 참고.
6단계로 알아보는 라이브 생방송 송출 원리
https://medium.com/naver-cloud-platform/
스트리밍 영상 재생
기기와 관계없이 통일된 방식의 재생 가능 방법을 찾아야 하는데, 요즘 웹브라우저 시장은 Webkit 아니면 Blink 기반이므로 이 부분도 크게 고민할 게 없어 보였다.
다만, 동영상 플레이어에는 기획팀의 몇 가지 요구사항이 있었는데,
- 영상을 컨트롤하는 기능은 화면에 보이지 않아야 함
- 영상 재생 전에는 영상에 대한 썸네일 이미지가 제공돼야 함
- 영상이 반복 재생 가능해야 함
- 영상 재생 수를 카운트할 수 있어야 함
놀랍게도 이 모든 게 가능한 오픈소스 라이브러리 Video.js 가 있었고, 우리는 서비스 핵심 기능 개발에 집중할 수 있었다. 게다가 HLS 가 제공하는 ABS 기능은 사용자의 네트워크 대역폭에 맞춰 적절한 영상 파일을 자동 선택함으로써 품질과 속도의 균형을 맞춘 영상 재생이 가능하게 하고 있다.
앞으로 우리의 숏폼 서비스는 새로운 상품의 정보를 다각도로 해석한 콘텐츠로 무장하여
고객들의 흥미와 관심을 이끌 정보 제공의 수단으로 활용할 계획이다.
감사합니다.
