문제 정의: 스타트업 서비스를 저렴하고 빠르게 배포해야 한다.

• 회사 개발 인력 6명
• 4명은 기능 개발 담당
• 2명은 인프라 담당
• 스타트업이므로 비용과 시간이 부족하며, 비용이 절대적으로 부족함

• 작은 비용과 운영 복잡도로 서비스를 빠르게 출시할 수 있는 환경 구축

기준

1. 적은 비용
2. 빠르게 배포(적은 운영 복잡도)

1차 배포에서는 장애로 인해 서비스 제공이 잠시 중단되어도 괜찮다고 판단했다.

우리 서비스는 초기에 부트캠프 내부에서만 폐쇄적으로 배포되므로 서비스가 중단되더라도 큰 문제가 발생하지 않기 때문이다.

트래픽 집중 시간: 평일 쉬는 시간(9:00–18:00 중 매시 50분–정각, 9회×10분=90분) + 점심시간(12:00–13:00, 60분) = 140분 = 8,400초

v1은 사용자 수가 적고 사용 시간대가 고정되어 있어 피크 RPS보다 평균 RPS가 더 유의미하다. 평균 RPS = 하루 총 요청 수 ÷ 트래픽 집중 시간(초)

세션 평균 요청수

하루 총 요청 수 = 세션 수 × 세션 평균 요청 수 = 30 × 21.23 = 636.9
평균 RPS       = 636.9 ÷ 8,400 ≈ 0.076

1. 사용자 규모(DAU 30명): 소규모 초기 서비스에서 30명 전원이 특정 순간에 일제히 세션 요청을 쏟아붓는 극단적인 피크 상황은 비현실적
2. 명확한 활동 시간대: 24시간 상시 접속 서비스가 아니므로, 실제 요청이 발생하는 주요 활동 시간대(쉬는 시간 + 점심시간 = 140분 / 8,400초)를 기준으로 산정해야 현실적인 초당 부하를 파악할 수 있음
3. 결론: v1 인프라 사이징의 현실적인 기준은 비현실적인 순간 피크가 아닌, 집중 시간대 평균 RPS

1차 배포의 목표: 적은 비용과 빠른 배포

우리 서비스는 클라우드 서비스를 사용해 1차 배포한다.

• 배포는 크게 온 프레미스와 클라우드 서비스로 나뉜다.

