1. 문제 제기

[ "여러 인스턴스에서 동시에 GPU 스타일 변환 요청이 발생하면, GPU 서버에 과도한 부하가 집중되어 병목이 생기지 않을까?" ]

• 처음에는 하나의 FastAPI 인스턴스만 GPU 서버에 요청을 전송하는 구조였기 때문에,
  • 서비스가 다중 인스턴스로 확장되면 모든 인스턴스가 동시에 GPU 서버에 요청을 보내는 상황이 발생할 수 있다.
• 이때 GPU 서버의 연산 자원이 포화되어 지연, 타임아웃, 실패 등의 문제가 발생할 수 있다.
• 그래서 "Redis 메시지 큐를 도입해 GPU 요청을 일정하게 조절하고, 병렬 처리량을 제한하는 방식으로 안정적인 처리가 가능하지 않을까?" 하는 해결 방안을 검토하게 되었다.

---

2. 방안

a. 다중 인스턴스에서 Redis를 인메모리로 띄워 각각 메시지 큐를 도입하는 방식(기존)

• 각 인스턴스가 Redis를 자체 인메모리로 띄우면, 큐는 인스턴스 간에 공유되지 않음
• 결과적으로 GPU 서버에 중복 요청이 발생하거나, 요청 순서가 꼬일 위험
• 캐시 역시 인스턴스별로 분리되기 때문에, 중복 임베딩/중복 추론 발생 가능성
• 이 방식은 단일 인스턴스에서는 유효하지만, 다중 인스턴스 확장 시에는 안정성을 보장할 수 없음

b. GPU 서버에 Redis를 인메모리로 띄우는 방식

• 하나의 GPU 서버가 Redis 큐 + 추론 워커 역할을 모두 수행
• 모든 FastAPI 인스턴스가 해당 GPU 서버의 Redis에 요청을 넣는 구조

가. 장점

• 빠르게 구성 가능
• 별도 Redis 관리 불필요

나. 단점

• 병목 지점이 GPU 서버로 집중됨
• Redis 장애 시 전체 태스크 중단
• 확장성 및 장애 대응 어려움

다. 결론

• MVP 단계에서는 고려 가능하지만, 장기적으로는 권장되지 않음

c. Redis 서버를 따로 두는 방식 (권장)

• Redis 서버를 중앙에서 독립적으로 운영 (ex. GCP Cloud Memorystore, 독립 VM 등)
• 모든 FastAPI 인스턴스와 Worker가 이 Redis를 바라보며 큐와 캐시를 공유

가. 장점

• 큐/캐시 공유 → 요청 중복 방지
• Worker 수 조절로 병렬성/부하 조절 가능
• 다중 GPU 서버로 확장 가능
• 실질적인 메시지 큐 도입 구조로, 가장 안정적이고 확장성 높은 구성

---

3. 메시지 큐 도입 방식 비교

방식	장점	단점	적합한 경우
각 인스턴스마다 Redis 인메모리로 운영	구성 단순	큐/캐시 분리, 확장성 없음	단일 인스턴스 환경
GPU 서버에 Redis 포함	빠른 구성	병목 집중, 장애 대응 어려움	테스트/MVP 환경
중앙 Redis 서버 운영	안정적, 공유 가능	Redis 인프라 추가 필요	실서비스, 스케일링 구조

---

4. 최종 정리

• GPU 요청과 같은 외부 요청 제어가 필요한 작업은 반드시 공유 가능한 Redis 메시지 큐를 통해 관리해야 한다.