미팅 프로젝트에서 P2P, SFU, MCU 중에 MCU방식을 택한 이유

 

미팅 프로젝트에서 P2P, SFU, MCU 중에 MCU방식을 택한 이유

P2P 형태는 유저 n이 매우 작은 경우에 한하여 Server less로 유용함은 자명하다.

그러나 상용앱에서 채택하는 경우는 없다.

 

먼저 일반적으로 알려진 SFU의 단점에 대해 알아보자.

WebRTC 프로토콜 중 미디어 데이터 전송 프로토콜인 SRTP에서는 네트워크 상황에 따라 적절한 이미지를 제공해 주는 현상 및 개념이 존재하는데 이에 따라 네트워크 bandwidth를 많이 차지하는 SFU방식에서는 저품질의 영상이 보여질 확률이 높다. 사용자 환경에 따라 영상의 품질을 결정할 수 있는 UX를 선택했다면 코덱을 Single-layer가 아닌 SVC나 Simulcast 전용으로 교체할 수는 있으나 MCU방식에서는 좀 더 좋은 품질의 영상을 볼 수 있었던 유저가 저품질의 영상을 봐야한다는 단점을 극복하지는 못한다.

 

SFU, MCU를 구현, 운영하면서 일반적으로 알려진 개념과의 차이가 있었는데 Server CPU 사용률이다.

SFU 방식은 개념적으로는 Peer Client1의 publish된 스트림을 Server에서는 릴레이만 수행해 서버 자원을 줄이는 이점이 있다고 한다. 그러나 릴레이 작업내에는 DTLS End-to-End(Peer-to-Peer) 암, 복호화 작업을 포함한 서버 네트워크 디바이스 I/O가 포함되어 있고 MCU방식에서는 Client가 SubScribe시 mixing된 1개의 Stream을 서버에서 보내지만 SFU 방식은 n-1개의 Stream을 여러개의 패킷으로 전송되는지의 차이가 있어 Client N이 커지는 경우 릴레이 작업이 무시될 수 없는 수준에 이른다.

 

SFU 방식은 Client N에 linear하게 서버의 자원을 사용하는 반면 MCU 방식의 Decode + Layout + Encode 작업은 Client 수가 변하여도 작업 시간의 큰 차이가 없다. View port가 64명인 경우 65명 이상 Client가 있어도 video mixing시 64명까지만 사용되기 때문이다. 이에 따라 MCU방식에 비해 SFU 방식의 장점이라고 이야기했던 서버 사용률 또한, Client N이 매우 커지는 경우 MCU에서 Mixing을 담당하는 Agent 사용 증가율보다 SFU WebRTC Agent 사용 증가율이 높아 질 수 있어 MCU 방식을 채택한 뒤 Client에서 스트림을 가공하여 UX를 맞추는 방식을 택하게 되었다.

(Audio의 경우에는 view port의 개념을 도입할 수 없어 SFU 단점이 더 부각되며 echo cancel에도 문제가 있어보여 MCU를 채택하였다.)

 

 

관련글

SRTP : https://early-football.tistory.com/17

RTP 프로토콜 (Real-time Transport Protocol)