RabbitMQ vs Apache Kafka 비교

원문) https://www.cloudamqp.com/blog/when-to-use-rabbitmq-or-apache-kafka.html

 

Kafka vs Rabbitmq

Table of Contents

• The big question. When to use Kafka and RabbitMQ?
  • Message handling (message replay)
  • Protocol
  • Routing
• Message Priority
  • Acknowledgment (Commit or Confirm)
  • How to work with the queues?

 

만약 Apache Kafka 가 RabbitMQ 중 어느게 나은지, 어느게 믿을 수 있는 건지 의문이 든다면, 잠깐 시간을 내서 읽어주길 바란다. 이 문서는 넓은 관점에서 두가지를 비교하려 한다. 기능적으로 두 시스템 중 어느 시스템을 사용하는 것이 좋은 결정인지 도움을 주기위해 기능에 초점을 맞춰 이야기 할 것이다.

인터넷에서 가끔 어떤 기사들은 RabbitMQ가 더 뛰어나다고 하며, 어떤 기사는 반대로 쓰여져 있다. 하지만 나는 RabbitMQ와 Kafka 를 선택하는 것은 당신의 프로젝틔 요구사항이 어떤지에 따라 다르게 판단해야 한다는 것이 중요하다고 생각한다.

The terminology used in this article includes:

메세지 큐는 RabbitMQ의 큐이다. 카프카에서 queue는 log로 언급된다.
하기 문서에서는 혼선을 없애기 위해 log를 queue로 통일하겠다.

또한 카프카의 message는 record 로 언급되지만, 역시 message로 통일한다.

카프카의 topic 는 메세지 큐의 분류로 생각할 수 있다. 카프카의 topic은 partition들로 분리되어지고, partition은 불변한 sequence안에 record들을 갖고 있는 것이다.

(아래에 있는 그림을 참조하면 이해가 쉽다.)

두 시스템은 queue(topic)을 통해 메세지로 producer와 consumer가 상호작용할 수 있게 한다. 메세지는 어떤 정보의 종류든 간에 포함할 수 있다. 예를 들어, 이것은 웹사이트에서 일어나는 이벤트 정보이거나 App 간 이벤트 트리거 역할을 하는 간단한 텍스트 메세지일 수 있다.

다른 컴포넌트간 연결하기 위한 것이거나, 마이크로 서비스를 설계하거나, 실시간 데이터 스트리밍이거나, remote worker에게 작업을 전달하려 할 때 사용하는 이상적인 시스템이다.

Confluent 에 따르면, Fortune지 선정 500대 기업 중 1/3이 Apache Kafka를 활용한다. 다양하고 거대한 기업들, Zalando, WeWork, Wunderlist 및 Bloomberg 들도 역시 RabbitMQ 에 의존한다.
(아는 기업이 하나도 없다!!;;)

 

 

The big question. When to use Kafka and RabbitMQ?

"Is there any reason to use RabbitMQ over Kafka?" 라는 질문에 대한 답변: Stackoverflow

위 답변을 분해해서 설명하려한다. 우선 원문에서
아래와 같이 언급하였다.

RabbitMQ는 AMQP, MQTT, STOMP 등과 같이 몇몇 프로토콜을 지원하는 solid, mature, general-purpose(견고하고 성숙하며 범용성을 가진) 메세지 브로커이다. 일반적인 사용 사례로는 background job들을 제어하거나 microservices 사이에서 메세지 브로커로써 동작한다.
Kafka는 high-ingress(높은 유입(?)) 데이터 스트림 및 replay에 최적화 된 message bus이다. Kafka는 어플리케이션이 디스크에서 스트리밍 데이터를 처리 및 재처리를 할 수 있는 지속가능한 message broker로 간주된다.

 

mature(성숙함) 는 무엇인가? RabbitMQ(2007년 이후, 카프카는 2011년)는 오랜 기간동안 출시하여 서비스하고 있다. 두 서비스 모두 성숙하다고 할 수 있다. 즉 둘 다 안정적이고 확장가능한 메세지 시스템이다.

 

Message handling (message replay)

대부분의 메세지 시스템과 달리 카프카는 영속성을 가진다는 것이 주요 차이점이다. 시간 혹은 사이즈 초과 기간이 아니라면, 데이터 전송은 지정된 보존 기간이 종료될 때까지 저장된다.

메세지는 큐에 보존 기간/사이즈가 초과 될 때까지 머무른다. 즉, 메세지는 소비되기 전까지 삭제되지 않는다는 의미이다. 위 방법 대신에 여러번 반복되거나 소비되도록 할 수 있다. 이 기능은 적용가능한 설정이다.

