2026. 7. 28. 15:37ㆍ카테고리 없음
RabbitMQ로 주문 처리 흐름 구현
오늘은 RabbitMQ를 이용해서 주문 처리 흐름을 구현해봤다.
먼저 Order 애플리케이션에서 주문 요청을 받으면 DB에 주문 정보를 저장한 뒤 market.product 큐로 메시지를 전송하도록 만들었다. Product 애플리케이션은 해당 큐를 구독하고 있다가 메시지를 받으면 재고를 차감하고, 처리가 끝나면 market.payment 큐로 다시 메시지를 보낸다.
Payment 애플리케이션은 market.payment 큐를 구독하면서 결제를 진행한다. 정상적으로 결제가 완료되면 그대로 프로세스가 끝난다.
이번 실습에서 중요한 부분은 하나의 애플리케이션이 Producer와 Consumer 역할을 동시에 할 수 있다는 점이었다.
- Order : 주문 메시지 발행 + 오류 메시지 수신
- Product : 주문 메시지 수신 + 결제 메시지 발행
- Payment : 결제 메시지 수신 + 오류 메시지 발행
오류 처리 흐름도 같이 구현했다.
결제 금액이 한도를 초과하거나 결제가 실패하면 Payment에서 err.exchange로 에러 메시지를 전송한다. Exchange는 바인딩된 market.err.order 큐로 메시지를 전달하고, Order 애플리케이션은 해당 큐를 리슨하고 있다가 메시지를 받으면 주문을 취소하도록 구현했다.
재고 부족 상황도 같은 방식이다. Product에서 재고가 부족하면 err.exchange로 메시지를 보내고, Exchange가 market.err.order 큐로 전달하면 Order에서 주문 취소를 진행한다.
실습하면서 Exchange가 직접 데이터를 처리하는 것이 아니라, 어떤 큐로 메시지를 보낼지 결정해주는 역할이라는 점을 이해하게 됐다. 또 Queue는 메시지를 저장하고, Consumer는 필요한 순간에 메시지를 가져가 처리하는 구조라는 것도 다시 정리할 수 있었다.
오늘 구현한 흐름은 아래와 같다.
Order → market.product → Product → market.payment → Payment
오류 발생 시
Payment 또는 Product → err.exchange → market.err.order → Order(주문 취소)
처음에는 Producer와 Consumer 역할이 헷갈렸는데 직접 설계를 손그림으로 그리면서 보니까 하나의 애플리케이션이 상황에 따라 두 역할을 모두 수행할 수 있다는 점이 가장 기억에 남았다.
Kafka와 RabbitMQ 정리
RabbitMQ를 구현하면서 자연스럽게 Kafka랑도 비교해봤다. 둘 다 메시지를 전달하는 역할을 하지만 사용하는 목적이 조금 다르다.
RabbitMQ는 큐를 중심으로 동작한다. Producer가 큐에 메시지를 보내면 Consumer가 가져가 처리하고, 처리가 끝나면 메시지가 큐에서 사라진다. 작업 큐나 비동기 처리처럼 "메시지를 빠르게 전달하는 것"에 초점이 맞춰져 있다.
반대로 Kafka는 토픽을 중심으로 동작한다. Producer가 토픽에 메시지를 저장하면 Consumer는 필요한 시점에 메시지를 읽는다. 메시지가 바로 없어지는 것이 아니라 일정 기간 동안 디스크에 보관되기 때문에 같은 데이터를 여러 Consumer가 다시 읽을 수도 있다.
RabbitMQ는 주문 처리나 이메일 발송, 알림 전송처럼 하나의 작업을 빠르게 처리하는 서비스에 많이 사용되고, Kafka는 로그 수집, 사용자 행동 분석, 실시간 데이터 처리처럼 많은 데이터를 지속적으로 저장하고 분석하는 환경에서 많이 사용된다.
오늘 실습했던 주문 시스템을 기준으로 생각해보면 RabbitMQ는 주문 → 재고 → 결제처럼 작업을 순서대로 전달하는 데 적합했다. 만약 Kafka를 사용했다면 주문 이벤트를 저장해두고 재고 서비스, 결제 서비스, 통계 서비스가 같은 이벤트를 각각 가져가 처리하는 구조가 더 잘 어울릴 것 같았다.
또 하나 알게 된 점은 Consumer Group 개념이다. Kafka에서는 같은 Consumer Group 안에 여러 Consumer가 있으면 파티션을 나눠서 처리하고, 다른 Consumer Group이면 같은 메시지를 각각 받을 수 있다. 덕분에 하나의 주문 이벤트를 여러 서비스에서 동시에 활용할 수 있다.
메시지 브로커를 처음에는 단순히 데이터를 전달하는 역할이라고 생각했는데, 직접 구현하면서 서비스 간의 결합도를 낮추고 장애가 발생해도 영향을 최소화할 수 있도록 도와주는 중요한 역할이라는 걸 알게 됐다.
오늘 실습을 통해 Producer, Consumer, Queue, Exchange, Routing Key, Consumer Group까지 흐름을 직접 따라가면서 메시지 기반 아키텍처가 어떻게 동작하는지 조금 더 명확하게 이해할 수 있었다.
내일 목표
- MSA 구조와 설계 및 흐름를 이해하기
- Kafka와 RabbitMQ 활용방법 정리하기
- 대규모 데이터 스트리밍 처리 방식 이해하기
- Redis활용 실습 및 이해하기
- 대규모 프로젝트 환경에서의 협업 및 관리 방식 정리하기
- 실무에서 사용하는 아키텍처 흐름 정리하기