딴 생각하는 공대생/일상  ᕙ(•̀‸•́‶)ᕗ

WebRTC 미디어 연결 방식 (MCU, SFU, P2P)

일상을 공유함니다 2020. 12. 16. 13:30

크로미움 오픈소스와 WebRTC org 가 협업한 지 꽤 오랜 시간이 지났고 우리는 흔하게 WebRTC 라는 프로토콜을 접할 수 있게 되었다. 즉, 아무나 영상회의 서비스를 만들 수 있지만 누구나 잘 만들 수 있는 건 아니다.

 

WebRTC 기반의 영상회의 서비스에서 사용하는 연결 구조에 대한 이야기이다.

 

 

P2P

서버 방식이 아닌 클라이언트 간의 연결 다중 연결 방식으로 Mesh 구조를 생각하면 된다. 서버나 네트워크에 대한 지식이 부족한 클라이언트 개발자가 영상회의 서비스를 만들 수 있는 방법이다.

 

P2P 연결 방식

 

4개의 클라이언트가 연결된다고 한다면, 1개의 클라이언트는 3개의 클라이언트와 3개의 개별 커넥션을 맺고 미디어를 송출해야 한다. 그리고 3개 미디어를 수신하여 내 화면에 디스플레이하면 된다.

서버 자원을 이용하지 않는 대신 각 클라이언트의 네트워크 I/O 부하가 높게 발생하고 컴퓨터의 HW 리소스 사용률도 많이 증가하게 된다. 그래서 연결된 클라이언트가 적을 경우 매우 유리한 구조이지만 연결해야 될 클라이언트가 많을 경우 부하를 줄일 수 있는 알고리즘을 구현해야 될 것이다.

 

특이 사항

- 간단하고 빠르게 구현할 수 있다.

- 서버 비용이 들지 않는다.

- 종단간 암호화가 가능하다.

- 사용자 PC에 많은 부하를 준다.

 

 

SFU

서버를 이용하여 클라이언트의 미디어 스트림을 중계하는 역할을 수행하며 상황에 따라 연결된 클라이언트 일부만 중계하기도 한다. P2P 에서 다수의 사용자를 다루기 힘든 부분을 충분히 커버할 수 있는 장점을 가지고 있다.

 

SFU 연결 방식

P2P의 경우 연결된 클라이언트 수만큼의 업로드 트래픽이 발생했지만 SFU는 업로드 커넥션을 1개만 유지하면 나머지는 서버에서 각 클라이언트로 분배하여 내려주게 된다. 대표적으로 ZOOM 이 사용하고 있는 구조로 1000명이 한 번에 연결되어 회의를 할 수 있는 정도로 효율적이라 볼 수 있다.

단, 개별 클라이언트는 접속한  클라이언트 수(또는 내 화면이 디스플레이해야 되는 클라이언트 수)만큼의 영상과 음성을 디코딩해야 한다. 접속한 클라이언트 수가 많으면 많을수록 PC의 자원 사용량이 많아지면서 회의가 어려울 수 있다. 이를 해결하기 위해 SVC 코덱이나 Simulcast 를 활용해야 한다. ZOOM 의 경우는 PC에서 한 번에 25개의 클라이언트의 미디어를 디코딩하도록 설계되어 있다. (아마 그 이상 디스플레이는 컴퓨터의 자원 소모가 매우 심할 것으로 예상된다.) 또한 모바일 기기도 고려한다면 모바일 AP의 디코딩 성능도 감안해야 한다. 

 

특이사항

- P2P 보다 네트워크 트래픽이 적게 발생한다.

- 대규모 연결에 적합하다.

- 상황에 따른 미디어 품질 조정을 할 수 있다.

- 개별 레이아웃 조정이 가능하다.

 

 

MCU

서버를 이용하여 업로드된 미디어스트림을 하나로 합쳐(Mixing)서 클라이언트에 1개의 미디어스트림을 내려주는 구조이다. P2P 와 SFU 에서 발생하는 트래픽은 줄일 수 있으나 미디어스트림을 합치는 동작에서 서버에 자원을 많이 소모하게 된다.

 

MCU 연결 방식

MCU 방식은 서버 자원을 활용하여 각 클라이언트의 부담을 줄이는 연결 방식이다. 보통 연결된 클라이언트의 영상을 1개로 Mixing 하는 형태가 일반적이지만 사용자가 많은 경우 2-3개 그룹 형태로 Mixing 하여 분임토임 등 대규모 접속을 처리할 수도 있다. 

MCU 방식은 암호화된 미디어 스트림이 서버 한 번 복호화되고 다시 암호화되는 형태로 완벽한 종단간 암호화라 보기 어렵다.

하나로 Mixing 된 영상은 용량이나 해상도가 높을 수 있기 때문에 원활한 서비스를 위해서는 트랜스코딩이나 별도 알고리즘을 구현해야 한다.

 

특이사항

- 클라이언트 트래픽을 줄일 수 있다.

- 서버의 자원을 많이 사용한다.

- 상황에 따라 미디어 품질을 조정해야 한다.

 

 


정리

코로나19로 인해 원격근무가 뉴노멀로 자리 잡아감에 따라 영상회의에 대한 수요가 증가하고 있다. 이로 인해 협업 툴을 제공하는 서비스 제공자들이 접근성이 용이한 WebRTC 기반의 영상통화나 영상회의 서비스를 출시하고 있다. 하지만 서비스 품질 유지를 위한 노하우가 없다면 운영에 많은 애로 사항들을 겪을 수밖에 없다. 언제나 우리 고객들은 생각지도 못한 다양한 환경에서 서비스를 이용하기 때문이다.

 

SFU, MCU, P2P 연결 방식 중 1개 만을 집중하여 서비스를 제공하는 것보다는 상황이나 도메인 특성에 맞게 융합된 형태로 제공하는 방안을 검토해보는 것이 좋을 것이다.

 

Google MeetZOOM 은 SFU 연결 방식을 기반으로 한 대표적인 기업이다.

전통적인 HW 기반 영상회의 업체는 MCU 연결방식을 기본으로 하며 요즘은 SFU도 병행하는 형태이다.

간혹 소셜 미팅이나 원격 진료에 P2P 형태로 연결되는 서비스들이 있기도 하다.

 


 

SFU 를 위한 비디오 코덱 알아보기

 

WebRTC 개념원리 > 비디오 코덱

WebRTC의 기능 카메라 또는 마이크를 사용하는 기본 웹 앱에서부터 고급 영상 통화 애플리케이션 및 화면 공유에 이르기까지, WebRTC는 다양한 사용 사례가 있습니다. Google에서는 기술 작동 방식과

WebRTC org

 

WebRTC 개념원리 > chrome://chrome-urls/

WebRTC 디버깅은 참으로 짜증난다. 그냥 그렇다. 기본적으로 크로미움에서 제공하는 툴을 최대한 활용하도록 하자. chrome://chrome-urls/ 크롬에서 제공하는 기능들 리스트업되어 있다. 다양한 기능을

WebRTC org


LIST