221104 TIL [Spring boot + React]실시간 채팅 기능 구현하기 - 2

어제 실시간 채팅 기능을 구현하기 위해 Http 방식보다는 WebSocket을 이용해서 구현하는게 더 효율적이라고 판단이되어 WebSocket을 이용해서 구현하기로 결정했다.
그런데 WebSocket을 사용하면 채팅방이 1개밖에 존재하지 못한다는 문제점이 있었다.
여러개의 채팅방이 필요했었기 때문에 WebSocket만으로는 내가 원하는 기능을 구현하지 못할것 같았다. 그래서 멀티 채팅방 기능을 구현할 수 있는 방법을 찾다 STOMP라는 것을 알게되었다.
STOMP는 pub/sub패턴을 사용하기 때문에 멀티 채팅방을 구현할 수 있다는 것을 알게되었다.

STOMP

STOMP(Simple Text Oriented Messaging Protocol)는 메시지의 형식, 유형, 내용 등을 정의하여 메시징 전송을 효율적으로 도와주는 프로토콜으로 TCP 또는 WebSocket 같은 안정적인 양방향 스트리밍 네트워크 프로토콜을 기반으로 동작한다.

Pub/Sub (Publish-subscribe pattern)

 

Pub/Sub를 간단히 정리하면 pub(publisher)가 topic에 메세지를 보내면 해당 topic을 구독해놓은 sub(subscriber) 모두에게 메세지가 전송되면서 데이터 교환이 이루어지는 방법입니다.

pub/sub 패턴을 채팅방에 적용해서 예시를 들면 다음과 같다.

1. 채팅방에 5명의 사용자가 접속해있고 이 채팅방의 이름을 room 이라고 하자.
2. 여기서 room이 Topic이 되고 5명이 room이라는 Topic을 구독하고 있는 subscriber가 된다.
3. room을 구독하는 사용자가 채팅방에 메시지를 발행(publish)하면 같은 Topic을 구독하는 모든 subscriber(사용자 5명)에게 메시지가 전달된다.
4. 다른 Topic을 구독하는 subscriber에게는 메시지가 전달되지 않게 된다.

이때 이 Topic에 해당하는 subscriber에게 메시지를 전달해주는 역할을 하는 것이 메시지 브로커인데 메시지 브로커는 해당 Topic을 구독하는 세션정보를 통해서 메시지를 전달한다.

메시지 브로커

메시지 브로커중에서 가장 많이 쓰이는 RabbitMQ, Redis, kafka 3개가 존재한다.

RabbitMQ, Redis, Kafka 같은 기술을 메시지 플랫폼이라고 한다.
메시지 플랫폼은 메시지 브로커와 이벤트 브로커 2가지 종류로 나뉘어진다.

메시지 브로커의 특징이로는 메시지를 받아 적절히 처리하면 짧은 시간내에 메시지가 삭제된다는 특징이 있다. (RabbitMQ, Redis)
이벤트 보로커는 기본적으로 메시지 브로커와 마찬가지로 메시지 브로커와 같은 역할을 하지만 메시지 브로커와 다른점은 publisher가 생성한 이벤트를 저장하고 이후에 consumer가 특정 시점부터 다시 이벤트를 consume할 수 있는 장점이 있다. 즉 이벤트를 DB에 저장하듯이 저장이 가능하다. (Kafka)

RabbitMQ vs Redis vs Kafka 어떤게 좋을까

단기 메시지: Redis

Redis의 인메모리 데이터베이스는 지속성이 필요하지 않은 단기메시지를 사용할 때 적합하다
매우 빠른 인메모리 기능을 제공하기 때문에 단기 메시지를 처리할 때 최고의 성능을 보여준다

대용량 데이터: Kafka

Kafka는 대용량 데이터를 장기간 저장하기 위해 구축된 처리량이 많은 분산 스트리밍 플랫폼이다

복잡한 라우팅: RabbitMQ

RabbitMQ는 구성이 쉽고 복잡한 라우팅을 지원하는 많은 기능을 갖췄다.
메시지 큐에 도착하기 전에 exchange를 통해 라우트 된다.