kafka와 rabbitMQ에 대해 좋은 비교글이 있어 정리해본다.
https://www.cloudamqp.com/blog/when-to-use-rabbitmq-or-apache-kafka.html
Kafka vs rabbitMQ 정리
rabbitMQ는 데이터를 큐에 넣어서 처리함.
kafka는 데이터를 로그파일로 저장함
RabbitMQ는 높은 처리량을 처리할 수 있습니다. 일반적인 사용 사례는 백그라운드 작업을 처리하거나 마이크로 서비스 간의 메시지 브로커 역할을 하는 것입니다.
Kafka는 높은 수신 데이터 스트림 및 재생에 최적화된 메시지 버스입니다. Kafka는 애플리케이션이 디스크에서 스트리밍된 데이터를 처리하고 재처리할 수 있는 내구성 있는 메시지 브로커로 볼 수 있습니다.”
내부구조
RabbitMQ에서 Exchange, Queues는?
Channel은 조선일보 신문이 no1이라는 구독 채널이고, 한겨례 신문이 no2라는 구독 채널이라고 생각해도 된다. 각자 구독중인 신문만 받아야할고 각자 우편함이 따로 존재할 것이다.
Exchange는 들어온 데이터를 제공하기 위해 구독 조건에 따라 Queue에 넣는다. 즉 Producer가 전달한 메세지를 Queue에 전달하는 역할. 메세지가 Queue에 직접 전달되지 않고 exchange type이라는 속성에 정의된대로 동작
Exchange Type : 특정 Queue에 보낼지 여러 Queue에 보낼지 제거될지등을 선택
Queues는 사용자마다 생성된다. Queue는 Exchange에 Binding된다.
Bindings: Exchange와 Queue를 연결해주는것.
RoutingKey: Exchange와 Queue가 Binding될 때 Exchange가 Queue에 메세지를 전달할지를 결정하는 기준.
Public RoutingKey가 Binding시 설정된 RoutingKey값과 일치하거나 (exchange type=direct) RoutingKey 값이 Binding시 설정된 패턴에 매칭될 때(exchange type=topic)
Consumer은 메시지 수신을 위해 Queue를 실시간으로 리스닝함.
https://brunch.co.kr/@springboot/695
https://hyunalee.tistory.com/39
메시지 처리
Kafka : 대부분의 메시징 시스템과 달리 Kafka의 메시지 대기열은 영구적입니다. 전송된 데이터는 지정된 보존 기간(일정 기간 또는 크기 제한)이 지날 때까지 저장됩니다. 메시지는 보존 기간/크기 제한을 초과할 때까지 대기열에 남아 있습니다. 즉, 메시지가 소비된 후에는 제거되지 않습니다. 대신 여러 번 재생하거나 소비할 수 있으며 이는 조정 가능한 설정입니다.
재생이 유용한 경우는 소비자에게 최신 버전을 배포해야 하는 버그가 있고 메시지의 일부 또는 전체를 다시 처리해야 하는 경우입니다
RabbitMQ: RabbitMQ에서 메시지는 수신 애플리케이션이 연결되어 대기열에서 메시지를 수신할 때까지 저장됩니다. 클라이언트는 메시지를 수신하거나 클라이언트가 메시지를 완전히 처리했을 때 메시지를 확인(확인)할 수 있습니다. 두 경우 모두 메시지가 확인되면 대기열에서 제거됩니다.
Protocol
“RabbitMQ는 AMQP 0.9.1을 기본적으로 구현하는 AMQP, MQTT, STOMP 등과 같은 여러 표준화된 프로토콜을 지원합니다
Kafka는 애플리케이션과 클러스터 간의 통신을 위해 TCP/IP 위에서 동작합니다.
Routing
Kafka는 매우 간단한 라우팅 접근 방식을 가지고 있습니다. 복잡한 방법으로 소비자에게 메시지를 라우팅해야 하는 경우 RabbitMQ가 더 나은 옵션을 제공합니다.
RabbitMQ의 가장 큰 장점은 메시지를 유연하게 라우팅할 수 있다는 것입니다. 직접 또는 정규식 기반 라우팅을 사용하면 추가 코드 없이 메시지가 특정 대기열에 도달할 수 있습니다.
direct 교환은 라우팅 키라고 하는 것과 정확히 일치하는 모든 대기열로 메시지를 라우팅합니다. 팬아웃 교환은 교환에 바인딩된 모든 큐에 메시지를 브로드캐스트할 수 있습니다. topic 메소드는 라우팅 키를 사용한다는 점에서 direct와 유사하지만 정확한 일치와 함께 와일드카드 일치를 허용합니다.
Kafka는 라우팅을 지원하지 않습니다.
kafka stream을 활용하면 동적 라우팅을 할 수 있다.
Message Priority
RabbitMQ는 우선 순위 대기열이라는 것을 지원합니다. 즉, 대기열이 우선 순위 범위를 갖도록 설정할 수 있습니다.
Kafka에서는 메시지를 우선 순위 수준으로 보내거나 우선 순위에 따라 전달할 수 없습니다. Kafka의 모든 메시지는 소비자 측이 얼마나 바쁜지에 관계없이 수신된 순서대로 저장되고 전달됩니다.
Acknowledgment (Commit or Confirm)
Kafka와 RabbitMQ는 게시된 메시지가 브로커에 안전하게 도달했는지 확인하기 위해 생산자 확인(publisher는 RabbitMQ에서 확인)을 지원합니다.
RabbitMQ는 메시지가 전송되면 전달된 것으로 간주하거나 수신된 경우 소비자가 수동으로 승인할 때까지 기다릴 수 있습니다. RabbitMQ 클라이언트는 메시지 처리에 실패할 때 메시지를 nack(부정적 승인)할 수도 있습니다. 메시지는 새 메시지인 것처럼 원래 큐에 반환됩니다. 이는 소비자 측에서 일시적인 오류가 발생한 경우에 유용합니다.
Kafka는 파티션의 각 메시지에 대한 오프셋을 유지합니다. 커밋된 위치는 저장된 마지막 오프셋입니다. 프로세스가 실패하고 다시 시작되면 이것이 복구될 오프셋입니다. Kafka의 소비자는 주기적으로 오프셋을 자동으로 커밋하거나 커밋된 위치를 수동으로 제어하도록 선택할 수 있습니다.
Queue가 어떻게 동작하나
RabbitMQ의 대기열은 비어 있을 때 가장 빠른 반면 Kafka는 대량의 메시지를 보관 및 배포하도록 설계되었습니다. Kafka는 오버헤드가 거의 없이 많은 양의 데이터를 유지합니다.
RabbitMQ를 사용해 본 사람들은 아마도 지연 대기열 기능을 인식하지 못할 것입니다. 지연 대기열은 메시지가 디스크에 자동으로 저장되어 RAM 사용량을 최소화하지만 처리 시간은 연장되는 대기열입니다. 경험상 지연 대기열은 더 나은 예측 성능으로 더 안정적인 클러스터를 생성합니다. 한 번에 많은 메시지를 보내는 경우(예: 일괄 작업 처리) 또는 소비자가 게시자의 속도를 일관되게 따라가지 못한다고 생각되면 지연 대기열을 활성화하는 것이 좋습니다.
Scaling - CONSUMER SCALING
pub이 빨라지면 Queue가 커지기 시작하고 결국 RabbitMQ의 메모리가 부족해질 수 있습니다. 이 경우 메시지를 처리(Consumer)하는 소비자 수를 조정할 수 있습니다. 메시지 처리는 모든 활성 소비자에 분산되어 있으므로 단순히 소비자를 추가 및 제거하여 RabbitMQ의 확장 및 축소를 수행할 수 있습니다.
Kafka에서 Subscriber를 분산하는 방법은 그룹의 각 소비자가 하나 이상의 파티션 전용인 토픽 파티션을 사용하는 것입니다
Scaling - BROKER SCALING
Kafka는 수평 확장(adding more machines)을 염두에 두고 처음부터 구축된 반면 RabbitMQ는 대부분 수직 확장(adding more power)을 위해 설계되었습니다.
RabbitMQ에서는 수평 확장이 가능하지만, 이는 노드 간에 클러스터링을 설정해야 한다는 것을 의미하므로 설정 속도가 느려질 수 있습니다.
Kafka에서는 클러스터에 더 많은 노드를 추가하거나 topic에 더 많은 파티션을 추가하여 확장할 수 있습니다.
이것은 RabbitMQ에서 해야 하는 것처럼 CPU나 메모리를 기존 시스템에 추가하는 것보다 쉽기도 합니다.
Confluent를 비롯한 많은 사람들과 블로그에서 Kafka가 확장성에 얼마나 뛰어난지에 대해 이야기하고 있습니다. 그리고 확실히 Kafka는 RabbitMQ보다 더 확장할 수 있습니다. 왜냐하면 구매할 수 있는 기계의 크기에는 항상 한계가 있기 때문입니다.
로그 압축
RabbitMQ에는 없는 Apache Kafka에서 언급할 가치가 있는 기능은 로그 압축 전략입니다.
로그 압축은 Kafka를 데이터베이스로 사용하는 방법으로 볼 수 있습니다. 보존 기간을 “영구”로 설정하거나 주제에 대한 로그 압축을 활성화하면 데이터가 영원히 저장됩니다.
로그 압축을 사용하는 예는 실행 중인 수천 개의 클러스터 중 하나의 클러스터의 최신 상태를 표시할 때입니다. 클러스터가 항상 응답하는지 여부를 저장하는 대신 최종 상태를 저장합니다. 현재 대기열에 있는 메시지 수와 같은 최신 정보를 즉시 사용할 수 있습니다.
푸시 또는 풀
메시지는 RabbitMQ에서 소비자로 푸시됩니다. 소비자를 압도하는 것을 방지하기 위해 프리페치 제한을 구성하는 것이 중요합니다(메시지가 소비자가 처리할 수 있는 것보다 더 빨리 대기열에 도착하는 경우).
소비자는 RabbitMQ에서 메시지를 가져올 수도 있지만 권장하지 않습니다. 반면 Kafka는 앞에서 설명한 대로 소비자가 주어진 오프셋에서 일괄 메시지를 요청하는 풀 모델을 사용합니다.
RabbitMQ 사용사례
내 요구 사항이 채널/대기열을 통한 시스템 통신을 처리하기에 충분히 간단하고 보존 및 스트리밍이 요구 사항이 아닌 경우 RabbitMQ를 선택했을 것입니다.
RabbitMQ를 선택하는 두 가지 주요 상황이 있습니다. 장기 실행 작업의 경우 안정적인 백그라운드 작업을 실행해야 할 때. 그리고 애플리케이션 내부 및 애플리케이션 간의 통신 및 통합을 위해, 즉 마이크로서비스 간의 중개자로서, 시스템은 웹샵에서의 주문 처리
RabbitMQ 사용 사례 - 장기 실행 작업
메시지 대기열은 비동기 처리를 가능하게 합니다. 즉, 즉시 처리하지 않고 대기열에 메시지를 넣을 수 있습니다. RabbitMQ는 장기 실행 작업에 이상적입니다.
ex : 사이트는 이 정보를 처리하고 PDF를 생성하여 사용자에게 다시 이메일로 보냅니다. 이 예제의 경우 작업을 완료하는 데 몇 초가 걸리며 이것이 메시지 큐를 사용하는 이유 중 하나입니다.
많은 고객이 RabbitMQ 대기열을 이벤트 버스로 사용하여 웹 서버가 그 자리에서 계산 집약적인 작업을 수행하는 대신 요청에 신속하게 응답할 수 있도록 합니다.
RabbitMQ 사용 사례 - 마이크로서비스 아키텍처의 중개자
RabbitMQ는 또한 많은 고객이 마이크로서비스 아키텍처에 사용하며, 여기서 메시지 전달의 병목 현상을 방지하면서 애플리케이션 간의 통신 수단으로 사용됩니다.
Apache Kafka의 사용 사례
일반적으로 스트리밍 데이터를 저장, 읽기(다시 읽기), 분석하기 위한 프레임워크를 원하면 Apache Kafka를 사용합니다. 감사를 받는 시스템이나 메시지를 영구적으로 저장해야 하는 시스템에 이상적입니다. 또한 데이터 분석(추적, 수집, 로깅, 보안 등) 또는 실시간 처리를 위한 두 가지 주요 사용 사례로 나눌 수 있습니다.
Apache Kafka의 사용 사례 - 데이터 분석: 추적, 수집, 로깅, 보안
Kafka의 원래 사용 사례는 페이지 보기, 검색, 업로드 또는 사용자가 취할 수 있는 기타 작업을 포함한 웹사이트 활동을 추적하는 것이었습니다. 이러한 종류의 활동 추적에는 각 작업 및 각 사용자에 대해 메시지가 생성되기 때문에 매우 많은 양의 처리량이 필요한 경우가 많습니다. 이러한 활동 중 많은 부분(사실 모든 시스템 활동)은 Kafka에 저장하고 필요에 따라 처리할 수 있습니다.
Producer는 데이터를 한 곳으로 보내기만 하면 되고 백엔드 서비스 호스트는 필요에 따라 데이터를 사용할 수 있습니다. 주요 분석, 검색 및 저장 시스템은 Kafka와 통합됩니다.
Apache Kafka의 사용 사례 - 실시간 처리
Kafka는 처리량이 많은 분산 시스템 역할을 합니다. 소스 서비스는 데이터 스트림을 실시간으로 가져오는 대상 서비스로 푸시합니다.
Kafka는 적은 수의 소비자와 실시간으로 많은 생산자를 처리하는 시스템에서 사용할 수 있습니다. 즉, 주식 데이터를 모니터링하는 금융 IT 시스템.
정리
RabbitMQ
What : RabbitMQ is a solid, mature, general purpose message broker
주요용도: 응용 프로그램 간의 통신을 위한 메시지 Queue입니다. 장기 실행 작업 또는 안정적인 백그라운드 작업을 실행해야 하는 경우 사용됨.
Persistence: acknowledgement 수신시 데이터 drop
Replay: 안됨
Routing: Consumer 노드에 정보를 반환할 수 있는 유연한 라우팅 지원
Message Priority: 설정가능
Kafka
What : Apache Kafka is a message bus optimized for high-ingress data streams and replay
주요용도 : 스트리밍 데이터를 저장, 읽기(다시 읽기) 및 분석하기 위한 프레임워크입니다.
Persistence : 보관 기간 이 지난 후 삭제할 수 있는 옵션에 따라 메시지를 유지합니다.
Replay : 가능
Routing : 유연한 라우팅을 지원하지 않으며 별도의 Topic을 통해 수행해야 합니다.
Message Priority: 불가능