1. 배포 단위
2. 백엔드 상태값 분리
3. 백엔드 요구 성능
4. 컨테이너 운용 방식

프론트, 백엔드, AI, DB는 각각 병목 지점이 다르고, 요구하는 사양이 다르다. 각각의 서비스를 하나로 묶어서 일괄적으로 개수를 늘리면 각 서비스에서 필요한 성능보다 실제로 더 적거나 많은 성능을 배정받을 수 있다.

예를 들어, 프론트 SSR은 CPU bound 작업이지만 스프링부트는 커넥션 점유가 많이 필요하기 때문에 필요로 하는 리소스의 크기와 종류가 다르다. 그래서 프론트 서비스의 CPU 할당을 늘리기 위해 인프라를 늘리게 되면, 나머지 백엔드, AI 서버에서는 사용하지 않는 자원을 배정 받을 수 있다.

DB를 포함하여 v1의 인프라를 그대로 복제하는 경우 DB도 하나씩 늘어나는데, 이러면 인스턴스마다 다른 DB를 사용하는 문제가 발생한다.

만약 DB를 제외한 인프라를 복제하는 경우에도 문제가 발생하는데, 프론트엔드 부하 때문에 백엔드도 함께 늘어나, 필요 없는 백엔드마다 DB 커넥션을 잡는다. 유휴 커넥션은 풀 설정(minimumIdle)으로 줄일 수 있지만, DB 최대 커넥션은 백엔드 수 × 풀 최대 크기(maximumPoolSize)로 잡아야 하므로 백엔드 수가 프론트엔드 부하에 따라 늘어나면 DB의 최대 커넥션을 그만큼 늘리거나, 백엔드마다 풀 최대 크기를 줄여야 한다.

복제 인스턴스 수	HikariCP 최대 풀 10개 × 인스턴스 개수	v1 MySQL max-connections=30
1대	10	OK
3대	30	한계 도달
5대	50	초과

위와 같은 이유로 백엔드 서비스는 독립된 인스턴스로 배포해야 한다.

백엔드 서비스를 독립 인스턴스로 배포할 때, v1 인프라에서 관리하는 값을 분리할 필요가 있다.

v1 배포에서는 JWT의 리프레시 토큰을 MySQL에서 관리하고, 로그인 세션을 사용하지 않았다. v2 배포에서는 서비스 트래픽 확장에 따라 빠른 읽기, 쓰기를 위해서 리프레시 토큰과 로그인 세션을 Redis에서 관리할 것이다.

백엔드 서비스를 여러 인스턴스에 독립적으로 배포하는 경우에, 리프레시 토큰과 로그인 세션을 각 인스턴스에서 관리한다면 사용자는 기존에 정보를 저장했던 서버에만 요청해야 한다. 이를 위해서 로드밸런서를 통해서 고정 세션(sticky-session)을 적용할 수 있는데, 아래의 문제가 발생한다.

1. 인스턴스 수를 유동적으로 관리하기 어렵다. 우리 서비스는 사용자가 특정 시간대에 몰리므로, 스케일링을 사용해 피크 시간대에 인스턴스 수를 늘리고 한가한 시간대에는 그 수를 줄여야 한다. 그러나 고정 세션을 사용한다면 사용자가 특정 인스턴스에만 통신하는 것을 강제로 중단해야 한다. 사용자가 강제로 로그아웃되는 정도의 문제지만, 매일 같은 일이 반복된다면 사용자 경험에 큰 문제가 된다.
2. 서버를 늘려도 부하가 바로 나뉘지 않는다. 사용자는 특정 인스턴스로만 요청을 해야하므로 사용자가 몰려도 옮길 수 없다.

고정 세션을 사용하지 않고, 모든 인스턴스에서 동일한 값을 가지도록 설정할 수 있다. 그러나 인스턴스 수만큼 중복된 데이터를 가지고 있어야 하므로(e.g. 백엔드 인스턴스 10개 = 사용자 A의 로그인 세션 10개 저장) 시스템 자원 낭비가 발생한다.

이를 해결하기 위해서 서버를 무상태로 만들어야 한다. 현재 서비스에서 리프레시 토큰과 로그인 세션을 공용 공간에 저장해서, 모든 백엔드 인스턴스에서 접근할 수 있다면 위의 문제를 해결할 수 있다. 따라서 인증 정보를 모든 인스턴스가 함께 접근하는 공유 저장소에서 관리한다.