RabbitMQ에서는 수신하는 App이 연결되고 메시지 전송을 종료할 때까지 메시지를 저장한다. 클라이언트는 메시지를 받거나 또는 클라이언트가 메시지를 완전히 처리할 때 메시지를 ack할 수 있습니다.

만약 당신이 카프카에서 반복을 사용하려 한다면, 당신이 올바른 방법 및 올바른 이유로 사용하는것을 보증한다. 이벤트를 여러번 반복하는 것은 대부분의 사용 사례에서 이상적이지않다. 예를 들어 당신이 고객주문을 여러번 저장하는 경우가 될 수 있다. 리플레이가 유용한 곳은 consumer에게 최신 버전을 배포해야 하는 버그가 있는 경우거나, 부분 또는 메시지 전체를 반복해야할 필요가 있을 때 이다.

Protocol

우리는 위에서 RabbitMQ는 AMQP, MQTT, STOMP 등과 같은 표준화 프로토콜을 지원한다고 하였다. 표준화 메시지 프로토콜의 사용은 당신이 RabbitMQ broker를 어떤 AMQP 기반 브로커로 교체하는 것을 허락한다.

카프카는 TCP/IP 에서 application과 cluster 사이에서 통신하는 커스텀 프로토콜이다. 카프카는 간단하게 제거하거나 교체될 수 없다. 이것은 이 프로토콜로 구현된 유일한 소프트웨어이기 때문이다.

다양한 프로토콜을 지원한다는 RabbitMQ의 기능은 수많은 시나리오들이 가능하다는 것을 의미한다.

AMQP 1.0은 플러그인을 통해 사용가능하다.

Routing

다음은 라우팅에 관한 글이다. "카프카는 간단한 라우팅 접근을 제공한다. 반면에 RabbitMQ는 당신이 메시지들을 consumer에게 복잡한 방식으로 라우팅이 필요하다면 더 나은 선택지를 제공한다."

RabbitMQ의 가장 큰 장점은 유연하게 메시지 라우팅이 가능하다는 점이다.
직접 혹은 regex(regular expression)방식의 라우팅은 메시지들이 추가적인 코드없이 특정 큐로 접근을 허락한다. RabbitMQ는 4가지 다른 라우팅 방법(direct, topic, fanout, header)이 있다.

• direct 교환 방법은 라우팅 키로 정확히 일치하는 모든 큐들로부터 메시지를 라우팅한다.
• fanout 교환 방법은 해당 교환에 엮여있는 모든 큐들에게 메시지를 전체 전송할 수 있다.
• topic 교환 방법은 direct방법과 유사하게 라우팅한다. 그러나 구체적인 매칭 검색에서 wildcard(*) 매칭을 허락한다.
• header 교환 방법은 포함된 헤더 인수를 기반으로 메시지를 라우팅한다.
  아래의 블로그에서 교환 방식들의 자세한 정보를 얻을 수 있다.
  https://www.cloudamqp.com/blog/part4-rabbitmq-for-beginners-exchanges-routing-keys-bindings.html

반면 카프카는 라우팅 방법을 지원하지 않는다. 카프카는 변경할 수 없는 순서로 메시지를 포함하는 파티션으로 나뉜다. RabbitMQ에서 라우팅을 위한 주제 선택을 하는 것 대신에 지속가능한 topic과 consumer 그룹을 만드는 것을 할 수 있다.

카프카 스트림의 도움으로 dynamic routing 생성할 수 있다. 카프카 스트림은 이벤트를 중심으로 하는 다이나믹 라우팅이다. 그러나 이는 기본 기능은 아니다.

 

Message Priority

RabbitMQ는 우선순위 큐(Priority Queue)를 지원한다. 각 메시지의 우선순위는 등록되는 시점에 정해진다. 메시지의 우선 순위에 따라 적절한 우선 순위 대기열에 배치됩니다. 그래서 우선순위 큐는 언제 사용될까? 다음의 간단한 예시를 참고하자. 우리팀은 ElephantSQL DB를 사용하고 매일 DB백업을 실행한다. 백업 이벤트가 수천개가 RabbitMQ에 의해 순서없이 추가되어진다. customer는 역시 백업을 실행하길 요구한다. 이런 일이 발생했을 때, 신규 백업 이벤트는 큐에 높은 우선순위로 추가되어진다.

카프카에서는 메시지가 우선순위와 함께 전달될 수 없거나, 우선 순위를 전달하지 않는다. 카프카의 모든 메시지는 consumer측이 얼마나 바쁜지에 상관없이 수신받는 순서대로 저장/전달되어진다.

 

이하 더 자세한 내용은 원문 참고부탁드립니다.