Server Programming/ETC

Apache Kafka 및 메세지 큐 종류와 차이점

Dev.BeryL 2022. 1. 27. 18:54
728x90

메세지 큐의 사용 이유

  • Application request에 서버가 실시간으로 response 할때 사용
  • Application 과 서버가 강한 결합일 경우 DB와 백엔드에서 장애발생시 Application 역시 장애발생

MQ 사용시 장점

  • 설계를 보다 느슨한 결합할 수 있음
  • Application Architecture가 DB성능에 덜 영향을 받음
  • 여러 다른 API로 부터 비동기통신이 가능
  • 다수의 프로세스로부터 Message 처리 가능

메세지큐 종류

  • Kafka
  • RabbitMQ
  • ActiveMq

Kafka

  • 확장성, 고성능 및 높은 처리량
  • 대용량 데이터 특화 시스템으로 범용으론 적합하지 않다.
  • 분산시스템을 설계 → 분산, 복제 구성이 쉽다.

이점

  • 대용량 실시간 로그처리 특화
  • AMQP 프로토콜이나 JSM API를 사용하지 않고 단순한 메시지 헤더를 지닌 TCP 기반 프로토콜 사용 → 통신 오버헤드가 적음
  • 노드 장애에 대한 대응성
  • Producer는 각 Message를 Batch로 broker에게 전달해 TCP/IP 라운드 트립을 줄임
  • Message를 기본적으로 파일 시스템에 저장해 별도의 설정을 하지 않아도 장애 발생시 해당 지점부터 복구가 가능 → 기존 메시징 시스템은 메시지를 메모리에 저장함
  • Message를 파일시스템에 저장해 적재가 많이 되어있어도 기존 메시징 시스템에 비해 성능이 크게 감소하지 않음

ref : https://wedul.site/577

 

[번역] shared message queues와 publish-subscribe 방식에 Custom Group 방식을 더한 Kafka 소개

전통적으로 메시지 모델은 Shared Message Queue, Publish-subscribe로 구분된다. 두 가지 모델 모두 그들만에 pros and cons를 보유하고 있다. 하지만 이 두개의 모두 최초 디자인 제한 때문에 큰 데이터를 다

wedul.site

 

RabbitMQ

AMQP 프로토콜을 구현해 놓았으며 직관적이다.

AMQP(Advanced Message Queing Protocol) - 다 기종 간 호환이 가능한 MQ Protocol

 

이점

  • 릴리즈가 오래되어 신뢰성있으며, 안정성이 좋다
  • 유연한 라우팅 기능(Message Queue가 도착하기 전에 라우팅 되며 플러그인을 통해 더 복잡한 라우팅도 가능)
  • 클러스터링 기능(로컬네트워크에 있는 여러 RabbitMQ 서버를 논리적으로 클러스터링할 수 있고 논리적인 브로커도 가능)
  • simple UI  (관리자 페이지 및 모니터링 페이지가 제공됨)
  • 대부분의 언어 및 운영체제에서 지원 가능

ActiveMQ

ActiveMQ는 자바로 만들어진 오픈소스 메세지 브로커이다.

 

이점

  • 다양한 언어와 프로토콜 지원한다. 
  • OpenWire를 통해 고성능의 클라이언트를 지원한다.
  • Stomp를 통해 C, Ruby, Perl, Python, PHP 클라이언트가 다른 인기있는 메시지 브로커들과 마찬가지로 ActiveMQ에 접근이 가능하다.
  • Message Groups, Virtual Destinations, Wildcards와 Composite Destination를 지원한다.
  • Spring 지원으로 ActiveMQ는 Spring Application에 매우 쉽게 임베딩될 수 있으며, Spring의 XML 설정 메커니즘에 의해 쉽게 설정 가능하다.
  • Geronimo, JBoss 4, GlassFish, WebLogic과 같은 인기있는 J2EE 서버들과 함께 테스트된다.
  • 고성능의 저널을 사용할 때에 JDBC를 사용하여 매우 빠른 Persistence를 지원한다
  • REST API를 통해 웹기반 메시징 API를 지원한다.
  • 웹 브라우저가 메시징 도구가 될 수 있도록, Ajax를 통해 순수한 DHTML을 사용한 웹 스트리밍 지원한다.

 

결론..

 메시지 소비량

Kafka vs RabbitMQ 는 메시지 Consumption 으로 봤을 때는 차이가 많다.

대용량 트래픽을 감당 하기 위해 탄생한 Kafka는, 분산 / 고성능을 추구하면 권장한다.

하지만 그 반대로 대용량 트래픽의 분산처리가 필요 없다 라고 가정할 시 구성이 자유롭다는 점에서 RabbitMQ 가 나을 수 있다. 

분산 / 대용량 메시지 처리 / 고성능 / 노드 장애 대응 기능이 필요하다면 Kafka 를, 상용성과 구성의 자유도가 중요하다면 RabbitMQ 를 사용하는 것이 좋다고 생각한다.

반응형