Refresh Token과 로그인 세션의 크기와 개수를 아래와 같이 가정한다. 세션과 키의 크기는 백엔드 구현에 따라 달라지므로 가정했다.

항목	개수 가정	크기 가정	합계
Refresh Token (TTL 14일)	14일 안에 로그인한 사용자 최대 20만 (MAU 전체)	0.5KB	약 100MB
로그인 세션	DAU 4만	1KB	약 40MB
합계			약 140MB

• 처리량: Peak 80 RPS에서 요청마다 Redis 명령을 1~2번 보내도 초당 최대 160건이다. Redis는 작은 노드에서도 초당 수만 건을 처리하므로 처리량에는 문제가 없다고 판단했다. spare_cores-t3 nano redis 벤치마크
• 장애 허용 기준: Redis에서 로그인 세션과 JWT 리프레시 토큰만을 관리하므로, 데이터는 유실돼도 괜찮다.(재로그인이 필요) 그러나 Redis가 멈춘다면 인증이 필요한 모든 요청이 불가능해지므로 허용할 수 없다.

직접 운영(EC2)과 관리형(ElastiCache)을 비교했다. 서울 리전 공식 요금 기준이며, 한 달은 730시간으로 계산했다.

방식	구성	월 비용	자동 전환	추가 관리
EC2 직접, replica 사용	t4g.micro × 2 + gp3 20GB × 2	약 $19	없음	복제 설정, 백업, 패치, 장애 시 사람이 replica를 승격해야함
EC2 직접, Sentinel 사용	t4g.micro × 3 + EBS	약 $28	있음	Sentinel 3대 구성, 클라이언트를 Sentinel 방식으로 설정, 전환
ElastiCache 노드, Redis OSS	cache.t4g.micro × 2 ($0.024/h)	$35.0	있음	서브넷 그룹, 파라미터 그룹
ElastiCache 노드, Valkey	cache.t4g.micro × 2 ($0.0192/h)	$28.0	있음	위와 동일
ElastiCache Serverless, Redis OSS	최소 1GB 과금 ($0.151/GB-h)	약 $110	있음	없음
ElastiCache Serverless, Valkey	약 0.14GB ($0.101/GB-h)	약 $12	있음	없음

• EC2 요금: t4g.micro $0.0104/h, gp3 GB당 월 약 $0.09
• Serverless Valkey 저장 요금: 0.14GB × $0.101 × 730 ≈ $10.3
• Serverless Valkey 처리 요금: 1KB 이하 단순 읽기, 쓰기는 명령당 1 ECPU. 160 명령(80 RPS × 명령 2개)을 하루 종일 받는다고 크게 잡아도 월 4.1억 ECPU × $0.0027/백만 ECPU = 약 $1.1
• AWS ElastiCache pricing
• EC2로 직접 운영하는 것은 저렴하지 않고, 사람이 replica를 승격하거나 redis를 최소 3대로 구성해야 한다. 또한 Redis 구성이나 백업, 전환 등을 전부 관리해야 한다.
• ElastiCache 중 Serverless Valkey가 가장 저렴하고 여러 AZ에 복제되므로 AZ 배치를 따로 설계할 필요가 없다. 따라서 ElastiCache Serverless Valkey를 사용해 세션과 리프레시 토큰을 관리한다.
• 다만 이후 트래픽이 더욱 성장하는 경우, 저장 데이터가 늘어나는 만큼 Serverless 사용 비용이 늘어나므로 노드 방식이 더 저렴해질 수 있다. (e.g. MAU 500만 -> Refresh Token 2.5GB -> 최소 $184/월)

Redis Multi-AZ 통신 방법

• 백엔드는 엔드포인트 주소 하나로 접속한다. 어느 노드가 primary인지, 전환이 일어났는지는 AWS가 관리한다.
• Redis는 인터넷으로 나갈 일이 없으므로 프라이빗 서브넷에 둔다. 보안그룹은 6379 포트를 백엔드 보안그룹에서만 받는다.
• AZ 간 전송 비용은 판단 요소가 아니다. 요청당 1KB를 주고받고 80 RPS가 하루 종일 Redis에 요청한다고 가정해도 월 약 207GB, 절반이 AZ를 넘으면 약 104GB × 방향당 $0.01 × 2 = 약 월 $2다.

