[36] WebSocket - In Memory 대신 외부 브로커 사용하는 이유

Message Broker란?

• Publisher로부터 전달받은 메세지를 Subscriber로 전달해줄 때 중간에서 메세지를 주고 받게 해주는 중간 역할

https://docs.spring.io/spring-framework/docs/4.3.x/spring-framework-reference/html/websocket.html

26. WebSocket Support

 

In Memory Broker란?

• Spring websocket에서 STOMP 프로토콜을 사용해서 웹소켓 기능을 구현할 때 STOMP는 Message Broker가 필요하다.
• 이 때 아무 설정 없이 Spring 환경에서 STOMP 프로토콜을 사용한다면 메세지 브로커로 In Memory Broker를 사용하게 된다.

 

그렇다면 하나의 서비스를 만들 때 In Memory Broker를 메세지 브로커로 사용해도 상관 없을까?

상관있다... 아래를 보면, In Memory 브로커의 단점들이 존재한다.

1. 세션을 수용할 수 있는 크기가 제한되어 있다.
2. 장애 발생 시 메세지의 유실될 가능성이 높다.
3. 따로 모니터링하는 것이 불편하다.

 

그렇다면 In Memory 브로커 대신 무슨 브로커를 사용할 수 있을까?

• RabbitMQ, ActiveMQ 등에서는 STOMP 프로토콜의 Message Broker 기능을 제공해준다. 
• 따라서 이들의 힘을 빌려 In Memory 브로커 대신 잘 만들어진 STOMP 전용 외부 브로커를 사용하는 것이 더 좋다.

 

STOMP 전용 외부 브로커를 사용하는 장점이 무엇이 있을까?

1. 확장성 : 세션을 수용할 수 있는 크기가 크다.
2. 결함 허용성 : 영구적이며 문제가 발생했을 시 재시도가 가능하여 복구가 가능하다.
3. 모니터링 : 간편하게 모니터링을 할 수 있다.

 

---

[ 참고자료 ]

 

https://withseungryu.tistory.com/137