서비스 인프라 확장성과 모니터링 설계 [V2] - 100-hours-a-week/6-nemo-wiki GitHub Wiki

1. 아키텍처 개요

본 설계는 초기 1단계 MVP 버전을 개선하여 고가용성, 확장성, 보안성을 고려한 GCP 기반 3-Tier 아키텍처를 구축하는 것을 목표로 한다.

설계 목표:

  • 완전한 3-Tier (Frontend, Backend, Database) 구조 분리
  • 서비스(VPC1)와 AI(VPC2) 완전 분리 및 VPC Peering 연결
  • Docker 기반 컨테이너화 및 표준화된 배포
  • AutoScaling 그룹 기반 수평 확장성 확보
  • HTTPS Load Balancer 도입 및 SSL 종료 처리
  • Cloud CDN, WAF(Cloud Armor), DNS를 통한 글로벌 가속 및 보안 강화
  • GCR/GCS 기반 배포 파이프라인 구축
  • 메시지 큐(Redis 기반) 도입으로 알림톡 기능 지원

운영환경(Prod)과 개발환경(Dev)을 완전히 분리하여, 독립된 인프라로 관리한다.

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

2-1. 주요 서비스 구성 요소

컴포넌트 내부 포트 설명
Next.js (Frontend) 3000 사용자 인터페이스 제공
Spring Boot (Backend) 8080 비즈니스 로직 처리 및 DB/AI 연동
MySQL (Cloud SQL) 3306 고가용성 데이터 저장소
Redis 6379 세션, 캐시, 메시지 큐 저장소
FastAPI (Local LLM) 8000 텍스트 생성, 질문응답, 요약 등
ChromaDB - 벡터 데이터 저장소 (AI 서버용)

※ Cloud HTTPS Load Balancer가 모든 외부 요청을 443(HTTPS) 포트로 수신하며,

내부적으로는 서비스별 포트로 트래픽을 분배한다. 사용자는 포트를 인식할 필요가 없다.

2-2. 인프라 환경 및 사양

항목 설정 값
클라우드 Google Cloud Platform (GCP)
컴퓨트 Compute Engine (MIG AutoScaling)
컨테이너화 Docker 단일 컨테이너 구동
레지스트리 Google Container Registry (GCR)
스토리지 Google Cloud Storage (GCS)
데이터베이스 Cloud SQL (MySQL, HA 구성)
메시지 큐 Redis (Spring Boot 연동)
모니터링 Cloud Monitoring
보안 HTTPS Load Balancer + Cloud Armor + Cloud CDN + Cloud DNS

2-3. 네트워크 구성 및 트래픽 흐름

운영환경 (Production)

  • VPC1 (서비스용)
    • 퍼블릭 서브넷: HTTPS Load Balancer → Next.js, Spring Boot 컨테이너
    • 프라이빗 서브넷: Cloud SQL, Redis
  • VPC2 (AI용)
    • 프라이빗 서브넷: FastAPI, ChromaDB

트래픽 흐름

사용자 요청
    ↓
Cloud DNS
    ↓
Cloud CDN (글로벌 캐시 가속)
    ↓
Cloud Armor (WAF 보안 필터링)
    ↓
HTTPS Load Balancer (SSL 종료 및 라우팅)
    ↓
Next.js (3000) / Spring Boot (8080)
    ↓
Private Subnet → Cloud SQL (3306), Redis (6379)
    ↓
VPC Peering → FastAPI (8000), ChromaDB

※ 개발환경(Dev)에서는 하나의 인스턴스에 모든 컴포넌트(Next.js, Spring Boot, FastAPI, Chroma, MySQL, Redis)를 통합하여 운영한다.

2-4. 아키텍처 다이어그램

V2 _final drawio

2-5. CI/CD 자동화 구성

  • GitHub Actions를 통한 CI/CD 파이프라인 구축
  • 빌드 → Docker 이미지 생성 → GCR Push
  • GCS에 배포 스크립트 및 로그 파일 저장
  • 서버는 GCR Pull 후 Docker Container 재구동
  • Health Check 자동 검증

CI/CD 흐름 요약


GitHub Push
    ↓
GitHub Actions (Docker Build → GCR Push)
    ↓
GCS에 배포 스크립트 저장
    ↓
서버에서 Pull → Docker Container 구동
    ↓
Health Check 검증
  • develop 브랜치: 자동 배포 (Continuous Deployment)
  • 전 단계와 다르게 Docker build를 한 다음 GCR에 푸시함
  • main 브랜치: 수동 승인 후 운영 배포 (Continuous Delivery)

CICD최최종 drawio

2-6. FastAPI 자체 모델 설계

  • 핵심 역할
    1. Redis 캐시 조회 후 재사용 가능한지 확인
    2. 로컬 LLM 모델 호출
    3. 응답 결과를 Redis에 저장
    4. 최종 결과를 반환
  • 요청/응답 흐름
    1. Spring Boot → FastAPI로 REST 요청 전송
    2. FastAPI → Redis 조회
    3. 캐시 미스 → LLM 모델 추론
    4. Redis 저장 → 최종 결과 반환
  • 전체적 흐름

1. 사용자가 요청을 보냄
2. 요청 키(Request Key)를 Redis에서 조회
3.
   - 캐시 HIT (존재하면) → 저장된 추론 결과 바로 반환
   - 캐시 MISS (없으면) → FastAPI가 LLM 모델로 직접 추론
4. 새로 얻은 추론 결과를 Redis에 저장
5. 결과 반환

3. 확장성을 고려한 설계

  • MIG 기반 Compute Engine AutoScaling 구성
  • Multi-AZ 분산 운영 (Azone, Czone)
  • Cloud SQL 고가용성 이중화 (Primary-Standby)
  • FastAPI 및 ChromaDB 별도 VPC에서 이중화
  • Docker 이미지 기반 일관성 있는 배포
  • 향후 Kubernetes(GKE) 클러스터 확장 고려

4. 캐시 및 메시지 큐 전략

  • Redis를 Backend(Spring Boot) 서버가 직접 연동
  • 사용 예정:
    • 로그인 세션 캐시
    • 검색 결과 캐시
    • 알림톡 메시지 큐 처리
    • AI 모델 추론 결과
    • 검색 결과(Chroma DB)
  • 현재는 Redis DB를 그대로 사용, 향후 대규모 트래픽 시 Kafka로 전환 계획

5. 모니터링 및 지표 수집/시각화 방안

  • Cloud Monitoring 및 Logging 기본 사용
  • 수집 지표:
    • CPU, Memory, Disk, Network
    • Application 응답 시간 및 에러율
    • Database 성능 및 연결 수
  • 향후 Prometheus + Grafana로 어플리케이션 레벨 모니터링 고도화 예정

6. 부하 테스트 및 시스템 자원 분석

  • Apache Benchmark(ab), k6 등을 통한 부하 테스트 예정
  • 주요 목표:
    • 동시 사용자 150명 이상 수용성 테스트
    • AutoScaling 조건 임계점 검증
    • 최대 트래픽 수용량 측정

7. 향후 성장 및 안정적 운영을 위한 계획

  • 쿠버네티스 도입 및 AWS 전환
  • GKE 기반 오케스트레이션 전환 준비
  • 멀티 리전 기반 DR(Disaster Recovery) 설계
  • Redis Cluster 고가용성 구성
  • Blue-Green / Canary 배포 전략 적용
  • 멀티 클라우드(AWS 이전 고려) 아키텍처 대응