나만의 동영상 스트리밍 시스템 설계하기 - (2. 업로드/재생 설계)

 

나만의 동영상 스트리밍 시스템 설계하기 - (1) 에 이어서 작성되는 글입니다!

나만의 동영상 스트리밍 시스템 설계하기

1. 선택한 동영상 처리 방법들과 그 이유

동영상 스트리밍 시스템을 설계하기 전, 현재 나의 서비스 상황을 아래와 같다.

모든 시스템을 설계할 때에는 상황에 맞춰 방법들을 선택하는 것이 좋다.

 

현재 동영상 스트리밍 시스템을 구축하고자 하는 서비스는 띵동이라는 서비스이다.

띵동은 명지대학교 동아리 통합 플랫폼으로, 다음과 같은 특성을 가지고 있다.

 

시청(스트리밍) 대상: 약 10,000명 (전체 학우)

시청(스티리밍) 환경: 불안정한 대학 와이파이 ****

업로더: 약 400명 (동아리 회장 및 운영진)

기존 제약: 동영상 크기 300MB 이하만 업로드 가능

사용중인 클라우드 서비스: AWS

 

전체적으로 동영상 업로드 과정은 비동기 방식으로 처리하였다.

그 이유는 앞서 설명한 비동기 처리의 장점들(사용자 대기 시간 단축, 서버 리소스 효율성 등) 때문이다.

 

[업로드 방법 - 단일 Presigned URL 업로드]

 

업로드 방법으로는 단일 Presigned URL 업로드를 선택했다.

 

서버를 거쳐 파일을 업로드하는 방식을 적용하지 않은 이유는 다음과 같다.

단순 HTTP 업로드 방식은 300MB 파일이 업로드될 때마다 서버 메모리에 전체 파일을 적재해야 하고, 서버를 거치는 방식은 클라이언트→서버→S3로 이중 전송이 발생하여 서버 대역폭을 과도하게 소비한다.

청크 단위로 나누어 업로드하더라도 각 청크마다 서버 메모리를 사용하고, 청크 상태 추적을 위한 세션 정보 관리와 디스크 I/O가 발생하며, 서버가 모든 데이터 전송의 중간 경유지가 되어 대역폭을 점유한다는 근본적인 문제는 해결되지 않는다. 또한, 청크의 개수만큼 HTTP 요청이 복잡하며, 구현 복잡도가 높다.

 

S3 Multipart Upload(Presigned URL + chunk) 방법을 사용하지 않은 이유는 용량 제한과 구현 복잡도다. 용량이 300MB 제한으로 걸려있고, 사용자는 크기가 큰 동영상을 많이 업로드 하지 않았다. 또한, S3 Mutipart Upload보다, 단일 Presigned URL이 단순했다.

Presigned URL의 선택 이유는 앞에서 말했던 장점과 같다!

 

[트랜스코딩 설정 및 파이프라인 구축 방법 - 클라우드 관리형 서비스]

 

띵동 서비스는 트랜스코딩 파이프라인 구축을 위해 클라우드 관리형 서비스(AWS MediaConvert)를 선택했다.

 

동영상 트랜스코딩은 CPU와 메모리를 집중적으로 사용하는 무거운 작업이어서 동기 처리 방식을 선택하지 않았다. 또한, 자체 서버에서 FFmpeg을 직접 실행하는 방식도 고려했지만, 다음과 같은 이유로 AWS MediaConvert를 선택했다.

첫째, 인프라 구축 및 운영 부담이 없다.

트랜스코딩 서버를 직접 구축하여 생기는 인스턴스 프로비저닝, 장애 대응 등 비용이 사라진다.

둘째, 자동 확장성을 제공한다.

동아리 홍보 기간처럼 업로드가 몰리는 시기에도 자동으로 리소스를 확장하여 처리한다.

셋째, 초기 비용이 합리적이다.

띵동 서비스는 약 400명의 업로더를 대상으로 하며, 일일 업로드 수가 많지 않은 초기 단계이다.

