Tencent Cloud StreamLink
들어가기 전에
라이브 스트리밍을 다루다 보면 결국 “이 신호를 다른 곳으로 안정적으로 보내야 한다”는 문제를 만납니다. 인코더는 현장에 있고, 처리 채널은 다른 리전에 있고, CDN이나 모니터링 시스템은 또 다른 곳에 있는 식입니다.
처음엔 ffmpeg 한 줄이면 될 것처럼 보입니다. 실제로는 네트워크 손실, 프로토콜 변환, 백업 입력, 출력 fan-out, 모니터링이 붙으면서 갑자기 수공업 방송국이 됩니다. 여기서 패킷 하나 꼬이면 현장 단톡방이 조용히 뜨거워집니다.
Tencent Cloud StreamLink는 이 구간을 관리형으로 맡는 서비스입니다. 공식 제품 설명 기준으로는 글로벌 사용자를 위한 안정적인 고품질 비디오 전송 서비스이고, 여러 프로토콜의 입력을 받아 여러 출력 노드로 전달할 수 있습니다.
StreamLink의 위치
StreamLink는 플레이어도 아니고 패키저도 아닙니다. 핵심은 스트림 전달입니다.
StreamLive가 라이브 신호를 트랜스코딩하고, StreamPackage가 HLS/DASH 오리진과 DRM을 담당한다면, StreamLink는 그 앞뒤에서 신호를 운반하는 역할에 가깝습니다.
| 서비스 | 역할 |
|---|---|
| StreamLink | 라이브 스트림 전송, relay, remuxing |
| StreamLive | 채널 기반 라이브 처리, 트랜스코딩 |
| StreamPackage | 패키징, 오리진, DRM, SSAI |
| CSS/CDN | 시청자 대상 배포 |
StreamLink는 AWS 쪽으로 치면 MediaConnect에 가까운 포지션입니다. 방송 신호를 안정적으로 옮기고, 필요하면 프로토콜을 바꿔서 여러 목적지에 전달합니다.
기본 단위는 Flow입니다
StreamLink는 Flow 단위로 구성합니다. 하나의 Flow 안에 Input node와 Output node가 들어갑니다.
입력 노드는 소스 신호를 받는 지점이고, 출력 노드는 그 신호를 어디로 내보낼지 정하는 지점입니다. 하나의 Flow에 여러 output node를 붙일 수 있어서 같은 신호를 다른 리전이나 다른 시스템으로 동시에 보낼 수 있습니다.
공식 제품 페이지에서도 single flow에 multiple output node를 추가할 수 있다고 설명합니다. 이게 중요합니다. 현장 인코더 하나에서 모든 목적지로 직접 송출하면 인코더와 현장 회선이 부담을 다 떠안습니다. StreamLink를 중간에 두면 현장은 StreamLink로 하나 보내고, 이후 fan-out은 클라우드가 맡습니다.
입력 프로토콜
공식 콘솔 가이드 기준으로 StreamLink 입력은 다음 계열을 지원합니다.
| 입력 프로토콜 | 방식 | 의미 |
|---|---|---|
| SRT | Listener / Caller | 손실 네트워크 대응, 암호화, latency 조정 |
| RTMP_PUSH | Push | 인코더가 StreamLink 주소로 송출 |
| RTMP_PULL | Pull | StreamLink가 외부 RTMP URL을 가져옴 |
| RTP | Push | 방송 장비 계열 TS 전송 |
| RTSP_PULL | Pull | 카메라나 외부 RTSP 소스 수신 |
| RIST | Listener | 신뢰성 기반 인터넷 스트림 전송 |
SRT는 Listener와 Caller 모드를 구분해야 합니다. Listener 모드에서는 StreamLink가 주소를 열고, 송출 쪽이 SRT caller로 붙습니다. Caller 모드에서는 StreamLink가 사용자가 지정한 소스 주소로 접속해 스트림을 가져옵니다. SRT 입력에서는 FEC와 암호화 설정도 가능합니다. FEC는 여분의 패킷을 보내 손실을 복구하는 방식이고, 암호화는 송출 쪽과 같은 key/key length를 맞춰야 합니다.
출력 프로토콜과 remuxing
StreamLink 출력은 입력 프로토콜에 따라 가능한 조합이 정해집니다.
| 입력 | 가능한 출력 |
|---|---|
| RTMP_PUSH / RTMP_PULL | RTMP_PUSH, RTMP_PULL, SRT |
| SRT | SRT, RTMP_PUSH, RTMP_PULL |
| RTP | RTP |
| RTSP_PULL | RTSP_PULL |
| RIST | RIST |
공식 제품 페이지는 StreamLink가 RTP, SRT, RTMP 사이의 remuxing을 지원한다고 설명합니다. 즉 SRT로 들어온 신호를 RTMP로 내보내거나, RTMP 입력을 SRT 출력으로 바꾸는 식의 브릿지 역할을 할 수 있습니다.
다만 이걸 만능 프로토콜 변환기로 보면 안 됩니다. StreamLink는 스트림 전송과 remuxing 구간이지, HLS 패키징이나 플레이어 제공 서비스가 아닙니다. HLS/DASH 패키징은 StreamPackage나 CSS 쪽 일입니다. 역할을 헷갈리면 아키텍처가 겉으로는 클라우드인데 내부는 거의 손바느질이 됩니다.
Failover와 안정성
StreamLink의 중요한 기능 중 하나가 primary/backup 입력입니다. 공식 문서에 따르면 SRT Listener, RTMP_PUSH, RTP 같은 입력에서는 failover 구성을 제공할 수 있습니다. 활성화하면 StreamLink가 두 개의 입력 주소를 만들고, 두 주소로 스트림을 보낼 수 있습니다.
동작은 단순합니다. 먼저 도착한 스트림을 primary source로 쓰고, primary가 끊기면 backup으로 자동 전환합니다.
이 구조는 스포츠 중계나 대형 이벤트에서 꽤 중요합니다. 현장 회선 하나만 믿고 가면 장애가 났을 때 복구할 시간이 없습니다. 라이브는 VOD처럼 “다시 처리하면 됩니다”가 잘 안 통합니다. 끊긴 순간 시청자는 이미 봤고, 운영자는 이미 연락을 받습니다.
Output node 타입
StreamLink output node에는 Pinpoint와 MultiMesh 타입이 있습니다.
| 타입 | 용도 |
|---|---|
| Pinpoint | 일반적인 출력. 출력 트래픽을 제어하기 쉬움 |
| MultiMesh | 하나의 출력 노드에서 더 많은 수신자가 pull해야 할 때 |
공식 문서 기준 Pinpoint output은 1개 push 또는 최대 4개 pull 요청을 지원하고, 제한을 넘으면 요청이 거부됩니다. MultiMesh는 현재 SRT Listener만 지원하며, pull 수 제한 없이 쓰는 시나리오에 맞습니다.
이 차이는 운영에서 은근히 큽니다. “한두 군데서 받을 거다”라고 생각하고 Pinpoint로 만들었는데, 나중에 수신자가 늘어나면 갑자기 pull이 막힙니다. 이런 건 장애라기보다 설계가 미래의 나를 때리는 구조입니다.
언제 쓰면 좋을까
StreamLink는 이런 경우에 잘 맞습니다.
- 현장 인코더 신호를 다른 리전으로 안정적으로 보내야 할 때
- SRT, RTP, RIST, RTMP 같은 프로토콜을 브릿지해야 할 때
- 하나의 소스를 여러 출력 목적지로 fan-out해야 할 때
- primary/backup 입력으로 송출 안정성을 높여야 할 때
- StreamLive 앞단에서 신호 운송 계층을 분리하고 싶을 때
반대로 단순 RTMP ingest 후 바로 CDN으로 배포하는 정도라면 StreamLink까지 넣을 필요가 없을 수 있습니다. CSS나 StreamLive 입력으로 바로 붙이는 게 더 단순합니다. StreamLink는 “신호를 안정적으로 옮기는 문제”가 실제로 있을 때 가치가 나옵니다.
정리
StreamLink는 라이브 스트리밍 파이프라인에서 전송 계층을 담당합니다. 소스 신호를 받아 여러 목적지로 보내고, SRT/RTMP/RTP/RIST 계열 프로토콜을 연결하며, 일부 입력에서는 failover를 제공합니다.
핵심은 플레이어 서비스가 아니라는 점입니다. 시청자에게 보여주는 서비스가 아니라, 시청자에게 보여주기 전까지 신호를 안전하게 운반하는 서비스입니다.
라이브 시스템은 결국 입력 안정성이 반입니다. 인코딩이 아무리 좋아도 신호가 못 오면 끝입니다. StreamLink는 그 “신호가 제대로 오게 만드는” 쪽의 서비스라고 보면 됩니다.
참고자료 : Streamlink https://www.tencentcloud.com/document/product/1073?lang=en