RabbitMQ vs Kafka

RabbitMQ

RabbitMQ는 메세지 기반 미들웨어로 서비스 간 데이터를 교환해주는 역할을 하며, Exchange를 통해 라우팅 방법을 결정하고 Queue에 메세지를 저장했다가 Consumer가 consume하는 구조입니다. ack와 durable 모드를 통해 consumer에게 메세지 전달 보장성과 메세지 유실 방지 할 수 있습니다. 그 외, 재처리 방식, clustering, rpc 모드 등 다양한 기능을 제공합니다. 

클러스터링 경우에는 RabbitMQ가 single node로 작동 시 node가 죽으면 메세지가 모두 유실되고, 서비스가 장애나기 때문에 HA를 고려하여 미러링 방식의 master-slave구조를 갖습니다. slave node는 master의 메세제를 sync하기만 하고, producer 및 consumer는 master 통해서만 메세지를 주고 받습니다. master가 죽으면 slave node 중 가장 sync가 비슷한 것을 내부 알고리즘을 통해 master로 승격시킵니다. 따라서 SPOF는 피하지만 분산처리, scale out측면에서는 효율적이지 못합니다.

추가로 Message Broker로 Redis 대비 장점은 확실한 delivery를 지원해줍니다. duarble & persistent mode 통한 data를 disk에 저장할 수 있습니다. 또한 ack 응답을 통해 delivery를 보장합니다 .반면 redis는 socket기반이라서 consumer가 inactive하면 메세지는 유실됩니다. 또한 RabbitMQ는 메세지 브로커로 다양한 라우팅 방식, rpc, retry 방식 등 지원합니다.

 

Kafka

1) RabbitMQ는 consumer 당 queue를 만들어야 해서 높은 결합성이 있습니다. 또한 다수의 consumer가 하나의 queue를 읽지 못해서 각각 queue를 만들어주어야 합니다. Kafka는 토픽에 offset을 저장하기 때문에 다수의 consumer에 읽기 가능합니다. 

2) RabbitMQ는 기본적으로 메모리에 데이터를 저장합니다.(disk에도 옵션에 따라 저장 가능) 하지만 kafka는 디스크에 저장하기 때문에 추후 replay나 다른 consumer가 읽을 수 있습니다.

3) topic을 partition별로 분산 처리를 통한 높은 처리량, zookeeper와 연동하여  HA구성을 할 수 있습니다.

토픽은 Controller Broker에 의해 Leader Partition과 Follower Partition으로 구성되어 있습니다. Leader만 producer/consumer와 read/write할 수 있고, follower는 단지 복제된 파티션을 저장해서 추후 Leader Broker 장애 시 복구하는 HA 용도로만 사용하게 됩니다. 이 때, offset lag이 심해지면 kafka 디스크에도 부담이 가고, 처리량도 늦어짐으로 파티션 개수를 늘려서 분산처리를 늘리는 방식과 consumer group의 서버를 증가시키는 방안이 있습니다.

 

* 파티션 내에는  append 방식이라 순서 보장이 힘들지만 파티션 간 순서보장은 힘들어서 partition key를 사용해야 합니다. 기본적으로는 round robin 방식이지만 파티션 키를 이용하면 특정 브로커에 집중 될 수도 있는 단점이 있습니다.

 

* Controller Broker : 리더 선정, 토픽 생성, 파티션 생성 등 역할을 합니다.

 

* ISR : 리더/팔로워 파티션이 모두 sync인 상태입니다. ISR 내 모든 follower들을 sync 상태라 데이터 정합성을 보장하기 때문에 leader가 될 수 있습니다.

 

Reference

https://alvincjin.github.io/Kafka-Partition-Leader-and-Controller/

Kafka Partition Leader and Controller

https://deep-jin.tistory.com/entry/apache-kafka

[Kafka] 카프카 주요 개념 정리

https://damdam-kim.tistory.com/17