MediaConvert는 사용한 만큼만 비용을 지불하는 종량제 방식이므로 초기에는 비용 부담이 크지 않다. 서울 리전 기준 SD 화질은 분당 약 $0.0085이다.

넷째, 간단한 설정만으로 다양한 출력을 생성할 수 있다.

HLS 세그먼트 분할, 여러 해상도 생성, 썸네일 추출 등 스트리밍에 필요한 기능을 Job 설정만으로 처리할 수 있다.

 

트랜스코딩 설정은 아래와 같다.

코덱과 프로토콜을 선정하는 데 있어 가장 중요하게 생각한 점은 호환성이다. 그래서 선택한 조합은 H264 + HLS 조합이다. 사실상 표준인 H264는 거의 모든 디바이스와 호환되고, HLS도 마찬가지다.

불안정한 네트워크속에 ABR을 지원하기 위해 240p, 480p, 720p 세 가지 해상도로 HLS 출력을 구성했다. 1080p 이상의 고화질을 제공하지 않는 가장 큰 이유는 비용때문이다. 사용자 대부분이 노트북이나 모바일에서 시청하는 환경을 고려하면 720p까지만으로도 충분한 화질을 제공할 수 있을 것이라 예상했다.

각 해상도별 비트레이트는 720p 4Mbps, 480p 2Mbps, 240p 0.5Mbps로 설정했고, 오디오는 AAC 코덱에 128kbps를 사용하여 충분한 음질을 제공하였다. HLS 세그먼트는 10초 단위로 분할하여 적응성과 효율성의 균형을 맞췄다.

추가적으로 fps(frame per second)는 원본 영상을 그대로 사용했고, 썸네일은 영상 첫 번째 프레임을 사용했다.

 

2. 동영상 업로드부터 재생까지 아키텍처 설명

앞서 선택한 방법들을 바탕으로 띵동 서비스의 전체 아키텍처를 구성했다. 사용자가 동영상을 업로드하고, 이를 처리하여, 최종적으로 시청자가 재생할 수 있기까지의 전체 과정을 단계별로 살펴보자.

[동영상 업로드 과정]

동영상 업로드 과정

동영상 업로드 파이프라인은 크게 5단계로 구성된다:

1. 사용자가 업로드를 위한 Presigned URL 요청
2. Presigned URL로 S3 원본 저장소에 직접 업로드
3. S3 원본 저장소에 동영상 저장 완료 후 Lambda 함수 자동 호출
4. Lambda 함수 실행
5. MediaConvert Job 실행

이제 각 단계를 자세히 살펴보자.

 

1단계는 Presigned URL 요청이다.

사용자가 동영상 업로드를 시작하면, 클라이언트는 먼저 백엔드 서버에 Presigned URL을 요청한다.

서버는 요청을 받아 파일 크기 검증 (300MB 이하인지 확인), 사용자 권한 확인 (동아리 운영진인지 확인), S3 Presigned URL 생성 (유효기간 5분)의 작업을 수행한다.

클라이언트는 이 URL과 함께 videoId, 만료 시간 등의 정보를 응답받는다.

 

2단계는 클라이언트는 응답받은 Presigned URL로 S3 원본 저장소에 직접 업로드한다.

 

3단계는 S3 원본 저장소에 원본 동영상 저장 완료 후 Lambda 함수를 호출한다.

동영상이 S3에 성공적으로 저장되면 S3 이벤트가 자동으로 발생하게 된다. 띵동 서비스는 S3 버킷의 원본 동영상 경로(prod/VIDEO/)에 ObjectCreated 이벤트 알림을 설정하여 Lambda 함수를 호출하도록 구성했다.

Lambda는 AWS의 서버리스 컴퓨팅 서비스로, 직접 작성한 함수 스크립트를 실행시켜주는 것이라 이해하면 된다.

 

Q. Lambda를 사용한 이유?

가장 큰 이유는 비용과 단순함이다.

