1. 왜 메시지 큐를 도입해야 하는가?

a. 핵심 목적

• “비동기 작업을 분산된 워커에서 병렬 처리하고, 처리 상태를 제어/모니터링/복구할 수 있게 하기 위해서”

b. 도입 필요성 요약

이유	설명
확장성 확보	직렬 큐 + 스레드 기반은 단일 프로세스에 묶여 있음. 요청이 많아지면 병목 발생
분산 처리 가능	메시지 큐는 여러 서버에 걸친 워커 분산 실행을 지원함
처리 실패 복구	작업 실패 시 자동 재시도, 지연 처리, 오류 로그 추적 가능
작업 우선순위/스케줄링	작업마다 우선순위 큐 또는 딜레이 큐 사용 가능
모니터링 및 가시성	대기 중인 작업 수, 처리 시간, 실패율 등 시각화 가능 (Flower, Prometheus 등)

---

2. 대표적인 도입 시나리오 5가지

a. 요청량이 급격히 늘어난다

• 사용자가 많아져서 임베딩 + 후속 작업이 폭주

• 직렬 큐 기반 구조로는 서버 한 대가 감당 못함

  → 메시지 큐로 요청을 분산 → 여러 워커가 병렬 처리

b. AI 서버를 여러 대로 수평 확장한다

• 지금은 단일 AI 서버지만, 나중엔 2~3대 이상 필요

  → 메시지 큐 도입 시, 모든 서버가 같은 큐를 구독해서 자동으로 작업 분산처리 가능

c. 일부 작업이 실패하거나 너무 오래 걸린다

• 예: 외부 이미지 다운로드 실패, 잘못된 포맷, 간헐적 timeout

  → 메시지 큐는 작업 실패 시 자동 재시도, 에러 추적, 리트라이 제한 설정 가능

d. 작업 스케줄링이 필요하다

• 예: “30분 뒤에 하이라이트 재평가” 같은 기능 추가

  → 메시지 큐는 countdown, eta, retry 등 지연/예약 실행 지원

---

3. 메시지 큐를 도입해야 하는 결정적 시점 2가지

a. 서버 수를 늘릴 때 (수평 확장)

• 단일 서버에서는 queue.Queue나 asyncio.Semaphore 등으로 과부하를 막을 수 있다.

• 그러나 서버가 여러 대가 되면 큐가 프로세스 간 공유되지 않기 때문에 작업을 균등하게 분산할 수 없음

  → 어떤 서버는 놀고, 어떤 서버는 과부하될 수 있음

• 이럴 때 메시지 큐(RabbitMQ, Redis Queue 등)를 중앙에 두고 각 서버가 큐를 구독하게 만들면 자동으로 Load Balancing 가능

b. 마이크로서비스로 전환할 때

• 마이크로 서비스 : 기능별로 API 서버, embedding 서버, 후속 작업 서버 등을 나눈다

  • API 서버가 embedding 서버로 직접 RPC나 REST 요청을 보내는 구조 → 연동 복잡도 증가, 장애 시 전체 연결망 불안정

  → 메시지 큐를 중간에 두면:

  • API 서버는 단순히 메시지를 큐에 올리기만 하면 됨
  • 실제 처리는 해당 워커 서비스가 담당
  • 느려도 괜찮고, 장애 발생 시에도 복구/재시도 용이

---

4. 결론

• 지금 구조는 “싱글 서버 + 저부하” 상황에 매우 최적화된 형태지만 서비스가 성장하면 메시지 큐가 유일하게 확장성과 안정성 둘 다를 확보해줄 수 있는 선택지