하나의 입력, 여러 FAST 채널 프로그램

하나의 입력으로 수백 개의 프로그램 — MediaLive에서 24/7 FAST 채널 실행

24/7 FAST 채널은 매일, 그리고 영원히 하루에 수백 개의 고유한 프로그램을 재생합니다. AWS MediaLive는 채널당 20개의 입력 첨부 파일로 제한합니다. 비디오당 하나의 입력이라는 단순한 설계는 점심 시간 전에 슬롯이 소진되어 라이브 스트림을 오프라인으로 전환하는 채널 재시작을 강제합니다. 우리는 채널이 재생할 모든 프로그램을 서비스하는 하나의 동적 입력과 배포, 부분 실패, 운영자 편집 전반에 걸쳐 타임라인을 자체 복구하는 프로그램 수준의 오케스트레이션 계층을 통해 이 문제를 해결했습니다.

이것은 해당 오케스트레이션이 실제로 어떻게 작동하는지에 대한 엔지니어링 이야기입니다.

빠른 개요

비즈니스 문제

FAST 채널은 24/7 서비스입니다. 운영자는 일주일 또는 한 달 분량의 고유 비디오를 미리 예약하고, 채널은 각 비디오를 정확한 시간에 재생해야 합니다 — 소스를 깔끔하게 전환하고, 워터마크를 안정적으로 유지하며, 광고 구간 신호를 내보내고, 모든 공백을 방송국 브랜드 슬레이트로 채웁니다. 시청자는 검은 화면, 고정된 로고 또는 지난주 프로그램이 반복되는 것을 보아서는 안 됩니다.

이러한 오케스트레이션은 운영자가 수행하는 모든 작업에 견뎌야 합니다: 내일 편성표 편집, 주중 광고 구간 추가, 단일 프로그램 실패 후 재배포, 두 번의 Deploy 클릭 경쟁. 시스템은 모든 변경 사항을 라이브 채널에 대해 원자적으로 적용하거나 깨끗하게 복구해야 합니다. "채널이 이제 아무도 이해할 수 없는 상태에 있다"는 라이브로 방송되는 인프라에서는 용납할 수 없는 결과입니다.

60초 MediaLive 입문

AWS MediaLive는 장시간 실행되는 클라우드 인코더입니다. 하나 이상의 입력 (소스 스트림 또는 파일 URL)과 시간 지정된 액션 (이 입력으로 전환, 이 오버레이 켜기, 이 큐 삽입) 스케줄을 제공합니다. 인코더는 영원히 실행되며, 예약된 타임스탬프에 따라 액션을 실행하고 시청자 플레이어가 소비하는 HLS 매니페스트를 내보냅니다.

두 가지 AWS 제한 사항이 모든 다운스트림에 영향을 미칩니다:

• 채널당 20개의 입력 첨부. 하드 제한입니다. 비디오당 하나의 입력으로 단순하게 설계된 "인기 영화 20선" 채널은 21번째 영화에서 제한에 도달합니다.
• 채널당 1500개의 스케줄 액션. 역시 하드 제한입니다. 각 프로그램은 여러 액션 (입력 전환, 렌디션별 워터마크, 광고 큐, 슬레이트 전환)으로 구성되므로, 실제 상한선은 한 번에 수백 개의 프로그램에 가깝습니다.

두 가지 제한 모두 고유한 콘텐츠를 무기한 재생해야 하는 24/7 채널에 중요합니다.

단순한 접근 방식이 실패하는 이유

각각의 명백한 경로는 다른 방식으로 실패합니다:

