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

• 회사 개발 인력 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)하므로 적은 비용으로 배포해야 하고, 빠르게 배포해야 하므로 하나의 인스턴스에 모든 애플리케이션을 배포하는 것이 좋다고 판단했다.

"EC2 1대에 다 넣으면 메모리가 부족하지 않은가?"를 검증하기 위해, 우리 서비스에서 배포할 애플리케이션 의 기본 컨테이너 이미지를 사용해 기본 메모리(Idle) 점유율을 실측했다.

• 모든 컨테이너가 가동된 상태의 IDLE 메모리는 143MB이므로 t3.medium 메모리 4GiB의 약 3.5%에 불과하다.
• 단, 단일 EC2가 다운되면 서비스가 중단되는 단일 장애점이 발생한다. 그러나 v1은 내부 폐쇄적 서비스이며 일시적 장애를 용인하기로 합의했으므로, 비용을 아끼고 빠르게 배포하기 위해 이 가용성 리스크를 감수한다.

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

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

• 프론트엔드
  • 프론트엔드는 정적 파일을 빌드하여 CSR 방식으로 배포한다. 따라서 React를 위해 Node.js 서버를 상시 구동할 필요가 없다.
  • [결론]
    • vercel은 팀 프로젝트는 유로이고, Github Pages는 SPA 접근 시 문제 해결이 필요하므로 선택하지 않았다.
• 백엔드 & AI 서버
  • Java와 Python의 서로 다른 런타임 의존성 충돌을 방지하며, 외부 LLM을 호출하는 AI 서버의 병목이 백엔드로 전파되지 않아야 한다.
  • [결론] 따라서 백엔드와 AI 서버는 각각 독립된 Docker 컨테이너로 배포한다.
• DB(PostgreSQL, Redis)
  • 컨테이너는 종료 시 내부 데이터가 소멸된다. 관리형 서비스를 사용하면 추가 비용이 발생된다.(RDS 월 $21)
  • [결론] 비용 절감을 위해 PostgreSQL과 Redis를 각각 컨테이너로 직접 띄우되, 인스턴스의 디스크(EBS)와 볼륨을 연결해 데이터 영속성을 보장한다.

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

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

서비스 요약
- 스타트업이 최초로 배포하는 서비스, 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)
                                                     ├─ 데이터   ──> PostgreSQL 컨테이너
                                                     └─ 캐시/세션 ──> Redis 컨테이너

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

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

EC2 직접 저장은 디스크 용량 고갈과 인스턴스 교체 시 데이터 이전 위험이 있으므로, 현재 규모에서 비용이 $0이면서 무제한 확장이 가능한 AWS S3에 이미지를 저장한다.

• EC2 직접 저장: S3 연동 코드가 없어 초기엔 빠르지만, 사진이 쌓이면 EBS 용량 부족이 발생하고 서버 재배포/교체 시 데이터 이전이 매우 번거로움.
• AWS S3: 현재 규모에서(5GB 무료) 비용이 없으며, EC2 디스크 용량 고갈 걱정 없이 파일 저장소를 인스턴스와 완전히 분리해 안정적으로 운영할 수 있음.

-> 이미지가 얼마나 쌓일지 계산을 다시해봐야할 수 있습니다. (비용 계산 및 논리 검증 필요) e.g. 120명의 유저가 물건을 10개, 물건 당 3장의 사진 -> nGB

퍼블릭 이미지 배포 시 세 도구 모두 무료이므로, 별도의 외부 계정 연동이나 시크릿 발급 없이 빠르고 편리하게 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까지 모든 서비스가 즉시 중단된다.
• 무중단 배포 불가: 단일 인스턴스로 배포하므로 새 버전을 배포할 때 컨테이너 재시작 동안 서비스 중단(다운타임)이 발생한다.

• 복구 기능 부재: 관리형 RDS가 제공하는 자동 다중화(Multi-AZ), 실시간 시점 복원, 자동 장애 복구가 지원되지 않는다.

• 트래픽이 늘어났을 때 서버 대수를 늘려 트래픽을 분산하는 오토스케일링이 불가능하며, 인스턴스 체급을 올리는 Scale-up만 가능하다.