AWS 에서 리전 간의 탄력적인 라이브 스트리밍 아키텍처 구축하기

이 글은 AWS M&E 블로그의 Build a resilient cross-region live streaming architecture on AWS by Jamie Mullan, Andrew Fayle, and Christer Whitehorn의 한국어 번역입니다.

개요

라이브 스트리밍 비디오 사용 사례를 가진 고객은 라이브 스트리밍 서비스를 배포하는 방식에 있어 유연성을 원하는 경우가 많습니다. 모든 라이브 채널이 동일하게 사용되지 않으며, 라이브 서비스를 위해 복원력과 비용 사이의 균형을 맞추는 능력이 중요합니다. Amazon Web Services(AWS)에서 AWS 미디어 서비스는 이중화를 염두에 두고 설계되었습니다. AWS Elemental MediaConnect와 AWS Elemental MediaLive와 같은 비디오 전송 및 인코딩을 위한 상태를 유지하는 서비스는 AWS 리전 내의 여러 가용 영역(AZ)에 배포될 수 있습니다. AWS Elemental MediaConvert, AWS Elemental MediaPackage, AWS Elemental MediaTailor를 포함한 비디오 트랜스코딩, 오리지네이션, 배포를 위한 상태 정보를 저장하지 않는 서비스들은 사용자가 별도로 설정하지 않아도 자체적으로 여러 가용 영역에 걸쳐서 운영됩니다.

지금까지는 고객이 하나의 리전에서 다른 리전으로 라이브 스트리밍 서비스를 원활하게 장애 조치할 수 있는 간단한 옵션이 없었습니다. 이 기능은 특히 중요한 라이브 스트리밍 이벤트나 고품질 콘텐츠에서 필수적입니다. 이 블로그 포스트에서는 이러한 기능들이 어떻게 가능해졌는지와 이를 구현하는 데 필요한 사항에 대하여 설명합니다.

자동 무 중단 전환의 예

그림 1: 리전 간 무 중단 전환
기술적인 세부 사항을 살펴보기 전에, 먼저 최종 사용자 관점에서 리전 간의 전환이 어떻게 이루어지는지 살펴보겠습니다. 이 예시에서는 타임코드와 오버레이를 사용하여 비디오 세그먼트가 어디에서 시작되었는지를 보여줍니다.

• 주요 비디오 파이프라인이 위치한 오하이오 리전에서 제공하며, 플레이어는 처음에 오하이오(us-east-2)에서 세그먼트를 제공합니다.
• 01:54:38:00 시점에 오하이오에서 장애가 발생하면 미디어 세그먼트 전송이 포틀랜드(us-west-2)의 백업 오리진으로 전환됩니다.
• 01:54:46:00 시점에 오하이오에서 세그먼트가 다시 사용이 가능해지면서, 세그먼트가 다시 오하이오 리전에서 제공됩니다.

아키텍처의 개요

그림 2: 리전 간 아키텍처 예시

위의 그림으로 리전 간의 잠재적인 아키텍처를 살펴보고 주요 구성 요소를 확인해 보겠습니다.. 그림 2는 MediaLive의 표준 채널 클래스를 사용하는 메인 리전(1)을 보여줍니다. 이 모드에서 MediaLive는 두 개의 서로 다른 가용성 영역(AZ)에서 이중화 된 파이프라인을 실행합니다. 반면에, 보조 리전(2)은 MediaLive의 단일 파이프라인 채널 클래스를 기반으로 구성됩니다. MediaLive 동기화는 채널 수준에서 수행되므로 사용 사례에 맞게 리전 내 이중화 모델을 자유롭게 선택할 수 있습니다. 프리미엄 라이브 이벤트에는 두개의 리전 모두에서 표준 채널을 사용하는 것이 필요할 수 있습니다. 일반 라이브 이벤트 채널은 리전 1의 표준 채널과 리전 2의 단일 파이프라인 채널 또는 두 리전 모두의 단일 파이프라인 채널만으로도 적절하게 처리될 수 있습니다.

온프레미스 인코더(AWS Elemental Live)는 라이브 프로덕션 피드를 인코딩합니다. 이중화된 두개의 인코더는 각각 해당 비디오 프레임에 동일한 UTC 타임 코드를 삽입합니다. 하위 스트림에서 MediaLive는 이 타임코드를 사용하여 Epoch Locking을 통해 출력을 동기화합니다. 이러한 분리된 접근 방식은 파트너 리전에 장애가 발생해도 각각의 처리 경로가 독립적으로 작동할 수 있게 합니다. 이는 서비스의 연속성을 유지하는데 중요합니다.

