MessageQueue 의 장점과 RabbitMQ vs Kafka

 고전적인 메시지 큐는 단순히 메시지를 발행하고 소비하는 형태였지만 현대 메시지 큐는 EDA(Event Driven Architecture) 를 지원하기 위해 메시지를 영구 저장하여 반복 소비하는 형태로 변화하고 있다. 이와 같이 메시지를 영구 저장하는 메시지 서버를 event broker 라 부른다. 가장 대중적으로 사용하는 플랫폼으로는 kafka 이며 고전적인 Message Queue 들도 메시지를 저장, 재소비하는 방향으로 개발되고 있다. (RabbitMQ 는 메시지를 저장해 재시작할 때 메시지 유실을 방지하지만 아직은 영구 저장이 되지는 않는 것으로 알고 있다.)

 

Message Queue 의 장점

 메시지 큐의 공통적인 장점은 fan-out(팬-아웃), asynchronous processing(비동기 처리), decoupling(결합도 완화) 인 것 같다.

 

 fan-out 는 논리 회로에서 하나의 논리 게이트의 출력이 얼마나 많은 논리 게이트의 입력으로 사용되는지 서술할 때 쓰인다고 한다. 즉, 생산자가 메시지를 대기열에 발행하면 여러 소비자는 각각의 다른 목적으로 메시지를 사용할 수 있다는 의미이다. 예를 들어, 결제 서비스는 결제, 알림, 분석의 다운스트림 서비스로 데이터를 전송하여 사용하는 것을 의미한다. 

fan-out example(source : Why Do We Need a Message Queue?)

 

 

asynchronous processing 는 로직을 대기할 필요가 없다는 의미이다. 만약, Tomcat 기반의 WAS 에서 외부 API call 을 사용한다면 응답 올 때까지 해당 스레드가 블로킹 되어야 하지만 메시지 큐를 활용한다면 대기열에 메시지를 발행하고 대기열을 구독하여 로직을 처리한다면 스레드를 블로킹하지 않아 성능 향상을 기대할 수 있다. 예로 결제 지시가 대기열에 배치되고 결제가 완료되면 고객에게 알림을 전송하는 방식을 들 수 있다.

 

decoupling 의 의미는 각 서버를 독립적으로 수정, 배포 가능한 구조가 될 수 있다는 점이다. 서비스는 서로 긴밀하게 의존하지 않고 잘 정의된 메시지 인터페이스를 사용해 서로 상호 작용하며 아키텍처 설계에 유연성을 제공한다. horizontal scalability, availability 은 decoupling 으로 인한 부수 효과이다. 수요에 따라 독립적으로 서비스를 확장 가능해 다수 요청에 대한 성능 향상을 기대하고 서버의 안정성에 기여할 수 있다.

특정 서비스를 API server 로 분리되는 것 또한 decoupling(결합도 완화) 으로 볼 수 있을 것인가?? YES (당연한 이야기지만 내부 코드 또한 독립적으로 배포 가능한 구조여야 할 것이다.)

 

RabbitMQ vs Kafka

RabbitMQ vs Kafka (출처 : bytebytego)

 

 

 RabbiqMQ 와 Kafka 는 성능(performance) 와 확장성(scalability) 에서 차이가 있다. RabbitMQ 는 초당 수만 개의 메시지(tens of thousands/sec)를 처리하지만 scale-up 을 하더라도 처리량에 개선에 크게 영향을 미치지 않는다고 한다. 반면 kafka 는 높은 확장성으로 초당 수백만 개의 메시지(million/sec)를 처리할 수 있다.

 

Kafka 는 ecosystem 지원이 잘 되어 있다. Kafka 는 대용량 로그 처리를 위해 구축되어 있기 때문에 최신 빅데이터와 스트리밍 애플리케이션과 통합할 수 있다. RabbitMQ 는 Kafka 만큼의 ecosystem 지원을 잘하지 않는다.

 

RabbitMQ 와 Kafka 의 가장 큰 차이점 중 하나는 메시지를 소비하는 형태이다. RabbitMQ 는 메시지를 발행자가 보내는 즉시 소비자에게 전달하는 푸시 모델(push model) 이다. 소비자에게 메시지를 전달하면 메시지를 삭제한다. 푸시 모델은 즉시 소비자에게 바로 보내기 때문에 지연이 낮은 장점이 있지만, 발행자의 메시지 전송량이 좌우되므로 소비자가 그에 맞는 처리량에 대한 자원 스펙을 맞춰야 한다.

Kafka 는 풀 모델(pull model) 이다. RabbitMQ 와 반대로 메시지 소비 속도를 소비자가 결정한다. 풀 모델은 소비자가 메시지가 만료될 때까지 메시지를 보관하고 소비자가 자신의 속도에 맞춰 메시지를 가져올 수 있어 일괄 처리에 적합하다. 반면, broker 에 메시지가 없어도 소비자에게 계속 데이터를 가져가려고 시도해 소비자의 자원을 낭비할 수 있다.

 

push model (출처 : Hookdeck)

 

pull model (출처 : Hookdeck)

 

 

사용 사례를 비교해보자. Kafka 는 로그 처리 및 분석, 추천을 위한 데이터 스트리밍, 시스템 모니터링 + 알람, 데이터 변경 캡처(CDC), 애플리케이션 마이그레이션 과 같은 대용량 메시지 처리하는데 활용되고 있다. 자세한 내용은 해당 링크에서 확인해볼 수 있다. RabbiMQ 는 메시지 지연과 기능을 제공해 발행자가 메시지 처리 지연 시간을 헤더(x-delay) 를 통해 결정할 수 있다.

 

출처 : [bytebytego] How to Choose a Message Queue? Kafka vs. RabbitMQ - Log Processing and Analysis

출처 : [bytebytego] How to Choose a Message Queue? Kafka vs. RabbitMQ - Delayed Messages

 

 

Reference

• [가상 면접 사례로 배우는 대규모 시스템 설계 기초2] 4장. 분산 메시지 큐
• [bytebytego] Why Do We Need a Message Queue?
• [wikipedia] fan-out
• [bytebytego] How to Choose a Message Queue? Kafka vs. RabbitMQ
• [Hookdeck] Message Queues : Deep Dive