현재 WebRTC를 활용한 화상 회의 플랫폼을 프로젝트로 진행하고 있다.
WebRTC(Web Real-Time Communication)는 웹 애플리케이션과 모바일 애플리케이션에서 플러그인 없이 음성, 영상 및 데이터 공유를 실시간으로 가능하게 해주는 오픈 소스 프로젝트이다.
WebRTC는 P2P 통신이 기본이지만, WebRTC의 연결을 관리하려면 시그널링 서버가 필요하다.
이 서버는 피어들 간에 SDP(Session Description Protocol) 및 ICE(Interactive Connectivity Establishment) 정보를 교환하는 역할을 합니다.
또한 시그널링 서버를 단순하게 구현하려면 WebSocket을 직접 활용해서 클라이언트 간의 연결 정보를 주고받으면 된다. 하지만!! 이런 방식이면 서버에 부하가 심해지고, 다자간 연결에 어려움을 겪는다. 이럴 때 메시지 브로커를 도입할 수 있다.
근데 우리는 일단 빠른 개발 및 데모 시연을 위해 SpringBoot에서 WebSocket을 직접 활용하고 나중에 확장성을 고려해서 도입하겠다.
왜 메시지 브로커가 서버의 부하를 감소시키는가??
메시지 브로커가 가 없을 때 vs 있을 때 차이
🔹 WebSocket만 사용하면?
✔ WebSocket 서버가 모든 클라이언트를 직접 관리해야 함
✔ 다자간 연결 시 부하가 급증
✔ WebSocket 서버를 여러 개로 확장하기 어려움
🔹 메시지 브로커를 추가하면?
✔ WebSocket 서버 여러 개를 운영할 수 있음 (수평 확장 가능)
✔ WebSocket 서버 간 직접 연결할 필요 없이 Kafka가 메시지를 중계
✔ 부하가 줄어들고, 서버 간 확장성이 높아짐
Message Broker(메시지 브로커)는 Publisher(송신자)로부터 전달받은 메시지를 Subscriber(수신자)로 전달해주는 중간 역할이며 응용 소프트웨어 간에 메시지를 교환할 수 있게 한다. 이 때 메시지가 적재되는 공간을 Message Queue(메세지 큐)라고 하며 메시지의 그룹을 Topic(토픽)이라고 한다.
메시지 브로커는 송신자가 보낸 메시지를 메시지 큐에 적재하고 이를 수신자가 받아서 사용하는 구조이다. 이러한 구조를 Pulibsh/Subscribe(pub/sub) Pattern이라고 한다.
각각 Redis와 Apache Kafka를 사용했을 때 어떻게 메시지 브로커가 작동하는지 참고할 수 있는 사진들이다.
