✅ RabbitMQ 기반 비동기 아키텍처 도입 성능 개선 사례
1. 기술 도입 배경
기존 시스템은 주문 생성 API를 시작으로, 배달 생성 → 배달 경로 계산 → 슬랙 메시지 전송까지 총 4단계의 API 호출이 순차적으로 진행되는 구조였다.
JMeter를 활용한 성능 테스트 결과, 동기식 처리 흐름에서 평균 처리량은 약 26건/초(26 TPS) 수준으로 확인되었다.
그러나 트래픽이 증가하는 상황에서 각 API 호출이 순차적으로 진행됨에 따라 병목현상이 발생했고, 시스템 전체의 확장성에 한계가 있었다.
이에 따라 각 단계를 비동기화하여 병렬로 처리하고, **메시지 지향 미들웨어(RabbitMQ)**를 도입해 안정적이고 효율적인 비즈니스 플로우를 구성하고자 했다.
2. RabbitMQ 적용 과정
✅ 아키텍처 변경 사항
- 기존:
사용자 → 주문생성 API → (동기 호출) 배달생성 → 경로계산 → 슬랙알림 - 변경 후:
사용자 → 주문생성 API → RabbitMQ로 메시지 전송
→ 컨슈머 1: 배달생성 → 메시지 발행
→ 컨슈머 2: 경로계산 → 메시지 발행
→ 컨슈머 3: 슬랙알림 전송
✅ 기술 적용 흐름
- 주문생성 API에서 메시지를 order.queue에 발행
- 메시지를 받은 컨슈머가 각 단계의 처리를 담당하며, 완료 시 다음 큐로 메시지 전달
- 전체 흐름은 메시지 기반의 엄격한 순차 실행을 유지하면서도, 비동기 처리를 통해 API 간 종속 시간을 제거
✅ 테스트 환경 구성
- JMeter로 TPS 100 이상 유입 테스트 진행
- 처리 완료 기준은 order의 status가 배송완료로 변경되기 까지
- 처리 완료 로그 또는 DB 기록 기반으로 최종 처리량 산정
3. 해결한 문제 및 성과
🎯 주요 성과
평균 처리량 (Throughput) | 26 TPS | 87 TPS | ▲ 234% 증가 |
병목 발생률 | 높음 (API 순차 지연) | 매우 낮음 (비동기 큐 병렬 소비) | 해소 |
API 대기 시간 | 순차적 누적 발생 | 컨슈머 기반 비동기 처리 | 감소 |
🧠 해결한 문제
- 병목 현상 해소:
비동기 구조로 API 간 대기시간 제거 → 시스템 응답 시간 대폭 개선 - 확장성 확보:
컨슈머 수 증가를 통해 자연스러운 수평 확장이 가능해짐 - 유지보수 유리:
각 처리 단계가 독립적인 서비스 단위로 분리되어, 향후 개별 개선 및 로깅, 모니터링이 용이
💡 추가 성능 개선 및 RabbitMQ 사용 이유
- 확장성:
트래픽 증가 시 컨슈머 인스턴스 수만 늘리면 대응 가능 - 유연한 장애 대응:
특정 단계 장애 발생 시 해당 큐만 지연되고, 전체 서비스는 영향 없음 - 비동기 기반 구조 확장성:
이후에도 재고확인, 결제처리, 배송추적 등 다양한 플로우에 유연하게 연결 가능 - 비즈니스 로직 분리:
서비스 간 강결합을 줄이고, 각 단계를 이벤트 중심으로 전환함으로써 **도메인 중심 아키텍처(Domain-driven architecture)**로의 전환 기반 확보RabbitMQ 적용 전 평균 처리량
- RabbitMQ 적용 전 평균 처리량
- RabbitMQ 적용 후 처리량
- 메시징 아키텍쳐
'TIL' 카테고리의 다른 글
캐싱을 통한 성능 개선 (0) | 2025.04.01 |
---|---|
QueryDSL을 활용한 동적 쿼리 최적화 (0) | 2025.03.31 |
RabbitMQ 와 Kafka (0) | 2025.03.07 |
DB인덱싱 (0) | 2025.03.06 |
Cache (0) | 2025.03.05 |