Kafka를 통해 RabbitMQ를 사용해야하는 이유가 있습니까?

Kafka 대신 RabbitMQ를 평가하라는 요청을 받았지만 Kafka보다 더 나은 일을하는 이유를 찾기가 어렵다는 것을 알았습니다. 처리량, 내구성, 대기 시간 또는 사용 편의성이 실제로 더 나은지 아는 사람이 있습니까?

RabbitMQ는 AMQP, MQTT, STOMP 등과 같은 여러 프로토콜을 지원 하는 견고한 범용 메시지 브로커 입니다. 높은 처리량을 처리 할 수 ​​있습니다. RabbitMQ의 일반적인 사용 사례는 백그라운드 스캔 또는 파일 스캔 , 이미지 스케일링 또는 PDF 변환 과 같은 장기 실행 작업을 처리하는 것 입니다. RabbitMQ는 또한 마이크로 서비스간에 사용되며, 애플리케이션 간 통신 수단으로 사용되어 메시지를 전달하는 병목 현상을 방지합니다.

Kafka는 대용량 데이터 스트림 및 재생에 최적화 된 메시지 버스 입니다. 많은 양의 데이터를 이동하거나 실시간으로 데이터를 처리하거나 일정 기간 동안 데이터를 분석해야하는 경우 Kafka를 사용하십시오. 즉, 데이터를 수집, 저장 및 처리해야하는 곳입니다. 예를 들어 웹샵에서 사용자 활동을 추적하고 구매 제안 품목을 생성하려는 경우가 있습니다. 또 다른 예는 추적, 수집, 로깅 또는 보안을위한 데이터 분석입니다.

Kafka는 애플리케이션이 디스크에서 스트리밍 된 데이터를 처리하고 재 처리 할 수 있는 내구성있는 메시지 브로커 로 볼 수 있습니다 . Kafka는 매우 간단한 라우팅 접근 방식을 가지고 있습니다. RabbitMQ는 복잡한 방식으로 소비자에게 메시지를 라우팅해야하는 경우 더 나은 옵션을 제공합니다. 오프라인 일 수있는 배치 소비자 또는 대기 시간이 짧은 메시지를 원하는 소비자를 지원해야하는 경우 Kafka를 사용하십시오. 

Kafka에서 데이터를 읽는 방법을 이해하려면 먼저 소비자와 소비자 그룹을 이해해야합니다. 파티션을 사용하면 데이터를 여러 노드로 분할하여 주제를 병렬화 할 수 있습니다. 파티션의 각 레코드는 고유 한 오프셋으로 할당 및 식별됩니다. 이 오프셋은 파티션의 레코드를 가리 킵니다. 최신 버전의 Kafka에서 Kafka는 파티션의 각 레코드에 대한 숫자 오프셋을 유지합니다. Kafka의 소비자는 주기적으로 오프셋을 자동 커밋하거나이 커밋 된 위치를 수동으로 제어하도록 선택할 수 있습니다. RabbitMQ는 소비 / 확인 / 확인되지 않은 메시지에 대한 모든 상태를 유지합니다. 메시지가 잠기면 큐에서 간단히 제거되는 RabbitMQ의 경우보다 Kafka가 이해하기가 더 복잡하다는 것을 알았습니다.

RabbitMQ의 대기열은 비어있을 때 가장 빠르며 Kafka는 오버 헤드가 거의없이 많은 양의 데이터를 유지합니다. Kafka는 대량의 메시지를 보관 및 배포하도록 설계되었습니다. RabbitMQ에서 대기열이 매우 길면 지연 대기열을 볼 수 있습니다 .

Kafka는 수평 확장 (기계를 추가하여 확장)을 염두에두고 처음부터 구축되었으며 RabbitMQ는 주로 수직 확장 (전력을 추가하여 확장)을 위해 설계되었습니다.