1. 온 프레미스는 초기 투자 비용이 높으므로([N100 미니 PC 22만원]((https://prod.danawa.com/info/?pcode=35770394&keyword=n100), 공유기 4.5만원 , UPS 18만원를 합쳐 44.5만원) 현재 상황에 적합하지 않았다.
2. 클라우드는 온 프레미스 대비 적은 비용(AWS EC2 t3.medium 기준 한 달 약 38달러)으로 서비스를 배포할 수 있어서 초기 비용을 줄여야 하는 지금 상황에 잘 맞았다.

• 따라서 1차 배포는 클라우드 서비스를 사용한다.

단일 인스턴스를 사용했을 때, CSP 간 비용 차이가 크지 않으므로 빠른 배포를 위해 팀원의 경험이 있는 AWS를 사용해 배포한다.

1. 우리 서비스는 DAU가 30명이므로 하나의 인스턴스를 사용할 것이다. 그런데 하나의 인스턴스만을 사용할 때의 CSP 간의 비용 차이가 적었다.(하단 비용 표 참조) 따라서 '적은 비용'이라는 기준에서는 CSP를 고를 수 없다고 판단했다.
2. '빠른 배포' 기준에서는 점유율이 높아 레퍼런스가 많고 팀원 모두의 사용 경험이 있는 AWS가 우수하다고 판단했다.

• 따라서 CSP로 AWS를 선택했다.

• 대상: 대표 CSP 3사(AWS, Azure, GCP)
• 기준 조건: Ubuntu, 온디맨드(Pay-As-You-Go), 한 달 730시간 가동, 순수 컴퓨팅 인스턴스 비용만 고려

버스터블 클래스의 크레딧 개념

• t3.medium, Standard_B2s는 크레딧 기반이라 크레딧이 없으면 baseline 성능으로 돌아가거나 크레딧을 사야 한다.(aws t3 unlimited의 경우)
• e2-medium은 공유 코어 방식이라 물리 서버에 여유가 있는 한, 계속해서 버스트할 수 있다.
• 우리 서비스는 특정 시간대에 사용되는 구조를 가지므로 크레딧은 중요한 요소가 아니라고 판단했다.

초기 배포에서는 단일 EC2 인스턴스를 사용하는 것이 가장 경제적이고 단순하다.

• 우리 서비스는 적은 수의 사용자가 사용(평균 RPS 0.076)하므로 적은 비용으로 배포해야 하고, 빠르게 배포해야 하므로 하나의 인스턴스에 모든 애플리케이션을 배포하는 것이 좋다고 판단했다.

1대의 EC2 안에 여러 애플리케이션을 구동하면서 발생하는 환경 충돌과 장애 전파를 방지하기 위해 컨테이너 가상화 기술로 Docker를 사용한다.

• 단일 EC2 인스턴스 위에 백엔드(Java/Spring), AI(Python/FastAPI), 프론트엔드(React), 데이터베이스(PostgreSQL), 캐시(Redis) 등 다양한 애플리케이션을 동시에 배포하고 운영해야 한다.
• 여러 애플리케이션을 직접 설치하여 배포하는 경우 환경 충돌이나 한 애플리케이션의 장애가 다른 애플리케이션에 영향을 미칠 수 있다.
• 따라서 이를 방지하기 위해 컨테이너 기술 Docker를 도입한다.

• 프론트엔드

1. 지금 1차 배포에서는 유저가 30~100명이라 월간 대역폭 100GB에 미치지 않을 것이기에 토큰 한도는 고려하지 않아도 된다.
2. 저장소는 public이지만, 팀 프로젝트(organization)이기 때문에 vercel은 추가 비용(팀원 한 명당 20$/월)이 발생하기에 탈락이다.
3. GitHub Pages는 404 우회 설정이 필요한 점에서 복잡도가 증가하는데, 편의성도 있지만 복잡도가 더 클 것으로 판단해서 탈락이다.
4. CloudFront는 최대 장점이 글로벌 캐싱인데, [바꾸까]는 국내 거주자만 사용할 서비스이기 때문에 필요 없다.
5. 따라서 CloudFront와 Nginx는 현재 규모에서 크게 차이가 없다고 판단했다.
6. 다만, S3 버킷 정책을 FE 배포만을 위해 따로 관리하는 것보다는 Docker Compose로 다른 구성 요소들과 묶어서 한 번에 관리하는 게 더 편리하고 한눈에 구조를 이해하기 쉬울 것이다.
7. 결론적으로 Nginx 선정

• 백엔드 & AI 서버
  • Java와 Python의 서로 다른 런타임 의존성 충돌을 방지하며, 외부 LLM을 호출하는 AI 서버의 병목이 백엔드로 전파되지 않아야 한다.
  • [결론] 따라서 백엔드와 AI 서버는 각각 독립된 Docker 컨테이너로 배포한다.
• DB(MySQL, MongoDB, Redis)
  • 컨테이너는 종료 시 내부 데이터가 소멸된다. 관리형 서비스를 사용하면 추가 비용이 발생된다.(RDS 월 $21)
  • [결론] 비용 절감을 위해 DB와 Redis를 각각 컨테이너로 직접 띄우되, 인스턴스의 디스크(EBS)와 볼륨을 연결해 데이터 영속성을 보장한다.

• DAU가 30이기에 일반적인 운영 환경 기준이 아닌, 기본 구동이 가능한 수준으로 비용 최적화
• 메모리 관련 설정값(JVM 힙, 최대 Connection 등) 튜닝 필요

컨테이너 메모리 할당 상세

• Nginx: 50MB

  • 워커 프로세스 1개 메모리 10MB 내외 예상

• Redis: 128MB

  • 캐시 메모리 크기 10MB 내외 예상
  • BE의 Redis 활용 범위가 미정인 관계로 여유 있게 산정

• MySQL: 256MB

  • BufferPool 축소, 최대 Connection 제한 등 설정으로 220MB 선에서 부팅 예상

• MongoDB: 512MB

  • WiredTiger 엔진의 내부 캐시 하한선이 216MB
  • 캐시 외에 엔진 바이너리와 스택, 연결 메모리가 추가되어 실제 약 500MB까지 점유
  • 강제로 축소할 수도 있지만, 리눅스 Swap 메모리 설정을 고려하는 등 OOM Kill을 방지하는 복잡도가 증가하기에 안정적으로 최소 512MB 확보

• FastAPI: 512MB

  • 외부 API 호출 전용 서버이기 때문에 충분할 것으로 예상

• SpringBoot: 1GB

  • JVM 힙, metaspace, TreadPool 등 축소 시 충분할 것으로 예상

• AWS Pricing Calculator: calculator.aws

각 컨테이너의 최소 메모리의 합은 약 2.5GB이고, OS 커널과 Docker 데몬 오버헤드를 고려하면 3GB가 조금 안 될 거 같다.

SpringBoot, FastAPI 컨테이너의 사용량을 넉넉하게 산정했기 때문에 Swap 메모리를 활용하면 2GiB RAM으로도 구동이 가능할 것이다.

• t4g.small, t3a.small, t3.small

Swap 설정 없이 넉넉히 운영하려면 4GiB RAM을 사용한다.

• t4g.medium, t3a.medium, t3.medium

각 사양은 칩셋 아키텍처에서 차이가 있다.(ARM, AMD x86, Intel x86) 우리가 사용할 애플리케이션은 ARM에서도 작동하므로 굳이 x86 프로세서를 고수하며 비용을 더 지불할 이유가 없다. 따라서 사양은 동일하나 비용이 더 저렴한 t4g.medium을 사용한다.

EC2 비용표(서울 리전, 월 요금)

small과 medium을 현재 상황에서 명확히 결정하기에는 개발 팀원들의 산출물에 따라 달라질 거 같아 무리가 있다. 또한 빠른 배포가 목표이며, 비용 차이가 두 배라고 해도 월 2만원 정도의 금액이라 치명적이지 않다. 설계 단계에 산출물이 없는 상태에서 각 컨테이너를 임시로 가정하고 직접 튜닝을 해서 테스트하기에는 시간적, 비용적으로 효율적이지 않다고 판단하여, medium 사양으로 가정 후 아래의 단계를 거치기로 한다.

1. t4g.medium이 swap 메모리 설정이나 컨테이너 튜닝이 크게 필요하지 않아서 우선적으로 선택한다.
2. 팀원들이 medium에서 동작을 테스트하고 개발하는 동안, 메모리 절약을 위해 튜닝한 모든 컨테이너가 small 사양에서 무리 없이 동작하는지 확인한다.
3. CI/CD 시 무중단 배포를 할 경우 일시적으로 메모리가 2배로 필요할 수 있기 때문에 필요시 이 부분도 확인한다.
4. 검증을 성공적으로 마친 경우 t4g.medium에서 t4g.small로 전환한다.

여러 컨테이너를 선언적으로 일괄 제어하고 환경 설정 실수를 방지하기 위해 Docker Compose를 사용한다.

• 개별 `docker run`으로 관리하면 포트/볼륨/환경변수 등 복잡한 CLI 옵션 누락으로 휴먼 에러가 발생하기 쉽고, DB가 실행되기 전 백엔드가 먼저 시작되는 등의 컨테이너 간 실행 순서와 내부 네트워크 연결을 일일이 수동 관리해야 하는 문제가 있다.
• Docker Compose를 통해 단일 `yaml` 파일로 전체 서비스의 설정과 의존 관계를 관리하여 명령어 한 줄로 일괄 실행 및 재현이 가능하다.

sudo mkdir -p /data/mysql /data/mongodb /data/nginx/conf.d /data/nginx/certbot /data/frontend

sudo chown -R 999:999 /data/mysql
sudo chown -R 999:999 /data/mongodb
sudo chmod 755 /data/frontend

services:
  # 메인 DB
  mysql:
    image: mysql:8.4
    container_name: mysql
    restart: unless-stopped
    # dirty page 디스크 플러시를 위한 대기 시간 확보
    stop_grace_period: 1m
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
      TZ: Asia/Seoul
    # 256MB 환경 구동을 위한 메모리 다이어트 옵션 전달
    command:
      - --innodb-buffer-pool-size=128M
      - --performance-schema=OFF
      - --max-connections=30
      - --character-set-server=utf8mb4
      - --collation-server=utf8mb4_unicode_ci
    volumes:
      - /data/mysql:/var/lib/mysql
    deploy:
      resources:
        limits:
          memory: 384M # 256MB 목표이나 구동 시 버퍼 고려해 384MB 하드 리밋
    healthcheck:
      # 포트 오픈 여부가 아닌 실제 쿼리 응답 여부 검증
      test: ["CMD-SHELL", "mysqladmin ping -h localhost -u root -p$${MYSQL_ROOT_PASSWORD}"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 30s
    logging: &default-logging
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"
    networks:
      - backend-net

  # 채팅 DB
  mongodb:
    image: mongo:7.0
    container_name: mongodb
    restart: unless-stopped
    stop_grace_period: 30s
    environment:
      MONGO_INITDB_ROOT_USERNAME: ${MONGO_INITDB_ROOT_USERNAME}
      MONGO_INITDB_ROOT_PASSWORD: ${MONGO_INITDB_ROOT_PASSWORD}
      TZ: Asia/Seoul
    # WiredTiger 캐시를 256MB로 명시적 제한하여 OOM Crash 방지
    command: ["mongod", "--wiredTigerCacheSizeGB", "0.25"]
    volumes:
      - /data/mongodb:/data/db
    deploy:
      resources:
        limits:
          memory: 512M
    healthcheck:
      test: ["CMD-SHELL", "mongosh --eval 'db.adminCommand(\"ping\")' --quiet"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 20s
    logging: *default-logging
    networks:
      - backend-net

  # 세션 관리 및 응답 캐싱
  redis:
    image: redis:7.2-alpine
    container_name: redis
    restart: unless-stopped
    command: >
      redis-server
      --requirepass ${REDIS_PASSWORD}
      --maxmemory 96mb
      --maxmemory-policy allkeys-lru
    deploy:
      resources:
        limits:
          memory: 128M
    healthcheck:
      test: ["CMD", "redis-cli", "-a", "${REDIS_PASSWORD}", "ping"]
      interval: 5s
      timeout: 3s
      retries: 3
      start_period: 5s
    logging: *default-logging
    networks:
      - backend-net

  # AI 중계 서버
  fastapi:
    image: ${FASTAPI_IMAGE} # GitHub Actions에서 빌드/푸시한 이미지 태그
    container_name: fastapi
    restart: unless-stopped
    environment:
      - OPENAI_API_KEY=${OPENAI_API_KEY}
      - CLAUDE_API_KEY=${CLAUDE_API_KEY}
      - TZ=Asia/Seoul
    deploy:
      resources:
        limits:
          memory: 512M
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:8000/health || exit 1"]
      interval: 10s
      timeout: 5s
      retries: 3
      start_period: 10s
    logging: *default-logging
    networks:
      - backend-net

  # 핵심 비즈니스 로직 API 서버
  springboot:
    image: ${SPRINGBOOT_IMAGE}
    container_name: springboot
    restart: unless-stopped
    environment:
      - SPRING_PROFILES_ACTIVE=prod
      - SPRING_DATASOURCE_URL=jdbc:mysql://mysql:3306/${MYSQL_DATABASE}?useSSL=false&allowPublicKeyRetrieval=true
      - SPRING_DATASOURCE_USERNAME=${MYSQL_USER}
      - SPRING_DATASOURCE_PASSWORD=${MYSQL_PASSWORD}
      - SPRING_DATA_MONGODB_URI=mongodb://${MONGO_INITDB_ROOT_USERNAME}:${MONGO_INITDB_ROOT_PASSWORD}@mongodb:27017/${MONGO_DATABASE}?authSource=admin
      - SPRING_DATA_REDIS_HOST=redis
      - SPRING_DATA_REDIS_PORT=6379
      - SPRING_DATA_REDIS_PASSWORD=${REDIS_PASSWORD}
      - FASTAPI_BASE_URL=http://fastapi:8000
      - TZ=Asia/Seoul
      # JVM 힙 메모리를 512MB로 제한하고 GC 오버헤드를 줄이기 위한 옵션
      - JAVA_OPTS=-Xms256m -Xmx512m -XX:MaxMetaspaceSize=192m
    depends_on:
      mysql:
        condition: service_healthy # MySQL 핑 응답 확인 후 구동 시작
      mongodb:
        condition: service_healthy
      redis:
        condition: service_healthy
      fastapi:
        condition: service_healthy
    deploy:
      resources:
        limits:
          memory: 1024M
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:8080/actuator/health || exit 1"]
      interval: 15s
      timeout: 5s
      retries: 5
      start_period: 40s # Spring Boot JVM 부팅 시간을 감안한 유예시간
    logging: *default-logging
    networks:
      - backend-net
      - frontend-net

  # Reverse Proxy & Static Web Server
  nginx:
    image: nginx:alpine
    container_name: nginx
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /data/nginx/conf.d:/etc/nginx/conf.d:ro
      - /data/nginx/certbot:/etc/letsencrypt:ro
      - /data/frontend:/usr/share/nginx/html:ro # React 빌드 산출물 마운트
    depends_on:
      springboot:
        condition: service_healthy # 백엔드 기동 완료 후 라우팅 오픈
    deploy:
      resources:
        limits:
          memory: 64M
    healthcheck:
      test: ["CMD-SHELL", "wget -q --spider http://localhost/ || exit 1"]
      interval: 10s
      timeout: 3s
      retries: 3
    logging: *default-logging
    networks:
      - frontend-net

# 네트워크 분리: DB/캐시는 외부에 노출되지 않도록 완전 격리
networks:
  backend-net:
    driver: bridge
  frontend-net:
    driver: bridge

서비스 요약
- 스타트업이 최초로 배포하는 서비스, DAU 30, 평균 RPS 0.07, 부트캠프 내부 인원을 타겟으로 배포 시작
- AWS EC2 한 대에 각 서비스 컴포넌트를 컨테이너화하여 Docker Compose로 배포

우리 서비스는 하나의 인스턴스로 배포하므로 AWS의 기본 VPC와 서브넷을 사용한다.

기본 VPC의 퍼블릭 서브넷을 사용하여 인스턴스가 인터넷에 직접 노출되므로, 접근 범위를 줄이고 비인가 접근을 방지하기 위해 서비스 운영 및 관리에 필요한 최소 포트만 허용한다.

Inbound
- 80 TCP (HTTP) 0.0.0.0/0(전역): 사용자의 HTTP 요청, HTTPS로 리다이렉션한다.
- 443 TCP (HTTPS) 0.0.0.0/0(전역): 사용자의 HTTPS 요청, 트래픽을 Nginx 컨테이너로 전달해 요청 라우팅 처리한다.
- 22 TCP (SSH) 개발IP: 회사 인프라 팀의 IP에서만 접근하도록 설정한다.

우리 팀의 인프라 담당은 tobby와 janna 2인이다.

aws root 계정이 탈취되는 경우, 비싼 EC2 등을 생성/사용하여 인프라 비용이 과도하게 지출될 수 있다.

따라서 root 계정이 탈취되지 않도록 하고, root 계정에 인프라 담당자가 접근하지 않도록 인프라 담당자 각자의 개별 IAM User를 생성하고 'Infra-Admin' IAM 그룹으로 묶어 제한된 권한만을 부여해 사용하도록 한다.

AWS Account
│
├─ Root
│   └─ 일반적으로 작업에 사용하지 않는다
│
├─ IAM Group: Infra-Admin
│   ├─ tobby
│   └─ janna
│
└─ IAM Users
    ├─ tobby
    └─ janna

아래는 'Infra-Admin' IAM 그룹 설정에 필요한 내용이다.

• MFA가 없으면 모든 요청을 거부(MFA 등록 제외)
• 권한 상승(IAM 수정) 불가
• 허용된 서비스에만 접근 가능하고, 허용된 리소스만 생성할 수 있음
  • ec2(t3), S3, CloudFront, CloudWatch, Billing(현재 비용 읽기만 허용)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowListActions",
      "Effect": "Allow",
      "Action": [
        "iam:ListUsers",
        "iam:ListVirtualMFADevices"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowUserToCreateVirtualMFADevice",
      "Effect": "Allow",
      "Action": "iam:CreateVirtualMFADevice",
      "Resource": "arn:aws:iam::*:mfa/${aws:username}"
    },
    {
      "Sid": "AllowUserToManageTheirOwnMFA",
      "Effect": "Allow",
      "Action": [
        "iam:EnableMFADevice",
        "iam:GetMFADevice",
        "iam:ListMFADevices",
        "iam:ResyncMFADevice"
      ],
      "Resource": "arn:aws:iam::*:user/${aws:username}"
    },
    {
      "Sid": "AllowUserToDeactivateTheirOwnMFAOnlyWhenUsingMFA",
      "Effect": "Allow",
      "Action": "iam:DeactivateMFADevice",
      "Resource": "arn:aws:iam::*:user/${aws:username}",
      "Condition": {
        "Bool": { "aws:MultiFactorAuthPresent": "true" }
      }
    },
    {
      "Sid": "BlockMostAccessUnlessSignedInWithMFA",
      "Effect": "Deny",
      "NotAction": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:ListMFADevices",
        "iam:ListUsers",
        "iam:ListVirtualMFADevices",
        "iam:ResyncMFADevice",
        "iam:ChangePassword",
		"iam:GetUser"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" }
      }
    },
    {
      "Sid": "DenyIAMPrivilegeEscalation",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:CreateRole",
        "iam:CreateAccessKey",
        "iam:CreateLoginProfile",
        "iam:UpdateLoginProfile",
        "iam:UpdateAssumeRolePolicy",
        "iam:AttachUserPolicy",
        "iam:AttachGroupPolicy",
        "iam:AttachRolePolicy",
        "iam:PutUserPolicy",
        "iam:PutGroupPolicy",
        "iam:PutRolePolicy",
        "iam:CreatePolicy",
        "iam:CreatePolicyVersion",
        "iam:SetDefaultPolicyVersion",
        "iam:AddUserToGroup",
        "iam:PassRole"
      ],
      "Resource": "*"
    },

    {
      "Sid": "DenyExpensiveEC2Instances",
      "Effect": "Deny",
      "Action": [
		"ec2:RunInstances",
		"ec2:ModifyInstanceAttribute"
	  ],
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringNotLike": { "ec2:InstanceType": "t3.*" }
      }
    },
    {
      "Sid": "AllowEC2",
      "Effect": "Allow",
      "Action": "ec2:*",
      "Resource": "*"
    },
    {
      "Sid": "AllowS3",
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*"
    },
    {
      "Sid": "AllowCloudFront",
      "Effect": "Allow",
      "Action": "cloudfront:*",
      "Resource": "*"
    },
    {
      "Sid": "AllowCloudWatch",
      "Effect": "Allow",
      "Action": "cloudwatch:*",
      "Resource": "*"
    },
    {
      "Sid": "AllowBillingReadOnly",
      "Effect": "Allow",
      "Action": [
        "ce:Get*",
        "ce:Describe*",
        "billing:Get*",
        "billing:List*",
        "budgets:ViewBudget",
        "budgets:DescribeBudget"
      ],
      "Resource": "*"
    }
  ]
}

