카프카란?

카프카와 MQ는 메세지 브로커라는 점에서 같은 범주라고 볼 수 있다. producer -> broker -> consumer 라는 구조로 비동기 메세지 전달을 처리하는 시스템이다.
둘의 가장 큰 차이점은, MQ는 “메세지를 안전하게 한 곳으로 보내자”인 반면, Kafka는 “이벤트를 저장해서 여러 군데에서 활용하자”라는 서로 다른 용도라는 것이다.

MQ는 (IBM MQ를 위주로), 큐잉 기반 메세지 브로커

1:1: 처리가 기본이고 (하나의 consumer가 메세지를 가져가면 사라진다)
트랜잭션 신뢰성이 최우선이고 (Exactly-once처리)
순서보장, 신뢰보장, 일관성 보장이 중요한 업무에 적합하다.
목적: 정확하고 안전하게 메세지 처리하는 것

Kafka는, 분산 로그 기반 스트리밍 플랫폼

1: N구조로, 여러 consumer group이 독립적으로 읽기가 가능하다
메세지 유지를 전제로 한다. (기본적으로 삭제 안한다)
재처리, 리플레이, 스트리밍 처리 등 다양한 활용 가능
이벤트 기반 아키텍처, 로그 수저비, 실시간 분석에 적합
목적: 데이터 흐름을 중심으로 처리하고 저장하는 것

=> IBM MQ를 사용하는 이유는, 거래가 1:1로 소비되고, 트랜잭션 신뢰성이 높고, 순서를 보장하기 때문인 것으로 보인다.

디테일한 비교

기존 MQ 기반 시스템(예: IBM MQ, RabbitMQ 등)과 어떤 차이가 있고, 어떤 기준으로 Kafka를 도입할지를 판단해보려고 한다.

🧱 1. 아키텍처 및 메시지 처리 모델

항목	Kafka	기존 MQ (예: IBM MQ)
모델	분산 로그 기반 (log-centric)	큐 기반 (queue-centric)
처리 방식	Pub-Sub 구조, 메시지는 여러 Consumer가 읽을 수 있음	메시지는 일반적으로 한 Consumer에게만 전달됨 (1:1 소비)
메시지 보존	Consumer가 읽어도 메시지를 삭제하지 않음 (configurable)	소비되면 기본적으로 삭제됨

➡ Kafka는 로그 수집, 이벤트 소싱, 데이터 파이프라인 등에 적합
➡ MQ는 주문형 처리, 단건 신뢰성 높은 메시지 처리에 적합

⚡ 2. 성능 및 확장성

항목	Kafka	MQ
처리량	매우 높은 처리량 (100만 TPS 이상도 가능)	상대적으로 낮은 TPS
확장성	파티션 기반 수평 확장 매우 용이	브로커를 추가하더라도 확장성이 제한적일 수 있음
지연 시간	낮지만 전통 MQ보다 latency-sensitive 하지 않음	낮은 지연 시간 보장 가능

➡ 대용량 이벤트 스트림 처리에서는 Kafka가 압도적
➡ 저지연, 거래중심 시스템에서는 MQ가 더 적합할 수 있음

🛡 3. 신뢰성과 내구성

항목	Kafka	MQ
메시지 순서 보장	파티션 내에서는 보장, 전체 순서는 보장 안 됨	큐 기준 FIFO 보장
전송 보장	At least once, Exactly once 지원 (복잡함)	기본적으로 Exactly once or at least once
트랜잭션 지원	일부 트랜잭션 가능, 제약 많음	XA 트랜잭션 등 강력한 트랜잭션 지원

➡ 금융처럼 정확한 순서와 신뢰성 보장이 중요한 경우 MQ 선호
➡ 데이터 흐름 중심, 약간의 중복 허용 가능한 경우 Kafka 적합

🔍 4. 운영 및 관리

항목	Kafka	MQ
운영 난이도	클러스터 구성, 파티션 조정 등 복잡	상대적으로 단순하고 안정적
모니터링	별도 도구 필요 (Confluent Control Center, Prometheus 등)	벤더 도구 존재 (IBM MQ Explorer 등)

➡ Kafka는 DevOps 및 운영 자동화 역량 필요
➡ MQ는 레거시 환경, 안정성 요구에 강점

🧭 5. 도입 판단 기준

Kafka가 적합한 경우
- 대용량 로그 수집/분석, 이벤트 스트리밍 필요
- 마이크로서비스 간 이벤트 브로커
- 여러 소비자가 하나의 메시지를 반복적으로 소비해야 하는 경우
기존 MQ가 더 나은 경우
- 단건 메시지의 신뢰성, 순서, 트랜잭션 보장이 중요한 업무 (예: 금융 거래 처리)
- 레거시 시스템 연계가 많고 변경 비용이 크며 안정성이 중요한 경우

Kafka란?

MQ와 비교를 곁들인