WebRTC 미디어 서버간 스트리밍 분배 기술

여기 WebRTC 미디어 서버가 한대 있습니다.
이 서버의 최대 수용 가능한 인원은 1,000명입니다.
물론 더 좋은 성능의 CPU와 Memory로 업그레이드 하고
네트워크 트래픽을 더 늘린다면 1,500명까지 수용 가능하다고 판단이 됩니다.

여튼, 분명한 것은 한 대의 미디어 서버에 수용 가능한 최대 성능치는 정해져 있다는 것이고
이는 만고 불변의 원칙입니다.

자, 여기 두 대의 WebRTC 미디어 서버가 있습니다.
한 대의 미디어 서버가 최대 수용 가능한 성능치에 슬슬 도달해 가고 있을 무렵,
한가로이 여유를 즐기고 있는 또 다른 미디어 서버로 슬쩍 스트리밍 분배를 시도합니다.

새로 인입되는 구독자들은 스트리밍 서버가 바뀌었는지도 모르고 관심도 없습니다.
그저 아무런 문제없이 실시간 영상 스트리밍은 잘 전송이 되고 있을테니까요.
물론 물리적 서버 비용의 증가는 있을 수 있지만
미디어 서버간 스트리밍 분배 기술(이하 스트리밍 릴레이, Relay)은
간단한 서버 증설만으로 최대 성능치를 무한에 수렴시킬 수 있는 매력적인 기술입니다.

그래서 이번 시간에는 WebRTC 미디어 서버간 스트리밍 분배를 통해 확장성 있는 서비스가 가능한지,
가능하다면 어떤 부분을 기술적으로 고려해야 하는지를 한번 알아보겠습니다.

우선 놀고 있는 장비를 활용하여 총 3대의 WebRTC 미디어 서버를 동일한 환경으로 구축하고,
미디어 스트리밍 릴레이를 세 대에 걸쳐 진행해하여 실시간 스트리밍이 가능한지 확인해 보겠습니다.
Publisher(Notebook)와 Subscriber(Desktop)는 각각 별도의 장비로 시험을 진행하였습니다.

* 테스트 환경
- 랙타입 서버1대, 노트북 서버 2대, Publisher 노트북 1대, Subscriber 데스크탑 1대
- 서버 OS : Ubuntu linux 16.0x
- Janus Gateway 오픈 소스
- SFU 스트리밍 방식 적용
- Front-End / Back-End 별도 개발

참고로 Janus Gateway는 매우 잘 설계된 WebRTC 미디어 오픈 소스입니다.
코어는 C로 개발되어 있으며 이 또한 많은 오픈 소스를 활용하여 개발되어 있습니다.
대표적으로 libwebsocket, libnice, openssl, glibc-2.0, jasson 등이 있습니다.
다양한 Signaling 채널을 지원하며 Janus 웹페이지와 동일한 html/css/js 코드도 모두 제공합니다.

첫째, 직렬 스트리밍 분배 방식.

Publisher --> 서버1 ---> 서버2 ---> 서버3 <-- Subscriber

이 방식은 미디어 릴레이 기능을 매우 직관적으로 확인할 수 있는 좋은 방법입니다.
물 흐르듯 자연스러운 방식이지만 테스트 용도 이외에는 사용할 일이 없을듯 합니다. 자원 관리가 매우 불편할테니까요.
여튼, 서버1에서 방송되는 스트림을 서버2를 거쳐 서버3까지 이동 시키고
최종적으로 Subscriber는 서버3을 통해 릴레이된 스트리밍을 실시간으로 받아 볼 수 있는지를 확인합니다.
이 개념은 뒤에서 설명드릴 병렬 스트리밍 방식과도 동일합니다.

1. 기본 호 처리 개념

Publisher (Offer) --------> Server
Publisher <------(Answer) Server

WebRTC는 기본적으로 Offer/Answer 모델입니다. 대표적으로 SIP 프로토콜이 있죠.
Janus Gateway의 Video Room 소스 코드를 보신분이라면 아시겠지만
최초 방송을 개시하는 Publisher가 Offer SDP를 제공하고 서버는 Answer SDP로 응답하는 구조입니다.
그리고 이후 Subscriber는 해당 Video Room의 Offer SDP 메시지를 수신받고 Answer SDP 메시지로 응답합니다.
이미 개설된 방송 자원이 존재하므로 참여자는 기존 SDP 구조에 맞춰 진행해야 하기 때문에
논리적으로 매우 당연한 Flow를 가지고 있습니다.

즉, 참여자는 방송을 수신하기 위해 서버로 부터 Offer 메시지를 받고 Answer 메시지를 전송합니다.
이 때, 서버는 참여자를 위해 새로운 자원을 할당하게 되는데 이를 서버간 릴레이를 위한 자원으로도 활용할 수 있을것 같습니다.

