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 를 사용하는 것이 좋다고 생각한다.
반응형