Tencent Cloud StreamLive

들어가기 전에

AWS를 오래 쓴 미디어 엔지니어라면 AWS Elemental MediaLive가 익숙할 것이다. 인코더에서 들어오는 라이브 신호를 클라우드에서 받아서 트랜스코딩하고, HLS나 DASH 같은 출력으로 내보내는 채널 기반 라이브 처리 서비스다.

Tencent Cloud에서 이 포지션에 가까운 서비스가 StreamLive다.

StreamLive는 라이브 스트리밍 CDN이 아니다. 시청자에게 직접 대규모로 뿌리는 배포 계층이라기보다, 그 앞단에서 방송 신호를 정리하고 가공하는 처리 계층이다. 입력을 받고, 트랜스코딩하고, 어댑티브 비트레이트 출력을 만들고, 필요하면 SCTE-35 광고 신호나 DRM, 아카이브 출력까지 이어준다.

쉽게 말하면 StreamLive는 클라우드 안에 있는 방송용 인코딩 채널이다. 인코더 한 대 물려놓고 ffmpeg 프로세스 여러 개 띄워서 어떻게든 굴리는 구조를 관리형 서비스로 올린 느낌이다. 문제는 방송 워크로드는 한 번 끊기면 로그보다 전화가 먼저 온다는 점이다. 그래서 이런 서비스는 기능 목록보다 채널 구조, 입력 이중화, 출력 경로, 장애 감지가 더 중요하다.

파이프라인에서의 위치

Tencent Cloud의 방송급 라이브 파이프라인을 단순하게 보면 보통 이런 흐름이다.

각 서비스의 역할은 대충 이렇게 나뉜다.

여기서 StreamLive는 “신호를 받아서 방송 가능한 출력으로 만드는 구간”이다. StreamLink가 신호 운송 쪽에 가깝고, StreamPackage가 패키징과 오리진 쪽에 가깝다면, StreamLive는 중간에서 화질 ladder와 출력 포맷을 만드는 인코딩 팜에 가깝다. 물론 StreamLive 출력이 반드시 StreamPackage로만 가야 하는 것은 아니다. 공식 문서 기준으로 HLS나 DASH 출력은 HTTP PUT으로 외부 목적지에 보낼 수 있고, HLS_STREAM_PACKAGE나 DASH_STREAM_PACKAGE는 같은 계정의 StreamPackage 채널로 보낼 수 있다. HLS_ARCHIVE와 DASH_ARCHIVE는 COS에 저장하고, M2TS는 SRT 목적지로 보낼 수 있다. 이 flexibility 때문에 기존 워크플로를 전부 갈아엎지 않고 StreamLive만 중간에 끼우는 구성도 가능하다.

채널이 기본 단위다

StreamLive는 채널(Channel) 단위로 관리된다. 이게 핵심이다.

하나의 채널 안에 입력, 파이프라인, 트랜스코딩 설정, 출력 그룹이 들어간다. 채널을 시작하면 입력으로 들어온 라이브 신호가 이 설정을 따라 계속 처리된다. 채널이 실행 중이면 설정 변경에 제약이 있고, 보통 중요한 수정은 채널을 멈춘 뒤 적용한다. 방송 시스템에서 “실행 중인 파이프라인을 손으로 만진다”는 건 보통 사고 예고편이다.

공식 문서에서는 StreamLive 채널이 dual-pipeline 입력 구성을 지원한다고 설명한다. Pipeline A는 필수이고 Pipeline B는 선택이다. 두 파이프라인은 독립적으로 동작하며, A 입력은 각 output group의 A destination으로, B 입력은 B destination으로 이어진다.

이 구조는 고가용성 관점에서 중요하다. 라이브는 파일 처리와 달라서 나중에 다시 돌리면 된다는 말이 잘 안 통한다. 한쪽 입력이 죽었을 때 백업 입력을 받을 수 있는 구조를 처음부터 잡아야 한다. 여기서 설계 대충 하면 장애 때 “왜 B 파이프라인 안 물려놨어요?”라는 질문을 받게 된다. 대답할 말이 별로 없다.

입력은 Push와 Pull 둘 다 지원한다

StreamLive의 입력(Input)은 채널로 들어오는 소스다. 공식 문서 기준으로 입력은 보통 하나의 security group과 하나의 StreamLive channel에 연결된다.

지원 입력 타입은 다음과 같다.

Push 입력은 인코더가 StreamLive 쪽 URL로 밀어 넣는 방식이고, Pull 입력은 StreamLive가 외부 소스를 가져오는 방식이다. 현장 인코더를 직접 붙이는 방송이면 Push가 자연스럽고, 이미 어딘가에 떠 있는 라이브 URL을 가져와 재처리하려면 Pull이 편하다.

