서비스 인프라 확장성과 모니터링 설계 - 100-hours-a-week/KTB4-1st-wiki GitHub Wiki

단계 7. 서비스 인프라 확장성과 모니터링 설계

범위: AI Server(FastAPI, CPU) + ChromaDB + 기능6의 Modal 서버리스(vLLM). Backend·DB는 범위 밖.

1. 배포 아키텍처

graph TD
    subgraph Server["서버 (단일 인스턴스)"]
        AI["AI Server<br/>(Docker, FastAPI, 임베딩 모델)"]
        CHROMA[("ChromaDB<br/>인메모리, AI Server와 같은 프로세스")]
        AI --- CHROMA
    end

    Server -->|API 호출| CLAUDE["Claude API<br/>(외부 서비스)"]
    Server -->|API 호출, 기능6 v2| MODAL["Modal 서버리스 + vLLM<br/>(외부 서비스)"]
Loading

AI 서버와 ChromaDB는 같은 서버 안에 함께 둔다 — ChromaDB는 별도 서버가 아니라 AI 서버 프로세스 안에서 라이브러리 형태로 동작하는 인메모리 컴포넌트다. Claude API와 Modal은 우리가 배포·관리하는 대상이 아니라, API로 호출해서 가져다 쓰는 외부 서비스이므로 별도 박스로 명확히 구분한다.

  • 서버 1대로 충분: 프로젝트 규모(교육과정, 예산 36만원/3달)에서 다중 인스턴스·오토스케일은 오버엔지니어링으로 판단해 제외
  • ChromaDB는 AI 서버와 같은 프로세스 안에 있어 별도 네트워크 통신이 필요 없음
  • Modal은 Modal Labs가 자체적으로 서버리스 인프라를 관리하므로, 우리 쪽에서는 API를 호출하는 방식으로만 연동하고 내부 운영은 신경 쓸 필요가 없음

2. 인프라 기술 및 서비스 명세

구성요소 기술 이유
컨테이너화 Docker AI 서버 이미지 1개(경량, GPU 불필요)
배포 단일 서버 인스턴스 (예: AWS EC2 — [확정 필요]) 소규모 트래픽에 다중 인스턴스·오토스케일이 불필요하다는 피드백 반영, 배포 구조를 단순화
ChromaDB AI 서버와 같은 서버에 함께 배치 별도 서버·네트워크 통신 없이 인메모리로 즉시 접근
기능6(v2) 서빙 Modal (서버리스 GPU, 외부 서비스) Modal이 자체적으로 인프라를 관리하므로 이 부분은 API 연동만 신경 쓰면 됨
가격 캐시 Backend DB AI 서버 범위 밖

3. 모니터링 지표 및 수집·시각화

지표 대상 이유
응답시간 p50/p95 전체 엔드포인트, 특히 /api/registration/process 기능3(가격검색)은 지연 편차가 큼(45.9초 관측 사례) — p95 감시 중요
internal_error 발생률 전체 엔드포인트 Claude API 장애·rate limit 감지
Claude API 호출 횟수·비용 기능1,2,3,4, 기능5·6 v1 예산 관리(36만원/3달)
캐시 히트율 기능3 (Backend 쪽 지표) 캐싱 최적화 효과 검증
ChromaDB 검색 지연 기능4 RAG 응답 지연 기여도 확인
Modal 콜드스타트 빈도·지연 기능6(v2) 서버리스 특성상 첫 요청 지연 가능
서버 CPU·메모리 사용률 서버 전체 단일 인스턴스가 감당 가능한 트래픽 한계 파악

수집/시각화: 응답시간·에러율·CPU/메모리 사용률은 배포 클라우드가 기본 제공하는 모니터링 서비스(예: AWS 기준 CloudWatch)로 확인한다. Claude API 호출 횟수·비용은 Anthropic 콘솔에서 확인한다. ChromaDB 검색 지연은 AI 서버 코드에서 직접 로깅한다. 캐시 히트율은 Backend가 자체 집계한다. Modal 콜드스타트 빈도·지연은 Modal 자체 대시보드로 확인한다.

4. 부하 테스트 계획

  • Claude API 키 미발급 상태라 실측 대신 계획만 우선 제시 [측정 예정]
  • 저비용 엔드포인트(/api/moderation/check-text 단독)부터 동시요청 시뮬레이션(locust 등)
  • 측정 목표: 단일 서버가 감당 가능한 동시 요청 한계치, /api/registration/process(기능2+3 체이닝)의 종단 지연시간, rate limit(429) 발생 지점
  • 부하테스트 결과 서버 1대로 감당 안 되는 수준의 트래픽이 확인되면, 그때 다중 인스턴스·오토스케일 도입을 재검토

5. 성장 대응 설명

  • 지금은 트래픽 규모가 작아 서버 1대로 충분하다고 판단했으며, 이는 인프라를 단순하게 유지해 운영·비용 부담을 최소화하려는 선택이다.
  • 실질적 병목은 인프라보다 Claude API 자체의 rate limit일 가능성이 높다 — 서버를 늘리는 것보다 캐스케이드(기능2)·캐싱(기능3)으로 호출량 자체를 줄이는 게 더 근본적인 확장성 대책이다.
  • 기능6(v2, Modal)은 트래픽이 늘어도 Modal이 자체적으로 스케일을 담당해, 우리 쪽 인프라 설계 부담이 없다.
  • 트래픽이 실제로 늘어나 서버 1대로 부족해지면, 그 시점에 다중 인스턴스·오토스케일 구조로 전환을 검토한다 — 처음부터 과도하게 설계하지 않고, 필요해졌을 때 확장하는 방향.
⚠️ **GitHub.com Fallback** ⚠️