우리 서비스에 메시지 큐 도입이 적절한 이유 - 100-hours-a-week/5-yeosa-wiki GitHub Wiki

1. 현재 구조 요약

  1. 클라이언트가 이미지 URL 배열을 보내면
  2. 서버에서 이미지 임베딩 생성 (고비용 작업)
  3. 그 결과를 캐싱
  4. 이후에 다양한 후속 작업이 요청됨 (비교적 저비용)

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. 결론

  • 임베딩 요청을 메시지 큐로 넘기고, 후속 작업은 별도 워커로 분산 처리하는 구조 도입
    • 서버 부하를 줄이고 작업을 병렬화하며 시스템을 유연하게 유지