Introduce
프로젝트를 진행하던 중 카메라로 촬영되어 Synology NAS에 저장된 경기의 영상을 개발중인 플랫폼에서 시청해야 하는 기능이 필요했다. 해당 기능을 개발하며 조금은 다사다난했던 영상 스트리밍 시스템을 구축한 과정에 대해서 알아보자.
Requirements
영상 스트리밍 시스템의 요구사항은 다음과 같았다.
1. NAS에 저장된 영상을 개발한 앱 플랫폼에서 시청할 수 있어야 한다.
2. 영상 촬영 시간의 단위는 1시간이다.
요구사항을 말로만 들었을 때는 그렇게 어려워보이지 않았다. 이전에 이미지 로딩 관련 이슈를 다루며 CloudFront를 사용했던 경험이 있었기 때문에 영상도 CloudFront를 통해 스트리밍하면 되지 않을까 라는 생각을 하였고 이를 토대로 시스템 구축을 진행했다.
Initial Design
초기 디자인은 정말 별것 없었다. 시놀로지에 저장되어 있는 영상을 S3와 동기화 시킨 후, CloudFront를 통해 스트리밍을 하도록 설계하였다. 초기 설계를 하면서 시놀로지 저장소와 S3 버킷 동기화가 제일 고민이었는데 이는 천만다행히도 Cloud Sync라는 시놀로지 내부의 앱을 통해 해결할 수 있었다. Cloud Sync에서 동기화할 S3 버킷과 시놀로지 저장소 폴더를 직접 선택할 수 있었고 이를 통해 동기화 문제를 해결할 수 있었다. (시놀로지 만세)
이전에 사용해보았던 기술스택들이었어서 해당 작업을 진행하는데는 생각보다 오래 걸리지 않았다. 구현이 완료된 후 S3에 작은 길이의 영상을 업로드한 후 CloudFront를 통해 스트리밍 테스트를 진행해보았다.
위의 사진과 같이 잘 스트리밍 되는것을 확인할 수 있었다. 하지만 위의 요구사항에서 보았듯 촬영하는 영상 길이의 단위는 1시간이었다.
1시간짜리 영상으로 테스트를 하려했으나 현재는 카메라에 대한 테스트를 위해 30분 단위로 영상을 촬영중이었고, 1시간은 안되지만 1분 37초보다는 훨씬 긴 30분짜리 영상을 동일한 방법으로 테스트해보았다.
영상의 길이가 길어짐에 따라 파일의 용량 크기도 늘어났고, 이로 인해 영상을 로드하지 못하거나(Timeout으로 인해) 로드하는 시간이 너무 오래 걸리는 문제점이 발생하게 되었다. 이에 따라 경기 전체 영상을 한번에 스트리밍하는 방법이 아닌 다른 방법이 필요했다.
HLS
HLS란?
HLS(HTTP 라이브 스트리밍)은 가장 널리 사용되는 비디오 스트리밍 프로토콜이다. HLS는 비디오 파일을 다운로드할 수 있는 파일 조각(세그먼트)으로 나누고 이 ts 파일을 계속 요청하여 재생하는 방식으로 스트리밍이 진행된다.
HLS 변환 과정
1. 인코딩
비디오 데이터의 포맷을 다시 설정하여 모든 장치가 데이터를 인식하고 해석할 수 있게 합니다. HLS는 H.264나 H.265 인코딩을 사용해야 합니다.
2. 조각화
비디오를 몇 초 길이의 세그먼트로 나눈다. 세그먼트 길이는 다양하지만 현 프로젝트에서는 10초로 적용하였다.
3. 세그먼트 순서 기록
비디오를 세그먼트로 나누는 것과 더불어 HLS는 비디오 세그먼트의 인덱스 파일을 만들어 세그먼트의 순서를 기록한다. 이 순서는
m3u 또는 m3u8 확장자로 저장되는데 해당 파일을 열어보면 각 줄마다 재생할 영상의 위치를 저장하는 단순한 구조이다.
이처럼 HLS의 스트리밍 방식은 작은 크기의 세그먼트들을 지속적으로 사용자가 다운로드받는 것(버퍼링)이기 때문에 영상을 HLS로 변환을 하여 CDN으로 제공하면 영상의 크기가 크더라도 신속하게 스트리밍을 할 수 있을것 같다는 결론을 내리게 되었다.
MediaConvert vs FFmpeg
영상 파일을 HLS로 변환하기 위해 많이 사용하는 도구를 찾아보게 되었고 대표적으로 MediaConvert, FFmpeg 두가지 정도를 찾을 수 있었다.
MediaConvert란?
AWS Elemental MediaConvert는 AWS에서 제공하는 클라우드 기반 동영상 트랜스코딩1 이다.
장점
- AWS에서 완전 관리형으로 제공되므로 서버 관리와 설정에 신경 쓸 필요가 없다.
- 대규모 트랜스코딩 작업도 자동으로 처리 가능하다.
- HLS 변환에 특화되어 있고, 다양한 품질 프로파일을 자동으로 생성한다.
- S3, CloudFront 등의 통합으로 스트리밍 워크플로우를 간단히 구성 가능하다.
- IAM 및 S3 버킷 정책을 통해 안전하게 작업 가능하다.
단점
- 사용량에 따라 비용이 발생하며, 고화질 비디오를 처리할 경우 비용이 증가할 수 있다.
- FFmpeg처럼 복잡한 맞춤 설정이 어려울 수 있다.
FFmpeg란?
FFmpeg은 오디오 및 비디오의 녹화, 변환, 스트리밍을 처리할 수 있는 강력한 오픈소스 멀티미디어 프레임워크이다.
장점
- 다양한 포맷, 코덱, 옵션을 세부적으로 커스터마이징이 가능하다.
- 오픈소스이므로 트랜스코딩 자체에는 비용이 들지 않는다.
- 서버에서 직접 실행되므로 작업 흐름을 완전히 제어 가능하다.
- 복잡한 필터링, 색상보정, 자막 삽입 등 추가 기능을 쉽게 구현 가능하다.
단점
- 서버 설정, 확장성, 로드 밸런싱 등을 직접 관리해야 한다.
- 명령어와 스크립트를 작성해야 하므로 러닝 커브가 있다.
- 대규모 트랜스코딩 작업은 수동으로 확장하거나 추가 설정이 필요하다.
간단하게 두가지를 조사 후 현재 프로젝트의 상황에 대해 생각하며 어떠한 도구를 사용할지 생각해보았다.
1. 비용은 어느정도 감수할 수 있다.
2. 빠른 시간 내에 스트리밍 서비스를 개발해야 한다.
3. 현재 AWS S3, CloudFront, Lambda를 사용하고 있다.
Second Design
이를 통해 MediaConvert를 사용하여 HLS 변환을 하여 스트리밍 하기로 결정을 내리게 되었고 아래의 방식과 같이 MediaConvert에서 작업 템플릿을 지정해 주었다.
비디오 코덱, 화질, 인코딩된 영상의 저장위치 등 많은 것을 설정할 수 있었고 무엇보다 좋았던 것은 해당 작업 설정을 JSON파일로 추출할 수 있는 것이었다.
이로 인해 Lambda함수에서 MediaConvert 작업을 생성하는 로직을 작성할때 JSON파일을 통해 쉽게 적용할 수 있었고 설계를 아래와 같이 변경할 수 있었다.
시놀로지에 영상을 업로드 시 S3와 동기화가 되면서 S3에도 동일하게 원본영상이 업로드 → S3에서 PutEvent가 발생하면 이를 AWS Lambda 함수에서 이벤트를 캐치하여 업로드된 영상에 대해 HLS 변환을 시작 → 변환이 완료된 파일들을 S3의 output 폴더에 저장 후 CloudFront를 통해 제공
Cost Issue
HLS 변환을 통해 스트리밍 문제는 해결하였으나 몇주 뒤 AWS 청구서에서 놀라운 것이 발견되었다.
MediaConvert에서 210$의 요금이 나온 것이다. 적은 금액이 절대 아니었다....다행히 AWS 고객센터에 문의하여 환불을 받았다..
현재 S3에 저장된 영상의 양은 1달치 정도였는데 여기에서 문제점이 시작되었다. MediaConvert는 사용량에 비례하여 요금이 나오 때문에 이러한 일이 발생한 것 같았다. 매달 200$씩의 비용이 발생하는 것은 치명적이었고 이를 줄일 방법이 꼭 필요했다...
Next
다음 시간에는 이 MediaConvert의 비용 이슈를 어떻게 해결하였는지, 그 후 어떠한 방식으로 영상 스트리밍 시스템이 완성되었는지에 대한 내용에 대해 다룰 것이다.
- 하나의 미디어 포맷을 다른 미디어 포맷으로 변환하는 작업 [본문으로]
'AWS' 카테고리의 다른 글
| MediaConvert를 통한 영상 스트리밍 시스템 구축 - 2 우리는 자선단체가 아니다!! (0) | 2025.06.03 |
|---|