RabbitMq와 Kakfa 모두 메세지 큐를 이용해 시스템의 부하를 줄이고 성능을 높이기 위한 용도로 사용

pub/sub방식 워크플로

메세지 큐를 사용한다, rabbitMQ는 exchange영역에서 pub/sub 방식을 사용, kafka는 pub/sub방식을 사용한다는 점에서 같기도 하다.

RabbitMQ vs Kafka 차이점

RabbitMQ

RabbitMQ is the most widely deployed open source message broker.

• 큐 구현
• 전통적인 메시지 브로커
• 이벤트 메시지가 성공적으로 전달되었다고 판단될 경우 이 메시지가 큐에서 삭제
• 기존 메시징 시스템에서는 처리되지 않고 남아있는 메시지의 수가 많을수록 시스템의 성능이 크게 감소
• procuer는 message exchange에서 큐에 전송되는 메세지 시간을 정할 수 있다.
• 메시지 전달 실패시 : 소비자가 특정 메세지를 처리하고 재시도할 수없다면, 다른 소비자들이 메세지를 처리할 수 있음
  특정 소비자가 특정 메시지를 재시도하는 동안 전체 메시지 처리가 중단되지 않는다. 결과적으로 메시지 소비자는 전체 시스템에 영향을 주지 않고 원하는 만큼 메시지를 동기적으로 재시도한다.

메시지브로커란

(메세지 브로커라는 큰 틀 안에 메세지큐가 있는것이다.)

Message Broker(메시지 브로커)는 Publisher(송신자)로부터 전달받은 메시지를 Subscriber(수신자)로 전달해주는 중간 역할이며 응용 소프트웨어 간에 메시지를 교환할 수 있게 한다.
이 때 메시지가 적재되는 공간을 Message Queue(메세지 큐)라고 하며 메시지의 그룹을 Topic(토픽)이라고 한다.

메시지 브로커는 메시지 큐에서 더 확장된 기능을 가지고 있다고 봅니다. 더 광범위한 전송, 메시지 내용을 통한 라우팅 및 추가/고급 기능 등을 지원하고, 구현체 별로 어떤 방식을 통해 메시지를 전달하고, 내부 구조를 어떻게 구현했는가에 따라 동작하는 방식, 목적, 성능이 달라집니다.

전통적인 메시지 브로커 방식이 뭔데?

Event Producer가 메세지를 생성하면,
메세지 브로커인 RabbitMQ내에서 이 메세지를 어떤 큐에 발송할지 결정하는 exchange를 하게 되고,
이렇게 큐에 들어간 메세지는 Event Consumer가 가져가게 됩니다.

따라서 컨슈머가 메시지를 가져가면 큐에는 더 이상 남지 않고 사라지게 됩니다.

이 때 메시지 "큐"의 특성에 따라 "선입선출"이 적용되어 메시지는 순서대로 컨슈머에게 제공되고, 컨슈머는 미리 정해둔 한계점까지 지속적으로 메시지를 큐에서 읽어들입니다.
(주의사항 : 메세지 소비자가 하나라면, 메시지 순서를 보장한다. 그러나 메시지를 읽는 여러 소비자가 있으면 메시지 처리 순서에 대해 보장할 수 없다.)

kafka

• 큐 구현 대신 토픽에 데이터 집합체 저장
• 최신 기술로 사용되고 있는 이벤트 스트리밍 플랫폼
• Kafka는 소비자가 메세지를 소비했는지 여부와 상관없이, 미리 정해진 만료시간까지 파티션에 메세지를 보관
• Kafka는 메시지를 파일 시스템에 저장하기 때문에 메시지를 많이 쌓아두어도 성능이 크게 감소하지 않음
• 파티션은 append-only 이기 때문에, 메세지 시간을 조작할 수 없으며 어플리케이션 수준에서 구현해야 한다.
• fault 처리 메커니즘을 제공하지 않는다. 어플리케이션 수준에서 메세지 재시도 메커니즘을 구현해야 한다.
  만약에 소비자가 특정 메세지를 다시 시도한다면, 같은 파티션에 있는 다른 메세지들은 처리될 수 없다.
  왜냐하면 소비자가 메세지 순서를 바꿀 수 없기 때문이다.(파티션은 append-only라는 특징을 기억)

가장 큰 차이점: 전달된 메시지에 대한 휘발성

RabbitMQ는 queue에 저장되어 있던 메시지에 대해 Event Consumer가져가게 되면 queue에서 해당 메시지를 삭제한다.
하지만, kafka는 생성자로부터 메시지가 들어오면 해당 메시지를 topic으로 분류하고 이를 event streamer에 저장한다. 그 후, 수신인이 특정 topic에 대한 메시지를 가져가더라도 event streamer는 해당 topic을 계속 유지하기 때문에 특정 상황이 발생하더라도 재생이 가능하다.

Pub-sub에서, 모든 구독자(subscriber)는 발행자(publisher)가 exchange에 전송하는 메세지 복사본을 1개 이상 가지기 때문이다.

용도의 차이

kafka는 클러스터를 통해 병렬처리가 주요 차별점인 만큼 방대한 양의 데이터를 처리할 때, 장점이 부각된다.
RabbitMQ는 데이터 처리보단 Manage UI를 제공하는 만큼 관리적인 측면이나, 다양한 기능 구현을 위한 서비스를 구축할 때, 장점이 부각된다.

사용이유

Message queue는 MSA에서 많이 사용됩니다.
클라우드 기반 또는 서버리스 애플리케이션을 개발할 때 부하에 따라 앱을 scale 할 수 있습니다.

kafka

엄격한 메시지 순서관리가 가능하고,
Kafka의 메시지 보존은 메시지 로거 또는 거대하고 빠른 데이터 스트리밍 서버에 적합하기 때문에 사용

rabbitMQ

메시지 전송 타이밍 제어(메시지 만료 또는 메시지 지연 제어)가 가능하고
소비자의 확인 메시지가 보장되기때문에
사용한다.