사용자가 우리 서비스를 기억하기 쉬운 고정된 주소로 들어와야 하므로, 도메인을 구매하여 고정 IP(Elastic IP)에 연결한다.

• 사용자는 IP주소가 아닌 기억하기 쉬운 도메인 주소로 접근할 수 있어야 한다.
• 도메인 주소를 EC2 IP 주소에 연결할 때, EC2 재시작 시 IP 변경 문제를 해결하기 위해 고정 IP(Elastic IP)를 사용한다.

추가 인프라 비용을 발생시키지 않고 빠른 배포를 위해, ALB나 CloudFront 대신 EC2 내부의 Nginx와 Let's Encrypt(Certbot)를 사용하여 HTTPS를 적용한다.

• ALB + ACM: ACM 무료 인증서 지원 및 관리가 편하지만, ALB 기본 요금(월 약 $16~$22)이 발생하여 비용 측면에서 불리하고, 단일 인스턴스 환경에서 로드밸런싱이 불필요하여 제외함
• CloudFront + ACM: 1TB 전송/10,000,000건 무료, SSL 인증서 갱신이 자동으로 되지만 이미 프론트 배포와 인스턴스 내부 라우팅을 위해 존재하는 Nginx가 있는 상태에서 인증서 관리를 위해 Route53, CloudFront, ACM 설정을 할 필요가 없다고 판단함
• Nginx + Let's Encrypt: Let's Encrypt와 Certbot을 연동하여 SSL 발급과 관리가 가능함. 인증서 90일 만료 관리는 Certbot 자동 갱신 스케줄러를 등록하여 자동화로 해결 가능하고, 이미 단일 인스턴스 내 라우팅을 위해 Nginx 컨테이너를 사용하므로, 추가 비용 없이 빠르게 배포가 가능한 Nginx를 선택함

