메시지 브로커(Message Broker)
MSA 구조가 늘어나면서 서비스 간 비동기 통신이 점점 더 중요해지고 있다. 서비스 모듈끼리 동시에 반응하지 않아도 안정적으로 데이터를 주고받을 수 있어야 하기 때문에, 비동기 메시지 서비스의 중요성이 오르고 있다.
이때 핵심 역할을 하는 게 메시징 큐와 이벤트 스트림이다. 둘 다 비슷해 보이지만 목적과 특징에 다소 차이점이 존재한다.
Message Queue(메시지 큐)
Messaging Queue란?
말 그대로 "메시지를 임시로 쌓아두는 저장소"이다.
메시징 큐의 특징
위의 그림처럼 메시지를 발행하는 Producer(생산자)가 존재한다.
그리고 데이터(메시지)를 수신하고 처리하는 것이 Consumer(소비자)이다.
이러한 발행 메시지는 모두 queue에 쌓여있다가 소비자가 읽으면 큐에서 사라지는 구조이다.
우선은 메시징 큐의 기본적인 특성은 다음과 같다
- 비동기 통신: 송신자와 수신자가 동시에 켜져 있지 않아도 통신 가능
- 메시지 내구성: 대기열에 있는 메시지는 일반적으로 성공적으로 처리될 때까지 저장되므로 수신 구성 요소를 일시적으로 사용할 수 없더라도 메시지가 손실되지 않음(소비 되기 전까지는 안전)
- 부하 분산: 여러 소비자가 있으면 메시지를 분산함으로써 부하를 분산하고 시스템의 전반 처리량 개선=
대표적인 구현체로는 RabbitMQ, ActiveMQ, Amazon SQS 등이 있다.
이벤트 스트림
메시징 큐와 유사한 구조로 이루어진 이벤트 스트림이다. 주된 초점이 메시징 큐와 차이가 난다.
개별 메시지를 처리하는 메시지 큐와 달리, 이벤트 스트림은 데이터의 실시간 순차적 흐름을 강조한다.
이벤트 스트림 특징
이벤트 스트림에서는 이벤트 소스가 Publisher(발행자)로, 이벤트를 발행한다. 이벤트를 구독하는 Subscriber(구독자)가 이벤트를 처리한다.
특징은 다음과 같다.
- 실시간 처리: 실시간 데이터 처리에 최적화, 특히 이벤트 발생 시 즉시 대응해야 하는 애플리케이션에 유용
- 이벤트 소싱: 태 변화가 불변 이벤트 시퀀스로 캡처되는 이벤트 소싱 패턴을 지원하는 경우가 많아, 언제든 시스템 재구성이 가능, 이벤트가 로그처럼 순차적으로 저장되고 재생 가능
- 확장성: 여러 구독자가 동시에 같은 이벤트를 볼 수 있음( 고처리량 이벤트 시나리오 처리하도록 구축되어 효율적)
대표적인 구현체는 Kafka, Amazon Kinesis, Pulsar 등이 있다.
차이점
둘의 차이점은 무엇일까
발행 방향성
메시징 큐는 생산자가 직접 소비자의 큐로 메시지를 푸시(push) 하는 방식이다.
그래서 만약 하나의 메시지를 두 개 서비스에 보내야 한다면, 생산자가 각각 따로 "두 개의 메시지"를 만들어서 각각의 큐에 넣어야 한다.
그러나, 스트림의 경우에는, 생산자가 스트림 저장소에 메시지를 한 번만 넣으면, 여러 소비자가 같은 메시지를 가져가서 읽을 수 있다.
즉, 메시지를 복제해서 따로 저장하지 않아도 된다.
데이터의 영속성
메시지의 삭제에서의 영속성
- 메시징 큐에서는 소비자가 데이터를 읽는 시점에 큐에서 데이터를 삭제
- 이벤트 스트림의 경우에는 구독자가 메시지를 읽어도 바로 지워지지 않고, 저장소 설정에 따라 일정 기간 보관 가능
새로운 소비자 추가에서의 영속성
- 메시징 큐는 소비자가 중간에 들어오면, 그 시점 이후의 메시지부터만 조회 가능
- 이벤트 스트림은 저장소에 남아 있는 과거 데이터까지 조회 가능. 나중에 들어온 소비자라도 이전 기록을 확인 가능-> 히스토리 열람 가능
정리
구분메시징 큐이벤트 스트림
| 메시지 전달 | 소비자가 읽으면 큐에서 삭제 | 읽어도 저장소에 남아 있음 |
| 소비자 추가 | 추가된 시점부터 메시지 읽음 | 과거 데이터까지 조회 가능 |
| 순서 보장 | 큐 단위로 순서 보장 | 파티션 단위 순서 보장 |
| 재생 가능 여부 | 불가능 | 가능 |
| 주요 사용처 | 작업 분배, 백그라운드 처리, 마이크로서비스 통신 | 실시간 분석, 로그 집계, 이벤트 소싱 |
사례를 통해 알아보기
메시지 큐의 사용 사례
메시지 큐는 주로 작업을 안정적으로 분배하고 비동기적으로 처리해야 할 때 사용된다.
- 백그라운드 작업 처리
- 사용자 요청을 처리하거나 오래 걸리는 작업을 뒤에서 돌림 (예: RabbitMQ, Amazon SQS)
- 작업 스케줄링
- 알림 전송, 데이터 백업 같은 정해진 시간이나 주기로 실행해야 하는 작업 관리
- 주문 처리 시스템
- 주문이 몰려도 메시지 큐가 순차적으로 처리
- 마이크로서비스 통신
- 서비스 간 연결을 느슨하게 하여, 각 서비스가 독립적으로 동작하고 서로 장애 유발하지 않도록 함
이벤트 스트림의 사용 사례
이벤트 스트림은 실시간 데이터 흐름과 분석이 필요할 때 사용
- 실시간 분석
- 사용자 행동, 금융 거래 같은 대량 데이터를 빠르게 처리하고 분석 (예: Kafka)
- 이벤트 소싱
- 시스템 상태 변화를 이벤트 시퀀스로 저장해서 나중에 그대로 재생하거나 감사(감사 로그)
- 로그 집계
- 여러 소스에서 나오는 로그를 모아 중앙 저장소에 쌓고, 그걸 실시간 모니터링/분석
- 사기 감지
- 거래 데이터를 실시간으로 분석해서 패턴을 찾아내고, 이상 행동 감지
정리하면, 메시징 큐는 "실시간 전달 + 단발성 처리"에 가깝고, 이벤트 스트림은 "실시간 + 과거 데이터 재생 가능"에 가깝다!!!
REF
'백엔드' 카테고리의 다른 글
| [Docker] Docker를 활용한 Blue/Green 무중단 배포 (0) | 2025.07.19 |
|---|---|
| 블로킹 I/O vs 논블로킹 I/O 비교 (w/ RestTemplate vs WebClient) (3) | 2025.04.03 |