[WebRTC] 무조건 Openvidu를 사용하자 -2 (OpenVidu vs Kurento)

👈이전 글 가기

[WebRTC] 무조건 Openvidu를 사용하자 -1 (WebRTC란)

 

진짜 쓰고 싶은 말은 이 글이었다.

분명 둘 다 써 보신 분이 많을 텐데 관련 글이 정말 없었다. 

Openvidu와 Kurento가 각각 무엇인지, 실질적으로 어떤 차이를 가지는지 쓰려고 한다. 

+) 구구절절한 의문

 

Kurento란?

Introduction to Kurento — Kurento 6.16.1-dev documentation

전통의 쿠렌토다.

아마 6.16.1 버전을 사용할 확률이 높기에 해당 docs를 가져왔다.  

사이트를 쫙 둘러보면 WebRTC에 대한 기본적인 틀을 잡을 수 있다. Openvidu 또한 kurento 기반으로 개발되었으므로 kurento 웹사이트를 한 번 훑어보는 편을 추천한다. 

 

사이트를 들어가자마자 떡하니 Openvidu 추천글을 볼 수 있다.

나와 팀원들은 처음에 이 경고를 단순한 난이도 문제로 이해하고 무시했다. 

👩🧑🧒 쿠렌토가 오픈비두보다 빡센가 봐여ㅎㅎ 근데 우리는 이미 이미 설정 다 끝냈고 서비스 돌렸으니까 화이팅! 
(그리고 이 사람들은 땅을 치게 됩니다...)

백문이 불여일견이라고, 일단 사용을 해봐야 감이 잡힐 것 같았다.

메뉴에서 tutorial을 눌러보면 여러가지 튜토리얼들을 제공한다.

GitHub - Kurento/kurento-tutorial-java

git으로 kurento tutorial을 끌어오면 정말 많은 튜토리얼이 있는데, 팀원 분께서 모든 튜토리얼을 돌려 본 다음 노션에 정리해주셨다.

모든 튜토리얼은 signalling 서버에 static resources가 붙어 있는 SPA 어플리케이션이다. 

coturn을 써도 카메라를 켠 브라우저에서만 영상이 보였다.  마리오 화면이 입혀져서 보이는데 인식이 좀 처참하다.

로컬에서 Start 누르면 녹화가 시작되고, Stop을 누르면 녹화가 중지, Play를 누르면 녹화된 영상이 시작되는 것 같음(coturn을 켜도 녹화한 브라우저에서만 동작함)

1:N방식, Presenter와 Viewer가 있고, Presenter가 화면을 띄우면 Viewer가 동일한 화면을 볼 수 있다. Presenter가 화면을 Stop하면 Viewer도 자동으로 Stop.

Radio관련해서 Plate Detector filter라는게 있다는데 뭔지 모르겠음 그냥 start하면 화면 켜지고 stop하면 꺼짐 coturn을 켜도 카메라를 start한 브라우저에서만 영상이 보임

start누르면 갑자기 뭔 동영상 나옴 stop누르면 멈춤 동영상 틀어주는 그런거 인듯

영상과 텍스트를 같이 보낼 수 있음

아마 사람 인식하는 것 같은데  동작 안 됨... 뭔지 모르겠음  

ㅎㅎ안됨

1:1 영상통화 느낌 call 눌러도 안나옴

동영상을 재생, 일시정지, 정지, 원하는 초로 이동 등 기능을 사용할 수 있음

우리가 튜닝했던 예제

사람 감지해서 모자씌워줌

1:1로 통화하는거 같은데 작동이 안된다.

Calibrate를 누르면 remote stream에 이곳저곳 빨간 포인터가 옮겨다님

coturn을 켜도 카메라를 start한 브라우저에서만 영상이 보임

사람 얼굴 detect

one2one은 계속 동작을 안한다..

RTP 프로토콜 관련인거같은데 start 누르면 계속 로딩만함

우리는 kurento groupcall 예제를 이용했다.

SPA로 구성된 시그널링 서버에 몇가지 기능을 덧붙이고, vanila js로 이루어진 뷰 static 파일들을 뽑아내 react로 이식했다.

기존 maven dependency에 의존성을 가지는 정적 리소스 파일을 react에서 작동시키기 위해서 kurento-utils를 npm으로 설치했다.

 

kurento의 장점이자 단점 중 하나는, 네트워크를 직접 구성해야 한다는 거다.

데모를 사용하더라도 coturn과 kms는 별도로 돌려줘야 한다. kms 도커 내부의 설정 파일과 client단에서 최초 커넥션을 생성할 때 보내는 패킷에도 coturn의 ip를 적어줘야만 했다. 

이 과정에서 WebRTC 네트워크 구성요소에 대한 팀원들의 이해도가 비약적으로 상승했다.

 

 