Lambda가 아닌 선택지에는 EC2 or SQS + EC2가 있을 것 같은데, 이 방식들은 EC2로 워커서버를 생성해 메시지를 처리하는 구조다. 하지만 이 방식은 EC2가 항상 실행 중이어야 하므로 업로드가 없어도 월 $30~50의 고정 비용이 발생한다.
반면 Lambda는 S3 이벤트를 직접 트리거로 받아 파일이 업로드되는 순간 즉시 실행되며, 실행 시간만큼만 비용을 지불한다. 띵동 서비스처럼 월 100건 정도 업로드되는 경우 Lambda 비용은 월 $0.03 정도로 거의 무료 수준이다.

또한, EC2 or SQS + EC2는 서버 구축 및 운영 비용이 크고, 람다는 함수 로직만 작성하면 되서 편하다.

 

4단계는 Lambda 함수 실행이다.

Lambda가 S3 이벤트를 수신받고 실행되면 미리 정의된 트랜스코딩 설정(H.264 코덱, 240p/480p/720p 해상도, 10초 세그먼트)을 포함한 MediaConvert Job을 생성하여 실행한다.

 

5단계는 MediaConvert Job 실행이다.

MediaConvert는 AWS가 관리하는 서비스이므로, 모든 과정이 자동으로 확장되고 처리된다.

MediaConvert는 위에서 설명했던대로 트랜스코딩을 진행한다. 트랜스코딩이 완료된 후 변환된 파일은 미리 정의해놓은 Output S3 주소에 저장되게 된다.

 

이렇게 업로드가 마무리된다.

 

[동영상 재생 과정]

동영상 재생 과정

동영상 재생 과정은 크게 3단계로 구성된다:

1. 클라이언트가 서버에 동영상 정보 요청
2. 비디오 플레이어가 플레이리스트 다운로드 및 화질 선택
3. 세그먼트 파일 다운로드 및 적응형 스트리밍 재생

이제 각 단계를 자세히 살펴보자.

 

1단계: 동영상 정보 요청

시청자가 동영상을 클릭하면 클라이언트는 서버에 동영상 정보를 요청한다. 서버는 동영상 파일 상태를 확인하고, COMPLETED 상태인 경우에만 마스터 플레이리스트(master.m3u8) 파일의 CloudFront URL을 응답한다.

 

2단계: 플레이리스트 다운로드 및 화질 선택

비디오 플레이어는 CloudFront를 통해 마스터 플레이리스트를 다운로드한다. 마스터 플레이리스트에는 사용 가능한 화질 목록(720p, 480p, 240p)과 각 화질별 플레이리스트 위치가 담겨있다. 플레이어는 현재 네트워크 속도를 측정하여 적절한 화질을 선택한다. 예를 들어 6Mbps로 측정되었다면 안정적으로 재생 가능한 720p 4Mbps를 선택한다. 선택한 화질의 플레이리스트에는 10초 단위로 분할된 세그먼트 파일(.ts) 목록이 담겨있다.

 

3단계: 세그먼트 다운로드 및 적응형 재생

플레이어는 세그먼트 파일들을 순차적으로 다운로드하며 재생한다. 첫 번째 세그먼트(segment_0.ts)가 다운로드되면 바로 재생을 시작하고, 재생하는 동안 다음 세그먼트들(segment_1.ts, segment_2.ts...)을 미리 다운로드하여 끊김 없는 재생을 보장한다. 재생 중에도 플레이어는 지속적으로 네트워크 속도를 측정하여, 속도가 느려지면 자동으로 낮은 화질로 전환하고 빨라지면 높은 화질로 전환한다. 이것이 앞서 설명한 적응형 비트레이트 스트리밍(ABR)이다. 사용자는 화질이 순간적으로 조금 떨어지더라도 영상이 멈추지 않고 계속 재생되는 경험을 하게 된다.

 

 

지금까지 동영상 업로드/재생 설계에 대해 알아봤고, 다음 나만의 동영상 스트리밍 시스템 설계하기 - (3. 동영상 업로드 실시간 알람)로 이어집니다!