#2 내가 API 내부에서 파일을 처리하는 대신 BullMQ를 선택한 이유

Source: Dev.to

파일 변환 및 공유 앱을 만들면서, 처음 구현에서는 파일 변환을 API 요청 안에서 직접 처리했습니다.
동작했습니다.

하지만 파일 크기가 커지면서, 서버가 파일을 처리하느라 수백 밀리초 동안 요청이 열려 있었습니다.

문제는 변환 자체가 아니라, 사용자가 동기적으로 일어날 필요가 없는 작업을 기다리고 있었던 것입니다.

그래서 파일 변환을 Redis를 백엔드로 하는 BullMQ 워커로 옮겼습니다.

흐름은 다음과 같이 바뀌었습니다:
Upload → BullMQ에 작업 추가 → API가 즉시 응답 → 워커가 파일 처리 → 상태 업데이트 → 사용자가 결과 수신

BullMQ가 여기서 더 잘 작동한 이유:

• 더 빠른 API 응답
• 무거운 파일 처리와 요청 처리를 분리
• 워커 동시성을 통한 향상된 확장성
• 큐에 내장된 재시도 및 실패 처리
• 부하가 걸렸을 때 더 예측 가능한 시스템 동작

로드 테스트 결과

• API p95 지연 시간이 212배 감소 (800 ms → 3.8 ms)
• 처리량이 4.8배 증가 (1.3 → 6.2 요청/초)
• 동시 20개의 요청으로 테스트

트레이드오프:

• 추가 인프라(Redis + 워커)
• 운영 복잡도 증가
• 즉시 완료가 아닌 최종 일관성

모든 요청이 즉각적인 응답을 필요로 한다면, 동기 처리​가 여전히 더 간단한 선택일 수 있습니다.

이는 성능 향상이 작업 자체를 더 빠르게 만드는 것보다 중요한 요청 경로에서 작업을 분리함으로써 얻어지는 경우가 많다는 좋은 교훈이었습니다.