백엔드 서버가 2대 이상으로 늘어나면, 현재 채팅 구조(Spring 내장 SimpleBroker)에서는 같은 인스턴스에 연결된 구독자에게만 메시지가 전달된다. 대화 상대 A와 B가 서로 다른 인스턴스에서 통신하면 A의 메시지가 B에게 도착하지 않는다. 따라서 인스턴스 사이에 메시지를 전달하는 중계가 필요하다. 메시지는 DB에 먼저 저장한 뒤 발행하므로, 중계는 실시간 전달만 담당하고 기록은 DB에 남는다.

Redis Pub/Sub 도입 비용

Pub/Sub 메시지는 구독자에게 전달되면 사라지고 저장되지 않으므로 저장 요금이 늘지 않는다. 따라서 요금은 전달 건수에 비례한다. 우리 서비스는 채팅방이 1:1이라 메시지 한 건을 받는 인스턴스가 최대 2개(보낸 사람과 받는 사람의 인스턴스)다. 대화방 하나당 채널 하나를 쓰고, 그 방의 참여자가 통신하는 인스턴스만 구독하면 사용자 수가 늘어도 메시지 한 건의 전달 수는 늘지 않는다.

항목	값	비고
메시지 발생량	Peak 7건/초	채팅 메시지 송수신 Peak RPS
하루 종일 Peak로 받는다고 가정한 월 메시지	7 × 86,400 × 30 = 약 1,800만 건
메시지당 ECPU	발행 1 + 전달 최대 2 = 3	1KB 이하 명령은 1 ECPU
월 ECPU	약 5,400만

채팅 중계 Redis Pub/Sub 구성 방안

선택지	추가 비용	판단
ElastiCache Serverless, Valkey	월 약 $0.15	새 인프라가 없고, 요금이 메시지 건수에만 비례한다. Multi-AZ와 자동 장애 조치(primary 전환)
채팅용 Redis EC2에 구축	t4g.micro 한 대 이상, 월 약 $8 이상. 가용성을 고려 시 약 $19~28	저장이 없는 용도인데도 서버 비용이 고정으로 나가고, 패치와 장애 대응을 직접 해야 한다.
ElastiCache 노드, Valkey	cache.t4g.micro × 2 약 $28	Serverless가 Pub/Sub에 맞지 않을 때의 대체안이다. 평소에는 고정비가 더 크다
외부 STOMP 브로커 (Amazon MQ)	브로커 인스턴스 상시 과금, 이중화 시 2대 (서울 요금 미확인)	Spring의 브로커 연동(enableStompBrokerRelay)을 그대로 쓰고 전달 보장도 되지만, 메시지를 DB에 이미 저장하므로 필요하지 않음
SNS/SQS로 인스턴스에 전달	호출당 소액
DB 폴링 (각 인스턴스가 chat_messages의 새 행을 주기적으로 조회)	추가 인프라 없음	인스턴스 수와 활성 방 수에 비례해 DB 조회가 발생
인스턴스끼리 직접 전달	없음	스케일링으로 바뀌는 인스턴스 주소를 서로 알아야 함

ElastiCache Serverless Valkey가 저렴한 비용으로 Multi AZ와 자동 장애 조치까지 지원하며, 백엔드 상태 분리에서 이미 사용하는 인프라이므로 도입하기에 적절하다고 판단했다.

그러나, 전달을 보장하지 않는 문제가 있다. Pub/Sub은 구독자가 없거나 연결이 끊긴 순간의 메시지를 버린다. 메시지를 DB에 먼저 저장하므로 놓친 메시지는 사용자가 다시 접속할 때 채팅 히스토리 조회로 받는다. 교환 약속을 잡는 채팅에서는 "가끔 실시간 전달을 놓쳐도 기록은 남는다" 수준이면 충분하다고 판단했다.

우리 서비스의 타겟층은 20, 30대 자취 혹은 기숙사에서 생활하는 사람이므로, 트래픽 시간 분포는 이 타겟층이 활발히 인터넷을 사용하는 시간으로 정하는 것이 타당하다. 2026년 CJ 메조미디어 20대, 30대 타겟 리포트의 "인터넷 이용 시간대" 응답을 우리 서비스의 시간대별 부하 분포로 본다.