RTMP_PUSH나 RTMPS_PUSH는 사용자 이름과 비밀번호 인증을 설정할 수 있고, security group을 통해 허용 IP를 제한할 수 있다. SRT_PUSH는 streamid 기반 목적지 설정을 사용한다. 이런 입력 보안은 화려한 기능은 아니지만 운영에서는 기본이다. 입력 URL 하나 새면 엉뚱한 사람이 방송 채널에 신호를 밀어 넣을 수 있다. 그 순간부터 방송이 아니라 사고다.

트랜스코딩과 ABR 출력

StreamLive의 중심 기능은 트랜스코딩이다. 입력 하나를 받아 여러 해상도, 비트레이트, 프레임레이트 조합으로 출력한다.

예를 들어 원본 입력이 1080p라면, 시청자 네트워크 상태에 맞춰 1080p, 720p, 540p 같은 ladder를 만들 수 있다. 이렇게 해야 플레이어가 네트워크 상황에 따라 품질을 바꾸는 ABR(Adaptive Bitrate) 재생이 가능해진다.

StreamLive는 SD, HD, UHD, 2K, 4K 같은 다양한 해상도 출력을 지원하고, 오디오/비디오 트랜스코딩 템플릿을 출력에 연결하는 방식으로 구성한다. HLS 출력에서는 오디오 트랙을 별도로 다루는 separate transcoding도 쓸 수 있고, 다중 오디오 트랙이 필요한 방송에서는 RTP MPEG-TS 입력과 함께 의미가 커진다.

Tencent Cloud가 강조하는 TSC(Top Speed Codec)도 이 구간의 기능이다. 장면에 따라 인코딩 파라미터를 동적으로 잡아 낮은 비트레이트에서도 화질을 유지하려는 방식이다. 라이브에서 비트레이트는 곧 CDN 비용이다. 시청자가 많으면 10% 차이도 그냥 돈이다. 반대로 인코딩 복잡도가 올라가면 처리 비용과 latency도 같이 봐야 한다.

출력 그룹은 목적지별로 나뉜다

StreamLive는 하나의 채널에 여러 output group을 둘 수 있다. 출력 그룹은 “어디로 어떤 형태의 결과물을 보낼 것인가”를 정하는 단위다.

공식 문서 기준 주요 output group type은 다음과 같다.

여기서 StreamPackage로 보내는 출력은 오리진/패키징/DRM과 이어지는 구간이고, HLS/DASH HTTP PUT은 외부 CDN이나 오리진과 붙이는 구간이다. COS archive는 방송 출력의 일정 구간을 저장하는 쪽이고, frame capture는 썸네일이나 품질 감시, 모더레이션 파이프라인 입력으로 쓸 수 있다.

실무적으로 중요한 건 출력이 하나가 아니라는 점이다. 같은 입력에서 CDN용 HLS, 내부 모니터링용 M2TS, 아카이브용 COS 저장을 동시에 만들 수 있다. 이 구조를 손으로 ffmpeg 여러 개 묶어서 만들면 처음엔 된다. 그리고 장애 나는 날부터 담당자 표정이 사라진다.

SCTE-35는 조건을 봐야 한다

SCTE-35는 방송 스트림 안에 광고 삽입 타이밍 신호를 넣는 표준이다. OTT에서 SSAI를 하려면 이 신호가 뒤쪽 패키저나 광고 삽입 시스템까지 살아서 가야 한다.

StreamLive는 SCTE-35 pass-through를 지원한다. 다만 여기서 중요한 조건이 있다. 공식 문서 기준으로 SCTE-35 메시지는 MPEG-2 TS 입력에만 실릴 수 있기 때문에, StreamLive에서 SCTE-35 pass-through가 가능한 입력은 RTP_PUSH, UDP_PUSH, SRT_PUSH 쪽이다.

그리고 단순히 output 설정에서 SCTE-35를 켠다고 끝나는 게 아니다. 출력에서 SCTE-35 메시지가 보이려면 입력 스트림 안에 SCTE-35 메시지의 PES payload가 포함되어 있어야 한다. 원본 신호에 광고 마커가 없는데 StreamLive가 알아서 광고 타이밍을 발명해주진 않는다. 그런 건 기술이 아니라 주술이다. 그렇다고해서 RTMP 인입신호에 마커를 아예 담을 수 없는 것은 아니다. AMF 메타데이터 형태로 RTMP의 Data Tag에 onCuePoint ,onMetaData, scte35,cue와 같은 커스텀 데이터를 넣으면 Streamlive에서 이를 파싱하여 SCTE-35 형태로 삽입하는 것도 가능하다.

HLS 출력에서는 광고 마커 표현 방식을 선택할 수 있다. 공식 문서에는 Enhanced SCTE-35와 Date Range 방식이 예시로 나온다. 어떤 방식이 맞는지는 뒤쪽 SSAI, 플레이어, 오리진이 뭘 기대하느냐에 따라 달라진다. 여기서 포맷 하나만 삐끗해도 downstream에서 광고가 안 붙고, 모니터링 지표는 초록색인데 비즈니스 쪽 단톡방은 조용히 불탄다.

