[WebRTC] OpenVidu 분석

WebRTC를 이용하는 [ConCoder] 프로젝트에서 Mesh 대신 SFU 서버 구조를 적용하기 위해 WebRTC 라이브러리인 OpenVidu를 공부하였다.
OpenVidu를 공부하면서 동작 구조나 특징에 대해 정리해보고자 한다.

---

OpenVidu 라이브러리 동작 구조

1. 클라이언트의 요청을 받고, 스프링 서버에서 Session을 생성
   • 여기서 Session은 참가자들이 들어올 수 있는 가상의 방을 의미
2. 서버는 Session에 참가하는 사람이 생길때마다 Connection(슬롯)을 하나 생성한다.
   • 각각의 Connection은 Token을 가지고 있다.
3. 서버가 Token을 클라이언트에게 전달한다.
4. 클라이언트는 WebSocket을 통해 Token을 사용하여 Session에 연결한다.
   • 관련 코드는 openvidu-browser.js에 있다.
5. Session에 연결한 뒤, 참가자는 WebRTC를 통해 Stream을 publish 및 subscribe할 수 있다.
   • 관련 코드는 openvidu-browser.js에 있다.

• 스프링 프레임워크에서 OpenVidu를 사용하는 기본적인 방법은 아래 링크에서 공부하였다.
  백엔드 서버에서는 위의 Workflow에서 1, 2, 3의 역할을 수행한다.
  OpenVidu-Java(spring) Github Link
  
• 바닐라 자바스크립트에서 OpenVidu를 사용하는 기본적인 방법은 아래 링크에서 공부하였다.
  위의 Workflow에서 서버에 1, 2, 3을 요청하고 4, 5의 역할을 수행한다.
  OpenVidu-JavaScript Github Link
  + React 코드도 따로 있으니 참고 바람

Kurento vs Mediasoup

OpenVidu CE(무료)는 미디어 라우팅을 위한 미디어 서버로 Kurento만 사용할 수 있고, OpenVidu Enterprise(유료)부터 미디어 서버로 무엇을 사용할지 Kurento와 Mediasoup 중에서 선택할 수 있다.

Home - OpenVidu Docs

평균적으로 Mediasoup가 Kurento보다 가볍고 빠르다고 한다.
대신 kurento는 오디오와 비디오에 필터를 거는 등 미디어의 가공이 가능하다.

Discussion topics

단순히 무작정 OpenVidu를 적용하여 SFU 구조를 개발하는 것은 좋지 않다고 본다.
본 프로젝트(ConCoder)에 적용하기 위해서는 현재 개발 상황을 정리해보고, 어떤 trade-off 관계가 있는지 파악할 필요가 있다. 그리고 가치 판단하에 더 이득이 있는 방향으로 개발 진행 계획을 세워야 한다.
우리는 다음과 같은 Discussion topic이 있었고, SFU 서버 구조 적용이 그만한 가치가 있는 일인지부터 토론해보았다. (OpenVidu 공부를 하면서 생각보다 비용이 많이 발생할 것으로 판단되었기 때문)

• Mesh 구조에서 미디어 서버를 사용하는 SFU 구조로 바꾸면서 서버 비용이 발생할 것인데, 비용을 부담하면서까지 WebRTC 구조를 바꿀 필요가 있는가?
  • SFU 구조를 사용하는 것을 통해 클라이언트의 부담을 줄임으로써 서비스 품질이 향상된다. 이를 통해 더 많은 사용자를 모을 수 있다면 비지니스 모델에 따라 충분히 가치를 창출할 수 있다.
• 그렇다면 어떤 미디어 서버를 사용하는 것이 맞는가?
  • 기능적인 필요로 인해 Kurento를 사용해야 하는 것이 아니라면 Mediasoup가 효율이 좋다.
  • Kurento를 사용하는 장점을 극대화하는 기능을 추가한다면, Kurento가 좋다.
• 하지만 Mediasoup는 Node.js API만을 제공하고 있고, 현재 백엔드 서버는 스프링을 사용한다.
  • 스프링 및 자바에서 Node.js를 사용하는 방법을 찾거나, WebRTC 사용을 위한 서버를 따로 Node.js로 구축한다. (시간이 꽤 소요될 것으로 예상)

토의 결과 '일단 OpenVidu로 빠르게 기능 구현 후, 품질 향상을 위한 Mediasoup 개발은 추후 진행'하기로 결정하였다.