RabbitMQ란?
RabbitMQ는 전통적인 메시지 지향 미들웨어로, 메시지 생성자와 소비자 사이에서 메시지를 중계해주는 message broker이다.
RabbitMQ를 쓰는 이유
먼저 Message Driven이란, 서비스 사이 비동기적으로 메시지를 전달하는 통신방법이다. 이를 통해 서비스들은 decoupling된 의존성을 갖게 되며, 부하를 관리하고 탄력적인 흐름 제어가 가능하게 된다.
Message Broker로 유명한 Kafka와 비교했을 때, 어떤 특징이 있는지 알아보자.
Main Concept
RabbitMQ는 Queue, Kafka는 log가 main concept이다.
RabbitMQ - Queue
queue는 FIFO(First In First Out) 구조이다. queue의 메시지는 소비되면 queue에서 즉시 삭제된다.
일반적으로 queue는 일시적으로 메시지를 보관하는데 최적화되어 있다. queue는 생산자와 소비자가 독립적, 비동기적으로 동작할 수 있도록 생산자와 소비자 사이에서 Queueing, Buffer의 역할을 한다.
RabbitMQ는 이런 queue의 특징을 그대로 구현하고 있다. queue에 담긴 모든 메시지들의 상태를 관리하고, 메시지가 queue에서 머무르는 시간이 짧을수록 성능이 좋도록 구현되어 있다.
Kafka - Log
log를 파일에 쓰는 형식이다. log는 메시지를 영구적, 또는 긴 기간동안 보관한다.
그리고 queue와는 다르게 같은 메시지를 반복적으로 읽을 수 있다. queue의 FIFO와는 다르게 추가되는 이벤트나 메시지를 계속 뒤에 덧붙이는 구조로, log는 소비자가 어떤 메시지를 읽었는지 관리하지 않는다.
이처럼 queue와 비교했을 때 log는 동작이 매우 단순하다.
Broker
이런 차이로 모든 메시지를 관리하는 queue 기반인 RabbitMQ를 smart broker, dumb consumer라 한다.
그리고 비교적 단순한 동작을 하는 log 기반인 Kafka는 반대로 dumb broker, smart consumer라고 한다.
RabbitMQ-smart broker
broker가 모든 메시지의 상태를 직접 관리한다.
대부분의 기능을 smart broker가 수행하고, consumer는 broker에 대해 독립적인 구조가 된다. 따라서 consumer application을 구현하거나 다양한 작업을 할 때 개발자가 할 일이 많이 줄어들게 된다.
한 가지 예로 consumer scale out을 들 수 있다. 만약 consumer의 성능이 부족해 consumer의 수를 늘려야 한다면, smart broker의 경우 단순히 consumer instance를 늘리기만 하면 된다.
이 때, smart broker는 여러 consumer가 소비하는 메시지의 상태를 모두 관리해야 한다. 이렇게 되면 broker가 하는 일이 많아지기 때문에 가지는 단점이 있다. Kafka와 비교해 느린 속도이다.
이는 경우에 따라 성능이 중요한 서비스에서는 치명적인 단점이 될 수 있다.
Kafka-dumb broker
dumb broker인 Kafka는 단순히 메시지를 덧붙인다.
broker는 consumer가 어떤 메시지를 어디까지 읽었는지 관리하지 않는다. 따라서 메시지를 어디까지 읽었는지는 consumer에서 직접 관리해야하며, 때문에 개발 시 리소스가 RabbitMQ에 비해 더 많이 들어가며, 고려해야 하는 점들도 더 많아지게 된다.
또한 개발자의 실수에 의해 의도하지 않은 오류가 발생할 수 있는 확률이 smart broker에 비해 클 수 있다.
consumer가 scale out될 때, consumer가 메시지를 중복적으로 읽어도 괜찮다면 특이사항이 없다.
하지만 중복없이 메시지를 읽도록 consumer를 scale out 해야한다면 consumer를 늘리는 것만으로는 부족하다. 늘어나는 consumer의 수만큼 partition의 수를 늘려주어야 한다.
추가적으로, consumer를 다시 scale in 했을 때, 늘렸던 partition을 어떻게 다시 줄일지도 고려해야 한다.
dumb broker는 매우 빠르고, 메시지를 영속적으로 보관할 수 있고, 메시지를 다시 읽을 수 있는 장점이 있다.
coupling
위와 같은 특성들을 바탕으로, RabbitMQ는 Kafka에 비해 비교적 Loose Coupling broker라고 할 수 있다.
성능면에서는 Kafka가 RabbitMQ에 비해 더 빠르다고 할 수 있다.
Quality of Service
At most Once
메시지 전달 과정에서 손실이 발생할 수 있음을 의미한다. producer가 queue에 메시지를 넣거나 consumer가 queue에서 메시지를 꺼낼 때 네트워크 문제나 기타 이슈로 중간에 메시지가 손실되는 문제이다.
예로 broker에서 메시지를 consumer에게 전달하고 바로 queue에서 메시지를 삭제한다. 전송 중 네트워크 및 기타 이슈로 consumer가 메시지를 받는 도중 실패가 발생하면 메시지는 유실되게 된다.
At least Once
At most Once에서 메시지 손실 가능성을 없애기 위해 반대로 중복 가능성이 있는 메시지 보장 수준이다.
broker는 consumer의 메시지 수신 확인 응답이 올 때까지 메시지를 queue에 유지한다.
만약 consumer가 broker에게 메시지 수신 확인 응답을 전달할 때 오류가 발생해 연결이 끊어진다면, queue에 남아있는 메시지는 다른 consumer에게 전달되어 중복이 발생할 수 있다.
Exactly Once
메시지를 손실, 중복없이 전달되는 것을 보장하기 때문에 가장 안전하다.
하지만 일반적으로 producer, consumer, broker 사이 transaction을 사용하기 때문에 성능이 떨어진다.
또한 Kafka가 exactly once 전략을 사용한다고 하더라도 현실적으로 구현하기 쉽지 않다.
tip
messaging service를 제공할 때 At most once를 선택하는 것이 좋을 수 있다.
service 특성 상 중복이 발생하는 것이 더 큰 문제가 될 수 있기 때문이다.
Protocol
RabbitMQ
- AMQP
- MQTT
- STOMP
Kafka
기준이 없고 자체 정의된 TCP 기반 binary protocol 사용하고 있다.
RabbitMQ에 비해 제공되는 protocol이 제한적이지만, 많은 connector를 제공하고 있기 때문에 다른 서비스나 미들웨어와 연결 시 크게 어려움은 없다.
Usability
RabbitMq
보다 가볍다.
설치 및 운영이 쉽고, built in 된 management console도 제공한다.
Kafka
보다 복잡하다. Zookeeper도 설치가 필요하고, 추가적인 관리에 필요한 도구들도 설치해야 한다.
Use cases
RabbitMQ와 Kafka는 상당 부분에서 다른 concept을 갖고 있기 때문에 주로 활용되는 용도가 다르다.
RabbitMQ
전통적인 message broker이기 때문에 동적으로 안전하게 queue를 생성, 삭제하고 다양한 방법으로 message를 라우팅 하는 등 messaging 기능에 특화되어 있다.
Kafka
실시간 Stream processing, Metric, Log Aggregation, Event Sourcing 등 다양한 곳에서 사용할 수 있다.