2. 미디어 릴레이를 위한 채널 개설

이러한 Offer/Answer 모델을 서버와 서버간에도 그대로 적용시켜 볼 수 있을 것 같습니다.
방송을 개시하는 Publisher는 Offfer SDP 메시지를 서버로 전달하고 서버는
이에 응답하는 Answer SDP 메시지를 보냄으로서 스트리밍이 가능해집니다.
즉, 서버1에서 생성된 Offer SDP 메시지를 서버2로 보내면 서버2는 Answer SDP 메시지를 생성하고 응답합니다. 두 서버간 스트리밍 전송이 가능한 환경이 만들어 지는 것이죠.

이번에는 서버2에서 Offer SDP 메시지를 생성하고 생성된 메시지를 서버3으로 전송합니다.
당연히 서버3은 Answer SDP를 생성하고 서버2로 응답합니다.
이렇게 되면 서버3으로 미디어 스트리밍이 흐르게 됩니다.

간단한 아이디어로 서버간 스트리밍 릴레이가 가능해졌습니다.
참고로 서버간 Signaling은 테스트 편의를 위해 tcp/ip 환경으로 구성하였습니다.

3. 방송 참여

Subscriber (Join) --------> Server
Subscriber <-------(Offer) Server
Subscriber (Answer) ----> Server

Subscriber는 서버3에서 정상적으로 스트리밍 수신이 가능하며
서버1, 서버2, 서버3 어디에서든 동일한 환경의 실시간 스트리밍을 받아 볼 수 있습니다.
Subscriber는 방송 참여를 위해 서버로부터 Offer 메시지를 수신 받기 위한 별도의 Signaling 메시지를 정의할 필요가 있습니다.

한가지 주의할 점은 릴레이된 스트리밍을 수신 받는 신규 참여자의 경우 RTCP 프로토콜에서 PLI 또는 FIR 에러가 발생할 수 있습니다.
이는 RTCP 프로토콜의 내부 로직에 의해 영상이 동기화 되는 시점까지 수 초에서 수 십초간 영상 신호를 볼 수 없게 된다는 의미입니다. 이때는 Publisher의 원본 영상이 스트리밍 되는 서버로 PLI 또는 FIR rtcp 신호를 전달하여 문제를 해결할 수 있습니다.

둘째, 병렬 스트리밍 분배 방식.

Master/Slave 서버 방식으로 Master 서버는 하위 모든 Slave 서버를 관리합니다.
Slave 서버를 늘리기만 하면 되는 구조로 확장성이 매우 뛰어납니다.
자원 분배가 용이하고 미디어 자원을 효율적으로 사용 가능합니다.
단, Slave 서버의 자원을 Master 서버에서 관리해야하기 때문에 Master 서버의 관리 포인트가 중가 하는 단점은 있습니다.
Master와 Slaver 서버간에는 별도로 Signaling을 구축해야합니다. 이는 해당 기술을 가장 잘 활용할 수 있는 방법이라면 무엇이든 상관없습니다. 저는 tcp/ip 기반으로 signaling을 처리하였습니다.

Master 서버의 주 역할은 방송 스트리밍을 수신하고 분배하는 역할입니다.
Publisher가 Master 서버에 방송을 개시하면 즉시 활용 가능한 Slave 서버를 탐색하여 방송을 릴레이 합니다.
한 곳의 Slave 서버에만 방송을 릴레이할 수 도 있고 여러곳의 Slave 서버에 방송을 릴레이 할 수 도 있습니다. 참여자는 릴레이중인 서버 어디서든지 동일한 환경의 영상을 시청할 수 있습니다.
상용화 서비스를 개발한다면 당연히 고려해 볼만한 아키텍쳐입니다.

* WebRTC 스트리밍 분배 정리.

스트리밍 릴레이가 최종 3 단계를 거치면서도 원본 영상의 실시간성과 영상 퀄리티는 변함이 없었습니다.
또한 동일한 방송 영상을 Slave1, Slave2에 동시 릴레이 할때도 실시간성과 품질에는 전혀 문제가 없었습니다.
이를 잘 활용한다면 무한에 가까운 동시 접속자수를 보장할 뿐만 아니라
해외 서비스를 추진하는 경우 현지에 Slave 서버를 두고 데이터 트래픽을
해당 지역의 Slave 서버로 전환 시킬 수 있다는 장점도 가질 수 있을것 같습니다.

시간이 허락되면 스트리밍 분배 서비스에서 또 다른 Publisher가 참여하여
양방향 방송 서비스가 가능한 기술에 대해 썰을 풀어 보도록 하겠습니다.