• VPC (SSMU-DEV)
  • CIDR: 192.168.0.0/16
• Public Subnet
  • 리전: ap-northeast-2, 가용 영역: ap-northeast-2a, ap-northeast-2c
  • SUBNET-SSMU-DEV-PUBLIC-AZONE: 192.168.10.0/24
  • SUBNET-SSMU-DEV-PUBLIC-CZONE: 192.168.110.0/24
• Nat Subnet
  • 리전: ap-northeast-2, 가용 영역: ap-northeast-2a, ap-northeast-2c
  • SUBNET-SSMU-DEV-NAT-AZONE: 192.168.20.0/24
  • SUBNET-SSMU-DEV-NAT-CZONE: 192.168.120.0/24
• Private Subnet
  • 리전: ap-northeast-2, 가용 영역: ap-northeast-2a, ap-northeast-2c
  • SUBNET-SSMU-DEV-PRIVATE-AZONE: 192.168.30.0/24
  • SUBNET-SSMU-DEV-PRIVATE-CZONE: 192.168.130.0/24
• EC2 (FE + BE)
  • 프론트/백엔드 서버가 각각 Docker 컨테이너로 구동되는 인스턴스
  • t3.medium2대 사용(Auto-Scaling Group)
  • docker-compose명령어를 이용해 서버를 가동
  • FE는 Nginx 컨테이너와 함께 구동되며, 정적 파일을 서비스하는 역할 수행
  • Docker 네트워크 구성: bridge 기반 커스텀 네트워크 app-net 사용하여 FE/BE 간 내부 통신 가능
• EC2 (OpenVPN)
  • OpenVPN AMI로 생성한 인스턴스
  • t3.micro 사용
  • 고정 퍼블릭 IP가 할당되어 있으며, 보안 접속용 VPN 게이트웨이 역할
  • 개발자는 이 인스턴스를 통해 프라이빗 인스턴스에 접근
• EC2 (Database Master/Replica)
  • 백엔드 서버에서 사용하는 관계형 데이터베이스 서비스를 설치할 인스턴스
  • t3.micro 2대 사용(데이터베이스 이중화 - Read Replica)
  • docker run명령어를 이용해 데이터베이스 서버(RDBMS)를 가동
  • 별도의 private subnet에 위치하여 데이터 보존성과 안정성 확보
• Route53
  • 도메인 관리 서비스
  • 사용자 요청을 ALB를 통해 EC2 인스턴스로 전달(도메인과 연결됨)
• S3 Bucket(images)
  • 정적 리소스(이미지, 파일 등) 저장 용도로 연동
  • 향후 애플리케이션 로그 및 분석 데이터를 적재하는 용도로도 확장 가능
• Developer
  • GitHub Actions를 통해 빌드된 Docker 이미지를 ECR에 Push
  • OpenVPN을 통해 인스턴스에 접근하여 docker-compose pull → up -d 명령으로 배포 수행

• VPC (SSMU-AI)
  • CIDR: 10.0.0.0/16
• Public Subnet (SUBNET-SSMU-AI-PUBLIC)
  • CIDR: 10.0.10.0/24
• GCP Compute Engine – AI 서버 (Standard VM)
  • Chroma DB/FastAPI 서버가 각각 Docker 컨테이너로 구동되는 인스턴스
  • e2-medium 사용
  • Docker 네트워크 구성: 사용자 정의 네트워크 ai-net을 활용하여 FastAPI ↔ ChromaDB 간 통신 구현
• GCP Compute Engine – GPU 서버 (AI 모델 전용)
  • AI 모델 (LLM 기반 추론 서버)을 구동하는 인스턴스
  • g2-standard-8 사용

• 환경 일관성 확보: 개발자의 로컬 환경과 서버 환경 간의 차이(예: OS, 패키지 버전, 설정 파일 등)로 인해 발생할 수 있는 실행 오류를 제거
• 배포 속도 개선: 이미지 단위 배포로 평균 배포 시간 15~20분 → 5분 이내로 단축
• 운영 자동화 기반 마련: GitHub Actions + ECR 연계로 자동화 가능한 구조 도입
• 의존성 관리 용이: 각 서비스 런타임을 컨테이너 내부에서 독립적으로 구성 가능
• 확장성 확보: 향후 ECS 또는 Kubernetes 환경으로의 전환도 유연하게 대응 가능