• "프로그램당 하나의 입력."은 첫날 20개 첨부 제한을 채웁니다. 더 추가하려면 채널을 다시 생성해야 하며, 채널 재생성은 라이브 스트림이 중단되는 60~90초가 걸립니다. 24/7 서비스에서는 용납할 수 없습니다.
• "배포할 때마다 채널 다시 생성." 매번 배포할 때마다 같은 문제입니다. 프로그래밍이 변경될 때마다 시청자는 중단을 경험합니다. 이는 라이브 상태여야 하는 채널에게는 현실적인 옵션이 아닙니다.
• "일주일 전체를 하나의 거대한 루프 파일로 사전 인코딩." 편집 모델을 망가뜨립니다. 내일 순서를 바꾸고 싶습니까? 일주일 전체를 다시 인코딩해야 합니다. 광고를 삽입하고 싶습니까? 다시 인코딩해야 합니다. FAST 채널이 비즈니스로서 작동하는 모든 이유는 동적 프로그래밍과 구간별 광고 삽입입니다 — 모든 것을 단일 파일로 굽는 것은 이 두 가지를 모두 불가능하게 만듭니다.
• "여러 채널을 병렬로 실행." 플레이어가 채널 간에 전환해야 하며, AWS 비용을 증가시키고, 오디오, MediaPackage 및 CDN 파이프라인을 분리시킵니다. 문제를 해결하기보다는 오히려 증폭시킵니다.

우리가 활용할 수 있었던 것은 단 하나의 AWS 문서화된 기능 — 동적 입력의 $urlPath$ 플레이스홀더 — 그리고 그 위에 우리가 원하는 어떤 오케스트레이션이든 구축할 수 있는 자유였습니다.

이것이 중요한 이유. 핵심은 $urlPath$를 사용하는 것이 아닙니다. AWS는 이를 문서화합니다. 핵심은 부분 배포, 운영자 편집, 동시 재시도를 견딜 수 있는 자체 복구 오케스트레이션 계층을 그 위에 구축하여 라이브 채널이 UI에서 설명할 수 없는 상태가 되지 않도록 하는 것입니다.

우리의 해결책

하나의 MediaLive 채널. 정확한 URL $urlPath$에 연결된 하나의 동적 입력. 공백을 채우기 위한 하나의 슬레이트 입력. 모든 프로그램 경계에서 InputSwitchScheduleActionSettings 액션이 동적 입력의 URL을 해당 프로그램의 실제 S3 경로로 재정의합니다. 채널은 새로운 입력 첨부가 필요하지 않으며, 재시작이 필요 없고, 결코 오프라인 상태가 되지 않습니다.

흥미로운 작업은 그 하나의 입력 위에 실행되는 오케스트레이션 계층입니다 — 모든 액션에 프로그램 ID를 부여하여 실패 후 고아 액션을 정리할 수 있도록 하고, 6초 이상의 공백을 슬레이트로 채워 시청자가 정지 프레임을 보지 않도록 하며, 모든 입력 전환 후 측정된 순간에 워터마크를 활성화하여 오버레이가 버퍼링되는 프레임을 통해 깜빡이지 않도록 하고, 1500개 액션 상한선을 사전 검사하여 배포가 AWS에서 중간에 실패하는 대신 UI에서 실패하도록 합니다.

다이어그램 1 · 채널 아키텍처

아키텍처

• 슬레이트 입력 — 프로그램 간의 공백을 채우기 위해 채널에 첨부된 정적 자산.
• 동적 입력 — Sources: [{ Url: "$urlPath$" }], Type: MP4_FILE로 한 번 생성됩니다. URL은 플레이스홀더이며, 실제 경로는 스케줄 시간에 프로그램별로 제공됩니다.
• Lambda 오케스트레이터 (fastChannel-lambda-fun/index.js) — 채널에 나타나는 각 활동을 소유합니다. 프로그램당 8바이트 16진수 programId를 생성하고 모든 관련 액션에 태그를 지정합니다.
• MediaLive 스케줄 — 하나의 BatchUpdateScheduleCommand를 통해 흐르는 단일 정렬된 액션 목록. AWS에 의해 1500개 액션으로 제한됩니다.
• 백엔드 사전 검사 (schedule.service.ts) — 모든 배포 전에 Lambda의 GET_SCHEDULE_COUNT를 호출하고, 새로운 액션이 제한을 초과할 경우 진행을 거부합니다.

• 고아 정리 (sweepIncompleteProgramGroups) — 모든 배포 후에 실행됩니다. programId로 액션을 그룹화하고, 앵커 input-switch 액션이 누락된 그룹을 삭제합니다.

   

주요 엔지니어링 결정

1. 프로그램당 하나의 동적 입력, 하나의 URL 재정의