OpenVidu란?

 

Kurento 기반으로 개발된 오픈소스다. 엄밀히 말하자면 이 친구도 쿠렌토지만 편의를 위해 쿠렌토와 오픈비두로 구별해서 부르고 있다. 

쿠렌토가 정말 날것이라면, openvidu는 잘 가공된 친구라 그냥 갖다 쓰기만 하면 된다.

openvidu도 정말 많은 튜토리얼들을 제공한다.

OpenVidu Docs

22년 02년 기준 2.20.0버전이 최신이다. 

메뉴의 deployment > onpremises 방식을 따라하면 ./openvidu start 라는 명령어 하나로 coturn server와 nginx와 kms와 signalling 서버를 한 번에 돌릴 수 있다. 하라는 대로 한 줄만 적어주면 SSL 인증서도 설정할 수 있다. 

On premises - OpenVidu Docs

실배포 전의 테스트와 코드 분석은 openvidu의 openvidu-server를 받아서 진행했다. 

client는 openvidu-tutorial의 insecure-react을 수정해서 우리 프론트에 실었다.

insecure-react는 클래스형 react.js로 구성되어 있는데, useState를 이용하는 함수형으로 수정만 해 주면 우리 프론트에 쉽게 이식할 수 있었다.  

GitHub - OpenVidu/openvidu: OpenVidu Platform main repository

 

GitHub - OpenVidu/openvidu-tutorials: OpenVidu tutorials to get started

 

 

왜 Kurento에서 Openvidu로 옮겼을까

지금 생각해봐도 거의 사기 당한 기분이다. 

쿠렌토와 오픈비두의 차이는 단순한 구축 난이도의 차이가 아니었다.

시그널링 서버의 내부 구조가 완전히 달랐다. 

왜 처음에 Kurento를 선택했을까?

Kurento를 선택하면서는 해결해야 할 과제가 있었다. 

어디 가서 Java 잘한다고 자랑할 만큼은 아니었지만 Signalling server 쯤은 충분히 이해하고 튜닝할 자신이 있었다.  

react에 대한 기본적인 이해도 있었고, github 검색이라면 이골이 났기에 js를 react로 이식하는 것도 어떻게든 되겠지 싶었다.

팀원 분께서 이미 서버 구조에 대해 통달하고 공유까지 마쳐주신 덕에, 쿠렌토의 가장 큰 장벽이라던 배포 네트워크도 튜토리얼을 돌려 보는 과정에서 이미 구축이 완료된 상황이었다. 

우리에게 필요한 음성 변조나 영상 인식 라이브러리도 kurento 데모나 추가적인 라이브러리를 통해 충분히 구현할 수 있겠다는 확신도 있었다. 

 

로우한 기술을 다루는 것에 대한 디메리트는 기술의 이해도와 튜닝의 난이도에 달렸는데, 우리 상황에서는 메리트가 더 크다고 판단했다.

그에 대한 두려움도 없었다. 

하지만...

Kurento 이슈

네트워크 구성이나 서버 튜닝의 난이도는 앞에서 아무 문제 없었다고 기술했으므로 패스한다. 

프론트 팀에서 열심히 react로 구성해주신 클라이언트에 kurento client를 이식해서 단체 테스트에 들어간 백엔드 팀은 난관에 직면했다.

바로 세션문제였다.

[Kurento] Websocket이 갑자기 끊겨버림

저것때문에 진짜 개고생했다.

3차 맞고 쉬셔야 할 멘토님도 웹엑스로 오셔가지고 같이 원인 잡아주시고... 정말 너무 감사드렸습니다ㅠㅠㅠㅠ

 

Kurento의 Signalling 서버는 WebSocketSession으로 participant를 관리하고, 클라이언트 측에서도 socket을 이용해 시그널을 날린다. 

그런데 시그널링 서버로 날아가는 사용자의 세션값이 요청마다 바뀌는 것을 확인할 수 있었다.

시그널링 서버에서는 당연히 해당 사용자가 저장되지 않은 사용자라고 판단해 에러를 일으켰고, 따라서 클라이언트 측에서는 웹소켓 연결이 바로 끊겨서 튕겨버리는 거다. (세션값이 바뀌든 말든 일방적인 수신은 제대로 됐다)

js로 테스트 해봤을 때는 문제가 없었으니 원인을 추측하기로는 리액트 컴포넌트 관련 문제인 것 같은데 괴상한 건... 컴포넌트가 재렌더링 되지 않았음에도 불구하고 세션값이 막 바뀜. 원인을 잡을 수가 없었다. 

노가다 디버깅을 통해 일부 해결할 수는 있었으나 그것마저 아니 이러면 된다고요 수준이었고 완벽하게 해결하는 건 불가능하다는 결론을 내렸다.

 