CJ 메조미디어 2026년 20대, 30대 인터넷 이용 시간대 자료

• 20대 자료 (링크)
• 30대 자료 (링크)

• 가장 붐비는 시간의 RPS를 80으로 두고, 나머지 구간은 시간당 값에 비례해 계산한다.
• 기상 직후와 심야는 자료에 끝 시각이 없어 각각 1시간(06-07), 3시간(23-02)으로 가정했다. 02-06시는 계산 편의상 0으로 가정했다.
• 20, 30대 값은 남녀 평균으로 계산했다.
• RPS는 Peak 타임인 20-23시의 1시간 비율에 비례하게 계산했다.
  • e.g. 기상직후 5.5%, RPS = 80 x (5.5 / 22.8) = 약 19

구간	시간	20대	30대	평균	1시간 비율	RPS
기상 직후	06-07	8.0%	3.0%	5.5%	5.5	19
등교·출근	07-09	17.0%	18.0%	17.5%	8.8	31
오전	09-11	4.5%	11.5%	8.0%	4.0	14
점심	11-14	15.0%	14.5%	14.8%	4.9	17
오후	14-17	16.0%	14.5%	15.3%	5.1	18
하교·퇴근	17-20	25.0%	28.0%	26.5%	8.8	31
저녁	20-23	66.5%	70.5%	68.5%	22.8	80
심야	23-02	41.5%	26.5%	34.0%	11.3	40
새벽	02-06	—	—	—	—	0

피크 시간대는 저녁 시간대(20-23시)로, 68.5%의 사람들이 사용한다고 응답했다.

트래픽은 세 단계로 나눌 수 있다.

단계	시간	RPS
피크	20~23시 (3시간)	80
중간	출근 07-09시, 퇴근 17-20시, 심야 23-02시 (8시간)	31-40
낮음	기상 직후, 낮 09-17시, 새벽 02-06시 (13시간)	0~19

v2 상황에서 백엔드 서버 리소스가 얼마나 필요한지 측정했다.

측정 방법 및 조건 (클릭해서 펼치기)

측정 요청은 백엔드 서버의 모든 API가 아닌, user flow 요청에서 51%로 가장 많이 호출되는 API 두 개로 물품 상세 조회와 물품 목록 조회를 골랐다. user flow 표에서는 각각 27.1, 13.4 RPS였는데, 조금 더 간단히 하여 측정 요청의 2:1 비율로 조정했다.

항목	값
측정일	2026-10-04
인스턴스	EC2 t4g.large 1대
이미지	백엔드 dev 이미지
백엔드 컨테이너	CPU 1개 제한, 메모리 2 GiB
DB	MySQL 8.4, 같은 인스턴스, 빈 DB에 Flyway V1 적용
데이터	그룹 20개, 사용자 2,000명(v2 Peak 동시 사용자 수), 물건 20,000개, 이미지 40,000장
부하	k6 고정 RPS. 20 RPS 워밍업 120초 후 20 / 40 / 80 RPS 각 180초
인증	테스트 전용 JWT secret으로 사용자별 Access Token을 서명
제외한 것	Sentry 비활성화, AI 서버·카카오 호출 없음
CPU 수집 기준	구간 시작·끝의 process_cpu_time_ns_total 차이
메모리 수집 기준	docker stats

• CPU 수집 기준 상세: 구간 끝 process_cpu_time − 구간 시작 process_cpu_time

측정 결과

목표 RPS	처리 요청 수	백엔드 CPU 사용 시간	요청당 CPU	평균 사용 CPU	p95 목록 / 상세	실패율	컨테이너 메모리 최대
20	3,601건	33.7초	9.35 ms	0.19 vCPU	16.5 / 16.5 ms	0%	444 MiB
40	7,201건	53.1초	7.37 ms	0.29 vCPU	15.7 / 17.0 ms	0%	458 MiB
80	14,401건	81.7초	5.67 ms	0.45 vCPU	15.4 / 17.0 ms	0%	457 MiB

• 요청당 CPU = 전체 CPU 사용 시간 / 처리한 요청 수
• 80 RPS에서도 CPU 1개의 45%만 쓰고 p95는 17 ms다. 1 vCPU가 현재 피크 전체를 처리한다.
• 워밍업 120초 동안은 20 RPS에서도 p95가 목록 2,362 ms, 상세 2,055 ms였다.
• 백엔드 컨테이너를 제외한 OS와 Docker를 위한 메모리는 약 340 MiB가 필요했다.