MediaLive는 DASH-IF CMAF Live Ingest(인터페이스-1) 프로토콜을 사용하여 출력을 생성합니다. 이는 리전 간 장애 조치(failover)를 가능하게 하는 핵심 요소입니다. 이 형식을 사용하면 MediaLive는 일관된 출력 세그먼트의 간격을 유지합니다. 프로토콜 자체 외에도 MediaLive CMAF Ingest 출력 동작은 다음의 세 가지 주요 측면에서 HLS 출력과 다릅니다.

1. 광고 마커는 새로운 출력 세그먼트가 생성하지 않습니다.
2. 채널의 입력이 손실되더라도 출력은 중지되지 않습니다. MediaLive는 공백을 채우고 유효한 비디오 세그먼트(검은 화면및 무음)를 오리진으로 계속 보냅니다.
3. MediaLive는 MP4 세그먼트 레벨 신호를 통해 하위 스트림 시스템에 입력 손실을 알립니다.

MediaPackage는 CMAF IF Ingest 스트림을 수집하도록 향상되었습니다. 이를 통해서 세그멘테이션, 이름 지정 및 암호화 측면에서 일치하는 HLS/TS, CMAF 및 DASH 출력을 생성할 수 있습니다. 세그먼트 수집이 Epoch 시간에 맞춰 조정되기 때문에, 키 로테이션(key rotation)이 활성화된 경우 여러 리전에서 동일한 세그먼트 경계에서 동일한 DRM 키로 시작됩니다.

컨트리뷰션 인코더(contribution encoder), 컨트리뷰션 네트워크(contribution network), 또는 MediaLive 서비스가 중단되면, MediaPackage는 해당 채널을 유효하지 않은 상태로 간주합니다. 이 상태에서는 채널 엔드포인트에 대한 요청에 대해서 404 오류 코드를 반환합니다.

Amazon CloudFront는 오리진 장애 조치(origin failover) 기능을 활용하도록 구성됩니다. 플레이어가 캐시되지 않은 객체를 요청하면, CloudFront는 요청을 메인 오리진(primary origin)으로 전달합니다. 만약 메인 오리진에서 앞서 언급된 상황으로 인해 404 응답을 받거나 오리진 자체를 사용할 수 없는 경우, CloudFront는 요청을 보조 오리진(secondary origin)으로 리디렉션합니다.

메니페스트(manifests)와 세그먼트가 동기화되고 동일한 이름을 가지고 있기 때문에, CloudFront는 보조 오리진에서 객체를 반환하여 요청을 완료할 수 있습니다. 이를 통해서 재생 디바이스는 사용자 경험에 영향을 주지 않고 스트림을 계속 재생할 수 있습니다. 메인 오리진이 사용 가능해지거나 MediaPackage가 엔드포인트 객체 요청에 대해 404를 반환하지 않을 때 트래픽은 자동으로 메인 오리진으로 복귀합니다.

고려사항 및 구성

완전히 끊김 없는 재생 경험을 제공하려면, 비디오 프레임을 가능한 비디오 체인의 초기 단계에서 시간 동기화를 해야 합니다. Elemental Live를 소스 인코더로 사용하는 경우, 비디오 신호에 포함된 타임코드를 참조하거나 로컬 LTC(Local Time Code) 소스를 참조하여 출력을 동기화할 수 있습니다.

이러한 방식으로 출력 잠금을 설정하면 여러 인코더에서 생성된 출력이 각 비디오 프레임에서 동일한 프레젠테이션 타임스탬프(PTS)와 화면을 유지할 수 있습니다. 자세한 내용은 AWS Elemental Live 사용자 가이드의 Output Locking 섹션을 참조하세요.

만약 비디오 신호가 소스에서 정렬되지 않은 경우에도 하위 스트림에서 동기화 및 장애 조치(failover)는 가능합니다. 하지만 리전 간 전환 시 사용자가 화면이 시간적으로 앞으로 점프하거나 뒤로 점프하는 현상을 경험할 수 있습니다.

리전 간의 장애 조치를 위해 인코더나 트랜스코더를 MediaPackage로 푸시하도록 설정할 때는 다음 제한 사항을 반드시 지켜야 합니다.

