spring 환경에서 실시간 메시징 기능을 구현할 때 SimpleBroker는 편리한 시작점이지만, 실제 운영 환경에서는 기능 및 성능상의 한계가 존재한다. 이번에는 SimpleBroker의 한계점에 대해서 알아보고 이를 해결하기 위해서 어떻게 해야되는지 한번 알아보는 시간을 가져보려고 한다.
SimpleBroker의 한계점
Spring에서 제공하는 SimpleBroker는 별도의 설정 없이 사용할 수 있는 인메모리 기반인 간단한 메시지 브로커이다. 개발 단계나 간단한 애플리케이션의 경우에는 유용하지만 명확한 한계를 가지고 있다.
- 제한적인 STOMP 명령어 지원 :
ack,receipt와 같이 메시지 확인 및 수신 보장에 관련된 중요한 명령어를 일부 지원하지 않는다. 이는 메시지 전달의 신뢰성을 보장하기 어렵게 만든다. - 클러스팅 불가 : SimpleBroker는 상태정보를 각 애플리케이션 인스턴스의 메모리에 저장하게 되는데 이렇게 되면 여러 인스턴스로 확장하는 경우, 인스턴스간 메시지 공유나 상태 동기화가 불가능하다.
- 메시지 영속성 문제 : 메시지를 메모리에만 저장하기 때문에 서버가 재시작이 되면 모든 메시지가 유실된다. 중요한 메시지를 안정적으로 보내야하는 서비스의 경우 부적합하다.
그렇다면 이러한 문제점을 해결하기 위해서는 실제 운영환경에서는 어떻게 해야되는지 알아보자.
외부 메시지 브로커
이러한 문제점을 해결하기 위해서 외부 메시지 브로커가 존재하는데 여러 메시지 브로커가 존재한다. RabbitMQ, redis, Kafka와 같은 메시지 브로커가 있는데 어떤 걸 사용해야 될까?
RabbitMQ 외부 메시지 브로커
RabbitMQ는 AMQP(Advanced Message Queuing Protocol)을 핵심으로 구현되었으며, STOMP, MQTT등 다양한 프로토콜을 지원하는 매우 인기 있는 오픈소스 메시지 브로커이다. 메시지를 보내는 생산자와 메시지를 받는 소비자 사이에서 안정적인 메시지 중재자 역할을 수행할 수 있다.
나의 상황에 맞는 메시지 브로커인가?
만약 본인의 프로젝트가 메시지를 안정적으로 보내야 하고 메시지 유실이 없어야 한다면 RabbitMQ 메시지 브로커를 선택하면 된다. 또한 RabbitMQ는 메시지 영속성을 보장하기 때문에 더욱 좋은 선택이 될 수 있다.
Redis 외부 메시지 브로커
Redis는 보통 성능 최적화를 하기 위해 사용하는 메모리 db로 많이 사용되는데 redis에서도 sub/pub와 같은 기능들을 제공한다. 하지만 redis를 가지고 메시징 처리에 대해서 사용성에 맞는지 판단해봐야 한다.
- redis에서 stomp의 프로토콜을 제공하고 메시지 처리함에 있어서 안정적인 중재자 역할이 가능한가?
- 전달 보장이 가능한가?
- 실패한 메시지 처리는 어떻게 관리하지..?
위와 같이 다양한 생각이 들 것이다. 그렇다면 어떠한 상황에 Redis가 좋은 선택이 될까?
실시간 알림, 이벤트 전파(조금의 메시지 유실이 허용이 됨) 또한 애플리케이션이 여러 인스턴스에 이벤트를 알리는 경우 사용하면 좋은 선택이 될 수 있다.
Kafka 외부 메시지 브로커
Kafka는 대규모 데이터 스트림을 실시간으로 처리하고 보장하기 위해 설계된 분산 스트리밍 플랫폼이다. 단순히 메시지를 전달하는 것을 넘어 데이터를 안정적으로 저장하고 필요에 따라 소비자가 가져갈 수 있게 하는 것에 중점을 둔다.
- 카프카는 분산 아키텍처와 높은 확장성을 가지고 대규모 트래픽 처리에 강점을 지니고 있다.
- 높은 처리량 : 디스크에 순차적으로 데이터를 기록하고 읽는 방식과 OS의 페이지 캐시를 적극 활용해서 초당 수십만건의 메시지를 처리할 수 있도록 한다.
- 영속성 및 내구성 : 메모리에 저장할 뿐만 아니라 디스크에 영속적으로 저장한다.
위처럼 많은 장점이 존재하지만 공부해야될 양이 상당히 많고 잘 알아야 그만큼 활용도 잘 할 수 있다. 그럼 제일 중요한 stomp를 사용해서 외부 메시지 브로커로서 사용할 수 있을까?
위의 장점이 존재하지만 실질적으로 stomp를 사용해 메시지 브로커로서 활용하기만 제한이 존재한다. kafka는 자체 TCP 기반 바이너리 프로토콜을 사용하기 때문에 STOMP 프로토콜을 네이티브하게 온전히 사용하기 힘들다.
보통의 경우 카프카는 실시간 데이터 처리등 로그 수집, 사용자 활동 추적, 다른 서버 인스턴스와의 연결에서 많이 사용하기 때문에 외부 메시지 브로커로서는 잘 사용하지 않는다.
그럼 외부 메시지 브로커는 RabbitMQ로 정해져 있는거 아냐...?
맞다.. 지금까지의 내용을 보기엔 redis와 kafka와 같은 것들보다 rabbitmq가 확실한 장점이 드러나기 때문에 rabbitmq를 많이 외부 메시지 브로커로서 사용한다. 하지만 뭐든 정답이란건 없다. 만약 본인의 애플리케이션에서의 우선 사항이 상당한 데이터 처리량이 더 중요하다면 kafka를 사용해야되고 stomp의 연동은 부가적인 요구사항이 될 것이다. redis또한 마찬가지로 단순성이 더 중요하고 메시지의 유실을 허용해도 된다면 redis를 사용해야될 것이다.
마무리
본인이라면 서버의 인스턴스 확장으로 인해 외부 메시지 브로커가 필요하다면 rabbitMQ를 사용해서 외부 메시지 브로커로 사용하면서 공부해보고 사용자들의 세션 관리를 redis를 통해서 관리하는게 좋은 선택이 될 수 있을 것 같다.
왜 세션은 redis로 관리하지? rabbitMQ 하나만 가지고 메시지 처리랑 세션 관리를 하면 되는거 아닌가..? 라고 의문이 든다면 한번 생각해보길 바란다.