타입	vCPU / 메모리	기준 성능	시간당 비용
t4g.micro	2 / 1 GiB	10% × 2 = 0.2 vCPU	$0.0104
t4g.small	2 / 2 GiB	20% × 2 = 0.4 vCPU	$0.0208
t4g.medium	2 / 4 GiB	20% × 2 = 0.4 vCPU	$0.0416

• v2 상황의 Peak RPS 80에 대응하기 위해서, 백엔드 서버 인스턴스는 최소 0.45 vCPU, 약 800 MiB(OS·Docker 약 340 MiB + 백엔드 컨테이너 약 460 MiB) 메모리가 필요하다.
• t4g.small 1대는 기준 성능 0.4 vCPU 안에서 약 71 RPS를 처리할 수 있다. (0.4 vCPU ÷ 요청당 5.67 ms) 따라서 가용성 하한선인 2대(AZ당 1대)로 피크 80 RPS를 기준 성능 안에서 처리한다(1대당 40 RPS, 0.23 vCPU).
• AZ 하나가 빠져도 남은 1대가 버스트(최대 2 vCPU)로 80 RPS(0.45 vCPU)를 처리할 수 있다.
• 메모리 2 GiB는 OS+Docker(약 340 MiB)와 백엔드 컨테이너(약 460 MiB)를 넣고도 여유가 있다.
• t4g.micro는 백엔드에 약 580 MiB만 남아, 요청이 몰리면 OOM으로 컨테이너가 종료될 수 있다.
• 따라서 t4g.small 1대를 두 AZ에 총 2대를 두어 운용할 것이다.

한계

• 물품 목록, 물품 상세만 측정했다. 로그인이나 물건 등록(S3, AI 호출), 교환, 채팅은 측정하지 않고 앞서 측정한 두 항목과 요청당 같은 CPU가 필요하다고 가정했다. 그러나 로그인과 물건 등록은 외부 응답을 기다려야 하므로 스레드 점유 시간이 길 것으로 예상된다.

상황

• v2 사용자는 서비스 중단을 용납하지 않으므로 배포는 무중단으로 한다. 배포 시점 제한이 없어지면서 배포 빈도가 늘어난다.
• 2차 배포까지는 서비스 수익이 적다고 판단했다. 그래서 가용성 하한선(AZ 두 곳에 배포)을 지키는 범위에서 최소 비용을 여전히 1순위로 둔다.

컨테이너 운용 방식 세 가지

항목	EC2 + ASG	ECS on EC2	ECS on Fargate
개수를 맞추는 대상	인스턴스(ASG의 desired capacity)	태스크(서비스의 desired count)와 인스턴스(용량 공급자가 ASG를 조정)	태스크
컨테이너 실행 주체	인스턴스 부팅 때 실행되는 user data 스크립트	EC2 인스턴스의 ECS 에이전트	Fargate
실행할 이미지 버전	시작 템플릿(user data의 이미지 태그)	태스크 정의 리비전의 컨테이너 정의(container definitions)	태스크 정의 리비전의 컨테이너 정의
ALB 대상	인스턴스	bridge 모드: 인스턴스(동적 포트) awsvpc 모드: 태스크 IP	태스크 IP(awsvpc 고정)

• 세 방식 모두 2개 AZ에 실행 단위를 두면 가용성 하한선을 만족한다.
• 요금 체계는 EC2 계열과 Fargate가 다르다. EC2(t4g)는 인스턴스 단위로 과금하고, CPU를 기준 성능과 크레딧 버스트로 제공한다. Fargate는 지정한 vCPU와 메모리에 각각 과금하고, 지정한 vCPU를 버스트 없이 보장한다.
• 태스크 정의 리비전: 태스크 정의(이미지, CPU·메모리, 환경변수 등)를 바꿀 때마다 만들어지는 새 버전

• 서울 리전, 온디맨드, 월 730시간 기준
• 백엔드 서버 측정치에 따라 Peak RPS 80에서 0.45 vCPU를 사용한다고 가정했다.
• 측정치에 한계가 있으므로, 여유를 두기 위해 AZ 장애로 실행 단위가 하나 빠진 상황까지 Peak RPS에서 vCPU 사용 비율을 70% 이하로 유지해야 한다고 판단했다.

