사용자 요청
↓
RabbitMQ Queue (FIFO 적재)
↓
Consumer → DB 예약 처리
현재 구조에서 선착순 보장은 RabbitMQ FIFO로 해결됐지만, 하나의 비효율이 존재했다.
핫스팟 문제: 100명이 10석 슬롯에 동시 요청하면, 90건은 실패가 확실한데도 Consumer가 하나씩 꺼내 DB 조회 후 실패 처리해야 한다.
오픈런 시나리오를 통해 실제 부하 테스트를 진행해서, 얼만큼의 비효율이 발생하는지 실제로 확인했다.
Micrometer 커스텀 메트릭(Consumer 처리 결과별 카운터)
| 항목 | 수치 |
|---|---|
| Consumer 처리 총량 | 100건 전부 큐 통과 |
| 성공 | 10건 |
| 거절 | 90건 (낭비 비율 90%) |
| Consumer 평균 처리시간 | 40.59ms/건 |
| 전체 Consumer 소요 | 4.9초 |
측정된 비효율이 실제로 사용자에게 영향을 주는가?
현재 구조는 MQ 기반 비동기 처리이기 때문에, 사용자 경험과 Consumer 처리 시간은 분리되어 있다.
| 대상 | 경험 |
|---|---|
| 성공한 10명 | 202 즉시 수신 → 비동기로 확정 알림 |
| 실패한 90명 | 202 즉시 수신 → 비동기로 실패 알림 |
→ Consumer의 4.9초 낭비는 사용자가 기다리는 시간이 아니고 백그라운드 처리 시간이다.
즉, 현재 규모에서 이 비효율은 사용자 경험에 직접적인 영향을 주지 않는다.