사용자 (브라우저)
   │
   ├─ [HTTP :80]  ──> Nginx ──> HTTPS(:443)로 301 리다이렉트
   │
   └─ [HTTPS :443] ──> Nginx (SSL 종료 및 라우팅)
                          │
                          ├─ [/] 정적 페이지  ──> React 빌드 파일 직접 서빙
                          │
                          └─ [/api] 요청 ──> 백엔드 컨테이너 (Spring Boot)
                                                     │
                                                     ├─ AI 검증 ──> AI 컨테이너 (FastAPI)
                                                     ├─ 데이터   ──> DB 컨테이너
                                                     └─ 캐시/세션 ──> Redis 컨테이너

비용을 줄이기 위해, RDS 같은 관리형 DB를 쓰지 않고 컨테이너로 직접 띄우되, 컨테이너 종료 시 데이터 소멸을 막기 위해 EC2의 기본 EBS 볼륨을 마운트하여 추가 비용 없이 데이터 영속성을 보장한다.

• PostgreSQL RDS 월 비용(서울): 인스턴스(t4g.micro, $0.0250/시간 * 730시간 = $18.25) + 스토리지($0.131/GB * 20GB = 2.62) = $20.87 RDS 비용 문서

사용자 업로드 사전을 저장하기 위해, 저렴한 수 있는 S3를 사용한다.