그래서 팀원들은 이를 악물고 시연 촬영 4일 전에 쿠렌토를 포기하고 openvidu로 갈아타는 모험을 감행한다.

사실 Openvidu도 어차피 kurento 기반이었기 때문에 이때까지만 해도 Openvidu가 우리의 이슈를 해결해 주리라는 확신은 없었다.

하지만 코드 분석 결과... 어 이건 될 수도 있겠다 싶었고... 과감하게 갈아엎었다.  

 

그렇게 쿠렌토로 단련된 팀원들은 하루 반만에 완벽한 이사에 성공하게 된다.

비료푸대도 아닌 판자때기임

 

 

Openvidu는 뭐가 다르길래?

Session

앞서 kurento는 WebsocketSession으로 사용자를 관리한다고 말한 바 있다. 클라이언트에서도 웹소켓을 날려 통신하므로 웹소켓의 세션값이 굉장히 중요해진다. 

Openvidu의 signalling server를 뜯어보면 좀 다르다. 

openvidu-server / kurento-group-call

Kurento-WebSocketSession

Kurento에서 사용자 요청 플로우를 따라가려면 CallHandler의 handleTextMessage()부터 보면 된다.

CallHandler.handleTextMessage()

CallHandler 클래스는 처음부터 org.springframework.web.socket.handler.TextWebSocketHandler를 implement해서 구현되어 있다. 

오버라이드 된 handleTextMessage에서는 처음부터 WebSocketSession과 message를 받는데, 클라이언트에서 Json타입으로 메세지를 만들어 웹소켓에 실어 보내면 이 친구가 그걸 잡은 다음에 json메세지의 id값에 따라 해당 요청을 수행하는 거다. 

만일 추가적인 기능을 붙이고 싶다면 case문을 추가해주면 된다.

WebSocketSession은 커스텀이 아니라 org.springframework.web.socket.WebSocketSession 라이브러리다. 

UserSession

각 유저 객체를 뜻하는 UserSession 클래스에서도 WebSocketSession을 그대로 저장해서 쓰고 있다. 

Openvidu-Session(사용자 정의)

Openvidu에서 사용자 요청 플로우를 따라가려면 rest->core 패키지 순으로 보면 된다. 

rest.SessionRestController

보다시피 openvidu는 클라이언트에서 axios로 날린 호출을 controller에서 낚아채는 REST 방식으로 작동한다. 

 

클라이언트에서 openvidu 관련 패키지를 설치하고 호출 주소만 잡아주면 끝이라 웹소켓을 따로 신경써 줄 필요가 없다. 

Openvidu에서도 Session객체를 사용하니까 얘도 세션값 바뀌면 에러 뜨는 거 아니냐 할 수 있는데

core.Session

사실 이 세션은 얘가 걍 만든 클래스였던 거임^^

Openvidu에서는 post 방식으로 @PathVariable에 실어보낸 sessionId라는 String값을 통해 participant를 관리하고 있다.

위에서 보이는 SessionProperties도 라이브러리가 아니라 따로 정의한 클래스다. 

그러니까 클라이언트 측에서는 SessionId라는 String을 계속 가지고 있기만 하면 kurento에서처럼 요청마다 세션값이 바뀌니 마니를 신경 쓸 필요가 없는 거다. 

이렇게 우리의 이슈가 해결되었다.

 

Signal

아예 요청 방식 자체가 다르다 보니 추가적인 기능을 붙이는 데에도 차이가 있었다.

결론부터 말하자면 openvidu가 쉽다.

Kurento-CallHandler,WebSocket

Kurento에서는 앞서 말했듯이 message의 id타입에 따라 서버가 수행하는 일이 달라지므로, 새로운 기능을 추가하려면 클라이언트와 서버를 모두 건드려야만 했다. 

Client receiver, Client sender (Server CallHandler case문도 추가해줘야 함) 

Openvidu-API

그러나 openvidu-server에는 단순히 메세지를 전달하기만 하는 API가 이미 존재하므로, 서버를 건드릴 필요가 전혀 없었다. 클라이언트에서 message type을 설정하고 해당 API로 post 요청을 날리면, 서버는 단순히 메세지를 전달만 해준다. 그러면 클라이언트에서 sender랑 receive만 짜 주면 되는 거다. 

Client sender, Client receiver

누구에게 보낼지도 클라이언트에서 모두 정할 수 있었다. 

mySession은 useState로 관리하는 객체로, openvidu-browser npm package를 설치하면 쓸 수 있는 Openvidu가 알아서 해 준다.

to를 없애거나 빈 array를 넣으면 해당 방에 있는 사람들에게 브로드캐스팅이 날아가고, 특정인을 적어넣으면 해당 사용자에게만 메세지가 날아간다. 채팅 예제만 들고왔지만 우리는 이펙트부터 레이아웃 변경까지 오만 기능을 우겨넣을 수 있었다. 

 

