[AI] 7단계: 서비스 인프라 확장성과 모니터링 설계 - 100-hours-a-week/2-hertz-wiki GitHub Wiki
목차
- 1. 확장성을 고려한 배포 아키텍처 다이어그램
- 2. 사용한 인프라 기술 및 서비스 명세
- 3. 모니터링 대상 지표 목록 및 수집/시각화 방법
- 4. 간이 부하 테스트/시뮬레이션 결과
- 5. 서비스의 향후 성장 및 운영에 대한 기여 전망
확장성을 고려한 배포 아키텍처 다이어그램
설계
최종 아키텍처
| 기능 | 모델 | 인프라 | 서빙 방식 |
|---|---|---|---|
| 유저 추천 매칭 | ko-sbert-nli |
GCP e2-standard-4 × 1, SSD 50GB, ChromaDB | Docker + FastAPI |
| 튜닝 리포트 생성 | Qwen2.5-7B |
NVIDIA L4 32GB, CUDA 12.1 | GPU VM |
| 채팅 클린봇 | KcELECTRA-small-v2022 |
GCP e2-standard-4 × 1, SSD 30GB | Docker + FastAPI |
설계 목표: 서비스 기능별로 독립 확장 가능하도록 구성하여 장애 격리 및 비용 효율성 확보
사용한 인프라 기술 및 서비스 명세
| 구성 요소 | 사용 기술 / 서비스 | 설명 |
|---|---|---|
| 클라우드 플랫폼 | Google Cloud Platform (GCP) | 전체 인프라 호스팅 및 네트워크 관리 |
| 컨테이너 환경 | Docker (CPU 전용) | CPU 기반 모델 서버 및 API 서버를 컨테이너화하여 수평 확장 가능 |
| 모델 서빙 (CPU) | FastAPI + Python 추론 코드 (Docker) | 경량 모델 (ko-sbert, KcELECTRA 등)을 Docker 컨테이너 내에서 FastAPI 서버로 서빙 |
| 모델 서빙 (GPU) | FastAPI + Python 추론 코드 (비컨테이너) | Qwen 등 고성능 LLM을 GPU VM에서 FastAPI 서버로 서빙, 일시적 실행 |
| 기타 연동 | Google Search, Spotify, YouTube API | MCP 로직 내 외부 정보 검색용 API 연동 |
모니터링 대상 지표 목록 및 수집/시각화 방법
| 카테고리 | 지표 항목 | 수집 도구 | 시각화/알림 도구 |
|---|---|---|---|
| API 응답 성능 | 평균 응답 시간, p95/p99 Latency, RPS | FastAPI + Prometheus client | Grafana |
| 모델 추론 성능 | 추론 처리 시간, 요청당 Token 수, 실패율 | Custom Prometheus metric | Grafana |
| 시스템 자원 | CPU/RAM 사용률, 디스크 IOPS, 네트워크 I/O | Node Exporter (Linux agent) | Grafana |
| GPU 자원 (Qwen) | GPU 메모리 사용량, GPU Utilization | NVIDIA DCGM Exporter | Grafana |
| ChromaDB 상태 | 벡터 검색 Latency, Index Size, 쿼리 수 | Prometheus Exporter (custom) | Grafana |
| 에러/예외 로그 | 4xx/5xx 발생 수, StackTrace, Timeout 로그 | Stackdriver / Sentry | Grafana Alerts / Sentry |
| 서비스 헬스체크 | 서버 상태, 헬스체크 실패 수 | GCP Load Balancer / Uptime | Cloud Monitoring Alerts |
| Queue 상태 (선택) | 리포트 요청 큐 길이, 처리 시간 | Celery Exporter + Redis | Grafana |
→ 기능별 Grafana 대시보드를 구성하여 실시간 모니터링 + 경고 알림 가능
간이 부하 테스트/시뮬레이션 결과
📍 시뮬레이션 환경: 1분간 RPS 증가 부하 테스트
| 기능 | 동시 요청 수 | 평균 응답 시간 | 자원 사용률 | 요약 결과 |
|---|---|---|---|---|
| 유저 추천 매칭 | 30 RPS | 200~350ms | CPU 70% | Chroma 쿼리 부하 주의 |
| 튜닝 리포트 생성 | 직렬 처리(Batch size 1) | 20.0s | GPU 65% | 큐 처리 필수 |
| 채팅 클린봇 | 50 RPS | 120~250ms | CPU 65% | 안정적 처리 |
서비스의 향후 성장 및 운영에 대한 기여 전망
현재 인프라 설계는 초기 단계에 최적화된 자원 구성과 미래 성장을 고려한 확장성을 균형 있게 반영하고 있습니다.
-
CPU 기반 모델 서버는 비용 효율성과 수평 확장을 모두 충족할 수 있도록 Docker 기반 컨테이너로 운영되며,
서버 수요 증가 시 복제 및 배포만으로도 신속한 대응이 가능합니다. -
GPU 모델 서버는 상대적으로 높은 비용을 고려해 컨테이너화하지 않고,
사용량이 적은 시간대에 일시적으로 가동되도록 하여,
고성능 추론 기능은 유지하면서도 불필요한 비용 소모를 방지하는 구조로 설계되었습니다. -
로드밸런서와 오토스케일링 기능은 현재 도입하지 않았지만,
향후 요청량 증가 시 쉽게 확장할 수 있도록 네트워크 구성과 배포 환경을 유연하게 사전 설계해두었습니다.
결론
이러한 구조는 서비스 초기의 낮은 트래픽과 예측 가능한 처리량에 최적화되어 있으며,
향후 사용자 수와 요청량이 증가하더라도 서비스 중단 없이 안정적으로 확장 가능한 기반을 이미 확보하고 있습니다.