[눈치 코치 캐치!] WebRTC를 어떻게 구현해야 할까?

 

시작하기 전에

지난 글에서 WebRTC에 대해 알아보았다.
그럼 이제 우리의 [눈치 코치 캐치!] 드로잉 게임 서비스에 맞게 WebRTC를 구현해야 한다.
WebRTC를 어떻게 구현해야 할까?

 

👇아직 이전글을 보지 않았다면?👇

[눈치 코치 캐치!] WebRTC 한 방에 정리하기

 

 

 

첫 번째 고민, WebRTC의 방식 선택

 

WebRTC의 다양한 방식(Mesh vs SFU vs MCU)

WebRTC는 기본적으로 서버를 사용하지 않는 P2P(Peer to Peer) 방식을 사용한다. 1:1 통신을 하는 것이다.
하지만 필연적으로 다자간 연결이 필요하다. 그러기 위해 다양한 종류의 서버(시그널링 서버, STUN 서버, TURN 서버, 미디어 서버 등)를 사용한다.

[눈치 코치 캐치!]에서는 하나의 게임방에 최대 8명이 참여할 수 있기 때문에 최대 8명의 음성 채팅을 구현해야 했다.
이렇게 다대다로 실시간 데이터를 주고받기 위해서는 2가지 방법을 생각해 볼 수 있다.

1. P2P 연결과 같이 각 피어(Peer)가 모두 자신의 미디어 스트림을 나머지 피어들에게 직접 전달
   ⇒ Mesh Networking(이하 Mesh)
2. 여러 피어들이 자신들의 미디어 스트림을 중앙의 한 곳(또는 그 이상)에 보내고 이를 일괄적으로 처리하여 피어들에게 전달
   ⇒ SFU(Selective Forwarding Unit) or MCU(Multi-point Control Unit)

각 방식의 특징들은 지난 글에서 살펴보았으니 장단점 위주로 살펴보자.

	장점	단점	결론
Mesh	중앙 서버 없이 P2P 방식으로 직접 연결되기 때문에 비교적 비용이 적게 들고, 구현이 간단하다.	연결이 많아질수록 스트림 수가 급격히 늘어나기 때문에 클라이언트에 부담이 크다.	1대1, 소규모 미디어 교환에 적합
SFU	중앙 서버를 통해 별도의 가공 과정 없이 미디어 트래픽을 중계하기 때문에 비교적 서버에 부하가 적게 걸린다. 지연 시간 역시 낮다.	각 피어간 연결 할당, 암호화 및 복호화 처리 비용 정도를 감수해야 한다. 미디어 서버의 구현이 쉽지 않다.	1:N 스트리밍 서비스, N:M 소통에 적합
MCU	미디어 스트림을 중앙 서버에서 모아 가공 후 전달하기 때문에 클라이언트의 부담이 적다.	중앙 서버의 CPU 사용량이 매우 커져 높은 컴퓨팅 파워가 요구된다. WebRTC의 최대 장점인 실시간성이 저해된다.	N:M 소통에 적합

 

여러 가지 장단점을 고려했을 때,
최종적으로 Mesh 방식을 이용하여 WebRTC를 구현하기로 결정했다.

 

 

Mesh 방식을 선택하게 된 이유

기술 선택의 기준은 어떻게 정해야 할까?
나는 WebRTC를 이미 구현한 서비스를 찾아 그 내부를 파헤쳐보는 게 가장 효율적일 것이라고 생각했다.
그래서 우리와 같이 이 기술을 사용하여 웹 게임을 구현했던 항해99 선배 기수분들의 다양한 프로젝트를 참고해 보기로 했다.
다행히 선배 기수분들이 고민의 흔적들을 잘 기록해 두셔서 많은 도움을 받을 수 있었다.

 

'Zzz 꿈 깨(온라인 3D 방탈출 게임 서비스)'는 Mesh 방식(음성, 최대 4명)

P2P 방식(Mesh 방식) 결정 이유
- 비디오 없이 오디오 통신만 사용하고, 한 방에 최대 4명까지 인원이 제한되기 때문에 Signalling Server를 만들어서 P2P 방식으로 구현해도 클라이언트의 부하가 크지 않을 것이다.
- SFU나 MCU는 우리가 직접 프로젝트에서 구현하기 어렵다.

📚 출처 Zzz 꿈깨 Github Wiki

 

'라이어 게임 : 비밀의 문(온라인 라이어 게임)'은 SFU 방식(영상+음성, 최대 8명)

