1. 시작하면서
드디어 기다리고 기다리던 Kurento 를 이용한 N:M 그룹 화상 채팅이 완료되었습니다! 사실 매번 이번 코딩은 너무 어려웠습니다 하고 시작했지만...이번에는 정말 최고 난이도 였던 것 같습니다.
이게 다른 것보다는 한글로 적혀있는 정보를 찾기가 너무 힘들어서 오류가 나거나 했을 때 해결하기가 정말 힘들었던 것 같습니다. 시간이 가장 많이 들어갔던 부분은 서버설정과 쿠렌토 미디어 서버와 연결하기 위한 코딩 부분이었습니다.
서버 설정에서는 Kurento Media Server - 쿠렌토 - 와 turn server - coturn - 을 설치한 후 spring 프로젝트와 연결시킬 때 정말 많이 오류가 발생했었습니다. 단순히 서버 설정이 잘못된 건지 java 쪽에서 쿠렌토 서버와 연결하는 부분이 문제인건지 솔직히 감이 안 잡히더라구요ㅠ.ㅠ 이 부분으로 약 2주 정도 보냈던 것 같습니다. 2주 내내 스택 오버플로우와 kurento 공식 홈페이지, 2015년도 쯤 작성된 어느 외국인 분의 사이트...등등에서 여러 정보를 수집한 결과, 결국 해결 할 수 있었습니다.
쿠렌토와 제 기존 코드를 접목시키는 부분은 오히려 시간이 얼마 안 들었습니다. 사실 학원에 다닐때처럼 선생님이 있는 것도 아니고 어떻게 접근을 할까 많이 고민을 하다가 결국 쿠렌토 그룹 채팅 코드를 하나하나 분석하기 시작했습니다.
이때 전체 코드를 놓고 각 클래스마다, 메서드마다 주석을 달고 실제로 구동해보면서 어떻게 동작하는지 이해하는 시간을 가졌습니다. 그렇게 코드를 분석하면서 느낀 것은 신기하게도, 어쩌면 당연?하게도 기존의 채팅과 비슷한 부분이 많다는 것이었습니다. 코드가 정말 깔끔하게 잘 짜여있어서 읽기도 쉬웠고 동시에 "어? 이건 내가 기존에 쓰던 방법과 비슷하네?" 나 "이건 내꺼에서 조금만 응용하면 되겠네" 정도의 생각이 들더라구요. 새삼 잘 짜여진 코드가 얼마나 중요하고 소중한지 깨달는 계기가 되었던 것 같습니다.
이렇게 2번의 고비를 넘어서 결국 N:M 채팅이 완료되었습니다.
솔직하게 kurento 를 이용한 그룹 채팅을 꼭 해보고 싶었습니다. 아무래도 1:1 로만 구현하기에는 멋이 없으니까...ㅋㅋㅋ
다만 시작하기 전에 어려울꺼라고 겁먹고 kurento 를 이용해 구현하는건 추후에 해보려고 사실상 포기했었는데 "kurento 를 사용하면 그룹채팅이 생각보다 쉽습니다" 라는 댓글에 속아서 시작하게 되었습니다. 쉽지는 않았지만...그래도 배워가는건 많았던 프로젝트 였네요ㅎ
이번 포스팅에서는 짧게 프로젝트 개요와 테스트 영상만 소개 후 코드 분석과 쿠렌토 미디어 서버 설치, turn 서버 설치 등과 관련해서는 추후 포스팅 하도록 하겠습니다.
2. 프로젝트 개요
- Kurento Media Server 를 이용한 N:M 그룹 화상 채팅 구현하기
- 실시간 화면 공유 기능
- docker 배포용 dockerfile 내용 첨부
- 서버 성능을 고려하여 4명이 참여한 환경에서 화상 채팅 테스트 완료
- 화상 채팅의 CSS 가 Kurento Group Chatting 기본 CSS 와 완전히 동일합니다. 이 부분 양해 부탁드립니다.
- 이 부분은 함께 프로젝트하실 프론트와 퍼블리셔분을 꼭! 모셔서 같이 뜯어 고칠거에요ㅠ.ㅠ 혼자서는 도저히 못하겠더라구요...
https://github.com/SeJonJ/Spring-WebSocket-WebRTC-Chatting
GitHub - SeJonJ/Spring-WebSocket-WebRTC-Chatting: SpringBoot WebSocket & WebRTC Chatting
SpringBoot WebSocket & WebRTC Chatting. Contribute to SeJonJ/Spring-WebSocket-WebRTC-Chatting development by creating an account on GitHub.
github.com
3. Kurento Media Server 란?
Kurento Media Server 줄여서 KMS 라고 불리는 사실 이 친구에 대해서 이전에 살짝 언급하고 넘어갔었다. 이 친구의 역할은 간단하다. 바로 이전에는 내가 직접 구현했던 시그널링 서버 역할을 대신 해주는 친구이다. 혹시나 기억 안나시는 분들을 위해서, 그리고 까먹은 나를 위해서 다시 정리하고 넘어가자.
1) 시그널링 서버 signaling server
시그널링 서버를 쉽게 이야기하자면 "누구와 통신하는지 파악하는 것을 돕는 서버"라고 할 수 있다.
즉 인터넷 세상에서 아직 서로에 대해 모르는 두 클라이언트 - peer - 가 만나기 위한 약속을 잡기 위해서 sdp 와 ice 를 사용해서 peer 가 또 다른 peer 를 인식 할 수 있도록 돕고, 두 peer 가 연결될 수 있도록 돕는다.
물론 이전처럼 간단히 구현한 시그널링 서버는 1:1 채팅에는 아주 적합하다. 사실상 부하는 거의 없고, 완전한 실시간에 가까울 정도로 직접적인 영상 통신을 확인할 수 있다. 하지만 이 시그널링 서버를 사용해서 N:M 채팅을 사용한다면...나의 영상을 각 사람에게 전달하기 위한 4개의 uplink 가 필요하며 동시에 다른 4명으로부터 영상을 받기 위해 4 개의 downloadlink 가 필요하다.
2) 왜 Kurento Media Server 가 필요해?
알다싶이 사실 시그널링 서버는 내가 직접 구현 가능하다. 근데 왜 굳이 쿠렌토 미디어 서버가 필요할까? 바로 다른 이점이 많겠지만 내가 생각했을 때 가장 큰 장점은 N:M 의 채팅을 구현했을 때 각 클라이언트 간의 연결 편의성과 클라이언트들에게 가해지는 부하 감소라고 생각한다.
3) 쿠렌토 미디어 서버 - SFU
쿠렌토를 SFU 방식으로 구현했기에 SFU 방식의 미디어 서버에 따른 장단점을 적어보도록 하겠다.
먼저 쿠렌토 미디어 서버를 사용하면 클라이언트는 더 이상 모든 클라이언트와 직접적인 연결을 하는게 아니라 쿠렌토 서버 - 클라이언트(peer) 가 연결된다. 따라서 이전에는 총 M개의 업링크와 M개의 다운로드 링크가 필요했다면 쿠렌토 미디어 서버와 함께라면 단 하나의 업링크만 필요로 한다. 물론 여전히 총 M개의 다운로드 링크가 필요하지만, 적어도 보내는 비용이 우려 M 배 줄어들기 때문에 클라이언트에게 가해지는 부담은 많이 줄어든다.
다만 이로 인한 문제도 분명 있다. 결국 p2p 방식이 아니기 때문에 실시간성이 많이 줄어든다. 물론 MCU 방식보다는 실시간성이 그나마 유지되지만 분명 시그널링 서버를 구현(mesh 방식) 보다는 떨어지는 것이 사실이다. 동시에 서버 유지 비용이 필요하다. 결국 쿠렌토 미디어 '서버' 를 어딘가에는 설치해서 사용해야하기 때문이다.
4) 쿠렌토 미디어 서버와 SFU 방식 정리
Kurento Media Server : 쿠렌토 미디어 서버
쿠렌토는 WebRTC 미디어 서버이자 클라이언트 API 세트이면서, WWW와 스마트폰 플랫폼을 위해 비디오 애플리케이션을 간편하게 개발할 수 있도록 도와주는 기술이다.
이를 위해 쿠렌토 미디어 서버는 그룹간의 통신, 녹음, 방송, 시청각 흐름의 라우팅 기술을 지원하고 있다. 다른 미디어서버와 차별화된 기능으로 쿠렌토는 컴퓨터 비전, 음성 분석같은 고급 미디어 처리 기능도 제공한다.
SFU 방식
P2P와 달리 서버에서 미디어 트래픽을 중계해준다.
이전에는 클라이언트(Peer) - 클라이언트(Peer) 간의 연결을 진행했다면 이번에는 서버(Peer) - 클라이언트(Peer) 간의 연결을 진행하게 된다.
그에 따라, N:M 상황에서 여러 명과의 링크를 유지해야하는 상황에서 서버와의 링크를 유지하면서 서버와 미디어 정보를 송수신하면 된다.
위의 그림에서처럼 자신의 미디어 정보를 송신할 링크(Uplink) 1개와 미디어 정보를 수신할 링크(Downlink) N개를 가지게 된다.
이전 Mesh 구조에 비해 Connection을 덜 유지하게 된다.
장점
서버가 미디어 트래픽을 중계해주기 때문에 모든 Connection에 대해 클라이언트가 직접 관리할 필요가 줄어들기 때문에 클라이언트의 부하가 줄어들지만 서버의 부하가 증가한다.P2P보다는 실시간성이 떨어질순 있지만 P2P에 걸맞는 실시간 송수신이 보장된다.
단점
클라이언트의 부하가 줄어들긴하지만 단순 정보 중계를 위해 사용하던 P2P 서버와는 달리 미디어 트래픽을 중계해야하기 때문에 서버의 부하가 증가한다.P2P에 비해 N:M 연결에서 부하가 줄어들긴 했지만 각각의 수신 링크(Downlink)를 개별적으로 유지해야하기 때문에 클라이언트의 부하는 여전히 높다.
4. Kurento Media Server 라이브러리 설정
- KMS 사용을 위한 라이브러리 임포트!!
/* Kurento 미디어 서버 관련 2개 */
// https://mvnrepository.com/artifact/org.kurento/kurento-client
implementation group: 'org.kurento', name: 'kurento-client', version: '6.18.0'
// https://mvnrepository.com/artifact/org.kurento/kurento-utils-js
implementation group: 'org.kurento', name: 'kurento-utils-js', version: '6.18.0'- KMS 를 정상적으로 사용하여 화상 채팅을 하기 위해서는 spring 의 vm 옵션에 아래 내용을 꼭 추가해야 한다.
- 이렇게 지정함으로써 해당 KMS 서버를 이용해 사용자가 연결되거나 미디어가 전송 할 수 있다.
- 이때 KMS 가 설치된 서버의 IP 와 KMS 가 사용하는 PORT 를 입력한 후 kurento 로 경로를 지정한다.
-Dkms.url=ws://<KMS IP>:<PORT>/kurento
5. 구현 영상
- 영상의 목소리가...많이 깨져요ㅠ.ㅠ 소리는 최소로 해놓고 들어주시기 바랍니다.
- Reference
https://doc-kurento.readthedocs.io/en/latest/index.html
Welcome to Kurento — Kurento 6.18.0 documentation
Warning Kurento is a low-level platform to create WebRTC applications from scratch. You will be responsible of managing STUN/TURN servers, networking, scalability, etc. If you are new to WebRTC, we recommend using OpenVidu instead. OpenVidu is an easier to
doc-kurento.readthedocs.io
https://andonekwon.tistory.com/71
WebRTC란? (시그널링 과정 feat. Kurento Media Server) (3)(작성중)
이전 글 복습 NAT 환경 같은 경우에는 자신은 Private IP를 가지고 있어서 시그널링을 할 때 Peer to Peer로 통신을 할 수 있는 방법이 없다. 따라서 자신의 퍼블릭 IP를 알아내기 위해 STUN서버를 통해서
andonekwon.tistory.com
댓글