[AI] 10_인프라_확장성_모니터링 - 100-hours-a-week/9-team-Devths-WIKI GitHub Wiki
단계 7: 서비스 인프라 확장성과 모니터링
확장 가능한 배포 아키텍처 및 모니터링 체계 설계
Why: 우리 서비스에 왜 필요한가?
개발 환경과 운영 환경은 다릅니다. 실제 사용자 트래픽을 처리하려면:
- 확장성: 사용자 증가 시 자동 대응
- 안정성: 장애 발생 시 빠른 복구
- 가시성: 실시간 성능 모니터링
인프라 진화 로드맵
| 버전 |
구성 |
스케일링 |
모니터링 |
| V1 (MVP) |
EC2 + Docker |
수동 |
기본 로깅 |
| V2 |
Docker Compose + RunPod |
수동 (replica) |
Grafana |
| V3 |
Kubernetes (GKE/EKS) |
자동 (HPA) |
Prometheus + Grafana |
V3 목표 아키텍처
┌─────────────────────────────────────────────────────────────────┐
│ Kubernetes Cluster │
│ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ AI Server Deployment (HPA: CPU > 70%) │ │
│ │ ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ │ │
│ │ │ Pod 1 │ │ Pod 2 │ │ Pod 3 │ │ Pod N │ ← Auto Scale │ │
│ │ └───────┘ └───────┘ └───────┘ └───────┘ │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌─────────▼─────────┐ │
│ │ Ingress / LB │ │
│ └───────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
모니터링 지표
| 지표 |
경고 임계값 |
수집 방법 |
| P95 응답 시간 |
> 10초 |
API 로그 |
| 에러율 |
> 5% |
로그 집계 |
| CPU 사용률 |
> 80% |
cAdvisor |
| API 비용 |
> $10/일 |
API 로그 |
예상 트래픽 및 인프라 계획
| 단계 |
DAU |
동시 사용자 |
인프라 |
| MVP |
100명 |
10명 |
EC2 1대 |
| V2 |
1,000명 |
50명 |
EC2 2대 |
| V3 |
10,000명 |
200명 |
K8s (HPA) |
결론
- 점진적 확장: V1 → V2 → V3 단계적 진화
- 자동 대응: HPA로 트래픽 변동 자동 처리
- 가시성 확보: 실시간 모니터링으로 문제 조기 발견