[WebRTC] WebRTC의 다양한 방식들 (Mesh, SFU, MCU)

P2P(Mesh)

이전 포스트에서 설명했던 P2P 방식이다.

클라이언트 즉, Peer 간의 연결을 진행하기 때문에 서버는 단순 연결을 위한 정보를 중계할 때만 사용된다.

위의 그림에서처럼 클라이언트마다 자신의 미디어 정보를 송신할 링크(Uplink) 1개와 미디어 정보를 수신할 링크(Downlink) 1개를 가지게 된다.

만약, 위의 그림처럼 5명의 클라이언트가 각각에 대해 Peer Connection을 맺는다면 각 클라이언트는 나머지 4명의 클라이언트에게 자신의 미디어 정보를 송신할 링크(Uplink) 4개와 4명의 클라이언트로부터 미디어 정보를 수신할 링크(Downlink) 4개를 가져 총 8개의 링크를 가지게 된다. (인원이 많아질수록 링크 개수는 기하급수적으로 늘어난다.)

​

장점

• 클라이언트끼리 직접 연결을 진행하고 서버는 단순 정보를 중계하기에 서버 부하가 적다.
• 직접 연결로 데이터를 송수신하기 때문에 실시간 송수신이 보장된다.

단점

• 단순 1:1을 넘어 N:M 연결로 확장시 클라이언트가 유지해야하는 링크가 증가함에 따라 클라이언트의 부하가 심해진다.

---

SFU(Selective Forwarding Unit)

P2P와 달리 서버에서 미디어 트래픽을 중계해준다.

이전에는 클라이언트(Peer) - 클라이언트(Peer) 간의 연결을 진행했다면 이번에는 서버(Peer) - 클라이언트(Peer) 간의 연결을 진행하게 된다.

그에 따라, N:M 상황에서 여러 명과의 링크를 유지해야하는 상황에서 서버와의 링크를 유지하면서 서버와 미디어 정보를 송수신하면 된다.

위의 그림에서처럼 자신의 미디어 정보를 송신할 링크(Uplink) 1개와 미디어 정보를 수신할 링크(Downlink) N개를 가지게 된다.

이전 Mesh 구조에 비해 Connection을 덜 유지하게 된다.

​

장점

• 서버가 미디어 트래픽을 중계해주기 때문에 모든 Connection에 대해 클라이언트가 직접 관리할 필요가 줄어들기 때문에 클라이언트의 부하가 줄어들지만 서버의 부하가 증가한다.
• P2P보다는 실시간성이 떨어질순 있지만 P2P에 걸맞는 실시간 송수신이 보장된다.

단점

• 클라이언트의 부하가 줄어들긴하지만 단순 정보 중계를 위해 사용하던 P2P 서버와는 달리 미디어 트래픽을 중계해야하기 때문에 서버의 부하가 증가한다.
• P2P에 비해 N:M 연결에서 부하가 줄어들긴 했지만 각각의 수신 링크(Downlink)를 개별적으로 유지해야하기 때문에 클라이언트의 부하는 여전히 높다.

---

MCU(Multi-point Control Unit)

SFU와 비슷하게 서버가 중간에서 미디어 트래픽을 중계해준다.

그렇기 때문에 마찬가지로 서버와 클라이언트 간의 연결을 진행하게된다.

SFU는 각각의 클라이언트에서 오는 미디어 정보들을 그대로 포워딩해준 반면 MCU에서는 각각의 클라이언트에서 오는 미디어 정보들을 혼합하고 가공해서 수신측으로 전송해준다.

그렇기 때문에 미디어 정보를 수신할 링크(Downlink)를 N개를 가질 필요 없이 혼합된 데이터를 받을 링크(Downlink) 1개만을 가지고 있으면 된다.

즉, 미디어 정보를 송신할 링크(Uplink) 1개와 미디어 정보를 수신할 링크(Downlink) 1개 총 2개의 링크만을 유지하면 되기에 네트워크에 최적화된 방식이라고 볼 수 있다.

하지만 위에서 언급했듯이, 연결되어있는 모든 클라이언트들의 미디어 정보들을 수신하고 이를 혼합 및 가공해야하기 때문에 서버의 부하가 기하급수적으로 높아진다.

​

장점

• 클라이언트는 단순 링크 2개(Uplink, Downlink 각각 1개)만을 유지하면 되기에 클라이언트의 부하가 상당히 줄어든다.
• N:M 연결에서 효율적인 모습을 보여줄 수 있다.

단점

• 모든 클라이언트들의 정보를 수집하고 한번에 혼합 및 가공을 진행하기에 실시간 송수신 보장이 어려울 수 있다.
• 서버가 모든 미디어 정보를 중계하고 이를 혼합 및 가공하는 과정까지 거쳐야하기 때문에 서버의 부하가 상당히 심해진다.

무엇을 선택해야하는가?

위에서 언급한 방식들은 각각에 대한 장점과 단점들이 존재한다.

이러한 부분에 있어서 우리의 요구사항에 맞게 방식을 선택하는 것이 중요하다.

우리의 스터디 화상회의 자체는 줌과 같은 형식을 띄고 있다.

실시간이 보장되는 환경에서 여러 명이 접속해 비디오 및 음성 데이터들을 주고 받아야하는데 참여 인원은 적을 수도 많을 수도 있다.

이러한 환경 속에서 어떤 방식을 채택하는 것이 좋은가 속에서 P2P 방식은 제외하도록 하였다. (실제 N:M 환경에서 운영될 것이기에 N:M에서 좋지 않은 모습을 보이는 P2P는 제외했다.)

그리고 SFU와 MCU 중 실시간성이 중요하기 때문에 SFU를 사용해보고자 하였다.

그렇다면 SFU와 MCU를 직접 구성할 순 있지만 이러한 부분들을 제공하게끔 만들어놓은 좋은 오픈소스들이 존재한다.

오픈 소스들 중 대표적인 것들에 대해 살펴보자면 MediaSoup, Kurento, Janus 등이 존재할 것이다. (이 외에도 많이 존재한다.)

나는 이 셋 중 하나를 고르고자 했고 구글링을 통해 조사한 결과 성능 쪽에서 Janus가 좋다는 것을 볼 수 있었고 Janus의 동작 방식 자체가 각각의 기능을 제공하는 Plugin들을 조립하고 빼버리면서 원하는 기능들을 손쉽게 Customizing할 수 있겠다는 생각이 들어 Janus를 활용해 화상 회의를 구축해보고자 하였다. (Janus에 대해서는 추후 포스트에서 다룬다.)

정리

각각의 방식에 대해서 장단점이 존재하는데 이것이 가장 좋다라는 정답은 존재하는 것 같지 않다.

다만 자신이 만들고자 하는 서비스에서 가장 적합한 방식을 선택하여 해당 방식을 통해 구성하는 것이 가장 좋은 것 같다.

추후 포스트에서는 Janus를 이용해 직접 서비스를 만드는 것을 진행해보고자 한다.