서비스 인프라 확장 & 모니터링 설계 - 100-hours-a-week/16-Hot6-wiki GitHub Wiki

상위 문서로 이동 : AI Wiki

서비스 인프라 확장 & 모니터링 설계

목차

  1. 확장형 배포 아키텍처 다이어그램
  2. 사용 인프라 스택 & 서비스 명세
  3. 모니터링 지표 & 시각화 구성
  4. 간이 부하 테스트 결과
  5. 성장 & 안정적 운영 기여
  6. 부록 — 장애 대응 5-단계 & HPA 적용 예시

1. 확장형 배포 아키텍처 다이어그램

graph TB
  %% Edge
  CDN["CloudFront CDN"] -->|TLS| APIGW["API Gateway"]
  APIGW -->|HTTP| ALB["Application<br/>Load&nbsp;Balancer"]

  %% EKS
  subgraph EKS
    direction TB
    ALB -->|gRPC| APIset["API Pods<br/>FastAPI&nbsp;Routers<br/>HPA 2-6"]
    APIset -->|HTTP| MCPset["MCP Pods<br/>S3 · Athena · 외부API<br/>HPA 1-10"]
    APIset -->|REST| LLMset["LLM Pods<br/>GPU NodeGroup<br/>HPA 1-4"]

    APIset -->|enqueue| RQ["Redis Queue"]
    RQ -->|pull| BGW["Worker Pods"]

    APIset -->|SDK| S3["Amazon S3"]
  end

  %% Observability
  subgraph Monitoring
    Prometheus
    Loki
    Grafana
    Alertmanager
    APIset --> Prometheus
    MCPset --> Prometheus
    LLMset --> Prometheus
    Prometheus --> Alertmanager
    Loki --> Grafana
    Prometheus --> Grafana
  end

  %% CI/CD
  GH["GitHub Actions"] --> ECR["ECR Images"]
  ECR --> Argo["Argo CD"]
  Argo -->|sync| EKS
  Vault["Secrets Manager"] -.-> APIset
  Vault -.-> MCPset
  Vault -.-> LLMset
Loading

2. 사용 인프라 스택 & 서비스 명세

레이어 기술 스택 설정 & 비용(서울 리전, 2025-04 기준)
컨테이너 Docker (distroless) api:1.0 · mcp:1.0 · llm:1.0
오케스트레이션 AWS EKS 1.30 NodeGroup 2종
└ 일반 노드 t3.large 2 vCPU·8 GiB $0.083 / h ≈ $60 / 월
└ GPU 노드 g5.xlarge T4 GPU $1.01 / h ≈ $730 / 월
오토스케일링 HPA + Cluster-Autoscaler CPU 70 % (p95 < 800 ms) 목표 — [공식 가이드]
네트워크 API Gateway + ALB /generated/* → API Pods
스토리지 Amazon S3 (버전 ON) PUT 0.005 USD / 1 k req
CI/CD GitHub Actions → ECR → Argo CD main 푸시 → Blue-Green 배포
비밀 관리 AWS Secrets Manager API Key · IAM 자격증명 주입
모니터링 Prometheus (30 s) + p95 메트릭 15 s
Loki · Grafana · Alertmanager
RED 패턴 대시보드

3. 모니터링 지표 & 시각화 구성

카테고리 핵심 지표 수집 방법 Grafana 패널
API Pods QPS, p95 ms, 4xx/5xx %, CPU % FastAPI middleware + Prom client RED
MCP Pods 외부 API Latency, 실패율 Custom metrics Bar + single-stat
LLM Pods GPU Util %, 추론 ms, VRAM GB DCGM Exporter Histogram
Queue 대기 길이, 처리 속도 redis_exporter Queue depth
클러스터 HPA replicas, 노드 CPU kube-state-metrics Cluster summary
로그 JSON error, req-id Promtail → Loki LogQL 패널
알림 p95 > 1 s (3 m)
5xx > 1 % (3 m)
Alertmanager → Discord ­—

4. 간이 부하 테스트 결과 (Locust)

동접 (VU) 목표 RPS 평균 ms p95 ms 오류 % API replicas LLM replicas
75 120 210 350 0.2 2 1
150 240 330 580 0.4 4 1
300 480 490 830 1.0 6 2

해석

  • 150 VU(예상 피크)에서도 p95 < 600 ms · CPU 60 % → 현재 스펙 OK.
  • 300 VU 피크 시 p95 > 800 ms → LLM max replica 4 → 6 상향 필요.

5. 성장 & 안정적 운영 기여

성장 시나리오 잠재 위험 설계상의 보호 메커니즘
사용자 × 10 API 과부하 ALB + HPA + Cluster-Autoscaler로 선형 확장
모델 2 종 추가 GPU 자원 부족 LLM Deployment 분리, GPU NodeGroup 증설
외부 API 장애 지연 · 타임아웃 MCP Circuit Breaker + 실패율 15 % 알림
빈번한 배포 다운타임 Argo CD Blue-Green + ALB 헬스체크
관측 불가 MTTR 증가 메트릭 30 s + p95 15 s 스크랩, Discord 알림

6. 부록 — 장애 대응 5-단계 & HPA 적용 예시

장애 대응 30 초 플로우

  1. Discord 알림 (p95↑)
  2. Grafana 탐색 (RED 대시보드)
  3. 문제 Pod 로그 확인 kubectl logs
  4. 임시 조치 kubectl rollout restart or 스케일업
  5. Post-mortem 작성 & 재발 방지

HPA 매니페스트 샘플

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-deploy
  minReplicas: 2
  maxReplicas: 6
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
⚠️ **GitHub.com Fallback** ⚠️