구성	실행 단위 vCPU 사용 비율	AZ 장애 시 vCPU 사용 비율	월 비용
Fargate 0.5 vCPU / 1 GB × 2	45%	90%	$33.2
Fargate 0.5 vCPU / 1 GB × 3 (AZ 3개)	30%	45%	$49.7
Fargate 1 vCPU / 2 GB × 2	23%	45%	$66.3
t4g.small × 2 (ECS on EC2)	56% (기준 성능 0.4 vCPU 대비)	23% (버스트 상한 2 vCPU 대비)	$35.8
t4g.small × 2 (ASG + EC2)	동일	동일	$31.8

• Fargate: ARM64 vCPU 시간당 $0.03725, GB 시간당 $0.00409. 태스크당 임시 스토리지 20 GiB가 요금에 포함된다.
• t4g.small: 시간당 $0.0208 × 2대 = $30.4에 루트 EBS가 더해진다. ECS 최적화 AMI의 루트 볼륨이 기본 30 GiB(gp3 GB-월 $0.0912)라 2대에 월 $5.5가 든다. EC2 + ASG는 일반 AL2023 AMI(8 GiB)를 쓰므로 월 $31.8이다.

Fargate 0.5 vCPU, 1 GB 구성은 AZ 장애 시 새 태스크가 할당되기 전까지 vCPU의 90%를 사용한다. 70%를 넘으므로 더 높은 성능이 필요하고, 방법은 두 가지다.

1. AZ 개수를 늘려 총 세 곳에 0.5 vCPU, 1 GB 태스크를 둔다.
2. 태스크 리소스를 1 vCPU, 2 GB로 늘린다. Fargate에는 0.75 vCPU가 없고, 1 vCPU의 최소 메모리가 2 GB다.

2번은 1번보다 비용이 약 33% 높으므로, Fargate를 쓴다면 1번을 쓴다.

EC2는 t4g.small을 쓸 수 있다. 평소에는 기준 성능(0.4 vCPU) 대비 사용 비율이 Fargate보다 높다. 하지만 0.4 vCPU를 넘는 순간부터는 적립한 크레딧으로 2 vCPU까지 버스트하므로, AZ 장애 시에도 사용 비율이 상한 대비 23%에 그친다. 결과적으로 요구를 만족하는 가장 저렴한 Fargate 구성($49.7)이 ECS on EC2($35.8)보다 월 약 $14, 약 1.4배 비싸다.

Fargate를 쓰지 않는 이유

Fargate는 EC2 계열보다 14~18 달러정도 저렴하지만, "비싸서 쓰지 않는다"가 아니라 "그 돈을 더 내고 얻는 것이 우리에게 필요한가"로 판단했다. Fargate가 현재 우리 서비스 상황에서 EC2보다 나은 점은 두 가지이고, 둘 다 우리 상황에서는 다른 방법으로 대응할 수 있다.

Fargate의 이점	우리 상황에서의 대응
인스턴스를 관리하지 않는다	인스턴스 교체와 개수 유지는 ASG가 자동으로 처리한다. AMI 갱신은 인스턴스 새로 고침으로 반영한다.
확장이 빠르다. EC2는 새 인스턴스를 띄운 뒤에야 태스크를 배치한다	현재 peak RPS 트래픽으로는 t4g.small 한 대 만으로도 서비스를 유지할 수 있다. 서비스가 점점 더 성장하는 상황에서는 피크 타임에 맞춰 ASG로 인스턴스를 늘려서 대응할 수 있다. 트래픽 급증은 외부 요인보다 내부 이벤트로 생길 가능성이 크므로, 이벤트 전에 인스턴스를 수동으로 늘린다.

감수하는 것

• 80 RPS의 CPU만 보면 t4g.small 1대로도 처리할 수 있다. 하지만 가용성 하한선 때문에 2대를 두고, 인스턴스마다 백엔드 하나만 실행한다.
• 메모리는 OS+Docker(약 340 MiB)와 컨테이너(약 460 MiB)를 합쳐 약 800 MiB다. 여유를 두어 1.5 GiB로 잡아도 인스턴스마다 약 500 MiB가 평소에는 쓰이지 않는다.
• 예측하지 못한 급증에는 Fargate보다 늦게 대응한다. 새 인스턴스 부팅, ECS 에이전트 등록, 태스크 배치를 거쳐야 하기 때문이다.

