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

1. 아키텍처 개요

본 MVP 설계 빠른 서비스 출시와 기초적인 확장성 확보를 목표로 하였으며, 향후 사용량 증가를 고려한 구조 확장 가능성도 함께 고려하였다.

본 설계의 목표는 다음과 같다.

  • 빠른 MVP 출시를 통한 시장 검증
  • 초기 사용자 트래픽(약 150명)을 안정적으로 수용
  • 향후 사용량 증가에 대비한 확장성 고려
  • 기본적인 운영 및 모니터링 체계 마련

→ 현재 구조는 서비스 기능별 역할 분리(Frontend / Backend / Database) 를 기반으로 한 3-Tier 형태를 따른다. 다만, 초기 단계에서는 프론트엔드와 백엔드가 같은 퍼블릭 서브넷 내에 존재하는 구성이며, 네트워크 레벨 분리는 완전한 3-Tier 형태로 구성되지 않았다.

→ 운영환경(Prod)과 개발환경(Dev)은 동일한 VPC 내에서 독립된 서브넷/인스턴스로 구분하여 관리한다.

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

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

컴포넌트 포트 설명
Next.js (Frontend) 3000 사용자 인터페이스 제공. 사용자 요청을 Backend로 전달
Spring Boot (Backend) 8080 핵심 비즈니스 로직 처리. DB/캐시 접근 및 AI 호출 수행
MySQL 3306 서비스 데이터 저장소
Redis 6379 세션 저장소 및 캐시로 사용
FastAPI (AI) 5000 AI 기능 처리 (Backend로부터 호출됨)

※ FastAPI 서버는 오직 AI 요청을 관리하는 데 집중하며, 모델 추론 자체를 수행하지 않고 외부 Google Gemini API를 호출하여 결과를 받아온다.

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

항목 설정 값 선택 이유
머신 타입 e2-medium (2 vCPU, 4GB RAM) Spring + Next.js + MySQL + Redis + AI 서버가 동시에 실행 가능한 최소 사양
부트 디스크 Ubuntu 20.04 LTS, 30GB LTS 안정성 + MySQL 데이터/로그 저장 공간 확보
영역 asia-northeast3-a (서울) 한국 사용자 대상 최적화 (지연시간 최소화)
외부 IP 자동 할당 외부 SSH 및 서비스 접속을 위한 필수 조건
방화벽 설정 포트 개방 (3000, 5000, 8080, 3306, 6379, 22) 각 서비스 접근 허용을 위해 필수 설정

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

  1. 운영환경 (Production)
    • 퍼블릭 서브넷
      • Nginx, Next.js, Spring Boot, FastAPI
    • 프라이빗 서브넷
      • MySQL, Redis, ChromaDB

트래픽 흐름


외부 요청
    ↓
Nginx (80/443)
    ↓
Next.js (3000) / Spring Boot (8080) / FastAPI (8000)
    ↓
Private Subnet → MySQL (3306), Redis (6379), ChromaDB
  1. 개발환경 (Development)
  • 퍼블릭 서브넷
    • Nginx, Next.js, Spring Boot, FastAPI, MySQL, Redis, ChromaDB 모두 통합

트래픽 흐름


외부 요청
    ↓
Nginx
    ↓
Next.js (3000) / Spring Boot (8080) / FastAPI (8000)
    ↓
서버 내부 통신 → MySQL (3306), Redis (6379), ChromaDB

※ 개발환경에서는 퍼블릭 서브넷 내 단일 서버 구성으로, 빠른 개발/테스트를 우선하였다.

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

v1최종 drawio

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

현재 프로젝트는 GitHub Actions를 활용하여

CI(지속적 통합) 및 CD(지속적 배포) 파이프라인을 구성하였다.

CI/CD 주요 흐름 CI_CD drawio

  • 빌드 산출물(app.jar, 스크립트)은 Google Cloud Storage(GCS)에 저장된다.
  • 배포 실패 시, GCS에 저장된 이전 버전(app-previous.jar)을 통해 수동 롤백이 가능하다.

※ 향후 Docker 기반 컨테이너화 및 블루그린 배포 전략으로 확장을 고려하고 있다.

3. 확장성을 고려한 설계

현재는 단일 Compute Engine 인스턴스에 컨테이너 형태로 모든 서비스를 배포했지만, 다음과 같은 확장 계획을 고려하여 설계했다:

  • Auto Scaling 대비 (추후 예정)
    • Compute Engine Instance Group으로 수평 확장 가능성 열어둠
  • 로드밸런서 확장 예정
    • 현재는 Nginx 단일 Reverse Proxy지만, GCP HTTP(S) Load Balancer로 전환 고려
  • 멀티 AZ 대응 예정
    • 추후 다중 AZ에 서비스 분산 계획
  • DB 확장 고려
    • MySQL Replica 추가 및 Cloud SQL 전환 가능성 고려
  • 캐시 고가용성 고려
    • Redis Cluster 구성으로 확장 가능성 확보
  • AI 확장성 고려
    • FastAPI 서버는 Google Gemini API 호출형이므로 로컬 모델 운영 부담 없음 → 추후 서버 형태로 전환 고려

4. 캐시 전략

  • Redis는 Spring Boot 서버가 직접 관리
  • 사용 예정:
    • 로그인 세션 캐싱
    • 검색 결과 캐싱
  • AI 추론 결과는 MVP 단계에서는 캐싱하지 않음
  • Redis는 프라이빗 서브넷에 배치하여 외부 노출 방지
  • 추후 메세지 큐도 Redis DB에서 관리하고, 더 나아가 메시지 처리 복잡성 증가 시, 전문 메시지 브로커(Kafka) 를 도입하여 이벤트 스트리밍, 장애 복구, 고신뢰 메시지 처리 에 대응할 계획.

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

  • GCP Cloud Monitoring 사용 중
    • Compute Engine VM 단위 모니터링 (CPU, Memory, Disk, Network)
  • 수집 예정 지표:
    • 서버 자원(CPU, Memory, Disk I/O, Network)
    • 어플리케이션 요청 처리 시간 및 에러율
    • DB 쿼리 성능 및 커넥션 수
  • 어플리케이션 레벨 모니터링 (추후 예정)
    • Prometheus Exporter 및 Grafana 도입 고려

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

현재 상태

  • 현재까지 별도의 부하 테스트나 시뮬레이션은 진행되지 않았음.

예정 사항

  • Apache Benchmark(ab) 또는 k6를 이용하여 부하 테스트 수행 예정
  • 테스트 계획
    • 동시 사용자 150명 기준 시스템 안정성 검증
    • 동시 사용자 수별 서버 응답 시간 측정
    • CPU/Memory 사용률에 따른 임계점 분석
    • 최대 수용 가능 트래픽 수치 측정
  • 테스트 결과에 따라 Auto Scaling 정책 및 서버 리소스 증설 계획 수립 예정

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

  • Auto Scaling 도입 준비
    • 트래픽 증가 시 인스턴스 자동 확장 구성
  • 로드밸런서 확장
    • GCP 글로벌 Load Balancer 도입으로 장애 대응력 향상
  • 데이터베이스 이중화
    • Read Replica 및 백업 정책 강화
  • 모니터링 고도화
    • Prometheus/Grafana 기반 실시간 모니터링 및 알람 체계 구축 예정