• 현재 우리 서비스는 스프린트 기간 내 다음과 같은 기능 업데이트가 예정되어 있으며, 각각의 기능이 안정적이고 독립적으로 운영되어야 한다:

  1️⃣ 이력서 초안 자동 작성 기능 – 백엔드 및 AI 서버 연동 중심

  2️⃣ 일일 CS 대회 및 랭킹 시스템 – 정확한 시간에 배포되어야 하는 백엔드 중심 기능

  3️⃣ IT 기업 추천 및 시각화 – 프론트엔드 및 AI 연계 필요

  4️⃣ 면접 질문 큐레이팅 및 답변 첨삭 기능 – FastAPI 기반 AI 분석 로직이 별도로 구동됨

  이처럼 프론트엔드, 백엔드, AI 분석 로직이 명확히 분리되어 있으며, 컨테이너화를 통해 다음과 같은 이점을 얻을 수 있다:

  • 독립적인 빌드 및 배포: 예를 들어 AI 분석 모델만 업데이트하더라도 다른 컴포넌트는 영향을 받지 않음
  • 장애 전파 차단: 하나의 컨테이너에 장애가 발생하더라도 다른 서비스는 영향을 받지 않음
  • 무중단 배포 및 빠른 롤백: 컨테이너 이미지 기반 배포로 짧은 다운타임 내 배포 가능
  • 정시 운영 기능에 대한 신뢰도 확보: 일일 대회와 같은 이벤트 중심 기능이 특정 시간에 맞춰 실행되어야 하는 경우, 백엔드의 실행 환경을 고정하고, 컨테이너 단위로 배포함으로써 실행 시점의 예측 가능성과 안정성을 확보

특히 FastAPI 기반 AI 서버는 의존성 설치만 해도 수 분이 소요될 수 있으나, Docker 이미지 내에서 미리 설치되므로 매 배포 시마다 절감 효과가 크다.

• Docker는 미리 빌드된 환경을 가져온다
  • 기존에는 서버마다 라이브러리 설치 및 설정을 반복
  • Docker는 이미지 내에 이 모든 환경이 미리 설정되어 있어 pull과 run만으로 즉시 실행
• 단일 파트만 빠르게 재배포 가능
  • 예를 들어 AI 서버만 수정했을 때 전체 재배포가 필요 없이 해당 컨테이너만 재실행

두 배포 전략은 컨테이너 기반 시스템에서 무중단 배포를 실현하기 위한 대표적인 방식이다. 다음은 각 방식의 개요이다:

• Rolling Update: 전체 인스턴스를 순차적으로 교체하는 방식. 트래픽은 항상 일부 인스턴스를 통해 유지되므로 다운타임이 거의 없음
• Blue-Green Deployment: 현재 운영 중인 버전(Blue)과 신규 배포 버전(Green)을 병렬로 유지한 뒤, 트래픽을 Green으로 전환하는 방식. 장애 발생 시 Blue로 롤백 가능

🔹 따라서 Rolling Update 전략을 우선 적용하고, 최종적으로 Kubernetes 환경으로 전환 시 Helm 또는 ArgoCD 기능을 통한 Blue-Green 전략은 후일 부가적으로 고려한다.

• 각 빌드 시점마다 prod-<릴리즈버전> 형식의 고정 태그와 함께 rollback-<timestamp> 형태의 태그도 함께 관리함
• 장애 발생 시, 이전 정상 작동했던 태그를 기준으로 docker-compose.yml의 이미지 태그를 수정
• GitHub Actions 워크플로우 내에서 과거 태그로 pull 후 재배포하는 스크립트를 추가 가능:

# 예시: 이전 버전으로 롤백
IMAGE_TAG=prod-1.0.1

docker pull 123456789012.dkr.ecr.ap-northeast-2.amazonaws.com/careerbee-be:$IMAGE_TAG
docker tag 123456789012.dkr.ecr.ap-northeast-2.amazonaws.com/careerbee-be:$IMAGE_TAG careerbee-be:rollback
docker-compose down && docker-compose up -d

• 또는 아래와 같은 직접 실행 방식도 가능:

docker stop careerbee-be # 백엔드 서버 종료
docker rm careerbee-be
docker run -d --name careerbee-be -p 8080:8080 careerbee-be:rollback

• Discord나 GitHub Actions 주석을 통해 롤백 시점과 커밋 정보를 자동 기록할 수 있도록 구성

• AWS - docker-compose.yml

  version: '3.8'
  services:
    nginx:
      image: nginx:alpine
      ports:
        - "80:80"
      volumes:
        - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro
        - ./frontend/dist:/usr/share/nginx/html:ro
      depends_on:
        - frontend
      networks:
        - app-net
    frontend:
      image: 123456789012.dkr.ecr.ap-northeast-2.amazonaws.com/careerbee-fe:prod-1.0.0
      ports:
        - "80:80"
      restart: always
      networks:
        - app-net
  
    backend:
      image: 123456789012.dkr.ecr.ap-northeast-2.amazonaws.com/careerbee-be:prod-1.0.0
      ports:
        - "8080:8080"
      restart: always
      environment:
        - SPRING_PROFILES_ACTIVE=prod
        - DB_HOST= MYSQL
      networks:
        - app-net
  
  networks:
    app-net:
      driver: bridge

• GCP - docker-compose.yml

  version: '3.8'
  services:
    ai:
      image: gcr.io/careerbee-ai/fastapi:prod-1.0.0
      ports:
        - "8000:8000"
      restart: always
      environment:
        - MODEL_PATH=/models/careerbee_model.pt
        - API_KEY=${AI_API_KEY}
      networks:
        - ai-net
  
    chromadb:
      image: chromadb/chroma:latest
      ports:
        - "8001:8000"
      volumes:
        - chroma-data:/chroma/.chroma/index
      networks:
        - ai-net
  
  networks:
    ai-net:
      driver: bridge
  
  volumes:
    chroma-data:

FROM node:18-alpine
WORKDIR /app
COPY . .
RUN npm install && npm run build
CMD ["npx", "serve", "-s", "dist"]

FROM openjdk:17-alpine
ARG JAR_FILE=build/libs/*.jar
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["java", "-jar", "/app.jar"]

FROM python:3.11
WORKDIR /app
COPY . .
RUN pip install --no-cache-dir -r requirements.txt
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

📌 기존에도 Self-hosted Runner 기반의 CI/CD가 구축되어 있었으나, Docker 기반 CI/CD는 다음과 같은 점에서 차별적인 개선 효과가 기대된다:

• CI/CD의 배포 일관성 향상: 이전에는 서버에 직접 배포 스크립트를 실행하며 .jar, 정적 리소스, Python 가상환경 등을 수동으로 제어해야 했으나, Docker 기반에서는 컨테이너 단위로 통일된 배포 환경을 구성할 수 있음
• 의존성 설치 불필요: 기존에는 백엔드/AI 서버에서 각각 Java/Python 의존성을 설치하고 실행 환경을 설정했지만, Docker 이미지는 빌드시 이미 모든 환경이 포함되므로 pull과 run만으로 실행됨
• 무중단 배포 및 롤백: 이미지 단위 배포이므로 서비스 중단 없이 빠르게 재배포 및 롤백 가능
• 운영 서버 측 자동화 용이성: docker-compose pull && up -d 명령으로 전체 서비스 일괄 갱신 가능하며, 이를 Webhook 또는 SSH 자동화로 연결할 수 있음

[1] GitHub Push or PR 발생
        ↓
[2] GitHub Actions 실행
    - 빌드 (FE/BE/AI)
    - 테스트 및 Lint
    - ECR에 Docker 이미지 Push
        ↓
[3] Discord 알림 전송
    - 상태: 성공/실패
    - 커밋, 작성자, 빌드 소요 시간 등 포함
        ↓
[4] 운영 서버(EC2/GCP) 접속
    - docker-compose pull
    - docker-compose up -d
        ↓
[5] 배포 완료 및 로그 확인
    - docker ps
    - docker logs

• Discord 연동 목적: 배포 성공/실패 여부, 커밋 정보, 빌드 시간 등을 Discord로 전달하여 실시간 대응 가능
• 적용 위치: GitHub Actions 내 워크플로우 마지막 단계에 삽입

name: CI/CD Pipeline

on:
  push:
    branches:
      - main
      - dev
          
  pull_request:
    branches:
      - main
      - dev
          

env:
  ECR_REGISTRY: 123456789012.dkr.ecr.ap-northeast-2.amazonaws.com
  SLACK_WEBHOOK_URL: ${{ secrets.DISCORD_WEBHOOK_URL }}

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v2

      - name: Login to Amazon ECR
        uses: aws-actions/amazon-ecr-login@v1

      - name: Build and Push FE Image
        run: |
          docker build -t $ECR_REGISTRY/careerbee-fe:prod-1.0.0 ./frontend
          docker push $ECR_REGISTRY/careerbee-fe:prod-1.0.0

      - name: Build and Push BE Image
        run: |
          docker build -t $ECR_REGISTRY/careerbee-be:prod-1.0.0 ./backend
          docker push $ECR_REGISTRY/careerbee-be:prod-1.0.0

      - name: Build and Push AI Image
        run: |
          docker build -t $ECR_REGISTRY/careerbee-ai:prod-1.0.0 ./ai
          docker push $ECR_REGISTRY/careerbee-ai:prod-1.0.0

      - name: Notify to Discord
        if: always()
        uses: 8398a7/action-slack@v3
        with:
          status: ${{ job.status }}
          fields: repo,message,commit,author,job,took
        env:
          DISCORD_WEBHOOK_URL: ${{ secrets.DISCORD_WEBHOOK_URL }}

운영 배포 시점과 연동하여 Discord 채널로 빠르게 알림이 가므로, 장애 대응 시간 최소화 및 배포 승인 커뮤니케이션에 용이함

• GitHub Actions:
  • 브랜치 또는 PR 기준 자동 빌드 → ECR에 이미지 Push
  • 태그 전략 기반으로 버전 구분 (예: prod-1.2.3)
• EC2 서버:

  • docker-compose pull → docker-compose up -d

  • 변경된 서비스만 이미지 갱신 가능 (무중단 배포 기반)

    구분	docker pull	docker-compose pull
    대상	개별 이미지 지정 필요	docker-compose.yml에 정의된 모든 서비스의 이미지를 한 번에
    사용 위치	터미널에서 직접	Docker Compose 기반 프로젝트 디렉토리
    예시	docker pull nginx:latest	docker-compose pull
    장점	특정 이미지만 빠르게 가져올 수 있음	다수의 컨테이너 서비스를 동시에 업데이트 가능
    활용 시점	수동 업데이트, 개별 테스트	CI/CD 또는 운영 환경에서의 전체 서비스 업데이트 시

💡 예상 총합 (월): 약 $300 수준(주 45시간 운영 기준)

📌 본 페이지는 2025년 5월 26일에 마지막으로 업데이트되었습니다.