동적 입력은 Sources: [{ Url: "$urlPath$" }]로 생성됩니다. 각 프로그램 경계에서 Lambda는 UrlPath: [program.videoUrl]를 제공하는 InputSwitchScheduleActionSettings 액션을 내보냅니다. 이는 해당 프로그램의 MP4 실제 S3 URL입니다. MediaLive는 실행 시 플레이스홀더를 대체하고 실제 소스에서 가져옵니다.

이제 하나의 입력 첨부 파일이 채널이 재생할 모든 프로그램을 서비스합니다 — 채널 수명 동안 사실상 무제한의 고유 비디오를 제공하며, 특정 시점의 배포별 스케줄 액션 제한에 의해서만 제약됩니다. 20개 입력 제한은 더 이상 제약이 아니며, 채널은 새로운 콘텐츠를 추가하기 위해 재시작이 필요 없습니다.

다이어그램 2 · 동적 입력 URL 재정의

의도적으로 감수한 절충안. 동적 입력은 URL을 사전 검증하지 않습니다 — MediaLive는 전환 시에만 플레이스홀더를 해석하므로, 404 오류는 배포 시 거부가 아닌 스트림 측 오류로 나타납니다. 우리는 하나의 입력이라는 아키텍처의 단순성을 얻는 대가로 이 비용을 감수합니다. 백엔드의 별도 ffprobe 검증은 배포 전에 잘못된 형식의 소스를 포착합니다.

2. 프로그램 태그가 지정된 액션 이름으로 자체 복구 가능

Lambda에서 내보낸 모든 액션은 이름에 프로그램의 8바이트 16진수 programId를 포함합니다: input-switch-${programId}, watermark-on-${programId}-${rendition}, ad-break-start-${programId}-${i}, program-end-${programId}, slate-switch-${programId}.

모든 배포 후, sweepIncompleteProgramGroups는 현재 채널에 있는 모든 액션을 나열하고, 포함된 programId로 그룹화하며, 앵커 input-switch 액션이 누락된 그룹을 삭제합니다. 이는 실패한 부분 배포, 경쟁 편집, 그리고 채널에 절반의 프로그램 액션만 남길 수 있는 다른 모든 조건에 대한 정리 경로입니다.

액션 이름 인코딩은 전체 식별 메커니즘입니다. MediaLive 자체는 "프로그램"이라는 개념이 없습니다 — 오케스트레이션 계층은 명명 규칙을 통해 이를 MediaLive에 투영합니다.

이것이 중요한 이유. 모든 액션 이름에 프로그램 ID가 포함되어 있지 않다면, 고아 정리는 어떤 액션이 함께 속하는지 알 방법이 없을 것입니다. 액션 수준의 정리는 너무 많은 것을 삭제하거나 (전체 채널 초기화) 너무 적은 것을 삭제할 수 있습니다 (결코 꺼지지 않는 고립된 워터마크). 명명 규칙이 바로 데이터 모델입니다.

3. 6초 슬레이트 규칙

프로그램은 거의 완벽하게 연결되지 않습니다 — 하나의 MP4가 끝나고 다음 예약된 프로그램이 시작될 때까지 거의 항상 몇 초의 공백이 있습니다. 오케스트레이션은 그 공백이 6초 (MIN_SLATE_GAP_MS = 6000) 이상일 때마다 슬레이트 전환 액션을 내보냅니다.

이 임계값은 임의적이지 않습니다. MediaLive는 두 스케줄 액션 사이에 최소 5초의 간격을 강제합니다. 다음 프로그램의 입력 전환에 이보다 더 가깝게 슬레이트 전환을 내보내면 거부됩니다. 6초 규칙은 MediaLive에 필요한 간격을 제공하고 오케스트레이션 계층에 1초의 클록 드리프트 안전 여유를 남겨줍니다. 6초 미만일 경우, 배포 거부의 위험을 감수하기보다는 이전 프로그램의 마지막 프레임이 잠시 멈추도록 둡니다.

4. 측정된 활성화 지연을 가진 렌디션별 워터마크

워터마크는 출력 렌디션(1080p, 720p, 480p, 360p)당 내보내지는 StaticImageOutputActivate 액션으로, 프로그램당 4개의 액션입니다. 각 액션은 해당 프로그램의 입력 전환 1,500ms 후에 실행됩니다.

