제안한 인프라/모니터링 설계가 팀 서비스의 향후 성장과 안정적 운영에 어떻게 기여하는지에 대한 설명

1. 사용자 수 100배 증가에도 대응 가능한 확장성 확보

MIG 기반 오토스케일링 인프라를 도입하여, 트래픽 급증 상황에서도 서비스 중단 없이 확장 가능하도록 설계

• FastAPI 서버는 Managed Instance Group으로 구성되어 CPU 사용률 조건에 따라 자동으로 인스턴스를 수평 확장함
• 인스턴스 템플릿은 Docker 기반으로 정의되어 있어, 인프라가 증가해도 환경 일관성을 유지
• 향후 사용자 수가 10배, 100배까지 증가하더라도, 클러스터 자동 확장을 통해 요청 처리가 지연 없이 가능

사용자 수 100배 증가 시에도, FastAPI 인스턴스는 1대 → 최대 3대까지 자동 확장되며, Nginx가 적절히 트래픽 분산시켜주기 때문에 서비스 중단 없이 처리량 증가에 유연하게 대응

---

2. AI 스타일 변환 서버의 독립성과 확장 대비 구조

• Stable Diffusion GPU 서버는 FastAPI와 분리된 인스턴스에서 독립적으로 운영되어, 비동기 요청 처리와 리소스 간섭 방지가 가능
• GPU 스타일 변환은 대기열 기반으로 처리되며, 향후 처리량 증가에 따라 GPU 서버를 별도 확장하거나 큐 기반 작업 분산도 가능

스타일 변환 요청이 몰려도 FastAPI 서버에는 영향이 없고, GPU 서버만 수평 확장하거나 워커 분산으로 처리 가능

---

3. 실시간 관측 체계를 통한 장애 대응력 강화

Prometheus + Grafana + Alertmanager를 통한 모니터링 체계는 장애를 사전에 예측하고,

즉시 대응할 수 있도록 하여 운영 안정성과 가용성을 극대화

• FastAPI 요청 지연 시간(P95, P99), Redis 큐 대기량, GPU 메모리 사용률 등 핵심 지표 실시간 추적
• Grafana에서 서비스 병목 시각화 및 Alertmanager를 통해 Slack 실시간 알림 구성
• 자동 알림 기반 운영 체계 유지

Redis 큐가 100건 이상 쌓이면 Slack에 즉시 알림 전송되어 워커 병목을 빠르게 인지하고 대응할 수 있음

---

4. 장애 격리 및 내부 통신 안정성 확보

• FastAPI, Redis, Exporter 등은 모두 내부 IP 기반 통신으로 네트워크 비용 및 보안 이점 확보
• 각 인스턴스는 독립적인 역할을 수행하도록 설계되어, 한 구성요소의 장애가 전체 시스템에 영향을 주지 않음

---

5. 관측 기반의 데이터 축적 → 성능 개선에 활용 가능

• Prometheus에 수집된 시계열 데이터는 장기적으로 분석하여 서비스 확장/리팩터링의 기준이 됨
• 예: CLIP 임베딩 평균 처리 시간, GPU 스타일 변환 대기 시간, 사용자 요청 피크타임 등을 바탕으로 AI 서버 증설 시점 예측 가능