RabbitMq와 Kakfa 모두 메세지 큐를 이용해 시스템의 부하를 줄이고 성능을 높이기 위한 용도로 사용됩니다. 각 기술의 특징과 차이점을 알아보도록 합니다.
각 차이점을 알기 전에 비동기 메세징 방식을 이해하면 좋습니다.
Message Queue와 Pub-Sub의 개념에 간단히 정리했습니다.
Message Queues vs Pub/Sub
Asynchronous Messaging Pattern 비동기 메세징은 확장성과 안정성, 성능 향상을 목적으로 발행자(producer)의 메세지 생성이 구독자(consumer)의 작업과 분리되는 방식입니다. 메세징 시스템을 다룰 때, 일반
escapefromcoding.tistory.com
RabbitMQ와 Message Broker는 무엇인가?
RabbitMQ
RabbitMQ는 Message Broker의 구현체입니다. 기본적으로 전통적인 Message Queue 방식을 지원합니다.
또한, message exchange를 사용하여 pub/sub 방식도 구현합니다.
발행자(Publisher)가 message exchange에 메시지를 보내면, 구독자(Subscriber)가 메세지를 구독합니다.
여러개의 Producer와 여러개의 Consumer를 사용할 수 있습니다. 여러개의 Producer가 Message Exchange에 메세지를 보내며, 정해진 규칙에 따라서 큐에 routing이 되고, Consumer들이 메세지를 처리합니다.
Kafka
큐와 exchange를 기반으로 Message Broker의 구현체인 RabbitMQ와 달리 Kafka는 분산 스트리밍 플랫폼입니다. Kafka는 또한 실시간 스트림 처리를 위한 Sream API 및 다양한 데이터의 손쉬운 통합을 위한 Connector API를 제공합니다.
Topic
Kafka는 큐를 구현하지 않습니다, 대신에 토픽(topic)라고 불리는 카테고리에 데이터 집합을 저장합니다. 각각의 토픽에, Kafka는 분할된 메세지 로그를 가지고 있습니다. 하나의 토픽에 하나의 파티션 혹은 여러개의 파티션을 가질 수 있습니다. 각 파티션은 메세지가 지속적으로 추가되며 데이터 순서가 정해져있고, 내용이 바뀌지 않습니다.
토픽은 마치 파일 시스템의 폴더와 유사하고 파티션은 메세지를 저장하는 물리적 파일입니다. 발행자(Producer)는 어떤 토픽에 저장할지 선택하고, 소비자(Consumer)는 어떤 토픽을 구독할지 정합니다. Pub/Sub은 토픽을 기준으로 메세지를 교환합니다.
만약에 하나의 토픽이 여러개의 파티션을 가지고 있다면, round-robin방식을 사용해서 각각 파티션에 메세지를 일관성있게 분배합니다.
Partition
파티션들은 메세지를 저장하는 물리적 파일로 메세지 추가만 가능한 append-only 속성을 가지고 있습니다. 파티션에는 각 메세지 저장 위치가 있는 오프셋이 있어서, 메세지가 어디에 저장되어 있는지 알 수 있고, 오프셋 기준으로 메세지를 순서대로 읽어 처리합니다. 발행자(Producer)가 넣은 메세지는 파티션의 맨 뒤에 추가됩니다.
또한 해당 파티션들이 소비자(Consumer)로 메세지를 전달하는 것이 아니라, 소비자(Consumer)가 polling을 통해 데이터를 가져가서 처리합니다.
토픽을 소비하기 위해 함께 작동하는 소비자의 그룹을 컨슈머그룹(Consumer Group)이라고 부릅니다. 1개의 파티션은 컨슈머그룹의 1개의 소비자(Consumer)만 연결이 가능합니다. 즉, 컨슈머그룹에 속한 컨슈머들은 하나의 파티션을 공유 할 수 없습니다. Kafka API는 컨슈머 그룹에 있는 소비자들과 소비자의 현재 파티션 오프셋의 저장을 처리합니다.
3개의 파티션을 가지는 1개의 토픽이 있고, 2개의 커슈머 그룹이 있다고 가정합니다. 예를 들어, 파티션 맨 위에 있는 것을 파티션 0번이라 했을 때, offset 12번을 처리한다고 하면, 컨슈머 그룹 A에 있는 Consumer1도 읽을 수 있고, 컨슈머 그룹 B에 있는 Consumer1도 해당 메세지를 읽을 수 있습니다.
Kafka는 소비자가 메세지를 소비했는지 여부와 상관없이, 미리 정해진 만료시간까지 파티션에 메세지를 보관합니다. 덕분에, 소비자가 과거 메세지를 쉽게 다시 읽을 수 있습니다. 그러므로, 개발자들은 이벤트 소싱이나, 감사 로그와 같은 메커니즘을 구현하기에 적절합니다.
RabbitMQ와 Message Broker 의차이점은?
1. 동작 아키텍처
Kafka : Producer -> broker -> partition -> Consumer
RabbitMQ : Producer -> Exchange -> binding rules -> queue -> Consumer
2. 성능
Kafka : 순차적인 disk I/O 방식을 통해 성능 향상한다. 적은 비용으로 많은 데이터 유지, 1초에 수백만개의 메세지 처리 가능하다.
RabbitMQ : 큐가 비어있을 때만 성능이 빠름, 1초에 수백만개의 메세지 처리 가능하지만 자원이 더 필요하다.
3. 메세지 순서 보장
Kafka : 같은 토픽 파티션으로 보내진 메세지는 순서대로 처리됨을 보장한다. 하지만 같은 토픽 내에 여러개의 파티션 사이에서 처리 순서는 보장하지 않는다.(라운드 로빈으로 메세지를 분배하기 때문) 만약 여러개의 파티션 사이에서 순서를 보장하고 싶다면, 키를 이용해서 메세지를 그룹화하여 동일한 키를 가진 메세지는 동일한 파티션으로 이동하도록 해야한다.
RabbitMQ : 메세지 소비자가 하나라면, 메시지 순서를 보장한다. 그러나 메시지를 읽는 여러 소비자가 있으면 메시지 처리 순서에 대해 보장할 수 없다.
관련되 내용은 아래 글 참고
https://stackoverflow.com/questions/29820384/apache-kafka-order-of-messages-with-multiple-partitions
4. 라우팅 기능
Kafka: 소비자가 polling 이전에 토픽에서 메세지를 필터링을 할 수 없다. 소비자는 예외없이 파티션의 모든 메세지를 수신해야만 한다. 물론, 토픽에서 메세지를 읽고, 필터링하고 또다른 토픽으로 보낼 수 있지만 복잡한 과정이 필요하다.
RabbitMQ: topic exchange를 통해 헤더에 routing_key라는 값으로 라우팅 가능하다. 또한, header exchange를 사용해 임의의 메시지 헤더를 기반으로 라우팅할 수 있다. 최종적으로 소비자는 받고싶은 메세지의 종류만 수신 가능하다.
5. 지연 메세지
Kafka: 토픽에 메세지가 도착하면 바로 파티션에 전달해서 소비자가 바로 소비할 수 있도록 한다. 파티션은 append-only 이기 때문에, 메세지 시간을 조작할 수 없으며 어플리케이션 수준에서 구현해야 한다.
RabbitMQ: 생산자는 message exchange에서 큐에 전송되는 메세지 시간을 정할 수 있다.
6. 메세지 보유 및 삭제
Kafka: 토픽에 설정된 타임아웃 시간까지 모든 메세지가 저장된다. 카프카의 성능이 저장소 크기와 상관이 없으므로 이론상으로 성능 영향없이 무한대로 메세지를 저장할 수 있다.
RabbitMQ: 소비자가 메시지를 소비하자마자 ACK 메세지를 보내고 메세지 삭제된다. NACK 가 수신되면, 메세지는 다시 큐에 보내진다. message broker 설계 방식이므로 이 방식이 변경될 수 없다.
7. fault 처리
Kafka : fault 처리 메커니즘을 제공하지 않는다. 어플리케이션 수준에서 메세지 재시도 메커니즘을 구현해야 한다.
만약에 소비자가 특정 메세지를 다시 시도한다면, 같은 파티션에 있는 다른 메세지들은 처리될 수 없다.
왜냐하면 소비자가 메세지 순서를 바꿀 수 없기 때문이다.(파티션은 append-only라는 특징을 기억)
RabbitMQ : 소비자가 특정 메세지를 처리하고 재시도할 수 없다면, 다른 소비자들이 메세지를 처리할 수 있다.
특정 소비자가 특정 메시지를 재시도하는 동안 전체 메시지 처리가 중단되지 않는다. 결과적으로 소비자는 전체 시스템에 영향을 주지 않고 원하는 만큼 메시지를 동기적으로 재시도한다.
최종적으로, 각 기술의 특징은 다음과 같습니다.
Kafka
1. 엄격한 메세지 순서관리
2. 과거 메시지 재생 가능성을 포함하여 장기간 메시지 보존
3. 기존 솔루션으로는 충분하지 않는 대규모 구조
Kafka의 메시지 보존은 메시지 로거 또는 거대하고 빠른 데이터 스트리밍 서버에 적합합니다. 실패 후 메시지를 다시 시도해야 하는 책임은 소비자에게 있으므로 Kafka는 메시지가 성공적으로 전달되었는지 여부를 신경 쓰지 않습니다. 이것은 추가 구현을 덜어주고 데이터 재생 및 쿼리에 중점을 둡니다.
RabbitMQ
1. 유연한 라우팅 규칙 적용 가능
2. 메시지 전송 타이밍 제어(메시지 만료 또는 메시지 지연 제어)
3. 소비자가 메시지 처리에 실패할 가능성이 더 높은 경우 고급 오류 처리 기능
4. 단순하게 소비자 기능 구현 가능
RabbitMQ는 메시지 저장 기간이 짧으며 소비자의 확인 메시지가 보장되므로 강력한 메시지 브로커인 응용 프로그램 중재자에 더 적합합니다.
* 참고
Kafka vs RabbitMQ: What Are the Biggest Differences and Which Should You Learn?
RabbitMQ vs. Kafka
RabbitMQ vs Kafka: Head-To-Head
'문제 해결, 기술 비교 > 개인프로젝트(북클럽)' 카테고리의 다른 글
| Redis Persistence AOF vs RDB (0) | 2022.06.28 |
|---|---|
| Message Queues vs Pub/Sub (0) | 2022.06.26 |
| In-memory Redis vs Memcached 비교하기 (0) | 2022.06.21 |
| cache란? Redis를 cache로 조회 성능 개선하기 (0) | 2022.06.20 |
| Redis를 로그인 Session Storage로 이용하기 (0) | 2022.06.17 |