EBS 비용

• EBS gp3 0.08$/GB
  

S3 비용

• S3 스탠다드 0.023$~0.025$/GB
  

S3에 비해 EBS가 3배 이상 비용이 크기 때문에 S3로 결정한다.

퍼블릭 이미지 배포 시 세 도구 모두 무료이므로, 별도의 외부 계정 연동이나 시크릿 발급 없이 빠르고 편리하게 GitHub 생태계에서 관리할 수 있는 GHCR을 사용한다.

• Public 컨테이너 레지스트리, 소수의 docker 이미지 빌드/업로드 조건에서는 Docker hub, AWS ECR, GHCR 세 컨테이너 레지스트리 모두 무료
• CI/CD 단계에서 Docker hub와 ECR은 각각 시크릿 관리가 필요하지만, GHCR는 github에서 제공하는 인증 토큰을 사용할 수 있어 편리하다.(${{ secrets.GITHUB_TOKEN }})

프로메테우스나 그라파나 같은 별도 모니터링 툴 구축은 리소스 낭비와 운영 복잡도가 커지므로, 추가 비용과 설치 없이 EC2의 CPU/메모리/네트워크 상태를 기본 제공하는 AWS CloudWatch 기본 메트릭과 알람을 사용한다.

우리 서비스는 적은 비용과 빠른 배포를 해야하는 현재 목표와, 서비스가 특정 사용자와 특정 시간대에 사용될 것을 고려하였기 때문에 아래의 한계점을 갖는다.