EC2 + ASG 대신 ECS를 고르는 이유는 관리 단위다.

• 우리가 배포하는 단위는 컨테이너다. ASG는 인스턴스 개수만 관리하고, ECS는 컨테이너(태스크)를 직접 관리한다. 그래서 월 약 $4의 비용 차이가 있어도 ECS를 사용한다.
• EC2 + ASG에서는 컨테이너의 버전 고정, 장애 교체, 무중단 배포를 user data와 배포 스크립트로 직접 만들어야 하고, 이 일은 배포와 장애가 있을 때마다 반복된다.
• ECS는 이를 태스크 정의와 서비스 설정으로 처리하는 대신, 인스턴스(용량 공급자)와 태스크(서비스) 두 계층의 스케일링을 처음에 함께 구성해야 하는 부담을 진다.

작업	EC2 + ASG	ECS on EC2
무중단 배포	인스턴스에 CodeDeploy 에이전트, appspec, 훅 스크립트가 필요. 인스턴스 묶음 단위로 전환	이미지가 태스크 정의에 고정되어, 스케일 아웃이나 교체로 생기는 태스크도 현재 버전을 실행한다. CodeDeploy ECS 블루/그린을 서비스 설정으로 쓴다
장애 시 복구	ASG 헬스 체크 유형을 ELB로 두어, ALB가 인스턴스 헬스체크 후 ASG가 인스턴스 교체	태스크 장애: 장애가 발생한 태스크만 중지하고 새로 띄운다 인스턴스 장애: 새 인스턴스 교체
인스턴스 교체	대상 그룹의 등록 해제 지연이 끝나면 인스턴스를 종료하고 인스턴스 교체	인스턴스 드레이닝이 종료할 인스턴스의 태스크를 다른 인스턴스에 먼저 띄운 뒤 기존 태스크를 멈춘다
비밀값	user data가 SSM에서 읽어 환경변수로 넣는다. 권한은 인스턴스 프로파일 단위다	태스크 정의 secrets가 주입한다. 권한은 태스크 역할 단위다

• 드레이닝: EC2 인스턴스를 종료하거나 교체할 때 실행 중인 태스크(Task)를 안전하게 중지하고, 새로운 태스크가 해당 인스턴스에 배치되지 않도록 상태를 전환하는 기능 공식문서

항목	값
인스턴스	t4g.small 2대 (AZ당 1대), ECS의 Capacity Provider는 ASG
태스크	인스턴스당 평상시 1개. 컨테이너 cpu는 가중치만 둔다. memoryReservation 약 512 MiB
네트워크	bridge 모드
배포 전략	블루/그린 무중단 배포. AWS CodeDeploy를 이용해 AllAtOnce 방식으로 새 버전의 Task를 동시에 배포

네트워크 모드

• awsvpc 모드: ECS에서 Task에 ENI를 직접 할당하여, EC2 인스턴스와 동일한 수준의 독립된 프라이빗 IPv4 주소와 네트워크 속성을 부여하는 네트워킹 모드
  • Task에 private IPv4 주소를 받으므로 백엔드에서 카카오 OAuth 아웃바운드 트래픽을 허용하기 위해 NAT 게이트웨이가 필요함
• bridge 모드: 컨테이너가 인스턴스의 네트워크를 거쳐 나가므로 인스턴스 공인 IP로 외부에 연결
  • 컨테이너 8080을 인스턴스의 동적 포트에 매핑
  • ALB 대상 유형은 instance

주의사항

실행 단위와 서비스 종류가 늘어 AMI와 용량 공급자 관리가 서비스 비용 차액인 월 $18보다 큰 부담이 되면 Fargate를 다시 비교한다. 태스크 정의는 그대로 쓸 수 있지만 서비스의 용량 공급자 유형은 바로 바꿀 수 없으므로, 새 서비스를 만들고 ALB에서 트래픽을 넘긴다.

참고 자료 (클릭해서 펼치기)

• AWS Fargate 요금
  • 태스크 1개 시간당 = vCPU 수 × $0.03725 + 메모리 GB × $0.00409
  • 0.5 × 0.03725 + 1 × 0.00409 = $0.022715 = 약 $33.2