Kafka vs RabbitMQ

예전에 메시지 큐 방식들을 비교했던 기억이 있습니다. 그때 당시의 결론으로는 RabbitMQ가 더 좋다는 결론을 냈었는데 대기업에서는 Kafka를 사용하더라구요. 이유를 예상할 수 있었지만 혹시 모르니 다시 또 비교해보는 시간을 가져보려고 합니다.

 

메시지 큐란?

 

메시지 큐(message queue)는 키보드나 마우스를 통해 발생하는 사용자의 입력을 메시지로 전달하는 윈도우즈 시스템에서 어떤 프로세스에 대한 메시지를 저장하기 위해 할당된 큐다. - 출처 : 위키백과 - 

 

위키백과에서 설명하는 메시지 큐는 제가 아는 지식이랑은 조금 다르군요. 제가 다룰 메시지 큐는 프로세스끼리 데이터를 교환할때 사용하는 통신 방법을 얘기합니다. 저는 통신을 위한 큐 자료구조라고 이해했어요. 

 

메시지 큐의 장점

 

 - 비동기(Asynchronous): Queue에 넣기 때문에 나중에 처리할 수 있습니다.
 - 비동조(Decoupling): Appliction 과 분리할 수 있습니다.
   (각 서비스의 연결을 느슨하게 합니다)
 - 탄력성(Resilience): 일부가 실패 시 전체에 영향을 받지 않습니다.
 - 과잉(Redundancy): 실패할 경우 재실행 가능합니다.
 - 보증(Guarantees): 작업이 처리된걸 확인할 수 있습니다.
 - 확장성(Scalable): 다수의 프로세스들이 큐에 메시지를 보낼 수 있습니다.

출처: https://sugerent.tistory.com/644 [MISTERY]

 

위의 장점들때문에 메시지 큐를 사용하고는 합니다. 대용량의 데이터를 처리하기 위해 분산 처리할때 쓰인답니다. 대부분은 일단 메시지 큐에 메시지를 넣어두고 필요한 쪽에서 알아서 받아서 처리해서 씁니다. 이게 바로 역할 분리..???

 

RabbitMQ

 

“open source distributed message broker”

 

Erlang으로 작성된 이 기능은 복잡한 라우팅 시나리오에서 효율적인 메시지 전달을 지원합니다. 인기 있는 AMQP 프로토콜을 기반으로 초기 구축되었으며 기존 기술과도 호환성이 뛰어나며, 서버에서 사용할 수 있는 플러그인을 통해 기능을 확장할 수 있습니다. RabbitMQ 브로커는 네트워크 또는 서버 장애 시 신뢰할 수 있도록 배포 및 구성할 수 있습니다. 소비자중심의 설계를 했으며 구성이 쉽다고 합니다. 또한 필요에 따라 동기/비동기식 처리가 가능합니다.

 

Apache Kafka

 

“distributed event streaming platform”

 

원시 처리량에 포커스를 맞췄습니다. 스칼라 및 Java로 작성된 Kafka는 분산 로그를 기반으로 합니다. 이 로그는 디스크에 보존된 로그의 끝에 메시지가 기록되고 클라이언트가 해당 로그에서 읽기 시작하는 위치를 선택할 수 있습니다. 이와 마찬가지로 Kafka 클러스터도 여러 서버에 분산 및 클러스터링하여 가용성을 높일 수 있습니다. 생산자 중심의 설계로 구성되었으며 구독 방식의 비동기식 구성이고 고성능 방식입니다. 

 

RabbitMQ vs Kafka

 

설계면에서 차이를 찾을 수 있습니다. RabbitMQ는 메시지 브로커 방식이고 Kafka는 pub/sub 방식입니다.

 

메시지 브로커란 응용프로그램, 서비스 및 시스템이 정보를 통신하고 교환할 수 있도록 하는 소프트웨어 모듈입니다. 메시지 브로커는 지정된 수신인에게 메시지를 확인, 라우팅, 저장 및 배달합니다. 브로커는 다른 응용 프로그램 간의 중개자로 작동하여 보낸 사람이 소비자의 위치, 활성 여부, 또는 그 중 몇 개가 있는지도 모르게 메시지를 보낼 수 있습니다. 그러나 pub/sub은 생산자가 원하는 각 메시지를 게시할 수 있도록 하는 메시지 배포 패턴입니다.

 

예전에 읽었던 논문에서는 Kafka는 고성능을 추구하기 때문에 비교적 무겁다고 했습니다. 따라서 굳이 그 정도의 대용량 데이터를 다루지 않는다면 가벼운 RabbitMQ가 더 낫다고 했습니다. 또한 그때 당시에는 Kafka가 등장한지 얼마 되지 않았기에 비교적 역사가 있는 RabbitMQ를 추천하는 분위기였죠. 그러나 지금은 시간이 흘러 Kafka 사용 사례들이 늘기도 하고 예전에 비해 탄탄해지지 않았나 생각합니다. 실제로 개발자들이 스트리밍 데이터를 더 쉽게 처리할 수 있도록 해주는 클라이언트 라이브러리 구현인 Kafka Streams가 사용하기 괜찮아졌죠. 

 

즉, 이제는 사용 목적에 따라서 메시지 큐 방식을 선택해야겠습니다. 

 

kafka가 적절한 곳

 

Kafka는 복잡한 라우팅에 의존하지 않고 최대 처리량으로 스트리밍하는 데 가장 적합합니다. 또한 이벤트 소싱, 스트림 처리 및 일련의 이벤트로 시스템에 대한 모델링 변경을 수행하는 데 이상적입니다. Kafka는 다단계 파이프라인에서 데이터를 처리하는 데도 적합합니다.

결론적으로 스트리밍 데이터를 저장, 읽기, 다시 읽기 및 분석하는 프레임워크가 필요한 경우 Kafka를 선택해야겠죠. 정기적으로 감사하는 시스템이나 메시지를 영구적으로 저장하는 데 이상적입니다.

 

kafka 키워드 요약 : 실시간 처리

 

RabbitMQ가 적절한 곳

 

위에서 언급한 복잡한 라우팅. 이 경우에는 RabbitMQ를 사용합니다. RabbitMQ는 신속한 요청-응답이 필요한 웹 서버에 적합합니다. 또한 부하가 높은 작업자(20K 이상 메시지/초) 간에 부하를 공유합니다. RabbitMQ는 백그라운드 작업이나 PDF 변환, 파일 검색 또는 이미지 확장과 같은 장기 실행 작업도 처리할 수 있습니다.

 

요약하자면, 장시간 실행되는 태스크, 안정적인 백그라운드 작업 실행, 애플리케이션 간/내부 통신/통합이 필요할때 RabbitMQ를 사용하세요. 

 

 

추가적인 정보가 필요하신 분들은 Kafka나 RabbitMQ 공식 페이지에서 확인해보셔도 되고

 

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

When to use RabbitMQ or Apache Kafka - CloudAMQP

 

위 링크에서 정보를 얻으셔도 좋습니다. 각 성능별로 두 MQ를 분석하고 있는 글입니다. 다만 2019년도에 작성된 글로 현재와는 다른 점들이 있으리라고 생각하여 제 글에 포함하지 않았습니다.