OpenVidu(SFU 방식) 선택 이유
MCU 방식은 WebRTC를 사용하는 이유인 실시간성이 저해되고 비디오, 오디오와 같은 미디어 자원을 사용하는 데에 있어 비용이 많이 든다는 단점이 있습니다. Mesh 방식은 클라이언트끼리 직접적으로 연결되어 클라이언트의 과부하가 급격하게 증가합니다. 따라서, 다대다 WebRTC 연결방식 중 클라이언트의 부하가 적은 SFU 방식 선택하였고, SFU연결에 필요한 미디어 서버 구축에 필요한 리소스를 절약해 주는 open-vidu 라이브러리 이용하였습니다.

📚 출처 라이어게임 : 비밀의 문 Github Repository

 

표로 정리해 보면 다음과 같다.

	WebRTC 방식	필요한 미디어	최대 인원
Zzz 꿈깨	Mesh	음성	4명
라이어 게임 : 비밀의 문	SFU	영상+음성	8명
눈치 코치 캐치!	???	음성	8명

 

위의 레퍼런스를 참고하기도 하고,
기술 멘토님께 조언을 구하기도 하고,
Github 오픈소스를 찾아보며 여러 가지를 고려했을 때 다음과 같은 이유들로 Mesh 방식을 선택하게 되었다.

• WebRTC는 기본적으로 P2P 방식을 권장.
• MCU 방식은 높은 컴퓨팅 파워를 요구하고, 실시간성이 저해되기 때문에 알맞지 않음.
• SFU 방식은 하나의 서버를 더 구축해야 하기 때문에 프로젝트 규모에 맞지 않음.
• 최대 인원수가 정해져 있는 것과 같이 부하가 예측 가능한 상황이면 Mesh 방식이 성능적 측면에서 나을 것이라는 조언.
• 영상 없이 음성 통신만 구현하기 때문에 클라이언트의 부하가 심하지 않을 것으로 판단.

 

 

 

두 번째 고민, 시그널링 서버를 구축할 언어 선택

 

Spring vs Node.js

Signaling을 위한 구체적인 구현 방법과 프로토콜은 WebRTC에 명세되어 있지 않기 때문에, 개발자는 자신에게 맞는 최적의 방법을 선택적으로 적용해야 한다.

 

P2P 방식으로 통신하기 위해서는 시그널링 서버를 구축해야 한다.
우리는 시그널링 서버를 구축할 언어로 2가지의 선택지를 놓고 고민하게 되었다.
‘당연히 Spring으로 구축하면 되는 거 아니야?’라고 할 수도 있지만,
Node.js를 고민하게 된 배경은 다음과 같다.

	장점	단점
Spring	팀원들 모두 익숙한 프레임워크를 사용할 수 있다. 서버를 1개만 관리하면 된다.	참고자료가 많지 않다.
Node.js	Socket.io 라이브러리를 사용하면 참고자료가 많다.	서버를 2개 관리해야 하기 때문에 유지 관리에 더 많은 비용이 소모된다. 팀원들에게 익숙하지 않은 언어와 프레임워크를 사용해야 한다.

위와 같은 이유로 'Zzz 꿈깨'는 Node.js를 사용하여 시그널링 서버를 구축하였다.
하지만 우리는 최종적으로 Spring을 이용하여 시그널링 서버를 구축하기로 결정하였다.

 

 

Spring으로 시그널링 서버를 구축하게 된 이유

WebRTC 자체가 처음 도전해 보는 기술이었고,
공식 문서도 친절하지 않았기 때문에 참고할 자료가 많지 않다는 건 치명적인 단점이었다.
그럼에도 Spring을 선택한 이유는 다음과 같다

• 주특기 언어인 Spring으로 구현해보고 싶다는 욕심.
• 현재 프로젝트 규모에서는 서버를 하나로만 구성해도 충분할 것이라는 판단.
• 확실히 Node.js가 구축하기 쉽겠지만 이전 기수를 참고하지 말고 도전해 봤으면 좋겠다는 멘토님의 조언.

 

그리하여 피어끼리 연결하는 Mesh 방식으로,
그에 따라 필요한 시그널링 서버는 WebSocket을 통신 프로토콜로 사용하여 Spring Boot로 구축하게 되었다!

 

 

 

Spring으로 시그널링 서버를 어떻게 구축하지?

다음은 직접 시그널링 서버를 구축하는 내용을 담아보려 한다.
앞서 말했듯, 참고자료가 많지 않았기 때문에 정말 악으로 깡으로(ㅋㅋㅋ) 도전해 보았다.
다음 편에 계속!

 

 

 

 

📚 참고 자료

1000명이서 실시간 커뮤니케이션을 하는 가장 효과적인 방법

2. WebRTC 구현 방식