사실 이건 kurento에서도 관련 case문만 하나 짜 주면 동일하게 구현할 수 있는 부분이기도 했다. 하지만 굳이 백엔드의 도움을 받아 maven으로 된 서버를 건드리지 않아도 프론트가 react로 모든 걸 조종할 수 있다는 건 정말 큰 메리트다.

 

media 제어

화상서비스에서 사용자의 미디어 제어는 필수적이다.

캠 껐다 켜고 마이크 껐다 켜야죠.

그런데 사용자 미디어는 누가 제어할까요.

kurento-rtcPeer

kurento를 이용할 때는 다음과 같은 코드를 짰다.

이게 진짜 골 때렸던 게 정확한 코드 가이드가 없다. 

kurento google forum에 누가 미디어 제어 관련해서 질문을 올리면 답변으로 한 세네가지 방식이 달린다. 다 해보세용 뭐 하나는 될 거임 이런 식임. 물론 우리는 다 안 돼서 팀원 분들이 kurento client에서 개별 사용자 설정을 총괄하는 rtcPeer 코드를 전부 까 본 다음에 찾아내셨다. 

Openvidu-stream

 

따로 쓸 일이 있어서 video랑 audio를 useState로 관리하는 바람에 길어보이지만 훨씬 쉽다. 

openvidu에서는 peer 각각을 stream으로 제어한다. stream을 확인해서 오디오 켜져 있으면 지금 퍼블리싱하는 오디오 끄라고 명령만 쳐 주는 거다. 

이 작업이 좋았던 게, openvidu는 자체 포럼과 docs가 굉장히 잘 구성되어 있다.

저런 단순 작업에 시간 쓸 필요 없이 그냥 공식독스나 포럼에서 보고 복붙하면 된다.

 

media 가공

음성 가공은 우리 서비스의 핵심이었다.

노래방을 만들었는데 에코가 안 되면 어떡합니까. 그리고 음성변조도 꼭 넣고 싶었다.

kurento-ㅎㅎ...

얘는 차마 코드를 못 가져왔다.

계획대로라면 GStreamer를 물려야 했는데 깃허브를 아무리 뒤져도 kurento에 gstreamer를 어떻게 물리는지 찾을 수가 없었다.

그래서 우리는... 급기야 getUserMedia()로 사용자 음성을 쌩으로 끌어온 다음에 오픈된 js라이브러리와 npm 코드를 까서 커스텀하게 된다. 정말 딥했다.

그런데 그렇게 가공한 음성을 kurento-utils에 어떻게 물려야 하는지를 알 수가 없었다. 당연히 kurento-utils도 내부적으로도 getUserMedia()로 사용자 음성을 가져와 전송하고 있었는데, 그 음성을 우리가 변조한 음성으로 대체하는 법을 도저히 못 찾겠던 거다. 

블럭만 잘 끼워맞추면 된다고 생각했지만 kurento-utils라는 기존 블럭을 아예 박살내고 재구성해야 하는 상황이 와 버린 거다. 

openvidu-applyFilter()

GStreamerFilter를 끼울 수 있는 applyFilter를 제공한다... 

추가 설명은 생략한다... 

 

 

마무리

Kurento와 Openvidu의 차이는 재료만 주어지느냐, 혹은 이미 만들어져 있는가의 차이라고 생각했다.

그렇기에 Kurento로도 충분히 openvidu만한 퍼포먼스를 낼 수 있고, 오히려 필요한 기능만 가볍게 들고 갈 수 있으리라 예상했다. 

 

그런데 kurento가 너무 low했다. 

체감상 Kurento가 나무 조각 하나라면 Openvidu는 수많은 라이브러리들을 끼워넣을 수 있도록 정교하게 가공된 블록 같았다. 

레퍼런스 차이도 너무 심했다. 

 

물론 서버 구축 방면에서는 kurento가 훨씬 좋았다.

kurento를 사용하면서 우리 입맛대로 맞춰 놓은 nginx나 coturn을, openvidu로 옮긴 뒤에는 고정된 설정값으로 사용해야만 했는데 그게 굉장히 불편했다. 

 

확실한 건 kurento는 데모와 공식독스, 그리고 포럼을 뒤진다고 해서 해결할 수 있는 친구가 아니었다. 딥하게 파고 들자면 클라이언트에 설치했던 kurento-utils package부터 우리 입맛에 맞게 뜯어고친 다음에 Signalling Server를 바닥부터 구축했어야 하는데

 

어쨌든 우리가 그걸 할 수 있었다면 화상서비스를 개발하는 게 아니라 진작 WebRTC 오픈소스에 기여하러 갔을 거다.

 

오픈비두 쓰세요.