RabbitMQ에는 웹 브라우저에서 RabbitMQ 서버를 모니터링하고 처리 할 수있는 사용자 친화적 인 인터페이스가 내장되어 있습니다. 무엇보다도 대기열, 연결, 채널, 교환, 사용자 및 사용자 권한을 브라우저에서 생성, 삭제 및 나열 할 수 있으며 메시지 속도를 모니터링하고 메시지를 수동으로주고받을 수 있습니다. Kafka는 관리 및 모니터링 기능을 제공 하는 여러 가지 오픈 소스 도구와 상용 버전을 가지고 있습니다. RabbitMQ를 잘 이해하는 것이 더 쉽고 빠릅니다.

자세한 내용과 비교 데이터는 https://www.cloudamqp.com/blog/2019-12-12-when-to-use-rabbitmq-or-apache-kafka.html 에서 확인할 수 있습니다.

또한 업계 논문을 추천 : "카프카 대 RabbitMQ : 두 산업 참조 출판 / 구독 구현에 대한 비교 연구": http://dl.acm.org/citation.cfm?id=3093908

Apache Kafka와 RabbitMQ를 서비스로 제공하는 회사에서 일하고 있습니다.

매주이 질문을 듣습니다 ... RabbitMQ (IBM MQ 또는 JMS 또는 일반적으로 다른 메시징 솔루션)가 기존 메시징에 사용되는 반면 Apache Kafka는 스트리밍 플랫폼 (메시징 + 분산 스토리지 + 데이터 처리)으로 사용됩니다. 둘 다 다른 사용 사례를 위해 만들어졌습니다.

"전통적인 메시징"에는 Kafka를 사용할 수 있지만 Kafka 관련 시나리오에는 MQ를 사용할 수 없습니다.