입력 보안과 상태 모니터링

StreamLive는 입력 보안 그룹을 제공한다. PUSH 입력을 만들 때 security group을 연결하고, security group에는 허용할 IPv4 CIDR을 넣는다. 그러면 allowlist에 없는 IP는 push에 실패한다.

방송 시스템에서는 이런 단순한 IP 제한이 생각보다 중요하다. 라이브 입력 URL은 사실상 채널의 관문이다. 인증과 IP 제한 없이 URL만 믿고 열어두면, 운영자가 밤에 자다가 깨는 구조가 된다.

또 하나 중요한 건 health report와 alert다. StreamLive는 채널 실행 상태와 스트림 품질을 볼 수 있는 health report와 alert 기능을 제공한다. 라이브는 장애를 “나중에 확인”하면 이미 늦다. 입력 bitrate가 떨어지는지, 출력이 정상인지, 채널이 RUNNING 상태인지 바로 봐야 한다. 결국 라이브 운영은 인코딩보다 관측성이 더 사람을 살린다. 그러나 확실한 것은 AWS보다 상태 모니터링 부분이 약한 것 같다. 대규모 사용자 일수록 모든 상태데이터를 로그나 Callback으로 받아야 하는데, 특히 중국계 벤더는 이 부분에 대한 고려가 잘 되어있지는 않은 편이다.

StreamLive와 CSS는 역할이 다르다

여기서 헷갈리기 쉬운 부분이 CSS와 StreamLive의 관계다.

CSS는 Tencent Cloud의 라이브 스트리밍 서비스이고, 인제스트와 CDN 배포, 트랜스코딩, 녹화 같은 기능을 제공한다. 일반적인 라이브 방송은 CSS만으로도 충분한 경우가 많다.

StreamLive는 더 방송급 처리 파이프라인에 가깝다. 다중 입력, dual-pipeline, 출력 그룹, StreamPackage 연동, SCTE-35, 아카이브, M2TS 출력 같은 구성이 필요할 때 의미가 커진다.

정리하면 이렇다.

처음부터 모든 걸 Stream 시리즈로 쌓으면 구조는 멋있어 보인다. 그런데 운영 복잡도와 비용도 같이 올라간다. 단순 방송이면 CSS로 시작하고, 다중 출력이나 광고 삽입, 패키징 요구가 생길 때 StreamLive와 StreamPackage를 붙이는 쪽이 현실적이다.

언제 쓰면 좋을까

StreamLive는 이런 경우에 잘 맞는다.

• SRT, RTP, UDP, RTMP 등 다양한 입력 신호를 받아야 할 때

• 하나의 입력에서 여러 해상도와 포맷의 출력을 만들어야 할 때

• StreamPackage와 연결해 HLS/DASH 패키징, DRM, 오리진 구성을 해야 할 때

• SCTE-35 기반 광고 삽입 파이프라인을 구성해야 할 때

• 주/백업 입력 파이프라인으로 방송 안정성을 높여야 할 때

• HLS/DASH archive나 frame capture 같은 부가 출력을 같이 만들어야 할 때

반대로 단순 RTMP ingest 후 HLS 배포 정도라면 StreamLive까지 끌고 올 필요가 없을 수 있다. 그건 CSS로도 충분한 경우가 많다. 설계는 기능 많은 쪽을 고르는 게임이 아니라, 운영자가 감당할 수 있는 복잡도를 고르는 게임이다.

정리

StreamLive는 Tencent Cloud 미디어 제품군에서 방송급 라이브 신호 처리를 담당하는 채널 기반 서비스다. 입력을 받고, dual-pipeline 구조로 안정성을 잡고, 트랜스코딩과 remuxing으로 출력 그룹을 만들고, StreamPackage나 외부 오리진, COS, SRT 목적지로 결과를 보낸다.

핵심은 “라이브 CDN”이 아니라 “라이브 처리 채널”이라는 점이다. 시청자에게 대규모로 배포하는 계층은 CSS/CDN 쪽이고, StreamLive는 그 전에 신호를 방송 가능한 형태로 만드는 쪽이다.

방송 시스템은 PPT에서는 항상 단순하다. 인코더에서 화살표 하나 나오고, 클라우드 박스 지나서 시청자로 간다. 실제 운영에서는 입력 하나 끊기고, SCTE-35 마커 하나 빠지고, 출력 destination 하나 인증 실패하면서 본모습이 나온다. StreamLive는 그 복잡한 구간을 관리형 채널로 묶어주는 서비스라고 보면 된다.

참고 : Tencent Cloud StreamLive product page https://www.tencentcloud.com/document/product/1048