이벤트 브로커와 메시지 브로커
제품별 특징과 아키텍처 선정 가이드
Kafka · RabbitMQ · ActiveMQ Artemis · IBM MQ · Solace PubSub+
요청·응답부터 이중화, 성능, 모니터링, 운영과 비용까지
대표 5개 제품 상세 해설 + 최초 소개 제품 전체 목록 별첨
- 01. 메시지 브로커와 이벤트 브로커를 이해하는 기준
- 02. 대표 5개 제품의 위치와 비교 요약
- 03. Apache Kafka — 이벤트를 기록하고 여러 업무가 독립적으로 사용한다
- 04. RabbitMQ — 업무 큐와 라우팅을 중심으로 처리 책임을 분배한다
- 05. Apache ActiveMQ Artemis — Java·JMS 연계와 다중 프로토콜 메시징
- 06. IBM MQ — 기업 시스템 사이의 신뢰성 있는 메시지 전달
- 07. Solace PubSub+ — 이벤트 라우팅과 Event Mesh
- 08. RPC·동기·비동기와 토큰을 정확히 구분한다
- 09. 순서 보장·Exactly-once·재시도와 데이터 정합성
- 10. 이중화·HA·DR·멀티센터 구성의 판단 기준
- 11. 처리 속도와 성능 — 고정 TPS 순위보다 측정 조건이 중요하다
- 12. 성능 모니터링·플러그인·운영 구성
- 13. 아키텍처 선정 기준과 업무 시나리오
- 별첨. 이벤트·메시지·MQTT 브로커 전체 제품 목록
- 참고 자료와 적용 범위
01. 메시지 브로커와 이벤트 브로커를 이해하는 기준
시스템 사이에 데이터를 전달할 때 먼저 결정할 것은 제품명이 아니라 무엇을 전달하고, 언제까지 보관하며, 누가 처리 완료를 책임질 것인가이다. 같은 브로커라도 업무 요청을 한 소비자에게 분배할 수 있고, 이미 발생한 사실을 여러 시스템에 배포할 수도 있다. 메시지 브로커와 이벤트 브로커는 기능이 겹치는 영역이 크므로 서로 완전히 배타적인 제품군으로 이해하면 선정 과정에서 혼란이 생긴다.
| 구분 | 의미 | 보험 업무 예시 |
|---|---|---|
| 메시지(Message) | 시스템 사이에 전달하는 데이터 단위. 명령·이벤트·응답을 모두 담을 수 있다. | 증권 발급 요청, 계약 체결 사실, 발급 결과 |
| 명령(Command) | 특정 업무를 실행해 달라는 요청. 처리 책임과 성공·실패 판단이 필요하다. | IssuePolicy — 증권을 발급하라 |
| 이벤트(Event) | 이미 발생한 업무 사실. 관심 있는 시스템이 각자 후속 행동을 결정한다. | PolicyIssued — 증권이 발급되었다 |
| 응답(Response) | 앞선 요청에 대한 처리 결과 또는 현재 상태. | 발급 완료, 거절, 처리 중 |
명령이 보통 하나의 책임 있는 업무를 향하고 이벤트가 여러 구독자에게 전달되더라도, 이것이 “메시지 브로커는 1:1만 가능하고 이벤트 브로커는 1:N만 가능하다”는 의미는 아니다. RabbitMQ·Artemis·IBM MQ도 발행·구독을 지원하며, Kafka도 소비 그룹을 이용해 작업을 분담한다.
1-1. 실제 비교에 유용한 세 가지 처리 모델
| 처리 모델 | 설계의 중심 | 소비 이후의 데이터 | 대표 제품·기능 |
|---|---|---|---|
| 업무 큐 중심 | 작업 분배, ACK, 재전달, 실패 격리 | 일반적으로 성공 처리한 메시지는 큐에서 제거 | RabbitMQ Queue, Artemis, IBM MQ |
| 이벤트 라우팅 중심 | 토픽·구독·필터를 통한 이벤트 전달 | 비영속 전달 또는 구독별 영속 큐 등 구성에 따라 다름 | Solace Event Broker, NATS, EventBridge |
| 로그·스트리밍 중심 | 기록 보존, 독립 소비, 오프셋·커서 기반 재읽기 | 소비와 별개로 보존 정책에 따라 유지 | Kafka, Pulsar, Redpanda, RabbitMQ Streams, NATS JetStream |
공식 자료 · RabbitMQ Queues · Kafka 설계 · NATS JetStream
02. 대표 5개 제품의 위치와 비교 요약
이 글은 Apache Kafka, RabbitMQ, Apache ActiveMQ Artemis, IBM MQ, Solace PubSub+를 중심으로 살펴본다. 이 다섯 제품은 공식 시장점유율 순위가 아니라, 서로 다른 메시징 요구를 비교하기 위한 대표 후보군이다. ActiveMQ Classic과 Artemis는 별도 구현이므로 상세 설명은 Artemis 기준으로 작성했다.
| 제품 | 가장 먼저 검토할 요구 | 요청·응답 | 운영에서 중요한 대상 |
|---|---|---|---|
| Apache Kafka | 이벤트 보존·재처리, 여러 업무의 독립 소비, 대량 스트리밍 | 요청·응답 토픽과 상관관계 헤더로 구현 | 파티션, 복제 상태, 소비 지연, 보존 용량 |
| RabbitMQ | 업무 큐, 유연한 라우팅, 워커 분배 | Reply-To와 Correlation ID로 구현 | Queue, Ready/Unacked, 소비자, Quorum 상태 |
| Apache ActiveMQ Artemis | Java/JMS 기반 연계, 다중 프로토콜, 트랜잭션 메시징 | JMSReplyTo·JMSCorrelationID 활용 | Address/Queue, Journal, Paging, HA 페어 |
| IBM MQ | 기업 간·기간계 메시지 전달, 기존 MQ 자산, 거래 복구 | MQMD의 MsgId·CorrelId·ReplyToQ 활용 | Queue Manager, 채널, 큐, 로그, HA 상태 |
| Solace PubSub+ | 다양한 프로토콜, 이벤트 라우팅, Event Mesh | API 및 CorrelationID·ReplyTo 활용 | Message VPN, Queue, Spool, 구독, 브로커 연결 |
| 항목 | Kafka | RabbitMQ | Artemis | IBM MQ | Solace |
|---|---|---|---|---|---|
| 기본 제공 형태 | 글로벌 오픈소스 | 글로벌 오픈소스 | 글로벌 오픈소스 | 해외 상용 | 해외 상용·제한된 무료 에디션 등 |
| Java 연계의 중심 | Kafka Client·Spring Kafka | AMQP Client·Spring AMQP | JMS/Jakarta Messaging·Core Client | MQI·JMS | Solace API·JMS 등 |
| 재처리의 중심 | 보존 로그와 오프셋 | 재전달·DLQ / Stream 재읽기 | 재전달·DLQ, 별도 보존 설계 | Rollback·Backout·별도 보존 설계 | 큐 재전달·설정된 Replay 로그 |
| 확장 단위 | 파티션·브로커 | 큐·소비자·노드 | Address/Queue·브로커 | 큐 매니저·큐·채널 | 브로커·서비스 등 구성 단위 |
오픈소스는 라이선스 비용의 구조를 설명할 뿐, 운영비가 없다는 뜻은 아니다. 반대로 상용 제품이 제공하는 기술지원과 운영 도구의 가치도 조직의 인력 구성, 복구 책임, 기존 연계 자산을 함께 놓고 판단해야 한다. 기능·지원 범위는 도입 버전과 에디션에 따라 확인한다.
03. Apache Kafka — 이벤트를 기록하고 여러 업무가 독립적으로 사용한다
3-1. 구조와 특장점
Kafka의 중심은 Topic을 Partition으로 나눈 분산 로그다. 생산자는 레코드를 기록하고, 소비자는 자신의 진행 위치를 관리하며 읽는다. 일반적인 소비 그룹 모델에서는 같은 그룹의 소비자들이 파티션을 나눠 처리하고, 서로 다른 그룹은 같은 기록을 독립적으로 읽을 수 있다. 소비가 끝났다고 원본 기록이 즉시 삭제되는 구조는 아니다.
계약 변경 이벤트를 고객 안내, 검색 색인, 통계, 이상징후 탐지 업무가 각자 읽도록 구성하면, 한 소비 업무의 장애가 다른 업무의 소비 위치를 직접 바꾸지 않는다. 보존 기간 안에 데이터가 남아 있다면 신규 로직을 적용해 재처리할 수 있다는 점이 큰 장점이다. 다만 압축된 토픽은 키별 과거 이력이 모두 남는 것이 아니며, 보존 기간이 지난 기록은 다시 읽을 수 없다.
3-2. RPC와 요청·응답 식별자
Kafka 위에서도 요청·응답 패턴을 만들 수 있다. 요청 토픽과 응답 토픽을 두고 상관관계 ID, 응답 토픽, 필요하면 응답 파티션을 헤더에 넣는다. Spring Kafka의 ReplyingKafkaTemplate은 이러한 패턴의 구현을 돕는다. 다만 이것은 Kafka를 이용한 애플리케이션 패턴이며, 브로커가 외부 업무 함수를 직접 호출해 결과까지 보장하는 기능은 아니다.
응답을 기다리는 클라이언트가 여러 인스턴스라면 응답이 실제 요청 대기자에게 도착하도록 소비 그룹과 파티션을 설계해야 한다. 요청마다 토픽을 만드는 방식은 메타데이터·운영 부담을 키우므로 피하고, 대기 요청 수·타임아웃·늦게 도착한 응답의 처리 정책을 명확히 한다.
3-3. 이중화와 확장
데이터는 파티션별 리더와 복제본으로 보호하며, KRaft 컨트롤러 쿼럼은 클러스터 메타데이터를 관리한다. 컨트롤러 쿼럼과 데이터 복제는 서로 다른 보호 계층이다. 브로커를 여러 대 설치했다는 사실만으로 모든 토픽의 복제가 충분한 것은 아니다.
- 검토 출발점: 복제 계수 3,
acks=all,min.insync.replicas=2. 실제 값은 장애 허용 수준과 처리량에 맞춰 결정한다. - ISR 부족 시 쓰기가 거절될 수 있다. 이는 데이터 보호를 위해 가용성을 제한하는 동작이므로 애플리케이션의 재시도·유입 제어가 필요하다.
- 일반 소비 그룹에서 소비 병렬성은 파티션 수의 영향을 받는다. 특정 계약 키에 부하가 몰리면 노드를 추가해도 해당 파티션의 병목은 남는다.
- 원격 센터 복제는 MirrorMaker 2 등의 별도 구조로 설계한다. 센터 간 네트워크와 복제 지연을 포함해 RPO/RTO를 검증한다.
3-4. 처리 성능의 특성
배치 전송, 압축, 순차 로그 기록, 파티션 병렬화는 많은 이벤트를 연속 처리할 때 유리하다. 반면 배치를 더 모으는 설정은 대기 시간을 늘릴 수 있다. 작은 단건 요청을 즉시 응답받는 업무와 대량 이벤트를 묶어 전송하는 업무는 최적 설정이 다르다. 처리량은 batch.size, linger.ms, 압축 방식, 메시지 크기, 복제, 디스크·네트워크의 영향을 함께 받는다.
3-5. 모니터링과 확장 생태계
| 구성 | 역할 | 운영 시 확인 |
|---|---|---|
| JMX + Prometheus JMX Exporter + Grafana | 브로커·클라이언트 지표 수집과 시각화 | ISR 변화, 오프라인 파티션, 요청 지연, 디스크 용량 |
| 소비 지연 수집기·관리 UI | 그룹별 진행 위치와 지연 파악 | 레코드 수뿐 아니라 가장 오래 지연된 이벤트의 시간 |
| Kafka Connect | 외부 시스템 Source/Sink 연결 | 커넥터·태스크 장애, 재시도, DLQ, 별도 라이선스 |
| Kafka Streams | 애플리케이션 안에서 스트림 처리 | 상태 저장소, 재처리 시간, 애플리케이션 처리 지연 |
| Schema Registry 등 외부 구성요소 | 메시지 스키마와 호환성 관리 | Kafka 코어 기본 기능과 별도 제품·라이선스 구분 |
Kafka에 어울리는 대표 요구는 CDC 데이터 전달, 다수 소비자가 활용하는 업무 이벤트, 로그 수집, 재처리가 필요한 분석 연계다. 반대로 모든 화면 조회를 Kafka 요청·응답으로 바꾸면 응답 라우팅과 지연 관리 비용이 커질 수 있다.
공식 자료 · Kafka 설계 · 토픽·복제 설정 · 생산자 설정 · Kafka 문서 · Spring 요청·응답 API
04. RabbitMQ — 업무 큐와 라우팅을 중심으로 처리 책임을 분배한다
4-1. 구조와 특장점
RabbitMQ의 AMQP 0-9-1 모델에서는 생산자가 Exchange로 메시지를 보내고, Binding과 Routing Key에 따라 Queue에 메시지가 전달된다. Direct·Topic·Fanout·Headers Exchange를 활용해 목적지와 업무별 라우팅을 구성한다. 하나의 큐에 여러 워커를 연결하면 작업을 나눌 수 있고, 업무마다 큐를 두면 동일 이벤트를 독립적으로 처리할 수 있다.
통지 발송, 문서 변환, 이미지 처리, 비동기 업무 요청처럼 “처리할 일”을 분배하는 용도에 이해하기 쉬운 구조다. Consumer ACK를 통해 처리가 끝나지 않은 메시지를 추적할 수 있으며, 재전달·Dead Letter 구성을 통해 실패를 관리한다.
4-2. RPC와 토큰
요청에는 reply_to와 correlation_id를 넣고, 처리자는 같은 상관관계 값을 담아 응답 목적지로 결과를 보낸다. 요청자가 기다리는 대상을 식별하는 값이지, 로그인 권한을 검증하는 인증 토큰은 아니다.
Direct Reply-To는 실제 응답 큐를 만들지 않고 응답을 전달하는 방식이다. 응답 전달이 at-most-once이므로 요청자의 연결이 끊기는 등의 상황에서 응답이 유실될 수 있다. 응답 보관이나 재수신이 필요하면 별도 응답 큐와 수명·ACK 정책을 검토한다.
4-3. 클러스터와 Quorum Queue
RabbitMQ 클러스터 구성과 메시지 복제는 같은 의미가 아니다. 일반 Classic Queue가 클러스터 안의 모든 노드에 자동 복제되는 것으로 이해하면 안 된다. 지속성과 복제가 필요한 업무 큐는 Raft 기반 Quorum Queue를 우선 검토할 수 있다. 예를 들어 큐 멤버 3개 중 과반이 가동되어야 해당 큐의 서비스를 유지할 수 있다.
노드 수와 큐별 복제 멤버 수는 구분한다. 노드가 추가되었을 때 기존 큐의 멤버 배치가 기대대로 조정되는지도 확인해야 한다. 원격 센터 연결용 Federation·Shovel은 로컬 Quorum 복제와 역할이 다르며, WAN 위에 하나의 클러스터를 무조건 확장하는 설계는 지연과 네트워크 분리 시 동작을 검토해야 한다.
4-4. 성능과 흐름 제어
Publisher Confirm은 생산자 관점의 수락 확인이며 Consumer ACK와 별개다. 영속 큐, 메시지 영속성, 복제, Confirm, ACK를 일관되게 설정한 상태로 측정해야 업무 신뢰성과 성능을 함께 판단할 수 있다. Prefetch가 너무 작으면 워커가 충분히 일하지 못하고, 너무 크면 Unacked 메시지와 메모리 점유가 늘어나 작업 편중이 발생할 수 있다.
큐를 여러 개로 나누고 소비자를 늘리는 방식으로 병렬성을 확보하되 외부 DB와 API의 허용 처리량을 넘지 않도록 한다. Stream은 일반 큐와 다른 로그형 모델이므로 장기 보존·다중 독립 소비 요구가 있다면 별도로 비교한다.
4-5. 모니터링과 플러그인
| 구성 | 용도 | 확인할 점 |
|---|---|---|
| rabbitmq_management | 관리 UI·HTTP API | 큐, 연결, 채널, 소비자 현황 |
| rabbitmq_prometheus | Prometheus 지표 제공 | Ready/Unacked, 발행·전달·ACK 속도, 디스크·메모리 경보 |
| Federation / Shovel | 브로커 간 메시지 연계 | 링크 장애, 적체, 중복 가능성과 루프 방지 |
| MQTT / STOMP 플러그인 | 추가 프로토콜 수용 | 프로토콜별 세션·QoS·ACK 의미의 차이 |
| 지연 메시징 관련 확장 | 예약·지연 전달 구성 | 서드파티 또는 별도 플러그인의 유지보수·버전 호환성 확인 |
공식 자료 · Quorum Queues · 클러스터 · Direct Reply-To · 모니터링
05. Apache ActiveMQ Artemis — Java·JMS 연계와 다중 프로토콜 메시징
5-1. Classic과 Artemis를 구분한다
ActiveMQ Classic과 Artemis는 구성 파일·저장소·클러스터·운영 방식이 다른 브로커다. Classic 환경의 설정이나 운영 경험을 Artemis에 그대로 적용해서는 안 된다. 문서와 배포 명칭에는 Apache ActiveMQ Artemis 또는 Apache Artemis가 보일 수 있으므로, 실제 도입 버전과 배포본을 기준으로 확인한다.
Artemis는 Address와 Queue를 분리하며 Anycast와 Multicast 라우팅 모델을 제공한다. JMS/Jakarta Messaging 기반 Java 업무뿐 아니라 AMQP·MQTT·STOMP·OpenWire 등의 프로토콜 연계도 검토할 수 있다. JMS는 Java API 표준이고 AMQP는 통신 프로토콜이므로 서로 같은 분류가 아니다.
5-2. 요청·응답과 트랜잭션
JMS 클라이언트에서는 JMSReplyTo로 응답 목적지를 지정하고 JMSCorrelationID로 요청과 응답을 연결한다. Temporary Queue를 활용할 수 있지만 연결 종료 후 복구해야 하는 응답까지 보관해야 한다면 영속 목적지를 별도로 설계한다. 동시 요청이 많을 때는 응답 선택자와 큐 공유 방식이 처리량에 미치는 영향도 측정한다.
JMS 트랜잭션과 XA 연계를 사용할 수 있으나, 선택한 클라이언트·프로토콜·트랜잭션 매니저의 지원 범위를 확인해야 한다. XA를 켰다는 사실만으로 외부 HTTP API나 모든 부수 효과까지 하나의 원자적 거래가 되지는 않는다.
5-3. HA와 클러스터
HA는 Primary/Backup 페어와 Shared Store 또는 Replication 방식으로 구성한다. Shared Store는 저장소 가용성이 중요하고, Replication은 복제 통신과 분리 상황에서 어느 노드가 활성화될지 판단하는 구성이 중요하다. 복제 페어 두 대만 두고 네트워크 분리 시 안전하게 동작한다고 가정해서는 안 된다. Quorum 또는 지원되는 Lock Manager 구성을 함께 확인한다.
클러스터의 부하 분산과 HA 페어의 장애 대체는 다른 목적이다. 여러 활성 브로커에 업무를 나누면서 각 활성 브로커를 백업으로 보호할 수 있다. 장애 시 클라이언트 재접속, 진행 중 트랜잭션의 결과, 중복 수신까지 함께 검증한다.
5-4. 성능과 저장소
Journal 기록 성능, 동기화 정책, 큰 메시지 처리, Paging 여부가 성능에 영향을 준다. Paging은 메모리 한도를 넘은 메시지를 디스크로 넘기는 장치이지만 무한 적체를 해결하는 수단은 아니다. 디스크 한도와 소비 처리율을 함께 관리해야 한다. 메시지 그룹을 이용한 업무 키 단위 순서 유지도 특정 그룹의 병목을 만들 수 있다.
5-5. 모니터링과 확장
| 구성 | 용도 | 운영 지표 |
|---|---|---|
| 관리 콘솔·JMX·Jolokia | 브로커·Address·Queue 조회와 제어 | Message Count, Delivering Count, Consumer Count |
| Micrometer 기반 Metrics Plugin | 모니터링 시스템에 메트릭 연결 | 메모리·디스크·주소별 메시지 상태 |
| Prometheus 연동 플러그인 또는 JMX Exporter | Prometheus·Grafana 통합 | 배포본에 포함된 것과 추가 설치할 것을 구분 |
| Broker Plugin·Interceptor | 감사·정책·확장 로직 | 브로커 처리 경로의 지연·예외·호환성 |
기존 Java 업무가 JMS API에 깊게 의존하고 다중 프로토콜과 트랜잭션 메시징을 함께 요구한다면 검토 가치가 있다. JEUS·WebLogic 등 WAS와 연계할 때는 JMS 버전, javax.jms/jakarta.jms 패키지, JCA Resource Adapter, XA 복구 호환성을 별도로 확인한다.
공식 자료 · Artemis 사용자 설명서 · HA·Failover · Metrics · 클러스터
06. IBM MQ — 기업 시스템 사이의 신뢰성 있는 메시지 전달
6-1. 구조와 특장점
IBM MQ는 Queue Manager가 큐와 메시지를 관리하고, 채널을 통해 원격 큐 매니저 및 클라이언트와 연결하는 기업용 메시징 제품이다. 기존 기간계·대외계에 축적된 MQ 인터페이스, 거래 복구 체계, 운영 절차와 함께 평가하는 경우가 많다. 포인트 투 포인트 외에 Pub/Sub도 지원한다.
메시지 영속성, 로그, 트랜잭션, 채널 상태를 함께 관리해 장애 후 거래를 복구하도록 설계한다. 안정성은 제품명 자체가 아니라 Persistent 설정, Commit 경계, 로그·저장소 보호, 클라이언트 오류 처리까지 포함한 전체 구성에서 나온다.
6-2. Request-Reply와 MQMD
요청·응답 패턴에서는 MsgId, CorrelId, ReplyToQ, ReplyToQMgr가 핵심이다. 대표적으로 응답의 CorrelId에 요청의 MsgId를 넣어 대응 관계를 만든다. 사용자 정의 상관관계 값을 유지하는 경우에는 송수신 규약을 명확히 한다. MQI의 식별자 표현과 JMS 매핑을 문자열 그대로 같다고 가정하지 않도록 주의한다.
업무 거래번호는 MQ 기술 식별자와 분리해 관리하는 편이 유용하다. 재전송 과정에서 기술 메시지가 달라지더라도 동일한 업무를 중복 실행하지 않도록 거래번호나 멱등 키를 유지해야 하기 때문이다.
6-3. HA 구성과 MQ 클러스터의 차이
| 구성 | 주된 목적 | 설계 확인 사항 |
|---|---|---|
| Multi-instance Queue Manager | 공유 저장소 기반 활성·대기 전환 | 파일시스템의 잠금·가용성·지원 조건 |
| RDQM | 복제 데이터 큐 매니저를 통한 HA/DR 구성 | 지원 Linux 환경, 복제와 장애 판단, 운영 권한 |
| Native HA | 큐 매니저 복제본 사이의 로그 복제로 HA 제공 | 버전·플랫폼·라이선스 및 Operator 지원 범위 |
| MQ Cluster | 여러 큐 매니저의 연결·워크로드 라우팅 단순화 | 하나의 큐 메시지를 모든 큐 매니저에 자동 복제하는 기능이 아님 |
예를 들어 Native HA의 활성 1개·대기 2개 복제본 구성과 여러 큐 매니저를 묶은 MQ 클러스터는 서로 다른 계층이다. 두 방식을 결합할 수 있지만, 메시지가 어느 큐 매니저에 있는지와 장애 후 누가 해당 데이터를 이어받는지를 명확하게 설명할 수 있어야 한다.
6-4. 성능과 거래 보장
Persistent 메시지와 Syncpoint 사용 시 로그 기록·Commit 비용이 중요하다. Commit을 배치로 묶으면 처리량을 높일 수 있지만 실패 시 재처리 범위와 거래 지연이 커진다. 메시지 크기, 채널 수, 동시 연결, 암호화, 디스크 지연을 실제 거래 패턴에 맞춰 측정해야 한다. “상용 MQ이므로 느리다” 또는 “금융권 제품이므로 유실이 없다”는 식의 단정은 모두 부정확하다.
6-5. 모니터링과 운영 도구
MQ Console·MQ Explorer 등 관리 도구와 MQSC/PCF·상태·통계 정보를 활용한다. Prometheus 연계에는 IBM의 mq-metric-samples가 제공하는 수집기 예제를 검토할 수 있다. 수집기 예제는 배포·권한·운영 책임까지 자동으로 제공하는 관리형 서비스가 아니다.
- 큐 깊이와 증가 속도, 가장 오래 대기한 메시지의 나이, 입출력 핸들 수를 본다.
- 채널의 Running·Retrying·Stopped 상태와 전송 큐 적체를 확인한다.
- 로그 공간·파일시스템 사용량·HA 복제 상태를 경보와 연결한다.
- Dead Letter Queue와 Backout Queue는 목적이 다르다. 업무 처리 실패를 무조건 DLQ로만 설명하지 않는다.
공식 자료 · MQMD 필드 · HA 구성 · Native HA · IBM 지표 수집기
07. Solace PubSub+ — 이벤트 라우팅과 Event Mesh
7-1. 구조와 특장점
Solace PubSub+로 알려진 Event Broker 제품군은 토픽 기반 이벤트 라우팅과 여러 메시징 패턴·프로토콜을 결합한다. 소프트웨어 브로커·어플라이언스·클라우드 서비스 등 제공 형태가 있으며, 구체적인 용량과 기능은 에디션에 따라 다르다. Message VPN은 브로커 안의 논리적 메시징 분리 단위다.
토픽 구독을 영속 큐에 연결하면 생산자는 이벤트 토픽으로 발행하고, 각 업무는 자신의 큐에서 후속 처리를 진행할 수 있다. Event Mesh는 여러 브로커를 연결해 이벤트를 필요한 위치로 라우팅하는 구성이다. 브로커를 연결한 것과 모든 이벤트의 원격 복제·보관을 보장한 것은 구분해야 한다.
7-2. Direct와 Guaranteed
| 방식 | 특성 | 설계 관점 |
|---|---|---|
| Direct Messaging | 영속 저장을 전제로 하지 않는 낮은 지연의 전달 | 실시간 갱신·일시 데이터 등에서 유실 허용 여부 판단 |
| Guaranteed Messaging | 큐·Spool·ACK 기반의 메시지 보관 및 전달 | 오프라인 소비자, 업무 메시지 복구, 저장소·쿼터 관리 |
| Message Replay | 설정된 Replay 로그를 이용한 재전달 | 기능·보존·용량 설정 필요. 모든 메시지가 영구 보존되는 것은 아님 |
7-3. Request-Reply
API와 메시지의 ReplyTo·CorrelationID를 활용해 요청·응답을 구성할 수 있다. Guaranteed 메시지를 사용할 때에도 요청과 응답을 연결하는 규약과 애플리케이션 처리가 필요하다. 응답 목적지의 구독이나 큐가 준비되기 전에 요청을 보내면 경합이 생길 수 있으므로 시작 순서를 검증한다.
7-4. HA와 멀티센터
소프트웨어 브로커의 대표적인 HA Redundancy Group은 Primary·Backup·Monitor 노드로 구성한다. Monitor는 장애 판단을 돕는 역할이며 데이터 처리 브로커 한 대가 더 생기는 것과는 다르다. 어플라이언스와 관리형 서비스는 배포 형태별 구성을 확인한다.
센터 간 Event Mesh 연결, 로컬 HA, DR 복제는 각각 역할과 장애 범위가 다르다. 원격 센터 단절 시 구독·큐·복제 상태가 어떻게 달라지는지, 복구 후 어떤 이벤트가 다시 전달되는지까지 검증해야 한다.
7-5. 성능·모니터링·연계
토픽 라우팅과 다양한 프로토콜의 통합이 강점이다. 성능은 Direct/Guaranteed 구분, 메시지 크기, 구독 수, 팬아웃, Spool 기록, HA 복제, 브로커 간 링크에 좌우된다. Direct 측정값을 Guaranteed 성능으로 인용해서는 안 된다.
| 구성 | 역할 | 확인 항목 |
|---|---|---|
| Broker Manager·SEMP API | 브로커 설정·관리·상태 조회 | Message VPN, 큐, 클라이언트, 구독 |
| SEMP 기반 Exporter·관측 연계 | Prometheus 등 외부 모니터링 통합 | Spool 사용률, 큐 적체, 폐기·거절, 링크 상태 |
| Solace Insights 등 서비스 | 메트릭·로그 관측 지원 | 구독·에디션·지원 범위 |
| 분산 추적·OpenTelemetry 연계 | 이벤트 경로와 지연 관측 | 브로커·클라이언트 버전과 추적 비용 |
| Kafka 등 외부 연계 구성요소 | 서로 다른 이벤트 환경 연결 | 헤더·스키마·순서·전달 보장의 매핑 |
공식 자료 · 전달 모드 · Message Replay · Request-Reply · HA 그룹 구성 · HA 모니터링 · 분산 추적
08. RPC·동기·비동기와 토큰을 정확히 구분한다
8-1. 브로커 기반 요청·응답은 가능하지만 시간적 결합은 남는다
브로커가 메시지를 중계하더라도 호출자가 응답을 기다리면 해당 업무 흐름은 동기적 성격을 가진다. 반대로 HTTP를 사용하더라도 접수 번호를 반환하고 나중에 상태를 확인하도록 만들면 업무 흐름은 비동기적일 수 있다. 통신 기술과 업무 완료 방식을 구분해야 한다.
| 패턴 | 흐름 | 적합한 상황 | 추가 책임 |
|---|---|---|---|
| 즉시 요청·응답 | 요청 후 제한 시간 안에 결과 대기 | 화면 즉시 결과, 짧은 조회·검증 | 타임아웃, 동시 대기 한도, 응답 라우팅 |
| 비동기 명령 | 접수 후 워커가 나중에 실행 | 문서 발급·통지·장시간 작업 | 접수 상태와 완료 상태 구분 |
| 이벤트 발행·구독 | 완료된 사실을 독립 업무에 전달 | 계약 체결 후 검색·통지·분석 | 소비자별 실패 처리와 최종 정합성 |
8-2. “토큰”이라는 말에 섞이기 쉬운 네 가지 값
| 식별자 | 역할 | 운영 규칙 |
|---|---|---|
| Correlation ID | 어떤 요청에 대한 응답인지 식별 | 요청·응답 사이에서 규약대로 전달 |
| Reply-To | 응답을 받을 목적지 | 허용 목적지·수명·권한·소유 인스턴스 관리 |
| Idempotency Key / 업무 거래번호 | 재시도가 같은 업무인지 식별 | 동일 업무 재시도에서 유지하고 처리 결과와 함께 저장 |
| 인증 토큰·자격 증명 | 접속 주체와 권한 검증 | TLS, 인증 설정, 만료·재발급, 최소 권한 적용 |
| Trace ID | 여러 서비스에 걸친 실행 경로 추적 | Correlation ID와 구분 가능하며 추적 시스템과 연계 |
Correlation ID를 알고 있다고 메시지를 읽거나 응답을 보낼 권한이 생기는 것은 아니다. 또한 인증 토큰을 메시지 본문에 넣었다고 브로커가 자동으로 검증하는 것도 아니다. 토큰 인증 지원은 제품·버전·프로토콜·플러그인별 접속 인증 설정으로 확인하고, 이벤트에는 필요 이상의 자격 증명을 실어 보내지 않는다.
8-3. 요청·응답 공통 처리 규약
09. 순서 보장·Exactly-once·재시도와 데이터 정합성
9-1. 순서는 전달 순서와 업무 완료 순서로 나눈다
브로커가 순서대로 전달하더라도 소비자가 여러 스레드에서 병렬 처리하거나 외부 API가 서로 다른 시간에 완료되면 업무 반영 순서가 바뀔 수 있다. 전체 메시지의 단일 순서가 필요한지, 계약번호·고객번호별 순서만 필요한지부터 결정한다.
| 제품·모델 | 주로 검토할 순서 범위 | 주의할 부분 |
|---|---|---|
| Kafka 일반 소비 그룹 | 파티션 안의 레코드 순서 | 키 분배, 생산자 설정, 소비 병렬화, Retry Topic |
| RabbitMQ Queue | 큐에서의 전달과 소비 방식 | 다중 소비자·재전달·우선순위가 처리 순서에 영향 |
| Artemis | 큐·Message Group 등 | 그룹 키와 소비자 연결, 장애 후 재전달 |
| IBM MQ | 큐·메시지 그룹·애플리케이션 규약 | 우선순위·선택 수신·병렬 처리·Rollback |
| Solace | 큐 접근 방식·흐름·업무 키 설계 | 다중 소비자·재전달·여러 발행 경로 |
9-2. Exactly-once는 보장 범위를 먼저 확인한다
Kafka의 트랜잭션은 Kafka 내부 읽기·처리·쓰기 흐름의 exactly-once 구성을 지원하지만, 외부 Oracle DB 갱신·HTTP 요청·알림톡 발송까지 자동으로 하나의 거래에 묶지 않는다. JMS/XA를 지원하는 제품도 참여 자원과 트랜잭션 매니저가 지원하는 범위 안에서 동작한다.
업무에서는 중복 전달이 발생해도 최종 효과가 한 번만 반영되도록 만드는 멱등성이 중요하다. 브로커의 전달 보장과 애플리케이션의 업무 정합성을 따로 정의해야 한다. 메시지를 받자마자 ACK하고 나중에 DB에 저장하면 장애 시 누락될 수 있고, DB 저장 후 ACK 전에 장애가 나면 중복 전달될 수 있다.
9-3. Outbox와 Inbox를 통한 경계 관리
- Outbox: 업무 DB 변경과 발행할 이벤트 기록을 같은 로컬 트랜잭션으로 저장한다. 별도 발행기 또는 CDC가 Outbox를 전달한다. 발행 과정의 중복 가능성은 남는다.
- Inbox·멱등 처리: 소비자는 이벤트 ID·업무 키의 처리 이력을 업무 변경과 같은 트랜잭션으로 반영한다. 중복 키 제약이나 원자적 상태 전이로 동시 중복을 제어한다.
- 외부 API: 상대가 제공하는 멱등 키를 활용하거나 상태 조회·대사·보상 절차를 둔다. 로컬 DB만으로 상대 시스템의 부수 효과까지 원자적으로 제어할 수는 없다.
9-4. 재전달, 재시도, 재생은 서로 다르다
| 용어 | 의미 | 운영 판단 |
|---|---|---|
| Redelivery | ACK 누락·Rollback 등으로 동일 메시지를 다시 전달 | 일시적 실패인지, 반복 불가능 오류인지 분류 |
| Retry | 정책에 따라 업무 실행을 다시 시도 | 횟수·간격·지수 백오프·지터·전체 기한 설정 |
| DLQ / 오류 격리 | 정상 경로에서 처리할 수 없는 메시지 분리 | 담당자·사유·보정·재투입 승인·보관 기간 정의 |
| Replay | 보존된 과거 데이터를 다시 읽어 후속 상태를 재구성 | 재알림·재정산 같은 부수 효과를 통제 |
실패한 메시지를 즉시 무제한 재투입하면 브로커와 DB에 재시도 폭주가 생긴다. 순서가 필요한 업무에서 특정 메시지를 Retry Topic이나 별도 큐로 빼면 뒤 메시지가 먼저 반영될 수 있으므로 업무 버전 번호·순서 검증·계약별 직렬화 등으로 보완한다.
공식 자료 · Kafka 전달 의미 · Kafka 전달 보장 해설
10. 이중화·HA·DR·멀티센터 구성의 판단 기준
이중화는 “서버 두 대”라는 수량이 아니라 어떤 장애를 견딜 수 있는지로 정의한다. 분산 합의가 필요한 제품은 오히려 세 개 이상의 투표 구성원이 요구되거나 유리하다. 반대로 Active/Standby 구조는 저장소와 장애 판단 계층까지 보호되어야 한다.
| 구분 | 해결하려는 문제 | 확인할 내용 |
|---|---|---|
| 부하 분산 | 처리량과 병렬성 확보 | 큐·파티션·키별 병목, 소비자 증설 효과 |
| 로컬 HA | 노드·프로세스·장비 장애 대응 | 데이터 복제, Quorum, 클라이언트 재연결 |
| DR | 센터·리전 단위 장애 대응 | 원격 복제, RPO/RTO, 전환 권한, 복귀 절차 |
| 멀티센터 Active/Active | 여러 지역에서 동시에 업무 처리 | 업무 소유권, 키 분배, 충돌·중복·순서·루프 |
| 백업·복구 | 오삭제·손상·설정 오류 복구 | 복제만으로 보호되지 않는 오류와 복원 시험 |
| 제품 | 로컬 HA의 중심 | 센터 간 구성의 검토 방향 |
|---|---|---|
| Kafka | 파티션 복제 + KRaft 메타데이터 쿼럼 | 별도 클러스터 복제, 소비 위치·스키마·권한 동기화 |
| RabbitMQ | Quorum Queue·Stream 복제 | Federation·Shovel 등 별도 연결과 중복·지연 관리 |
| Artemis | Primary/Backup + Shared Store 또는 Replication | 브리지·별도 DR와 저장소·네트워크 분리 검토 |
| IBM MQ | Multi-instance·RDQM·Native HA 중 환경에 맞는 방식 | 지원 DR 방식과 원격 큐 매니저·채널 경로 설계 |
| Solace | 배포 형태에 맞는 HA Redundancy | DR 복제와 Event Mesh 라우팅을 구분해 설계 |
RPO는 장애 시 허용 가능한 데이터 손실 구간이고, RTO는 복구 목표 시간이다. 원격 비동기 복제를 사용하면서 조건 없이 RPO 0을 약속해서는 안 된다. 또한 브로커가 복구됐더라도 애플리케이션 재접속·상태 확인·적체 해소가 끝나지 않으면 업무 복구는 완료되지 않는다.
- 브로커 프로세스 강제 종료, 노드 다운, 저장소 장애, 네트워크 분리를 구분해 시험한다.
- 장애 전 생산자에게 성공으로 확인된 메시지의 유실·중복을 업무 키 기준으로 검사한다.
- Failover 도중 응답 대기 요청과 진행 중 트랜잭션의 결과를 확인한다.
- DR 전환 후 기존 센터가 살아났을 때 이중 처리를 막는 Fencing·업무 소유권 정책을 둔다.
- 복구 직후 재처리 물량이 실시간 거래를 압도하지 않도록 제한 속도와 우선순위를 정한다.
11. 처리 속도와 성능 — 고정 TPS 순위보다 측정 조건이 중요하다
제품마다 초당 수십만·수백만 건 같은 수치가 소개되지만 메시지 크기, 영속성, 복제 수, 팬아웃, 장비, 압축, TLS, 확인 방식이 다르면 직접 비교할 수 없다. 영속·복제 메시지를 처리한 수치와 메모리에서만 전달한 수치를 같은 성능표에 놓지 않는다. 이 글은 동일 조건의 실측을 수행하지 않았으므로 제품별 고정 TPS 순위를 제시하지 않는다.
11-1. 분리해서 측정할 네 가지 성능
| 지표 | 정의 | 놓치기 쉬운 점 |
|---|---|---|
| 수락 처리량 | 브로커가 확인한 발행량: msg/s·MB/s | ACK·Confirm·Commit 시점이 제품마다 다름 |
| 업무 완료 처리량 | DB·외부 작업까지 성공한 업무 건수 | 발행량보다 소비 처리율이 낮으면 계속 적체 |
| 종단 지연 | 생산 시점부터 업무 완료까지 걸린 시간 | 평균뿐 아니라 p95·p99·최대값 측정 |
| 복구 성능 | 장애 후 정상 처리 및 적체 해소까지의 시간 | 브로커 재기동 시간만 측정하면 부족 |
11-2. 제품별 주요 튜닝 지점
| 제품 | 주요 조절 지점 | 부작용·상충 관계 |
|---|---|---|
| Kafka | 배치·압축·파티션·동시 요청·복제 | 배치 지연, 특정 키 쏠림, 메타데이터·재균형 부담 |
| RabbitMQ | Prefetch·큐 분할·Confirm 배치·소비자 수 | Unacked 증가, 메시지 편중, 외부 시스템 과부하 |
| Artemis | Journal·Paging·소비 윈도우·트랜잭션 크기 | 디스크 I/O 증가, 재처리 범위 확대 |
| IBM MQ | Commit 빈도·채널·Persistent·연결 재사용 | 지연·복구 범위와 처리량의 균형 |
| Solace | Direct/Guaranteed·구독·팬아웃·Spool·연결 수 | 보장 수준과 저장·복제 비용의 차이 |
11-3. 실무 PoC 시험 설계 예시
아래는 제품 성능값이 아니라 시험 조건 예시다. 기준 부하는 동일하게 두고, 각 제품이 같은 업무 보장 수준을 충족하도록 설정한다. 실행 전에는 버전·하드웨어·OS·스토리지·네트워크·클라이언트 설정을 기록한다.
| 항목 | 시험 조건 예시 |
|---|---|
| 메시지 크기 | 1 KB / 10 KB / 100 KB + 실제 업무 전문 |
| 전달 모델 | 업무 큐 / 구독자 5개의 팬아웃 / 독립 소비·재생을 분리 |
| 저장·복제 | 비영속 기준선과 영속·HA 운영 조건을 각각 측정 |
| 부하 패턴 | 평상시, 피크, 급증, 소비자 중단, 복구 후 재처리 |
| 부하 단계 | 목표의 50%·100%·150%에서 지연·적체·오류율 관찰 |
| 장애 | 노드 종료, 네트워크 분리, 디스크 부족, 소비자 재시작 |
| 성공 기준 | 목표 지연·처리량, 확인된 메시지 유실 여부, 멱등 처리, 복구시간 |
| 대사 | 생산·수락·수신·완료·실패·중복 건수를 업무 키로 비교 |
11-4. 용량과 적체를 계산하는 방법
기본 저장량 ≈ 초당 입력량 × 평균 메시지 크기 × 보존 시간 × 복제 계수
추가 고려: 헤더·인덱스·로그·압축률·팬아웃별 저장 방식·운영 여유
적체 증가율 ≈ 입력 속도 − 실제 처리 속도
적체 해소 시간 ≈ 적체 건수 ÷ (복구 후 처리 속도 − 현재 입력 속도)
※ 복구 후 처리 속도가 현재 입력 속도보다 높을 때만 해소 가능예를 들어 100만 건이 쌓였고 복구 후 처리 속도가 초당 5,000건, 새 입력이 초당 3,000건이라면 단순 계산상 약 500초가 필요하다. 실제로는 DB 경합과 외부 호출 지연 때문에 더 오래 걸릴 수 있다. 평균값만 보지 말고 가장 오래된 메시지의 대기 시간과 SLA 위반 업무를 함께 본다.
12. 성능 모니터링·플러그인·운영 구성
12-1. 모니터링은 세 계층으로 구성한다
| 계층 | 관측 대상 | 장애 판단 예시 |
|---|---|---|
| 인프라·브로커 | CPU·메모리·GC·디스크·네트워크·복제·쿼럼 | 저장소 지연, 복제 불능, 노드 장애 |
| 메시징 흐름 | 발행·전달·ACK·Lag·Queue Depth·최고 대기 시간 | 소비자 정지, 재시도 폭주, 응답 누락 |
| 업무 결과 | 성공·거절·중복·누락·미완료·대사 | 브로커는 정상인데 계약 발급이 멈춤 |
브로커 프로세스가 살아 있고 포트가 열려 있어도 실제 업무는 멈출 수 있다. 시험 메시지를 발행하고 소비·응답까지 확인하는 합성 거래를 별도로 운영하면 단순 헬스 체크가 놓치는 장애를 탐지하는 데 도움이 된다.
12-2. 제품별 모니터링 구성 예시
| 제품 | 수집 경로 | 우선 경보 |
|---|---|---|
| Kafka | JMX → JMX Exporter → Prometheus·Grafana / 소비 그룹 지연 수집 | 복제 이상, 오프라인 파티션, Lag 시간, 디스크 부족 |
| RabbitMQ | rabbitmq_prometheus → Prometheus·Grafana / Management API | Ready·Unacked 급증, 소비자 0, 메모리·디스크 Alarm |
| Artemis | Micrometer Metrics Plugin 또는 JMX Exporter → 모니터링 | Paging 급증, Queue Count 증가, HA 전환 실패 |
| IBM MQ | MQ 지표 수집기·상태·통계 → Prometheus 또는 상용 관측 도구 | 채널 중단, 전송 큐 적체, 로그 공간 부족 |
| Solace | SEMP 기반 수집 또는 제공 관측 서비스 → 모니터링 | Spool 포화, 메시지 거절·폐기, HA·링크 이상 |
12-3. 플러그인·Exporter·Connector를 구분한다
- 브로커 플러그인: 브로커 기능을 확장한다. 설치 버전·보안 패치·실행 경로의 성능 영향을 검토한다.
- Exporter: 지표를 수집해 노출한다. 수집 권한·주기·대상 수에 따라 브로커 부하가 늘 수 있다.
- Connector: 시스템 사이에서 데이터를 이동한다. 재시도·오프셋·DLQ·중복·스키마 호환성까지 운영 대상이다.
- 관리 UI: 운영자가 상태를 확인하고 설정을 바꾼다. 읽기 권한과 삭제·재투입 같은 변경 권한을 분리한다.
지표 라벨에 메시지 ID나 고객번호를 넣으면 시계열 개수가 폭증하고 민감한 값이 모니터링 저장소에 남을 수 있다. 세부 거래 추적은 로그·트레이스에 두고, 메트릭은 시스템·업무 유형·큐·토픽 등 관리 가능한 단위로 집계한다.
12-4. 경보와 운영 절차를 연결한다
| 증상 | 우선 확인 | 조치 방향 |
|---|---|---|
| 적체 증가 | 유입 증가인지 소비 처리율 저하인지 | 원인에 따라 유입 제한·소비자 증설·DB 병목 해소 |
| Unacked·처리 중 증가 | 느린 외부 호출·스레드 고갈·ACK 누락 | 타임아웃·동시성·ACK 시점 점검 |
| DLQ·오류 격리 증가 | 스키마 오류·업무 데이터·권한 오류 | 무조건 재투입하지 말고 원인 보정 후 제한 재처리 |
| 저장 공간 부족 | 보존 정책·Replay·미소비 구독·로그 | 삭제 영향 확인 후 용량 확장·보존 조정 |
| 응답 타임아웃 증가 | 처리 지연인지 응답 라우팅 오류인지 | 업무 상태 대사 후 재시도 정책 적용 |
공식 자료 · RabbitMQ 모니터링 · Artemis Metrics · IBM MQ Metrics · Solace 운영 문서
13. 아키텍처 선정 기준과 업무 시나리오
13-1. 선정 순서
업무 의미와 복구 조건을 먼저 정한 뒤, 요구에 맞는 제품을 PoC로 좁혀 간다. 제품을 먼저 결정하고 모든 업무를 같은 전달 모델에 맞추면 개발 코드와 운영 절차가 복잡해질 수 있다.
| 판단 질문 | 설계에 미치는 영향 |
|---|---|
| 요청인가, 발생한 사실인가? | 담당 처리자·응답 책임·독립 구독 범위 결정 |
| 즉시 결과가 필요한가? | 직접 API와 브로커 Request-Reply의 지연·복잡성 비교 |
| 얼마 동안 다시 읽어야 하는가? | 큐 중심과 로그·Replay 중심 모델 구분 |
| 어떤 키의 순서가 중요한가? | 파티션 키·Message Group·직렬 처리 단위 결정 |
| 유실·중복·지연을 얼마나 허용하는가? | 영속·복제·ACK·멱등성·재시도 정책 결정 |
| 어느 범위의 장애를 견뎌야 하는가? | 로컬 HA·DR·멀티센터·클라이언트 복구 결정 |
| 누가 운영하고 복구를 책임지는가? | 오픈소스 직접 운영·상용 지원·관리형 서비스 비교 |
13-2. 요구사항별 우선 검토 후보
| 업무 요구 | 우선 검토 후보 | 선정 이유와 검증 과제 |
|---|---|---|
| 계약 변경 이벤트를 여러 업무가 재사용 | Kafka | 보존·독립 소비·재생. 키와 스키마·재처리 부수 효과 검증 |
| 알림톡·이메일·문서 작업 분배 | RabbitMQ, Artemis | 워커·ACK·실패 격리. 외부 발송 중복 방지 필요 |
| 기존 Java/JMS 연계 확장 | Artemis, IBM MQ | API·트랜잭션·운영 자산 연속성. WAS 호환성 검증 |
| 기존 MQ 기반 기간계·대외 거래 | IBM MQ | 기존 메시지·채널·운영 절차 활용. 거래 복구와 DR 시험 |
| 다양한 프로토콜·센터 간 이벤트 배포 | Solace | 라우팅·프로토콜·Event Mesh. HA와 DR 범위 분리 |
| 화면에서 즉시 결과가 필요한 단순 조회 | HTTP/gRPC 직접 호출도 함께 검토 | 불필요한 응답 큐·상관관계·대기 상태 관리 최소화 |
여러 제품을 함께 쓰는 것도 가능하다. 예를 들어 계약 시스템의 이벤트는 Kafka에 보존하고, 후속 통지 작업은 RabbitMQ의 큐로 분배할 수 있다. 그러나 브로커가 하나 늘 때마다 장애 지점, 중복 처리 경계, 스키마·권한·관측 체계도 늘어난다. 요구가 하나의 제품으로 충족된다면 단순한 구성이 운영에 유리할 수 있다.
13-3. 운영 난이도와 비용
| 비용 항목 | 실제 검토할 내용 |
|---|---|
| 제품·지원 | 라이선스·구독·관리형 서비스 과금·기술지원 범위 |
| 인프라 | 브로커·대기 노드·쿼럼·저장소·센터 간 전송·백업 |
| 구축 | 클라이언트·커넥터·스키마·멱등성·DR·모니터링 |
| 운영 | 업그레이드·인증서·장애 대응·재처리·24시간 지원 인력 |
| 전환 | 기존 JMS/MQI/API 변경·데이터 이관·이중 운영·교육 |
| 장애 영향 | 업무 중단·중복 발송·미처리 대사·복구 인력 비용 |
Kafka는 파티션·보존·재균형·커넥터 운영 역량이 중요하고, RabbitMQ는 큐 정책·메모리·ACK·Quorum 운용이 중요하다. Artemis는 Journal·Paging·HA·JMS/XA의 이해가 필요하며, IBM MQ는 큐 매니저·채널·로그·권한·복구 절차에 대한 역량이 필요하다. Solace는 토픽 체계·구독·Message VPN·Spool·브로커 간 연결을 체계적으로 관리해야 한다.
13-4. 도입 전 최종 확인 목록
- 업무 메시지의 소유자·스키마·호환성 정책과 변경 승인 절차가 있는가?
- ACK·Commit·응답 시점이 업무 성공의 정의와 일치하는가?
- 재시도·재전달·재생에서 중복 반영을 방지할 수 있는가?
- 노드 장애와 센터 장애에서 RPO/RTO를 실제로 측정했는가?
- 정상·피크·장애·복구 부하 모두에서 p99 지연과 적체를 확인했는가?
- 운영자가 오류 메시지 조회·보정·재처리를 수행할 절차와 권한이 있는가?
- 지원 버전·JDK·프로토콜·플러그인·라이선스가 운영 표준과 맞는가?
별첨. 이벤트·메시지·MQTT 브로커 전체 제품 목록
처음 소개한 제품 목록을 빠짐없이 모으고, 제품의 성격을 더 잘 드러내도록 다시 분류했다. 아래 목록은 시장의 모든 제품을 망라한 순위표가 아니라 앞서 다룬 전체 후보군이다. 플랫폼·관리형 서비스·DB 내장 기능·독립 브로커가 함께 포함되어 있으므로 제공 형태도 함께 확인한다. 한 제품이 여러 모델을 지원하면 해당 내용을 특징에 표시했다.
별첨 A. 이벤트 스트리밍·로그 중심 제품군
| 제품·서비스 | 제공 형태 | 주요 특징·검토 사항 |
|---|---|---|
| Apache Kafka | 글로벌 오픈소스 · Apache 2.0 | 분산 로그, 파티션, 독립 소비, 보존·재처리. 생태계가 넓지만 파티션·보존·운영 설계가 중요하다. |
| Confluent | 해외 상용 플랫폼·클라우드 / 구성요소별 라이선스 | Kafka 기반 관리·연계·스키마 등 확장 생태계. Confluent 전체를 Apache Kafka와 동일한 무료 배포로 보지 않는다. |
| Apache Pulsar | 글로벌 오픈소스 · Apache 2.0 | 구독 모델과 영속 메시징·스트리밍, 브로커·저장 계층 분리. BookKeeper 등 운영 구성도 함께 평가한다. |
| Redpanda | 소스 공개형 BSL·상용 기능·클라우드 | Kafka API 호환을 지향하는 스트리밍 플랫폼. 실제 API·도구 호환 범위와 BSL 사용 조건을 검토한다. |
| Amazon MSK | AWS 유료 관리형 Kafka | Kafka 운영 기반을 관리형으로 제공. 비용·버전·설정 제약과 소비 애플리케이션 운영은 별도 검토한다. |
| Azure Event Hubs | Microsoft Azure 유료 관리형 서비스 | 이벤트 수집·파티션 기반 스트리밍. Kafka 호환 엔드포인트를 제공하지만 자체 Kafka 클러스터와 동일한 제품은 아니다. |
공식 자료 · Kafka · Confluent · Pulsar · Redpanda 라이선스 · MSK · Event Hubs
별첨 B. 이벤트 배포·라우팅·관리형 Pub/Sub
| 제품·서비스 | 제공 형태 | 주요 특징·검토 사항 |
|---|---|---|
| Solace Event Broker / PubSub+ | 해외 상용·일부 제한된 무료 에디션 | 토픽 라우팅, Direct·Guaranteed, 큐, Replay, Event Mesh. 에디션별 기능·용량 확인. |
| Amazon EventBridge | AWS 유료 관리형 이벤트 서비스 | AWS·SaaS·사용자 이벤트의 규칙 기반 라우팅, Event Bus·Pipes 등. Kafka식 파티션 로그와 구분. |
| Google Cloud Pub/Sub | Google Cloud 유료 관리형 서비스 | Topic·Subscription 기반 비동기 메시징과 이벤트 배포. 이벤트·메시지 양쪽 목록에 해당하는 하나의 서비스. |
| Azure Service Bus Topics | Microsoft Azure 유료 관리형 서비스의 기능 | Topic·Subscription·필터 기반 다중 구독 메시징. 아래 Queue와 같은 Service Bus 제품군. |
공식 자료 · Solace · EventBridge · Google Pub/Sub · Service Bus
별첨 C. 업무 큐·기업 메시징·복합 메시징 제품군
| 제품·서비스 | 제공 형태 | 주요 특징·검토 사항 |
|---|---|---|
| RabbitMQ | 글로벌 오픈소스 · MPL 2.0 / 별도 상용 제공 형태 | Exchange·Queue 라우팅, 작업 분배, Quorum Queue. Streams는 별도 로그형 기능. |
| Apache ActiveMQ Classic | 글로벌 오픈소스 · Apache 2.0 | JMS 기반 메시징과 기존 ActiveMQ 자산. Artemis와 다른 브로커이므로 전환 검증 필요. |
| Apache ActiveMQ Artemis | 글로벌 오픈소스 · Apache 2.0 | Address/Queue, JMS·다중 프로토콜, Journal·Paging, Primary/Backup HA. |
| IBM MQ | 해외 상용 | 기업 시스템의 큐·채널·트랜잭션 메시징. Queue Manager HA와 MQ Cluster 구분. |
| TIBCO Enterprise Message Service (EMS) | 해외 상용 | JMS 중심 기업 메시징. 기존 TIBCO 연계 환경, 지원 프로토콜·운영·HA 조건 확인. |
| Oracle AQ / Transactional Event Queues (TxEventQ·TEQ) | 해외 상용 DB 기반 기능 · 사용 조건 확인 | Oracle Database 트랜잭션과 결합한 큐·이벤트 처리. 독립 설치형 브로커와 DB 운영 의존성이 다름. |
| NATS / JetStream | 글로벌 오픈소스 · Apache 2.0 | Core NATS의 경량 Pub/Sub·Request-Reply에 JetStream의 저장·ACK·재생을 결합. 두 모드의 보장 차이 확인. |
| Redis Streams | Redis 내 기능 · 버전·배포판별 라이선스 | Stream과 Consumer Group을 통한 데이터 소비. 저장·복구·메모리·Pending 관리 필요. 일반 Redis Pub/Sub와 구분. |
| Amazon SQS | AWS 유료 관리형 큐 | Standard·FIFO 큐 기반 작업 분배. Visibility Timeout, 중복 처리, 재시도·DLQ 정책 설계. |
| Azure Service Bus Queue | Microsoft Azure 유료 관리형 서비스의 기능 | 업무 큐와 Lock·재전달·DLQ 등. Sessions·트랜잭션 등은 계층·설정별 지원 확인. |
| Google Cloud Pub/Sub (재분류) | Google Cloud 유료 관리형 서비스 | 같은 구독에 붙은 소비자 간 처리 분배도 가능. 별첨 B와 동일 서비스이며 중복 제품이 아님. |
공식 자료 · RabbitMQ · ActiveMQ Classic · Artemis · IBM MQ · TIBCO EMS · Oracle TxEventQ·AQ · NATS JetStream · Redis · SQS
별첨 D. MQTT·IoT 메시징 제품군
| 제품 | 제공 형태 | 주요 특징·검토 사항 |
|---|---|---|
| Eclipse Mosquitto | 글로벌 오픈소스 · EPL/EDL | 경량 MQTT 브로커. 소규모·엣지·게이트웨이 구성에 활용. 대규모 클러스터 기능을 자동으로 전제하지 않는다. |
| EMQX | 5.9부터 BSL 1.1 소스 공개형·상용/클라우드 | MQTT 연결·라우팅·데이터 연계. 예전 오픈소스 에디션 정보와 최신 라이선스를 구분한다. |
| HiveMQ | 해외 상용 / Community Edition 오픈소스 | MQTT 기반 기업·IoT 메시징. 클러스터·확장·지원 기능은 에디션별 확인. |
| VerneMQ | 오픈소스 코드 / 바이너리·이미지 배포 조건 별도 | 분산 MQTT 브로커. 소스 라이선스와 공식 사전 빌드 배포물의 사용 조건을 각각 확인한다. |
MQTT의 QoS 0·1·2는 MQTT 프로토콜 전달 절차의 보장이다. QoS 2를 사용했다는 이유만으로 외부 DB 갱신이나 장치 명령의 업무 효과가 시스템 전체에서 정확히 한 번 실행된다고 해석하면 안 된다. 세션 유지·Retained Message·오프라인 저장도 서로 다른 개념이다.
공식 자료 · Mosquitto · EMQX 라이선스 · HiveMQ · VerneMQ 배포 조건
참고 자료와 적용 범위
각 장과 별첨의 공식 문서 링크를 기준으로 개념과 구성 방향을 정리했다. 제품의 세부 설정·지원 환경·에디션 제한은 설치할 릴리스 문서를 우선한다. 이 글의 업무 예시, PoC 조건, 운영 판단 기준은 아키텍처 검토를 위한 설명이며 특정 환경의 실측 결과나 공급사의 성능 보증 수치가 아니다.
정리 기준: 2026년 9월 29일 · 주요 범위: Apache Kafka / RabbitMQ / Apache ActiveMQ Artemis / IBM MQ / Solace PubSub+ · 별첨: 최초 소개한 이벤트·메시지·MQTT 제품 전체 목록
'Programming' 카테고리의 다른 글
| jQuery DOM 객체와 탐색 범위 (0) | 2026.10.11 |
|---|---|
| jQuery가 실행 오류 (0) | 2026.10.11 |
| Java Thread (0) | 2026.10.08 |
| Java 예외처리 (0) | 2026.10.08 |
| Java 객체지향 (0) | 2026.10.08 |