• CMAF 출력 그룹 내의 모든 비디오 프레임 속도는 일관성이 있어야 합니다. 모든 프레임 속도가 분수(fractional) 프레임 속도이거나, 모든 프레임 속도가 정수(integer) 프레임 속도여야 하며, 이 두 가지를 혼합할 수는 없습니다. 단, 서로 배수 관계에 있는 프레임 속도(예: 25fps와 50fps, 29.97fps와 59.94fps)는 함께 사용할 수 있습니다.
• 두 인코딩 세션 간에 분수 프레임 속도에서 정수 프레임 속도로 (또는 그 반대로) 전환하는 것은 허용되지 않습니다. 인코딩 세션 간 프레임 속도는 서로 배수 관계일 수 있습니다. 예를 들어, 25fps에서 50fps로 또는 50fps에서 25fps로의 전환은 허용되지만, 25fps에서 30fps로 또는 30fps에서 25fps로의 전환은 허용되지 않습니다.
• 출력 세그먼트의 시퀀스 번호는 두 인코딩 세션에 걸쳐 반복되거나 과거로 돌아가서는 안 됩니다.

MediaLive 구성

출력 잠금모드(Output locking mode)

채널의 일반 설정(General Settings)에서 ‘Enable Global configuration’가 설정되어 있는지 확인하세요. 이를 통해 채널의 출력 잠금 모드를 ‘EPOCH_LOCKING’으로 설정할 수 있습니다.

그림 3: MediaLive 출력 잠금 모드

타임코드 구성(Timecode configuration)

MediaLive 채널이 입력 소스의 타임코드를 사용하도록 구성되어 있는지 확인하세요. 이를 위해 ‘EMBEDDED’ 옵션을 선택하세요. 이 설정은 기본적으로 활성화되어 있지만, 잘못 설정된 경우 여러 리전 별 채널의 비디오 프레임 정렬이 맞지 않을 수 있습니다. 이는 MediaLive에 입력되는 소스에 타임코드가 포함되어 있다는 가정을 기반으로 하며, Elemental Live를 컨트리뷰선 인코더로 사용하는 경우에는 타임코드가 포함되어 있을 것입니다. 만약 소스에 타임코드를 포함할 수 없는 경우에는 ‘SYSTEMCLOCK’을 선택하세요. 이 모드에서 MediaLive는 자체 NTP 클럭를 기반으로 출력 타임코드를 생성합니다.

그림 4: MediaLive 타임코드 구성 설정

출력 그룹 생성(Create an output group)

MediaPackage로 스트림을 푸시하려면 반드시 CMAF Ingest 그룹을 사용해야 합니다. CMAF Ingest 유형으로 구성된 MediaPackage V2 인제스트 포인트를 사용하고 있는지 확인하세요. 자세한 내용은 MediaLive 사용자 가이드의 CMAF Ingest 출력 그룹 생성 지침을 참조하세요.

MediaLive와 MediaPackage을 사용하여 라이브 스트림을 관리해 본 경험이 있다면, MediaLive의 ‘입력 손실 동작(Input Loss Action)’ 설정에 익숙할 것입니다. 이 설정은 파이프라인 입력이 사라졌을 때 HLS 출력의 동작을 제어합니다. 이중화(표준 채널) 구성에서는 이를 ‘PAUSE_OUTPUT’으로 설정하여 MediaPackage가 대체 입력으로 장애 조치하도록 해야 합니다.

CMAF Ingest를 사용할 경우 이 접근 방식이 변경됩니다. 이 출력 유형에는 입력 손실 설정이 없습니다. CMAF Ingest를 사용하면, 입력 실패 시에도 MediaLive가 계속해서 유효한 비디오(검은 화면과 무음)를 출력하며, 대신 세그먼트 레벨 신호을 통해 입력 손실을 보고합니다. MediaPackage는 선택적으로 이 신호를 장애 조치 트리거로 사용할 수 있습니다. 이는 이전보다 더 큰 유연성을 제공하며, 품질이 저하되더라도 플레이어가 항상 스트림을 받을 수 있도록 보장합니다.

MediaPackage 구성

MediaPackage 채널은 반드시 CMAF Ingest 유형으로 구성되어야 합니다. 이 설정은 채널 생성 시 정의되며, 이후에는 변경할 수 없습니다. CMAF Ingest 채널 유형은 MediaPackage V2 채널에서만 사용할 수 있습니다.

그림 5: MediaPackage 채널 생성 페이지에서 CMAF Ingest 선택

엔드포인트 에러 동작

MediaPackage는 오래된 상태(stale state)를 트리거하는 오류 시나리오를 제어할 수 있는 여러 옵션을 제공합니다.

그림 6: MediaPackage 엔드포인트 장애 조치 구성