기사“ Apache Kafka와 ESB (Enterprise Service Bus) — 친구, 적 또는 Frenemies? ( https://www.confluent.io/blog/apache-kafka-vs-enterprise-service-bus-esb-friends-enemies-or-frenemies/ )”는 Kafka가 경쟁력이 없지만 통합 및 메시징 솔루션을 보완하는 이유에 대해 설명합니다. (RabbitMQ 포함) 및 통합 방법

5 Kafka와 RabbitMQ의 주요 차이점 은 다음과 같습니다.

기존 메시징 시스템 중 어떤 메시징 시스템을 선택하거나 변경해야합니까?

위의 질문에 대한 답변은 없습니다. 당신이하는 메시징 시스템을 결정해야하거나 기존의 시스템 변경해야합니다 검토 한 가지 접근 방식 "이다 범위와 비용 평가 "

잊어 버린 한 가지 중요한 차이점은 RabbitMQ는 푸시 기반 메시징 시스템이고 Kafka는 풀 기반 메시징 시스템입니다. 이것은 메시징 시스템이 서로 다른 처리 기능을 가진 서로 다른 유형의 소비자를 만족시켜야하는 시나리오에서 중요합니다. 풀 기반 시스템을 사용하면 소비자는 푸시 시스템이 소비자의 상태에 관계없이 메시지를 푸시하여 소비자에게 높은 위험을주는 기능을 기반으로 소비 할 수 있습니다.

RabbitMQ 는 일반적인 범용 메시지 브로커입니다. 웹 서버는 요청에 빠르게 응답하고 여러 서비스에 메시지를 전달할 수 있습니다. 게시자는 메시지를 게시하고 큐에서 사용할 수 있도록하여 소비자가 메시지를 검색 할 수 있습니다. 통신은 비동기식이거나 동기식 일 수 있습니다.

반면에 Apache Kafka 는 단순한 메시지 브로커 . 메시지 대기열 역할을하기 위해 LinkedIn에서 처음에 설계하고 구현했습니다. 2011 년부터 Kafka는 오픈 소스 방식으로 분산 스트리밍 플랫폼으로 빠르게 진화하여 실시간 데이터 파이프 라인 및 스트리밍 애플리케이션의 구현에 사용됩니다.

수평 확장 성, 내결함성, 빠른 속도를 자랑하며 수천 개의 회사에서 생산됩니다.

현대 조직에는 시스템 또는 서비스 간의 통신을 용이하게하는 다양한 데이터 파이프 라인이 있습니다. 합리적인 수의 서비스가 실시간으로 서로 통신해야 할 때 상황이 조금 더 복잡해집니다.

이러한 서비스의 상호 통신을 가능하게하려면 다양한 통합이 필요하므로 아키텍처가 복잡해집니다. 보다 정확하게는 m 개의 소스 및 n 개의 목표 서비스를 포함하는 아키텍처의 경우 nxm 고유의 통합을 작성해야합니다. 또한 모든 통합에는 서로 다른 사양이 제공되므로 다른 프로토콜 (HTTP, TCP, JDBC 등) 또는 다른 데이터 표현 (Binary, Apache Avro, JSON 등)이 필요할 수 있습니다. . 또한 소스 서비스는 잠재적으로 대기 시간에 영향을 줄 수있는 연결에서 증가 된로드를 처리 할 수 ​​있습니다.

Apache Kafka는 데이터 파이프 라인을 분리하여보다 단순하고 관리 가능한 아키텍처로 이어집니다. Kafka는 소스 서비스가 데이터 스트림을 푸시하여 대상 서비스가 실시간으로 데이터를 가져올 수 있도록하는 고 처리량 분산 시스템의 역할을합니다.

또한 Kafka Cluster 관리를위한 많은 오픈 소스 및 엔터프라이즈 수준의 사용자 인터페이스를 사용할 수 있습니다. 자세한 내용은 내 기사 Apache Kafka 클러스터 용 UI 모니터링 도구 개요 및 Apache Kafka 이유를 참조하십시오 .

RabbitMQ 또는 Kafka로 갈지 여부는 프로젝트의 요구 사항에 따라 결정됩니다. 일반적으로 단순 / 전통적인 pub-sub 메시지 브로커를 원하면 RabbitMQ로 이동하십시오. 조직에서 실시간으로 이벤트를 수행 할 이벤트 중심 아키텍처를 구축하려면이 아키텍처 유형 (예 : Kafka Streams 또는 ksqlDB)에 더 많은 기능을 제공하므로 Apache Kafka로 이동하십시오.

나는 그것이 조금 늦었다는 것을 알고 있으며 아마도 이미 간접적으로 말했지만 Kafka는 전혀 대기열이 아니며 로그입니다 (누군가 위에서 말했듯이 설문 조사 기반).

간단하게하기 위해 Kafka보다 RabbitMQ (또는 모든 큐 테크노)를 선호해야하는 가장 확실한 사용 사례는 다음과 같습니다.

대기열에서 여러 소비자가 소비하고 있으며 대기열에 새 메시지가 있고 사용 가능한 소비자가있을 때마다이 메시지를 처리하려고합니다. Kafka의 작동 방식을 면밀히 살펴보면 파티션 스케일링으로 인해 파티션 전용 소비자가 있고 기아 문제가 발생할 수 있습니다. 간단한 큐 테크노를 사용하면 쉽게 피할 수 있습니다. 동일한 파티션에서 다른 메시지를 전달하는 스레드를 사용할 수 있지만 Kafka에는 선택적 승인 메커니즘이 없습니다.

당신이 할 수있는 가장 많은 사람들이 그 일을하고 Kafka를 대기열로 변환하려고합니다 : https://github.com/softwaremill/kmq

야닉

다음과 같은 경우 RabbitMQ를 사용하십시오.

• Bigdata를 처리 할 필요가 없으며 모니터링을 위해 편리한 내장 UI를 선호합니다.
• 자동으로 복제 가능한 큐가 필요 없음
• 메시지에 대한 다중 가입자 없음-로그인 Kafka와 달리 RabbitMQ는 대기열이며 메시지는 일단 소비되고 승인이 도착하면 제거됩니다.
• 메시지에 와일드 카드 및 정규식을 사용해야하는 경우
• 메시지 우선 순위를 정의하는 것이 중요한 경우

요약 : RabbitMQ는 우선 순위 대기열과 유연한 라우팅 옵션을 통해 데이터 트래픽이 적은 간단한 사용 사례에 적합합니다. 방대한 데이터와 높은 처리량을 위해서는 Kafka를 사용하십시오.

나는 둘 다에 대한 나의 경험을 바탕으로 객관적인 답변을 제공 할 것이며, 이미 알고 있거나 다른 답변이 이미 충분히 제공했다고 가정하고 그 뒤에있는 이론을 건너 뛸 것입니다.

RabbitMQ : 요구 사항이 채널 / 큐를 통한 시스템 통신을 처리하기에 충분히 단순하고 유지 및 스트리밍이 요구 사항이 아닌 경우이 방법을 선택합니다. 예를 들어 제조 시스템이 자산을 구축 할 때 계약 시스템에 계약 등을 구성하도록 알립니다.

Kafka : 이벤트 소싱 요구 사항은 주로 스트림 (때로는 무한대), 한 번에 많은 양의 데이터를 적절히 균형 조정하고, 주어진 상태 등을 보장하기 위해 오프셋을 재생해야 할 때 필요합니다. 이 아키텍처에는 주제 / 파티션 / 브로커 / 톰 스톤 메시지 등과 같은 개념이 최우선으로 포함되므로 더 복잡해집니다.

내가 생각할 수있는 유일한 이점은 트랜잭션 기능이며 나머지는 Kafka를 사용하여 수행 할 수 있습니다.

분산 내결함성 방식으로 두 가지를 모두 확장하는 것은 어렵지만 RabbitMQ를 사용하면 대규모로 훨씬 어려울 수 있습니다. Shovel, Federation, Mirrored Msg Queues, ACK, Mem 문제, Fault Tollanceance 등을 이해하는 것은 쉬운 일이 아닙니다. Kafka의 Zookeeper 등과 관련된 특정 문제는 없지만 관리해야 할 부분이 적습니다. 즉, Kafka가 아닌 RMQ와 Polyglot 교환을받을 수 있습니다. 스트리밍하려면 Kafka를 사용하십시오. 간단한 IoT 또는 이와 유사한 대용량 패킷 전달을 원하면 Kafka를 사용하십시오. 똑똑한 소비자에 관한 것입니다. 높은 비용과 약간의 복잡성으로 msg 유연성과 높은 안정성을 원한다면 RMQ를 사용하십시오.

복잡한 라우팅 요구 사항이 있고 내장 GUI가 브로커를 모니터링하려는 경우 RabbitMQ가 응용 프로그램에 가장 적합 할 수 있습니다. 그렇지 않으면 높은 처리량을 처리하고 스트림 기록에 액세스 할 수있는 메시지 브로커를 찾고 있다면 Kafka가 더 나은 선택 일 것입니다.

Apache Kafka는 데이터 파이프 라인에 전원을 공급하는 데 널리 사용됩니다. Apache kafka는 인기있는 etl 사용 사례를 지원하기 위해 kafka 스트림을 추가했습니다. KSQL을 사용하면 파이프 라인 내에서 데이터를 간단하게 변환 할 수 있으므로 다른 시스템에 메시지를 깔끔하게 연결할 수 있습니다. KSQL은 Apache Kafka의 스트리밍 SQL 엔진입니다. Java 또는 Python과 같은 프로그래밍 언어로 코드를 작성할 필요없이 Kafka에서 스트림 처리를위한 사용하기 쉽고 강력한 대화식 SQL 인터페이스를 제공합니다. KSQL은 확장 가능하고 탄력적이며 내결함성이 있으며 실시간입니다. 데이터 필터링, 변환, 집계, 조인, 창 및 세션 화를 포함한 광범위한 스트리밍 작업을 지원합니다.

https://docs.confluent.io/current/ksql/docs/index.html

Rabbitmq는 처리량이 적은 간단한 메시징 시스템이 필요한 시스템보다는 etl 시스템에 널리 사용되지 않습니다.

나는 이것이 오래된 질문이라는 것을 알고 있지만 RabbitMQ가 더 나은 선택 일 수있는 시나리오는 데이터 편집을 다룰 때입니다.

RabbitMQ를 사용하면 기본적으로 메시지가 사용되면 삭제됩니다. Kafka를 사용하면 기본적으로 메시지가 일주일 동안 유지됩니다. 이 시간을 훨씬 더 길게 설정하거나 삭제하지 않는 것이 일반적입니다.

두 제품 모두 메시지를 유지하도록 (또는 유지하지 않도록) 구성 할 수 있지만 CCPA 또는 GDPR 준수가 우려되는 경우 RabbitMQ를 사용합니다.

처리량, 내구성, 대기 시간 측면에서 Kafka가 RabbitMQ보다 우수합니다. 초당 10k 미만의 트랜잭션이 예상되는 경우 RabbitMQ를 사용할 수 있지만 구현에 따라 다릅니다.

우리는 70k / sec 이상의 트랜잭션을 처리하는 제품에 Kafka를 구현했으며 대기 시간은 평균 15ms이며 최대 스파이크는 40ms에 이릅니다. 주제 크기는 100kb입니다.

KAFKA 및 RabbitMQ에 대한 PFB 추가 데이터 포인트 : Apache Kafka에는 브로커 자체가 포함되어 있습니다. 브로커 자체는 실제로 가장 유명하고 가장 인기있는 부분이며 스트림 처리 시나리오를 위해 설계되고 눈에 띄게 판매되었습니다. 또한 Apache Kafka는 최근 Apache Spark, Apache Flink, Apache Beam / Google Cloud Data Flow 및 Spring Cloud Data Flow와 같은 스트리밍 플랫폼의 대안으로 자리 매김하는 Kafka Streams를 추가했습니다. 이 문서는 웹 사이트 활동 추적, 메트릭, 로그 집계, 스트림 처리, 이벤트 소싱 및 커밋 로그와 같은 널리 사용되는 사용 사례에 대해 잘 설명합니다. 이러한 유스 케이스 중 하나는 메시징이며 혼동을 일으킬 수 있습니다. 이제 그 포장을 풀고 Kafka에 가장 적합한 메시징 시나리오를 명확하게 살펴 보겠습니다.

최대 처리량 (100k / sec +)으로 복잡한 라우팅없이 A에서 B로 스트리밍하여 최소 한 번 분할 된 순서로 전달하십시오. 애플리케이션이 스트림 히스토리에 액세스해야하는 경우 파티션 된 순서로 한 번 이상 전달됩니다. Kafka는 내구성이 뛰어난 메시지 저장소이며 클라이언트는 메시지가 전달되면 대기열에서 제거되는 기존의 메시지 브로커와 달리 요청시 이벤트 스트림을 "재생"할 수 있습니다. 스트림 처리 이벤트 소싱 RabbitMQ는 범용 메시징 솔루션으로, 사용자가 결과를 기다리는 동안 리소스가 많은 절차를 수행하지 않고 웹 서버가 요청에 빠르게 응답 할 수 있도록하는 데 자주 사용됩니다. 또한 소비를 위해 여러 수신자에게 메시지를 배포하거나 고부하 (20k + / 초)의 작업자간에 부하를 분산시키는 데 유용합니다. 요구 사항이 처리량을 넘어 확장 될 때 RabbitMQ는 안정적인 제공, 라우팅, 페더레이션, HA, 보안, 관리 도구 및 기타 기능을 제공합니다. RabbitMQ에 가장 적합한 몇 가지 시나리오를 살펴 보겠습니다.

애플리케이션은 AMQP 0-9-1, STOMP, MQTT, AMQP 1.0과 같은 기존 프로토콜의 조합으로 작동해야합니다. 메시지 단위 (데드 레터 큐 등)에 따라보다 세밀한 일관성 제어 / 보증이 필요합니다. 그러나 Kafka는 최근 트랜잭션에 대한 지원을 강화했습니다. 애플리케이션은 다양한 지점 간, 요청 / 응답 및 게시 / 구독 메시징을 필요로합니다. 소비자에게 복잡한 라우팅, 여러 서비스 / 앱을 사소한 라우팅 로직으로 통합 RabbitMQ는 위의 여러 Kafka의 강력한 사용 사례를 효과적으로 해결할 수 있습니다. 추가 소프트웨어의 도움. RabbitMQ는 애플리케이션이 스트림 히스토리에 액세스해야 할 때 Apache Cassandra 또는 "무한"큐가 필요한 애플리케이션의 LevelDB 플러그인과 함께 사용되지만 RabbitMQ 자체와 함께 제공되는 기능은 없습니다.

짧은 대답은 "메시지 확인"입니다. RabbitMQ는 메시지 확인을 요구하도록 구성 될 수 있습니다. 수신자가 실패하면 메시지가 큐로 돌아가고 다른 수신자가 다시 시도 할 수 있습니다. Kafka에서 자체 코드를 사용 하여이 작업을 수행 할 수는 있지만 RabbitMQ와 함께 즉시 작동합니다.

내 경험상 정보 스트림을 쿼리해야하는 응용 프로그램이있는 경우 Kafka와 KSql이 가장 좋습니다. 큐잉 시스템을 원한다면 RabbitMQ를 사용하는 것이 좋습니다.

가장 많이 투표 된 답변은 대부분을 다루지 만 유스 케이스 관점을 강조하고 싶습니다. kafka가 토끼 mq가 할 수있는 일을 할 수 있습니까, 대답은 그렇습니다. 그러나 토끼 mq가 kafka 가하는 모든 일을 할 수는 있습니다. 따라서 토끼 mq가 할 수없는 것은 kafka를 차별화하는 것입니다. 즉, 분산 메시지 처리입니다. 이것으로 이제 가장 투표가 많은 답변을 다시 읽으면 더 이해가 될 것입니다. 자세히 설명하려면 페이스 북에서 "좋아요"와 같이 처리량이 높은 메시징 시스템을 작성해야하는 경우를 사용하고이를 위해 rabbit mq를 선택하십시오. 모든 게시자 (이 경우 FB 사용자)가 '좋아요'메시지를 게시 할 수있는 교환 및 대기열과 소비자를 만들었습니다. 처리량이 높기 때문에 소비자에서 여러 스레드를 작성하여 메시지를 병렬로 처리하지만 소비자가 실행중인 시스템의 하드웨어 용량에 의해 여전히 제한됩니다. 한 소비자가 모든 메시지를 처리하기에 충분하지 않다고 가정하면 어떻게해야합니까? 대기열에 소비자를 하나 더 추가 할 수 있습니까? 새 큐를 작성하고 해당 큐를 바인드하여 '좋아요'메시지를 공개하는 교환에 바인딩 할 수 있습니까? 대답은 메시지를 두 번 처리 할 이유가 없습니다. 이것이 kafka가 해결하는 핵심 문제입니다. 분산 된 파티션 (래빗 mq의 대기열)과 서로 통신하는 분산 소비자를 만들 수 있습니다. 그러면 주제의 메시지가 다양한 노드 (기계)에 분산 된 소비자에 의해 프로세스를 가져옵니다. Kafka 브로커는 메시지가 해당 주제의 모든 파티션에서로드 밸런싱되도록합니다. 소비자 그룹은 모든 소비자가 서로 대화하고 메시지가 두 번 처리되지 않도록합니다. 그러나 토끼 mq가 한 소비자에게도 데이터를 매우 빠르게 처리 할 수 ​​있기 때문에 처리량이 심각하지 않으면 실제로는이 문제에 직면하지 않습니다.