메시지 브로커(Message Broker) 알아보기
1. 메시지 브로커(Message Broker) 란?
메시지 브로커(Message Broker)는 애플리케이션 간의 메시지를 중개하는 소프트웨어입니다.
생산자(Producer)와 소비자(Consumer) 사이에서 메시지를 전달하고 관리하는 중간 매개체 역할을 수행하며, 서로 다른 시스템이나 서비스 간의 통신을 원활하게 만들어줍니다.
예를 들어 설명하자면, 메시지 브로커는 우체국과 같은 역할을 합니다.
생산자가 우체국에 편지를 맡기면, 소비자가 집에 없어도 우체국이 편지를 보관했다가 나중에 전달합니다.
마찬가지로 메시지 브로커도 소비자가 일시적으로 오프라인 상태더라도 메시지를 안전하게 보관했다가 전달합니다.
따라서 메시지 브로커는 마이크로서비스 아키텍처(MSA, Micro Service Architecture)나 분산 시스템에서 서비스 간 통신을 위해 널리 사용되며, 실시간 데이터 처리, 로그 수집, 비동기 작업 큐 등 다양한 분야에서 활용됩니다.
2. 왜 메시지 브로커가 필요한가?
시스템이 복잡해지고 여러 서비스로 나뉘면서, 서비스 간 통신 방식이 중요한 문제로 떠올랐습니다.
전통적인 직접 통신 방식은 간단하지만, 규모가 커질수록 여러 한계를 드러냅니다.
2-1. 직접 통신 방식의 문제점
특히, 마이크로서비스 아키텍처에서 서비스 간 직접 통신을 할 경우 다음과 같은 문제가 발생합니다.
- 강한 결합도
- 서비스 A가 서비스 B와 통신하려면 B의 정확한 주소, 포트, 프로토콜 등의 정보를 알아야 합니다.
- 이 경우 B의 위치나 인터페이스가 변경되면 A의 코드도 함께 수정해야하는 강한 결합의 문제가 발생합니다.
- 동기적 대기
- HTTP 요청-응답 방식에서는 서비스 A가 서비스 B의 응답을 받을 때까지 대기해야 합니다.
- 만약 서비스 B의 처리 시간이 길어지면 서비스 A도 함께 지연됩니다.
- 장애 전파
- 서비스 B가 다운되면 서비스 A도 함께 에러를 발생시키거나 타임아웃으로 인한 성능 저하를 겪습니다.
- 즉, 하나의 서비스 장애가 전체 시스템에 연쇄적으로 영향을 미치게 됩니다.
- 확장성 제약
- 새로운 서비스 C가 추가되어 B의 데이터를 받아야 한다면, A를 수정하여 C에도 메시지를 보내도록 해야 합니다.
- 서비스가 추가될 때마다 기존 코드를 수정해야 하므로 시스템 확장이 어렵고 유지보수 비용이 증가합니다.
- 트래픽 급증 대응 어려움
- 트래픽 급증으로 B가 처리할 수 없는 양의 요청을 받으면, 시스템 다운이나 데이터 유실의 위험이 있습니다.
- 요청을 일시적으로 버퍼링하거나 조절할 수 있는 메커니즘이 없어, 순간적인 부하에 취약합니다.
2-2. 메시지 브로커의 해결책
메시지 브로커를 도입하면 위의 문제들을 해결할 수 있습니다.
- 느슨한 결합
- 서비스는 브로커에만 메시지를 송수신하면 되므로, 상대방의 상태나 위치를 알 필요가 없습니다.
- 비동기 처리
- 생산자는 메시지를 보낸 후 응답을 기다리지 않고 다음 작업을 계속할 수 있습니다.
- 장애 격리
- 한 서비스의 장애가 다른 서비스에 즉시 전파되지 않습니다.
- 브로커가 메시지를 보관하고 있다가 서비스가 복구되면 전달합니다.
- 유연한 확장
- 새로운 서비스를 추가할 때 기존 코드를 수정할 필요 없이 브로커를 구독하기만 하면 됩니다.
- 부하 조절
- 트래픽이 급증해도 브로커가 메시지를 큐에 쌓아두고, 소비자가 처리 가능한 속도로 소비하도록 조절합니다.
3. 메시지 브로커의 구성과 동작 방식
메시지 브로커는 여러 구성 요소들이 유기적으로 협력하여 동작합니다.
먼저 각 구성 요소의 역할을 이해한 후, 이들이 어떻게 상호작용하며 메시지를 전달하는지 살펴보겠습니다.
3-1. 구성 요소
메시지 브로커는 여러 구성 요소로 이루어져 있으며, 각각 명확한 역할을 수행합니다.
3-1-1. Producer
메시지를 생성하여 브로커에 전송하는 애플리케이션입니다.
예를 들어, 주문 서비스가 “새로운 주문이 생성되었습니다.” 라는 메시지를 브로커에 보내는 역할을 합니다.
이때 Producer는 메시지를 어떤 Consumer가 처리할지 알 필요가 없으며, 단지 정해진 Queue나 Topic에 메시지를 보내기만 하면 됩니다.
3-1-2. Consumer
브로커로부터 메시지를 받아 실제 작업을 처리하는 애플리케이션입니다.
예를 들어, 재고 관리 서비스가 주문 메시지를 받아 재고를 차감하는 작업을 수행합니다.
하나의 메시지를 여러 Consumer가 동시에 처리할 수도 있고, 여러 Consumer가 분산하여 처리할 수도 있습니다.
3-1-3. Queue
메시지가 저장되는 일대일 통신용 저장소입니다.
하나의 메시지는 하나의 Consumer만 가져갈 수 있습니다.
예를 들어, 이메일 발송 작업을 Queue에 넣으면 여러 Worker 중 하나가 해당 작업을 가져가서 처리하며, 같은 작업은 중복으로 처리되지 않습니다.
3-1-4. Topic
메시지가 저장되는 일대다 통신용 저장소입니다.
하나의 메시지를 구독 중인 모든 Consumer가 받을 수 있습니다.
예를 들어, 사용자 가입 이벤트를 Topic에 발행하면 이메일 서비스, 통계 서비스 등 모든 구독자가 해당 이벤트를 받아 각자의 로직을 수행할 수 있습니다.
3-1-5. Message
실제로 전달되는 데이터 단위이며, 일반적으로 Header와 Body로 구성됩니다.
- Header: 메시지의 메타데이터를 포함합니다. ID, 타임스탬프, 발신자, 수신자 등의 정보가 포함됩니다.
- Body: 실제 전달할 데이터를 포함합니다. JSON, XML, 바이너리 등 다양한 형식으로 인코딩될 수 있습니다.
1
2
3
4
5
6
7
8
9
10
11
12
{
"header": {
"message_id": "MSG-00001",
"timestamp": "2025-11-27T12:30:00Z",
"sender": "order-service"
},
"body": {
"order_id": "ORDER-00001",
"user_id": 1234,
"items": []
}
}
3-2. 동작 방식
메시지 브로커는 다음과 같은 흐름으로 동작합니다.
- 메시지 생성 및 전송: Producer가 메시지를 생성하여 브로커에 전송
- 메시지 저장: 브로커가 메시지를 적절한 Queue 또는 Topic에 저장
- 메시지 소비: Consumer가 Queue 또는 Topic에서 메시지를 가져와 처리
- 확인 응답: Consumer가 작업 처리를 완료한 후 브로커에 ACK(Acknowledgement) 전송
일반적으로 브로커는 ACK를 받은 후에 해당 메시지를 Queue 또는 Topic에서 제거합니다.
만약 Consumer가 메시지를 처리하던 중 장애가 발생하여 ACK를 보내지 못하면, 브로커는 해당 메시지를 다시 Queue 또는 Topic에 넣어 다른 Consumer가 처리할 수 있도록 합니다.
4. 메시지 브로커의 주요 패턴
메시지 브로커는 크게 두 가지 메시징 패턴을 제공하며, 각 패턴은 서로 다른 통신 방식과 용도를 가지고 있습니다.
4-1. Point-to-Point (Queue 패턴)
하나의 메시지를 하나의 Consumer만 처리하는 1:1 관계 방식입니다.
메시지는 Queue에 저장되며, 여러 Consumer가 있어도 각 메시지는 한 번만 처리됩니다.
Point-to-Point 패턴은 1:1 관계로 인해 메시지 중복 처리를 방지할 수 있습니다.
또한, 여러 Consumer가 같은 Queue를 구독하면 메시지가 자동으로 분산되어 부하 분산 효과를 얻을 수 있습니다.
따라서, 결제 시스템이나 이메일 발송처럼 하나의 작업이 정확히 한 번만 실행되어야 하는 경우에 적합합니다.
4-2. Publish-Subscribe (Topic 패턴)
하나의 메시지를 여러 Consumer가 동시에 받는 1:N 관계 방식입니다.
Publisher가 Topic에 메시지를 발행하면, 해당 Topic을 구독하는 Subscriber가 메시지를 받을 수 있습니다.
Publish-Subscribe 패턴은 1:N 관계로 인해 하나의 이벤트를 여러 서비스가 독립적으로 처리할 수 있습니다.
또한, 새 Subscriber를 추가할 때 기존 코드 수정 없이 Topic을 구독하기만 하면 되기 때문에 유지보수에 용이합니다.
따라서, 이벤트 알림이나 시스템 로깅처럼 하나의 이벤트를 여러 곳에서 처리해야 하는 경우에 적합합니다.
5. 메시지 브로커의 종류
현재 대표적인 메시지 브로커로는 RabbitMQ, Apache Kafka, Redis(Pub/Sub)가 있습니다.
프로젝트의 요구사항과 규모에 따라 적절한 메시지 브로커를 선택하는 것이 중요합니다.
5-1. RabbitMQ
AMQP(Advanced Message Queuing Protocol) 기반의 오픈소스 메시지 브로커입니다.
다양한 라우팅 패턴을 지원하며, 관리용 웹 UI를 제공하여 사용하기 편리합니다.
중소규모 마이크로서비스 시스템이나 작업 큐 구현에 적합합니다.
5-2. Apache Kafka
대용량 실시간 데이터 처리에 최적화된 분산 스트리밍 플랫폼입니다.
높은 처리량과 메시지 영구 저장 기능을 제공하며, 로그 수집, 데이터 파이프라인 구축 등에 널리 사용됩니다.
5-3. Redis(Pub/Sub)
인메모리 기반의 가볍고 빠른 메시징 시스템입니다.
초저지연이 필요한 실시간 채팅, 알림 시스템 등에 적합하지만, 메시지 영속성이 제한적이라는 특징이 있습니다.