우리 서비스에 메시지 큐 도입이 적절한 이유 - 100-hours-a-week/5-yeosa-wiki GitHub Wiki
1. 현재 구조 요약
- 클라이언트가 이미지 URL 배열을 보내면
- 서버에서 이미지 임베딩 생성 (고비용 작업)
- 그 결과를 캐싱
- 이후에 다양한 후속 작업이 요청됨 (비교적 저비용)
2. 메시지 큐 도입이 적합한 이유
a. 고비용 임베딩 처리의 비동기화 및 과부하 방지
- 현재는 클라이언트가 요청하면 서버가 바로 임베딩 생성 → 응답하는 구조이므로, 동시에 여러 요청이 오면 서버 리소스가 과부하됨
- 메시지 큐를 두고 "요청을 큐에 넣기만 하고 바로 응답"하면, 서버는 폭주하지 않고 차근차근 작업 가능
b. 후속 작업의 비동기 분리
- 중복 그룹화, 필터링, 분류, 하이라이트 추천 같은 후속 작업들을 **각각 독립된 컨슈머(worker)**로 처리하면 모듈화 + 병렬화 가능
- 예: 이미지 임베딩이 끝나면
"embedding_done"
메시지를 큐에 넣고, 후속 작업들은 이 메시지를 보고 동작 시작
3. 메시지 큐가 하는 실제 역할
역할 |
큐에 넣는 메시지 |
누가 넣나 |
누가 꺼내 처리하나 |
임베딩 요청 |
이미지 URL 리스트 |
FastAPI 서버 |
임베딩 워커 |
임베딩 완료 알림 |
캐시된 키 또는 이미지 ID |
임베딩 워커 |
중복/카테고리/하이라이트 워커 |
후속 처리 결과 |
선택적으로 저장/로그 |
각 워커 |
DB 또는 통계 시스템 등 |
4. 구조 예시 (도식 요약)
[Client 요청]
│
▼
[FastAPI 서버] -- "embedding_request" --> [Message Queue] --> [Embedding Worker]
│
└→ "embedding_done" --> [Queue] → [Highlight/Category Worker]
5. 어떤 메시지 큐를 쓸 수 있나?
- Celery + Redis: Python 친화적, 간단한 비동기 태스크 큐
- RabbitMQ: 전통적인 메시지 브로커, 안정적
- Kafka: 고성능 대규모 스트리밍 처리에 적합 (너무 무거울 수 있음)
- AWS SQS: 클라우드 기반 서버리스 큐
6. 결론
- 임베딩 요청을 메시지 큐로 넘기고, 후속 작업은 별도 워커로 분산 처리하는 구조 도입
- 서버 부하를 줄이고 작업을 병렬화하며 시스템을 유연하게 유지