• 전체 서비스 중단: EC2 인스턴스 1대에 장애가 발생하면 웹, API, DB, AI까지 모든 서비스가 즉시 중단된다.
• 무중단 배포 불가: 단일 인스턴스로 배포하므로 새 버전을 배포할 때 컨테이너 재시작 동안 서비스 중단(다운타임)이 발생한다.

• 고가용성(HA) 부재: 단일 AZ 종속으로 인해 AZ 장애 시 자동 복구가 불가하고 다운타임이 길어진다.
• 시점 복원(PITR) 부재: 관리형 RDS와 달리 짧은 시간 단위(e.g. 초/분 단위) 복원이 어려워 장애 직전 데이터 복구에 한계가 있다.
• 쓰기 작업 시 스냅샷 데이터 불일치 위험성: 스냅샷은 단순히 EBS의 현재 데이터를 저장하는 것이라 쓰기 작업 중 스냅샷을 생성하면 데이터가 누락될 수 있음

• 트래픽이 늘어났을 때 트래픽을 분산해 줄 로드밸런서(ALB)가 없고, DB(PostgreSQL)가 인스턴스 내부 컨테이너로 함께 떠 있어 서버 간 데이터 공유가 불가능하므로 Scale-out이 불가능하며 인스턴스 체급을 올리는 Scale-up만 가능하다.