WebRTC와 Mediasoup을 선택한 이유
- 처음 실시간 스트리밍 서비스를 구현하려고 했을 때, 크게 두 가지 선택지가 있었습니다.
- WebRTC 기반 실시간 스트리밍
- RTMP를 이용한 스트리밍
- 저희는 네이버 부스트캠프 캠퍼들을 위한 서비스를 만들고 있었기 때문에, 사용자 접근성이 가장 중요했습니다.
- RTMP는 OBS 같은 별도의 송출 프로그램이 필요한데, 이는 사용자들에게 접근성에 대한 부담이 증가하게 됩니다.
- 반면 WebRTC는 브라우저만으로도 방송이 가능했기 때문에, WebRTC를 선택하게 되었습니다.
- 미디어 정보를 직접 peer끼리 connection을 맺어 주고 받는다.
- 서버가 필요없다고 생각할수도 있지만 peer끼리 connection을 맺기 위한 시그널 정보를 주고 받기 위한 시그널 서버가 필요하다.
- 시그널링 서버 구축을 위해 websocket, socket.io 와 같은 양방향 통신을 지원하는 기술을 사용해야만 한다.
- peer에서 직접 미디어 정보를 주고 받기 때문에 peer(클라이언트)에 부하가에 생길수 있다.
- 1:1 구조에 적합하다. 물론 1:N 또는 N:M도 가능하지만 디바이스에 부하가 심해진다.
- peer의 부하는 mesh에 비해서 줄어들지만, 그만큼 서버의 부하가 있다.
- 1개의 upstream과 N개의 downstream을 갖는 구조이다.
- 미디어 서버가 필요하다.
- 대규모 연결에 적합하다.
- 처음에는 Mesh 방식을 고려했지만, 수백 명의 캠퍼들이 동시에 접속할 수 있어야 했기 때문에 클라이언트 부하 문제가 있었습니다.
- 결국 미디어 서버를 두고 중계하는 SFU(Selective Forwarding Unit) 방식을 채택하게 되었습니다.
6주라는 제한된 시간 내에 안정적인 서비스를 구축해야 했기 때문에, 검증된 라이브러리를 사용하는 것이 현실적인 선택이었습니다.
마지막으로 어떤 라이브러리를 사용할지 고민했는데, Mediasoup을 선택하게 되었습니다.
- 오픈소스로 라이선스 비용이 없음
- 자세한 문서화와 활발한 커뮤니티
- WebRTC 표준을 충실히 구현
- 유연한 커스터마이징 가능
- Node.js 기반으로 저희 백엔드 스택과 호환성이 좋음