Shiftbloom Studio에서 라이브 스트림 아카이브를 분리하는 방법

shiftbloom studio와 함께, 저는 현실 세계의 문제들에 대한 다양한 실험적 접근 방식에 관한 도구와 프로젝트를 구축합니다.

이러한 사용 사례에서 발생하는 문제는 종종 대부분의 소규모 미디어 시스템이 시작되는 방식과 같습니다. 즉, 아무런 일이 일어나지 않을 때도 계속 비용을 발생시키는 하나의 거대한 상시 가동(always-on) 레코더를 사용하는 것입니다.

라이브 캡처(live capture)를 위해서는 당연히 항상 준비되어 있어야 합니다. 때로는 초기 몇 분을 놓치는 위험을 감수할 수 없기 때문입니다. 하지만 그 외의 모든 작업에는 이는 완전히 과도한 방식(overkill)입니다.

핵심 문제 (The Core Problem)

백필(Backfills), VOD 다운로드, 클립 가져오기, 복구 및 재인코딩(re-encodes)은 큐 작업(queue work)입니다. 이 작업들은 몇 초 정도 기다릴 수 있고, 버스트 용량(burst capacity)으로 실행하거나 일반적인 VPS 또는 노트북에서 실행할 수도 있습니다. 라이브 레코더와 같은 상시 가동(always-hot) 인프라가 필요하지 않습니다.

그것이 제가 시스템을 분리한 이유입니다.

하나의 거대한 모놀리스(monolith) 대신, 저는 다음과 같이 배포했습니다:

• Observer cells (옵저버 셀) — 오직 라이브 스트림만을 위한 것 (시간에 민감함)
• Harvest cells (하베스트 셀) — 모든 큐 처리(queue processing)를 위한 것 (지연 가능)

세 가지 역할 (The Three Roles)

1. Mothership (마더쉽)

작은 제어 평면(control-plane) 크론 잡(cron job)입니다. 이는 큐 크기, 현재 라이브 채널 및 실행 중인 옵저버 태스크를 확인한 다음 다음을 결정합니다:

• 현재 얼마나 많은 하베스트 셀(harvest cells)이 존재해야 하는지
• 어떤 채널에 옵저버 셀(observer cell)이 필요한지

이는 의도적으로 단순하게 설계되었습니다. 데이터베이스는 단일 진실 공급원(single source of truth)으로 유지됩니다.

2. Observer Cells (옵저버 셀)

각 옵저버 셀은 정확히 하나의 라이브 채널을 기록합니다. 환경 변수(environment variables)를 통해 할당을 받습니다:

+++env
OBSERVER_VOD_ID
OBSERVER_CHANNEL_ID
OBSERVER_CHANNEL_LOGIN
OBSERVER_CHANNEL_NAME
+++

즉시 녹화를 시작하여 HLS 세그먼트를 오브젝트 스토리지(object storage)에 쓰고, 하트비트(heartbeats)를 보내며, 스트림이 오프라인이 된 후 짧은 대기 시간(standby window)을 가집니다. 이 대기 시간은 스트림이 때때로 끊겼다가 빠르게 재연결되기 때문에 중요합니다. 이 과정이 없으면 결국 작고 깨진 많은 VOD 파편들이 생기게 됩니다.

3. Harvest Cells (하베스트 셀)

이들은 VOD 다운로드, 재인코딩 (re-encoding), 손상된 파일 복구 등 모든 백그라운드 작업을 처리합니다. Docker를 사용할 수 있는 곳이라면 어디에서나 실행할 수 있습니다 — AWS tasks, 소규모 VPS, 또는 여분의 노트북에서도 가능합니다. 이들은 Postgres와 오브젝트 스토리지 (object storage)에 대한 아웃바운드 (outbound) 액세스 권한만 있으면 됩니다.

변경된 사항

이전에는 라이브 녹화 (live recording)와 백로그 처리 (backlog processing)를 동일한 인프라 문제로 취급했습니다. 하지만 이 둘은 다릅니다. 하나는 할당 기반 (assignment-based)이고, 다른 하나는 처리량 기반 (throughput-based)입니다.

분리 작업 이후, 대규모 히스토리 마이그레이션 (historical migration)을 수행하여 단 36시간 만에 15.5 TB의 백필 (backfill) 데이터를 수집했습니다. 이 과정에서 라이브 스트림의 프레임을 단 하나도 놓치지 않았습니다.

상황	이전	이후
라이브 채널 없음	전체 레코더가 여전히 실행 중	옵저버 셀 (observer cells) 없음
...
아키텍처가 실제로 더 작아졌고 논리적으로 이해하기 쉬워졌습니다.

핵심 교훈

가장 큰 개선은 특정 도구나 플랫폼으로 전환한 것이 아니었습니다. 그것은 지금 당장 일어나야 하는 작업과 결국 언젠가는 일어나면 되는 작업 사이에 명확한 선을 그은 것이었습니다.

대부분의 VOD 아카이브 시스템은 이 두 가지 유형의 작업을 모두 가지고 있습니다. 모든 것을 하나의 모놀리스 (monolith)로 강제하는 대신, 이를 별개의 패턴으로 취급하면 시스템은 훨씬 더 자연스러워집니다. 마치 실제로 필요할 때만 가동되는 전문화된 컴포넌트 (components)들의 작은 군집처럼 말이죠.

저는 이 시스템을 Shiftbloom Studio (현재 제가 직접 운영 중인 곳)에서 구축했습니다. VOD 아카이브는 때때로 특이한 방식으로 녹화될 수 있으며, 이를 처리하기 위해서는 유연하고 오버헤드 (overhead)가 낮은 인프라가 필요하기 때문입니다.

이 접근 방식이 비슷한 문제를 겪고 있는 다른 분들에게 도움이 된다면 정말 좋겠습니다.