WebRTC를 이용한 1:N 스트리밍 서비스에서 시그널링 서버가 필요할까?

고민의 시작 : 단방향 스트리밍에서 시그널링 서버가 필요한가

현재 프로젝트는 단방향 스트리밍 서비스로, 클라이언트는 영상을 송출하거나 시청하는 역할을 한다. 일반적으로 WebRTC를 사용할 경우, 시그널링 서버를 통해 클라이언트가 필요한 정보를 교환한 후 SFU 서버와 연결하여 스트림을 송수신한다.

그러나 단방향 스트리밍에서도 P2P 연결이 반드시 필요한지에 대한 의문이 생겼다. 시그널링은 기본적으로 P2P 방식에서 필요한 정보를 교환하기 위해 존재하며, 스트리밍 서비스에서는 반드시 이를 활용해야 하는지에 대한 재검토가 필요했다. 특히 클라이언트가 스트림을 시청하는 경우에는 P2P 대신 HTTP 또는 WebSocket과 같은 단순한 방식으로도 충분히 처리할 수 있는것 같이 보였다.

이러한 고민의 시작을 기반으로 두 가지 접근 방식을 가설로 설정하여 고민을 정리하고 개발 방향을 잡았다.

가설 1: 세션 유지 실시간 P2P 단방향 스트리밍

구현 방식

• 방(room) 개념을 만들어서 그 안에서 P2P 방식으로 host와 client의 연결을 관리한다
• 방에 host와 client의 정보가 담겨져 있고, 실시간으로 데이터를 주고 받는다
• 이 방식으로 구현할 경우 시그널링 서버가 필요하다.

장점

1. 스트리밍에 적합
   • WebRTC 기반 P2P 방식은 매우 낮은 지연시간을 제공한다.
2. 기존 기술 활용 가능
   • Mediasoup과 같은 라이브러리가 이미 존재하므로 이를 활용해 효율적으로 구현할 수 있다.

단점

1. 서버 부하 증가
   • 모든 연결을 서버가 관리하기 때문에 대규모 스트리밍 서비스에서 서버에 가해지는 부하가 크다.

가설 2: 저장 기반 스트리밍

구현 방식

• 방을 만들어 참가자 정보를 유지하지만, 실제 세션을 유지하지 않고 데이터만 기록한다
• 스트리밍 데이터는 미디어 데이터로 변환 후 Object Storage, CDN에 저장한다.
• 사용자가 요청하면 CDN 혹은 Object Stroage에서 데이터를 가져와서 제공한다.
• 이 방식으로 구현할 경우 세션이 유지될 필요가 없기 때문에 시그널링 서버가 필요하지 않다.

장점

1. 서버 부하 감소
   • 실시간 연결을 관리하지 않아 서버 자원이 덜 소모된다.
2. 장기 보관 및 관리 용이
   • 데이터를 저장 기반으로 처리하기 때문에 콘텐츠 보관 및 관리에 유리하다.

단점

1. 높은 지연시간
   • WebRTC의 실시간 성능에 비해 delay가 크며, 실시간성이 중요한 서비스에 부적합할 수 있다.
2. 기존 기술과의 차이
   • 기존 WebRTC와 완전히 다른 방식이기 때문에 추가 학습이 필요하며, 기존에 존재하는 webRTC 라이브러리를 사용하지 못하게 될 수 있다.

결론내린 개발 방향

mediasoup을 사용하여 가설 1번과 같은 방식으로 실시간 스트리밍 서비스를 구현해 보자

근거

webRTC의 장점인 실시간 성을 살릴 수 있다.

• 단방향 스트리밍 서비스에서도 낮은 지연시간은 중요한 요구사항이다.
• WebRTC 기반의 실시간 P2P 방식은 지연을 최소화할 수 있다.

기존에 잘 만들어진 mediasoup과 같은 라이브러리를 이용하면 시그널링 과정도 쉽게 구현할 수 있을것이다.

• Mediasoup은 시그널링 서버 구현, 연결 관리, 멀티플렉싱 등 복잡한 작업을 라이브러리 수준에서 지원하므로 시그널링 과정 구현에 큰 코스트가 들지 않을 것이다.
• 이미 많은 프로젝트와 서비스에서 검증된 라이브러리를 사용하여 안정성과 성능을 어느정도 보장받을 수 있다.