Message Broker 선택과 운영

Overview

Message Broker는 Producer와 Consumer를 시간·속도·배포 측면에서 분리한다. Dev Atlas에는 내부 System 이름과 주소 대신, 실제 경험에서 확인한 Listener → 검증 → Routing → Worker Queue → 결과 Queue라는 일반 흐름만 남긴다.

flowchart LR; P[Producer] --> B[Broker Queue]; B --> L[Listener]; L --> R[Routing]; R --> W[Worker]; W --> O[결과 Queue]; B -. 반복 실패 .-> D[DLQ]

Broker 비교 관점

ActiveMQ는 JMS 생태계와 기존 Java Application 통합에서 자주 쓰인다. RabbitMQ는 Exchange와 Binding을 통한 Routing 표현력이 강하다. Kafka는 Consumer가 Offset을 관리하는 분산 Log 성격이 강해 Queue Broker와 운영 모델이 다르다. 제품 이름보다 전달 보장, 순서, Routing, Replay, 운영 역량을 기준으로 선택한다.

실패 설계

Acknowledgement 시점, Retry 횟수와 간격, DLQ 이동, Poison Message 격리, Consumer Idempotency를 함께 정한다. 처리 완료 전에 Ack하면 유실 위험이, 부작용 완료 후 Ack가 실패하면 중복 위험이 생긴다.

실무에서 발생하는 문제

• Consumer가 없는 결과 Queue에 메시지가 계속 쌓인다.
• Broker Prefetch와 Worker 수가 DB Connection Pool보다 커 하위 자원을 압박한다.
• 무한 Retry가 정상 메시지까지 막는다.
• 업무 Key 없이 중복 처리해 이메일·결제 같은 부작용이 반복된다.

Interview Questions

1. Ack 시점이 유실과 중복에 미치는 영향은?
2. RabbitMQ/ActiveMQ와 Kafka를 어떤 기준으로 구분하는가?
3. Consumer가 멱등해야 하는 이유는?
4. 결과 Queue에 Consumer가 없으면 어떤 현상이 생기는가?

Related Topics

ActiveMQ와 JMS 운영, Kafka, Amazon SQS/SNS를 함께 확인한다.