RabbitMQ 기반 비동기 아키텍처 도입 성능 개선 사례

✅ 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 적용 후 처리량

 

• 메시징 아키텍쳐