지연이 존재하는 이유는 입력 전환 후 첫 프레임들이 여전히 버퍼링 중이기 때문입니다. 정확한 전환 순간에 오버레이를 활성화하면 오버레이가 아직 완전히 렌더링되지 않은 프레임에 그려지면서 짧은 깜빡임이 발생할 수 있습니다. 1,500ms는 테스트에서 네 가지 렌디션 모두에서 일관되게 깨끗한 활성화를 만들어낸 값이었습니다. 이는 MediaLive 문서화된 매개변수가 아닌 측정된 상수이며, 코드의 한 곳에 존재하므로 향후 조정이 한 줄 변경으로 가능합니다.

의도적으로 감수한 절충안. 렌디션별 오버레이 액션은 단일 전역 오버레이보다 4배의 액션 수를 소모합니다. 우리는 이 비용을 감수하는데, 이는 렌디션별 경로가 MediaLive가 단일 오버레이를 네 가지 모두에 걸쳐 다운스케일링하도록 하는 대신, 각 출력에 해당 픽셀 치수에 정확히 맞는 워터마크를 적용할 수 있도록 하기 때문입니다. 그 결과 SD 출력에서 시각적으로 더 선명한 로고가 나타나며, 1500개 제한이 문제가 되기 전까지 수백 개의 프로그램을 위한 충분한 액션 예산을 남겨둡니다.

5. UI에서 사전 검사되는 1500개 액션 상한선

AWS는 MediaLive 채널을 1500개의 스케줄 액션으로 하드 제한합니다. 프로그램당 약 7~8개의 액션 (입력 전환 + 4개의 워터마크 + 2개의 광고 큐 + 가끔 슬레이트)으로, 채널은 광고 밀도와 슬레이트 빈도에 따라 대략 180~200개의 활성 프로그램을 보유합니다. 이는 장기 배포에 대한 실제 상한선이며, 정확한 숫자는 프로그램별 복잡성에 따라 달라집니다.

모든 배포 전에 백엔드는 Lambda의 GET_SCHEDULE_COUNT를 호출합니다. 이는 DescribeScheduleCommand를 통해 채널의 라이브 액션을 세고 { liveCount, capacity: 1500 }을 반환합니다. 만약 liveCount + (newPrograms × 8)이 1500을 초과할 경우, 백엔드는 MediaLive에 어떤 것도 제출하기 전에 정확한 여유 공간 숫자와 함께 SCHEDULE_ACTION_CAP_EXCEEDED를 발생시킵니다. 운영자는 UI에서 이전 프로그램을 먼저 삭제하라는 지침과 함께 제한을 확인합니다. 배포는 결코 중간에 벽에 부딪히지 않습니다.

다이어그램 3 · 한 프로그램의 액션 타임라인

결과

• 단일 MediaLive 채널은 하나의 동적 입력 첨부 파일로 수명 동안 사실상 무제한의 고유 프로그램을 제공합니다. 20개 입력 제한은 더 이상 우리가 계획해야 할 제약이 아닙니다 — 특정 시점의 용량은 입력 제한이 아닌 스케줄 액션 제한에 의해 결정됩니다.
• 채널 오케스트레이션은 자체 복구됩니다: 모든 배포는 고아 정리로 끝나므로, 실패한 부분 배포가 스케줄을 일관되지 않은 상태로 남겨둘 수 없습니다.
• 스케줄 용량은 제한적이며 가시적입니다. 운영자는 클릭하기 전에 UI에서 1500개 액션 상한선을 확인하며, 배포 중간에 불투명한 AWS 거부로 나타나지 않습니다.
• 프로그램 ID 명명 규칙은 전체 ID 계층이며 — 문자열입니다. 새로운 인프라, 추가 저장 공간, 종속성이 없습니다. "프로그램"을 MediaLive의 평면 액션 목록에 투영하는 가장 간단한 방법입니다.

기술 스택: AWS MediaLive · AWS Lambda · NestJS · MongoDB · TypeScript · Node 18 · AWS SDK v3 (@aws-sdk/client-medialive)