7. 서비스 인프라 확장성과 모니터링 설계 - 100-hours-a-week/20-real-wiki GitHub Wiki
1. 확장성을 고려한 배포 아키텍처 다이어그램
구성 설명:
- FastAPI 서버 + Qwen 2.5-7B-Instruct 모델을 Docker 컨테이너로 패키징
- GCP Compute Engine (L4 GPU) 기반으로 모델 서빙
- vLLM 서빙 구조 고려 → 비동기 요청 최적화 및 높은 동시성 지원
- GCP Load Balancer를 통해 트래픽 분산
- Managed Instance Group (MIG) + 오토스케일링 사용: CPU/GPU 사용률, 동시 요청 수를 기반으로 인스턴스 수 자동 조절
아키텍처 흐름:
2. 사용한 인프라 기술 및 서비스 명세
| 항목 | 내용 |
|---|---|
| 서버 | GCP L4 GPU 인스턴스 |
| 컨테이너 | Docker |
| 서빙 엔진 | FastAPI + (vLLM 고려) |
| 트래픽 분산 | GCP Load Balancer |
| 오토스케일링 | Managed Instance Group (CPU/GPU 사용률 기반) |
| 모니터링 스택 | Prometheus + Grafana + Discord Alert 연동 |
| 로깅 | GCP Logging + Loki(선택 가능) |
3. 모니터링 대상 지표 및 수집/시각화 방법
| 영역 | 지표 | 수집 방법 | 시각화 방법 |
|---|---|---|---|
| LLM 서버 성능 | 응답 시간, 동시 처리 수, 99th latency | Prometheus Exporter | Grafana 대시보드 |
| 모델 리소스 사용 | CPU 사용률, GPU 사용률, 메모리 사용량, 토큰 사용량 | NVIDIA DCGM Exporter + Node Exporter | Grafana |
| API 호출 | 호출 수, 실패율, 요청 경로 분석 | FastAPI Middleware + Prometheus | Grafana |
| 사용자 행동 | 기능별 사용량, 도구 호출 경로 | FastAPI 분석로그 + Loki (선택) | Grafana |
| 경고 알림 | 서버 상태 이상, 응답 지연 | Alertmanager → Discord Webhook | Discord 채널 알림 |
4. 간이 부하 테스트 계획
- 도구: locust 사용 (HTTP 부하 테스트)
- 시나리오:
- 1초에 100명 사용자가 챗봇 질문을 보내는 시뮬레이션
- 요청당 평균 응답시간, 99th 퍼센타일 응답시간, 서버 리소스 소모량 측정
- 성공 기준:
- 99th percentile latency < 2초
- GPU Memory Usage < 80%
- CPU Usage < 70%
5. 제안한 인프라/모니터링 설계가 팀 서비스에 기여하는 방식
- 빠른 대응성: 트래픽이 몰리는 특정 시간대에도 자동 확장으로 끊김 없이 응답 제공
- 안정적 운영: 서버 리소스 모니터링과 실시간 알림을 통해 장애를 조기에 감지하고 대응 가능
- 성장 대응성: 향후 사용자 수가 10배 증가하더라도 (ex: 카테부 외부 개방 등) 인프라 수평 확장만으로 대응 가능
- 비용 최적화: 사용량에 따라 인스턴스 수 자동 조절 → 과도한 리소스 낭비 방지
- 개발자 생산성: vLLM 기반 서빙으로 높은 동시성 확보 → 서버 튜닝 비용 최소화