오래된 매니패스트(Stale manifests) : MediaPackage가 입력에서 인제스트 스트림 수신을 중단합니다. 이는 인코더 또는 네트워크 경로에 문제가 생겼음을 나타냅니다.

불완전한 메니페스트(Incomplete manifests) : MediaPackage가 인제스트 세그먼트를 수신하고 있지만, 타임라인에 간격이 있습니다. 이로 인해 일부 렌디션에서 불완전한 타임라인이 나타나 재생에 문제가 발생할 수 있습니다.

누락된 DRM 키(Missing DRM Keys) : MediaPackage가 키 로테이션 작업 중 암호화 키를 검색하지 못한 경우를 말합니다. 이로 인해 키 로테이션 시간 이후에도 이전의 암호화 키를 사용하게 됩니다. 이는 재생에는 영향이 없을 수 있지만, 비즈니스나 콘텐츠 권한 관점에서 문제가 될 수 있습니다.

슬레이트 입력(Slate Input) : MediaPackage가 인제스트 스트림에 상당한 비중의 슬레이트 콘텐츠(검은 비디오 프레임, 무음 오디오)가 포함되어 있음을 감지하고 표시합니다. 재생은 영향이 없을 수 있지만, 사용자 경험이 저하됩니다. 이 경우, 다른 비디오 경로와 오리진으로 장애 조치를 수행하는 것이 적합할 수 있습니다.

MediaPackage가 이러한 시나리오에 반응하도록 구성되면, 문제가 있는 모든 세그먼트가 노출된 매니페스트 윈도우에서 제거될 때까지 매니페스트 요청에 대해 404 응답을 반환합니다. 미디어 세그먼트 요청과 관련해서는, 엔드포인트 장애 조치 조건이 해제되는 즉시 MediaPackage가 404 응답 반환을 중단합니다.

일반적으로 메인 MediaPackage 오리진에서는 옵션중에서 1, 2 와 4를 활성화하고, 백업 오리진에서는 아무것도 활성화하지 않는 것을 권장합니다.이는 CloudFront 및 플레이어가 백업 오리진 엔드포인트를 계속 사용할 수 있도록 보장하기 위해서 입니다. 옵션 3의 활성화는 재생 세션의 연속성 고려사항 뿐만 아니라 비즈니스 요구사항에 따라 결정됩니다.

CloudFront 오리진 그룹

CDN은 각각의 리전별 MediaPackage 를 위해 두개의 오리진으로 구성되어야 합니다. CloudFront는 오리진 그룹 기능을 통해 메인 오리진과 보조 오리진을 지원합니다. 또한 CloudFront Origin Shield를 활성화하는 것을 권장합니다.

오리진 구성을 완료한 후, 오리진 그룹을 생성하고 목록에서 두 개의 오리진을 추가하세요. 이때 메인 오리진이 첫 번째로 오도록 해야 합니다. 그런 다음, 메인 오리진에서 특정 오류 코드가 수신될 경우 요청이 보조 오리진으로 라우팅되도록 오류 코드를 정의합니다. 자세한 내용은 Amazon CloudFront 개발자 가이드를 참조하세요.

그림 7: 두개의 MediaPackage 오리진에 CloudFront 오리진 그룹 설정

옵션 비교

이전에도 고객은 리전 간의 장애 조치를 가능하게 하는 아키텍처를 구축해 왔습니다. 이러한 옵션들은 일반적으로 사용 가능한 기능을 제한하거나, 장애 조치를 처리하기 위한 클라이언트 측 로직을 구축하는 커스텀 개발이 필요했습니다. 아래 표는 이러한 옵션들을 MediaLive CMAF Ingest와 MediaPackage V2를 함께 사용하는 새로운 접근 방식과 비교한 것입니다.

표 1: 리전 간의 장애 조치 옵션 비교

결론

많은 사용 사례에서, AWS 리전 내에서 제공되는 중복성 옵션들은 복원력 요구사항을 충족하기에 충분합니다. 하지만 프리미엄 서비스와 이벤트는 때때로 더 높은 수준의 신뢰성을 요구하며, 이를 위해 구성 요소를 이동하거나 복제해야 합니다.. 이 블로그에서는 리전 간에 라이브 스트리밍 채널을 동기화하는 방법을 설명했습니다. 이를 통해 플랫폼은 과거에 가능했던 것보다 더 광범위한 장애 시나리오를 대응할 수 있게 됩니다. 더욱이, 리전 간의 전환이 자동으로 이루어질 수 있으며, 사용자 경험에 중단 없이 진행될 수 있습니다. 자세한 정보는 MediaPackage 사용자 가이드를 참조하시기 바랍니다.