메시지 큐(Message Queue)를 사용하는 이유와 Kafka, RabbitMQ의 차이를 설명해주세요.

메시지 큐는 서비스 간 작업을 직접 호출하지 않고 메시지로 전달하게 해주는 미들웨어입니다. 이를 통해 비동기 처리, 장애 격리, 트래픽 완충, 서비스 간 결합도 감소를 얻을 수 있습니다.

왜 메시지 큐를 사용하나요?

예를 들어 주문 생성 후 결제, 재고 차감, 알림 발송을 모두 동기 호출로 처리하면 하나의 서비스 지연이나 장애가 전체 응답을 늦춥니다.

Order API -> Payment API -> Inventory API -> Notification API

메시지 큐를 사용하면 주문 서비스는 이벤트를 발행하고, 각 서비스가 독립적으로 처리할 수 있습니다.

Order Service -> order.created -> Queue/Broker
                                 -> Payment Service
                                 -> Inventory Service
                                 -> Notification Service

장점

• 비동기 처리로 응답 시간 단축
• 일시적인 트래픽 폭주를 큐가 완충
• 소비자 장애 시 메시지를 보관했다가 재처리 가능
• 서비스 간 직접 의존성 감소
• 이벤트 기반 아키텍처 구현 가능

주의할 점

메시지 큐를 쓰면 시스템은 더 유연해지지만 복잡도도 증가합니다.

• 메시지 중복 처리 가능성
• 처리 순서 보장 범위
• 재시도와 Dead Letter Queue 설계
• 이벤트 스키마 변경 관리
• 최종적 일관성 이해 필요

Kafka

Kafka는 대용량 이벤트 스트리밍에 강한 로그 기반 메시지 플랫폼입니다.

특징:

• 토픽을 파티션으로 나눠 높은 처리량 제공
• 메시지를 일정 기간 저장
• Consumer Group 단위로 병렬 소비
• 같은 파티션 내 순서 보장
• 이벤트 재처리와 스트림 처리에 적합

topic: order-events
partition-0: [event1, event2, event3]
partition-1: [event4, event5, event6]

적합한 경우:

• 로그 수집
• 클릭스트림 처리
• 이벤트 소싱
• 대규모 데이터 파이프라인
• 여러 소비자가 같은 이벤트를 독립적으로 읽어야 하는 경우

RabbitMQ

RabbitMQ는 전통적인 메시지 브로커로, 라우팅과 작업 큐 패턴에 강합니다.

특징:

• Exchange와 Queue 기반 라우팅
• 다양한 라우팅 패턴 지원
• 메시지 acknowledgement 기반 안정적 처리
• 작업 분배와 RPC 패턴에 적합

Producer -> Exchange -> Queue -> Consumer

적합한 경우:

• 백그라운드 작업 큐
• 이메일 발송
• 이미지 처리
• 복잡한 라우팅 규칙이 필요한 업무 메시징

Kafka vs RabbitMQ

정리

메시지 큐는 비동기 처리와 서비스 결합도 완화에 유용하지만, 중복 처리와 최종적 일관성을 반드시 설계해야 합니다. 대용량 이벤트 스트리밍은 Kafka, 업무 메시징과 작업 큐는 RabbitMQ가 자주 선택됩니다.

메시지 큐를 도입하는 이유

메시지 큐는 요청 처리와 후속 작업을 분리해 시스템을 느슨하게 연결합니다. 주문 생성 후 이메일 발송, 이미지 변환, 로그 수집처럼 즉시 응답에 포함하지 않아도 되는 작업을 비동기로 처리할 수 있습니다.

API 서버 → order.created 메시지 → 소비자(메일, 포인트, 분석)

Kafka와 RabbitMQ 비교

실무 주의사항

• 메시지는 중복 처리될 수 있으므로 소비자는 idempotent하게 만들어야 합니다.
• 순서 보장이 필요한 단위는 partition key 또는 queue 설계를 명확히 해야 합니다.
• 실패 메시지는 재시도 정책과 DLQ(Dead Letter Queue)를 둡니다.
• 메시지 스키마 변경은 생산자/소비자 배포 순서를 고려합니다.