들어가기 전에

라이브 스트리밍을 다루다 보면 결국 “이 신호를 다른 곳으로 안정적으로 보내야 한다”는 문제를 만난다. 인코더는 현장에 있고, 처리 채널은 다른 리전에 있고, CDN이나 모니터링 시스템은 또 다른 곳에 있는 식이다.

처음엔 ffmpeg 한 줄이면 될 것처럼 보인다. 실제로는 네트워크 손실, 프로토콜 변환, 백업 입력, 출력 fan-out, 모니터링이 붙으면서 갑자기 수공업 방송국이 된다. 여기서 패킷 하나 꼬이면 현장 단톡방이 조용히 뜨거워진다.

Tencent Cloud StreamLink는 이 구간을 관리형으로 맡는 서비스다. 공식 제품 설명 기준으로는 글로벌 사용자를 위한 안정적인 고품질 비디오 전송 서비스이고, 여러 프로토콜의 입력을 받아 여러 출력 노드로 전달할 수 있다.

StreamLink의 위치

StreamLink는 플레이어도 아니고 패키저도 아니다. 핵심은 스트림 전달이다.

StreamLive가 라이브 신호를 트랜스코딩하고, StreamPackage가 HLS/DASH 오리진과 DRM을 담당한다면, StreamLink는 그 앞뒤에서 신호를 운반하는 역할에 가깝다.

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 모드를 구분해야 한다. Listener 모드에서는 StreamLink가 주소를 열고, 송출 쪽이 SRT caller로 붙는다. Caller 모드에서는 StreamLink가 사용자가 지정한 소스 주소로 접속해 스트림을 가져온다. SRT 입력에서는 FEC와 암호화 설정도 가능하다. FEC는 여분의 패킷을 보내 손실을 복구하는 방식이고, 암호화는 송출 쪽과 같은 key/key length를 맞춰야 한다.

출력 프로토콜과 remuxing

StreamLink 출력은 입력 프로토콜에 따라 가능한 조합이 정해진다.

공식 제품 페이지는 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 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