Day2. Infra Architecture

개요

프로젝트에 사용할 기술 스택을 다음과 같이 결정했다.

• 백엔드: Spring Boot (주요 로직 처리), FastAPI (AI 모델 서빙용)
• 프론트엔드: React (사용자 인터페이스)
• 모델 서빙: OpenAI GPT 모델 (추천 및 가사 생성)
• 데이터베이스: PostgreSQL + Vector DB(Redis)
• 컨테이너화: Docker Compose (모든 서비스의 관리 및 배포 용이)
• 웹 서버 : Nginx(리버스 프록시, 정적 파일 서빙)

이제 배포에 필요한 인프라 아키텍처를 설계할 차례이다.

As-Is

이 프로젝트는 MSA기반으로, Spring Boot, FastAPI, PostgreSQL, Vector DB 총 4개의 서버를 구성한다. 가장 먼저 생각난 방법은 각 도메인(프론트, 백, 모델)별로 VPC를 구축하고, 인스턴스로 관리하는 것이었다.

1. 컨테이너 오케스트레이션
   • 모든 구성 요소(Spring Boot, FastAPI, PostgreSQL, Vector DB, Nginx)를 Docker로 컨테이너화
   • Docker Compose를 사용
   • Docker 네트워크를 사용해 컨테이너들을 같은 네트워크 내에 묶음
2. 배포 및 서버 인프라
   • AWS 사용: EC2 인스턴스를 통해 전체 인프라 배포
   • RDS: PostgreSQL을 AWS RDS로 관리하여 확장성 확보
3. Nginx 구성
   • 리버스 프록시: 모든 클라이언트 요청을 적절한 백엔드 서비스로 라우팅
   • 정적 파일 서빙: React 빌드 결과물을 Nginx를 통해 제공

이대로 진행해도 큰 문제는 없었다. 단 한가지, 비용만 제외하면.
평범한 취업 준비생이라는 점을 감안하여, 비용을 줄일 수 있는 방법을 강구할 필요가 있었다.

To-Be

크게 변경된 점은 2가지이다. VPC 개수를 1개로 줄이고, RDS 대신 DB를 도커로 띄우도록 변경했다. 비용 절감뿐 아니라 관리 용이성도 함께 고려했다.

1. 컨테이너 오케스트레이션(처음과 동일)
   • 모든 구성 요소(Spring Boot, FastAPI, PostgreSQL, Vector DB, Nginx)를 Docker로 컨테이너화
   • Docker Compose를 사용해 서비스별로 컨테이너 관리
   • Docker 네트워크로 컨테이너들이 같은 네트워크 내에서 상호 통신하도록 구성
2. VPC 1개 - AWS 인스턴스 3개 사용
   • VPC를 3개 -> 1개로 줄임으로써 비용 절감과 관리 용이성을 증대시킴
   • AWS 인스턴스를 3개 사용하여 모든 서비스(Spring Boot, FastAPI, PostgreSQL, Vector DB)를 독립된 컨테이너로 띄우되, 하나의 VPC 내에 통합.
   • 인스턴스들은 하나의 공통 VPC내에 속해있으므로 네티워크 통신이 용이하고 보안 관리도 쉬워짐
3. GCP를 이용한 DB 관리
   • 비용 절감을 위해 AWS RDS를 사용하지 않고 PostgreSQL을 도커 컨테이너로 구성
   • GCP의 무료 크레딧을 활용하여 PostgreSQL을 이미지로 관리, 추가적인 비용 부담 해소
4. Nginx와 보안 관리
   • Nginx 리버스 프록시: 모든 클라이언트 요청을 적절한 서비스(Spring Boot, FastAPI)로 라우팅하고, 정적 파일은 Nginx에서 서빙.
   • 인스턴스 간 인바운드 규칙을 생성하여 포트 접근을 관리
     • 서버(Spring Boot)와 모델(FastAPI)는 특정 IP만 허용하도록 제한하여 보안 강화
     • 프론트엔드는 외부에서 접근 가능하도록 오픈
   • 각 서비스가 독립된 Docker Compose 파일을 가지며, 공통의 Docker 네트워크를 통해 통신

다음과 같이 변경하므로써

• 동일한 VPC 내에 위치시켜 지연을 최소화
• 네트워크 구성을 단순화시켜 장애 발생 최소화

할 수 있어 우리 프로젝트에 좀 더 적합한 아키텍처가 완성되었다.