-
[메시지큐] Kafka, RabbitMQ 비교 및 쓰는 이유개발 2021. 7. 21. 21:39
메시지 큐는 왜 쓸까?
메시지 큐는 주로 어플리케이션의 요청에 대해 서버가 실시간으로 응답해야 할 때 사용한다.
Application 과 서버가 강하게 결합되어 있을 경우, db나 백엔드 단에서 문제가 발생하면 어플리케이션에도 장애가 발생한다. 즉 서버와 어플리케이션 간의 의존성이 높다.
메시지큐를 사용하면..
- 느슨하게 결합된 설계
- 어플리케이션 아키텍쳐가 DB성능에 영향을 덜 받는다.
- 여러 다른 API 로부터 비동기 통신이 가능하다
- 다수의 프로세스로부터 메시지 처리 가능
- 비동기: Queue 에 넣기 때문에 나중에 처리 가능
메시지 큐 종류
Kafka
RabbitMQ
ActiveMQ
셋 다 비동기 통신하고, Sender 와 Receiver 를 구분하지만, 각 기술은 만들어진 목적이 다르다.
1. RabbitMQ
AMQP 프로토콜을 구현해 놓았고, 직관적.
AMQP 란?
- Advanced Message Queing Protocal
- 다 기종 간에도 호환이 되는 메시지큐 프로토콜
여기를 참고장점
- 신뢰성, 안정성 -> 나온지 오래되었음.
- 유연한 라우팅 (Message Queue가 도착하기 전에 라우팅 되며 플러그인을 통해 더 복잡한 라우팅도 가능)
- 클러스터링 (로컬네트워크에 있는 여러 RabbitMQ 서버를 논리적으로 클러스터링할 수 있고 논리적인 브로커도 가능)
- 관리 UI의 편리성 (관리자 페이지 및 모니터링 페이지가 제공됨)
- 거의 모든 언어 및 운영체제를 지원
2. Kafka ← Saas 로 제공
확장성과 고성능 및 높은 처리량. 대용량 데이터 특화 시스템이기 때문에 범용으로는 적합하지 않음.
분산 시스템을 설계 → 분산, 복제 구성 쉽게 가능.
장점
- 대용량 실시간 로그 처리에 특화되어 있다
- AMQP 프로토콜이나 JSM API를 사용하지 않고 단순한 메시지 헤더를 지닌 TCP 기반 프로토콜 사용함으로써 오버헤드가 비교적 작다.
- 노드 장애에 대한 대응성을 가지고 있다
- 프로듀서는 각 메시지를 배치로 브로커에게 전달하여 TCP/IP 라운드 트립을 줄였다
- 메시지를 기본적으로 파일 시스템에 저장하여 별도의 설정을 하지 않아도 오류 발생 시 오류 지점부터 복구가 가능하다 (기존 메시징 시스템은 메시지를 메모리에 저장)
- 메시지를 파일시스템에 저장하기 때문에 메시지가 많이 쌓여도 기존 메시징 시스템에 비해 성능이 크게 감소하지 않는다
Kafka 는 기존 싱글 메시지 큐 방식과 Pub/Sub 방식의 장점만 차용하였다. 이부분 너무 어렵다
3. ActiveMQ
ActiveMQ는 자바로 만든 오픈소스 메시지 브로커
장점
- 다양한 언어와 프로토콜 지원 (Java, C, C++, C#, Ruby, Perl, Python, PHP클라이언트 지원)
- OpenWire를 통해 고성능의 Java, C, C++, C# 클라이언트 지원
- 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 와 RabbitMQ 를 비교해 보자면, 메시지 Consumption 에 있어서 차이가 많이 난다.
애초에 클러스터 환경에서 대용량 트래픽을 감당 하기 위해 탄생한 카프카이니, 분산 / 고성능을 추구한다면 카프카를 사용하는게 맞는 것 같다.
프로그램이나 트래픽 규모가 분산까지 필요 없을 거라면 오히려 RabbitMQ 가 나을 수 있다. 제품이 나온지 오래 되었고, 구성이 자유롭다는 점에서 카프카보다 이점이 있다.
분산 / 대용량 메시지 처리 / 고성능 / 노드 장애 대응 기능이 필요하다면 Kafka 를, 상용성과 구성의 자유도가 중요하다면 RabbitMQ 를 사용하는 것이 좋다고 생각한다.
실무적으로는 트래픽을 많이 감당하는 대기업에서 대부분 카프카를 사용하는 것 같긴 하다.. (?)
'개발' 카테고리의 다른 글
@Transactional 태그 안에서 Exception Handling 시 유의 할 점 (0) 2021.08.27 [빅데이터 플랫폼]Lambda & Kappa Architecture (0) 2021.07.28 [JPA] Entity를 통해서 변경한 데이터를 DB는 어떻게 알아먹을까? → 영속성 관리 (0) 2021.07.28 [Spring Security] Stateless 서버를 위한 JWT 인증 방식 (0) 2021.07.28 [Kafka] 카프카 개념, Topic, Broker, Partition, Lag, Burrow 등 기초편 (0) 2021.07.21