1. 개요
분산 아키텍처에서 애플리케이션은 일반적으로 서로 간에 데이터를 교환해야 합니다. 한편으로 이것은 서로 직접 통신함으로써 이루어질 수 있다. 반면에 고가용성 및 파티션 허용 범위에 도달하고 응용 프로그램 간의 결합을 느슨하게 하려면 메시징이 적절한 솔루션입니다.
따라서 여러 제품 중에서 선택할 수 있습니다. Apache Foundation은 ActiveMQ와 Kafka를 제공하며 이 기사에서 서로 비교할 것입니다.
2. 일반적인 사실
2.1. 활성 MQ
Active MQ는 안전하고 신뢰할 수 있는 방식으로 응용 프로그램 간의 데이터 교환을 보장하는 것이 목표인 전통적인 메시지 브로커 중 하나입니다. 적은 양의 데이터를 다루므로 잘 정의된 메시지 형식과 트랜잭션 메시징에 특화되어 있습니다.
이 "클래식" 버전 외에 Active MQ Artemis라는 다른 버전이 있다는 점에 유의해야 합니다. 이 차세대 브로커는 2015년 RedHat에서 Apache Foundation에 코드를 제공한 HornetQ를 기반으로 합니다. Active MQ 웹 사이트 에는 다음과 같이 나와 있습니다.
Artemis가 "클래식" 코드 기반과 충분한 수준의 기능 패리티에 도달하면 ActiveMQ의 다음 주요 버전이 됩니다.
따라서 비교를 위해 두 버전을 모두 고려해야 합니다. "Active MQ" 와 "Artemis" 라는 용어를 사용하여 이들을 구별할 것 입니다.
2.2. 카프카
Active MQ와 달리 Kafka는 방대한 양의 데이터를 처리하기 위한 분산 시스템입니다. 기존 메시징뿐만 아니라 다음과 같은 용도로도 사용할 수 있습니다.
- 웹사이트 활동 추적
- 메트릭
- 로그 집계
- 스트림 처리
- 이벤트 소싱
- 커밋 로그
이러한 요구 사항은 마이크로 서비스를 사용하여 구축된 일반적인 클라우드 아키텍처의 출현으로 매우 중요해졌습니다.
2.3. JMS의 역할과 메시징의 진화
JMS(Java Message Service)는 Java EE 애플리케이션 내에서 메시지를 송수신하기 위한 공통 API입니다. 이는 메시징 시스템의 초기 진화 과정의 일부이며 오늘날에도 여전히 표준입니다. Jakarta EE에서는 Jakarta Messaging 으로 채택되었습니다 . 따라서 핵심 개념을 이해하는 것이 도움이 될 수 있습니다.
- Java 네이티브이지만 벤더 독립적인 API
- 공급업체별 통신 프로토콜을 구현하기 위한 JCA 리소스 어댑터 의 필요성
- 메시지 대상 모델:
- Queue ( P2P )은 여러 소비자의 경우에도 메시지 순서 지정 및 일회성 메시지 처리를 보장합니다.
- 게시-구독 패턴의 구현으로서 주제 ( PubSub )는 여러 소비자가 주제에 대한 구독 기간 동안 메시지를 수신함을 의미합니다.
- 메시지 형식:
- 브로커가 처리하는 표준화된 메타 정보로서의 헤더 (우선순위 또는 만료일 등)
- 소비자가 메시지 처리에 사용할 수 있는 비표준화 메타 정보로서의 속성
- 페이로드를 포함 하는 본문 – JMS는 5가지 유형의 메시지를 선언하지만 이는 이 비교가 아닌 API 사용과만 관련이 있습니다.
그러나 진화는 개방적이고 독립적인 방향으로 진행되었습니다. 즉, 소비자와 생산자의 플랫폼과 메시징 브로커의 공급업체로부터 독립된 것입니다. 자체 대상 모델을 정의하는 프로토콜이 있습니다.
- AMQP – 공급업체 독립적인 메시징을 위한 이진 프로토콜 – 일반 노드 사용
- 임베디드 시스템 및 IoT용 경량 바이너리 프로토콜인 MQTT 는 주제 를 사용합니다.
- STOMP – 브라우저에서도 메시징을 허용하는 간단한 텍스트 기반 프로토콜 – 일반 대상 사용
또 다른 발전은 클라우드 아키텍처의 확산을 통해 "Fire and Forget" 원칙에 따라 대량의 데이터 처리에 이전의 안정적인 개별 메시지 전송("전통적인 메시징")을 추가한 것입니다. Active MQ와 Kafka 간의 비교는 이 두 가지 접근 방식의 모범적인 대표를 비교한 것이라고 말할 수 있습니다. 예를 들어 Kafka의 대안은 NATS 일 수 있습니다 .
3. 비교
이 섹션에서는 Active MQ와 Kafka 간의 아키텍처 및 개발의 가장 흥미로운 기능을 비교합니다.
3.1. 메시지 대상 모델, 프로토콜 및 API
Active MQ는 Queue 및 주제 의 JMS 메시지 대상 모델을 완전히 구현하고 AMQP, MQTT 및 STOMP 메시지를 여기에 매핑합니다. 예를 들어 STOMP 메시지는 Topic 내의 JMS BytesMessage 에 매핑됩니다 . 또한 Active MQ에 대한 교차 언어 액세스를 허용 하는 OpenWire 를 지원합니다.
Artemis는 표준 API 및 프로토콜과 독립적으로 자체 메시지 대상 모델을 정의하고 이를 이 모델에 매핑해야 합니다.
- 메시지 는 고유한 이름, 라우팅 유형 및 0개 이상의 Queue 이 지정된 주소 로 전송됩니다 .
- 라우팅 유형 은 메시지가 주소에서 해당 주소에 바인딩된 Queue로 라우팅되는 방식을 결정합니다. 두 가지 유형이 정의되어 있습니다.
- ANYCAST : 메시지는 주소의 단일 Queue로 라우팅됩니다.
- MULTICAST : 메시지는 주소의 모든 Queue로 라우팅됩니다.
Kafka 는 여러 파티션 (최소 1개)과 다른 브로커에 배치할 수 있는 복제본 으로 구성된 주제 만 정의합니다. 주제를 분할하기 위한 최적의 전략을 찾는 것은 어려운 일입니다. 다음 사항에 유의해야 합니다.
- 하나의 메시지가 하나의 파티션으로 분배됩니다.
- 순서는 한 파티션 내의 메시지에 대해서만 보장됩니다.
- 기본적으로 후속 메시지는 주제의 파티션 간에 라운드 로빈으로 분산됩니다.
- 메시지 키를 사용하면 동일한 키를 가진 메시지가 동일한 파티션에 배치됩니다.
Kafka에는 자체 API 가 있습니다. JMS용 리소스 어댑터 도 있지만 개념이 완전히 호환되지 않는다는 점을 알아야 합니다. AMQP, MQTT 및 STOMP는 공식적으로 지원되지 않지만 AMQP 및 MQTT 용 커넥터 가 있습니다.
3.2. 메시지 형식 및 처리
Active MQ는 헤더, 속성 및 본문(위에서 설명한 대로)으로 구성된 JMS 표준 메시지 형식을 지원합니다. 브로커는 모든 메시지의 배달 상태를 유지해야 처리량이 낮아집니다. JMS에서 지원하기 때문에 소비자는 대상에서 동기식으로 메시지를 가져오거나 브로커에서 메시지를 비동기식으로 푸시할 수 있습니다.
Kafka는 메시지 형식을 정의하지 않습니다. 이는 전적으로 생산자의 책임입니다. 메시지당 전달 상태는 없으며 소비자 및 파티션당 오프셋 만 있습니다. 오프셋 은 전달 된 마지막 메시지의 인덱스입니다. 이것은 더 빠를 뿐만 아니라 생산자에게 묻지 않고 오프셋을 재설정하여 메시지를 재전송할 수 있습니다.
3.3. 스프링과 CDI 통합
JMS는 Java/Jakarta EE 표준이므로 Java/Jakarta EE 애플리케이션에 완전히 통합됩니다. 따라서 Active MQ 및 Artemis에 대한 연결은 애플리케이션 서버에서 쉽게 관리됩니다. Artemis를 사용하면 임베디드 브로커 도 사용할 수 있습니다 . Kafka의 경우 JMS용 리소스 어댑터 또는 Eclipse MicroProfile Reactive 를 사용하는 경우에만 관리 연결을 사용할 수 있습니다 .
Spring은 AMQP , MQTT 및 STOMP 뿐만 아니라 JMS 에 대한 통합을 제공 합니다. 카프카 도 지원됩니다. Spring Boot를 사용하면 Active MQ , Artemis 및 Kafka 용 임베디드 브로커를 사용할 수 있습니다 .
4. Active MQ/Artemis 및 Kafka 사용 사례
다음 사항은 어떤 제품을 가장 잘 사용할 수 있는지에 대한 지침을 제공합니다.
4.1. Active MQ/Artemis 사용 사례
- 하루에 적은 수의 메시지만 처리
- 높은 수준의 신뢰성 및 거래성
- 즉각적인 데이터 변환, ETL 작업
4.2. 카프카 사용 사례
- 많은 양의 데이터 처리
- 실시간 데이터 처리
- 애플리케이션 활동 추적
- 로깅 및 모니터링
- 데이터 변환 없이 메시지 전달(가능하지만 쉽지는 않음)
- 전송 보장 없이 메시지 전달(가능하지만 쉽지는 않음)
5. 결론
우리가 본 것처럼 Active MQ/Artemis와 Kafka는 둘 다 목적이 있고 그에 따른 정당성이 있습니다. 올바른 사례에 적합한 제품을 선택하려면 차이점을 아는 것이 중요합니다. 다음 표에서는 이러한 차이점을 다시 간략하게 설명합니다.
| 기준 | 액티브 MQ 클래식 | 활성 MQ 아르테미스 | 카프카 |
|---|---|---|---|
| 사용 사례 | 기존 메시징(신뢰성, 트랜잭션) | 분산 이벤트 스트리밍 | |
| P2P 메시징 | Queue | 라우팅 유형이 ANYCAST인 주소 | – |
| PubSub 메시징 | 주제 | 라우팅 유형이 MULTICAST인 주소 | 주제 |
| API/프로토콜 | JMS, AMQP. MQTT, 스톰프, 오픈와이어 | Kafka 클라이언트, AMQP 및 MQTT용 커넥터, JMS 리소스 어댑터 | |
| 풀 기반 및 푸시 기반 메시징 | 푸시 기반 | 풀 기반 | |
| 메시지 전달에 대한 책임 | 생산자는 메시지가 전달되었는지 확인해야 합니다. | 소비자는 소비해야 할 메시지를 소비합니다. | |
| 거래 지원 | JMS, XA | 사용자 정의 트랜잭션 관리자 | |
| 확장성 | 브로커 네트워크 | 클러스터 | 높은 확장성(파티션 및 복제본) |
| 소비자가 많아질수록… | ... 성능이 느려질수록 | ... 속도가 느려지지 않습니다 | |
