1차: ECS on EC2 기반 애플리케이션 구조 요약

0. ECS on EC2 애플리케이션 구조

1. 용량 공급자 비용 비교 (2 CPU / 4 GiB 기준)

	EC2 (c5a.large)	ECS 관리형 인스턴스 (c5a.large)	Fargate
시간당	$0.086	$0.086 + $0.01032	$0.11356
한 달	$61.29	$69.35	$81.00

2. 부하 테스트 결과

2-1. Backend 서버

2-2. WebSocket 서버

2-3. FastAPI 서버

---

3. 애플리케이션별 스펙

부하 테스트 결과를 기준으로 목표 트래픽을 처리하기 위한 애플리케이션별 스펙을 산정하였다.

애플리케이션	CPU	Memory
Spring Boot BE	2 vCPU	4 GiB
Socket	1 vCPU	2 GiB
AI BE	0.5 vCPU	1 GiB

4. 이중화 및 자원 격리

V1의 단일 인스턴스 구조에서 발생할 수 있는 단일 장애점과 컨테이너 간 자원 경합을 개선하기 위해 다음과 같이 구성하였다.

• 서로 다른 AZ에 EC2를 배치하여 이중화
• 컨테이너별 CPU/Memory 제한
• ECS Service를 통해 Task 이중화

5. 수평 확장

현재 서비스는 매일 19~20시에 평상시 대비 약 5.4배의 피크 트래픽이 발생한다.

ECS on EC2와 ASG를 구성하여 트래픽 증가 시 Task와 EC2를 Scale-out하고, 트래픽 감소 시 Scale-in하도록 설계하였다.

이를 통해 피크 트래픽에 대응하면서 평상시 유휴 자원을 최소화하고자 하였다.

---

하나의 EC2에 BE, Socket, AI Task가 함께 배치된다.

컨테이너별 자원 제한을 통해 자원 경합은 완화할 수 있지만, EC2 자체에 장애가 발생하면 해당 인스턴스의 BE, Socket, AI Task가 동시에 중단된다.

즉, 애플리케이션 간 자원은 격리했지만 동일한 호스트 장애 도메인을 공유한다.

비용 절감을 위해 평상시 EC2 Capacity를 현재 Task를 수용할 수 있는 수준으로 구성하였다.

이 상태에서 EC2 장애가 발생하고 기존 인스턴스에 Task를 재배치할 Capacity가 없다면 다음 과정이 필요하다.

EC2 생성 → ECS Cluster 등록 → Image Pull → Task 실행 → Health Check

따라서 새로운 Capacity가 확보되기 전까지 일시적으로 처리 용량이 감소한다.

이는 ECS on EC2 자체의 한계가 아니라 여유 Capacity 없이 구성한 현재 설계의 한계이다.

장애 시 Task를 즉시 재배치하기 위해서는 평상시에도 추가 EC2 Capacity를 확보해야 한다.

EC2에서는 애플리케이션 외에도 OS와 ECS Agent가 자원을 사용한다.

실제 c5a.large (2 vCPU / 4 GiB)에서 확인한 가용 메모리는 약 3.2 GiB였다.

Task	Memory
BE	2 GiB
Socket	1 GiB
AI	0.5 GiB
합계	3.5 GiB

따라서 기존 계획처럼 하나의 c5a.large에 3개의 Task를 모두 배치할 수 없다.

---

c5a.large를 기존 2대에서 3대로 증가시키고 6개의 Task를 분산 배치한다.

이를 통해:

• Task 배치를 위한 메모리 확보
• 장애 대응을 위한 여유 Capacity 확보
• 단일 EC2 장애 시 동시에 중단되는 Task 수 감소

가 가능하다.

다만 하나의 EC2에 여러 Task가 배치되는 구조는 유지되므로 호스트 장애 도메인 공유 문제는 남는다.

또한 현재 서비스는 빠르게 성장하고 있어 요구 Capacity가 지속적으로 변화하고 있다.

ASG와 ECS Capacity Provider를 통해 Scale-out/in 자체는 자동화할 수 있지만, Task 증가에 따라 EC2 인스턴스 타입, 기본 Capacity, 여유 Capacity에 대한 Capacity Planning과 Task 배치 전략 관리는 지속적으로 필요하다.

Fargate 전환 시 다음 문제를 개선할 수 있다.

기존 문제	Fargate 전환
EC2 시스템 자원 점유	Task에 필요한 CPU/Memory 직접 할당
EC2 Capacity 부족	EC2 Capacity 관리 불필요
호스트 장애 도메인 공유	Task 단위 격리
EC2 Capacity 운영 부담	AWS에 위임

Task의 CPU/Memory, Task 수, Auto Scaling 정책은 Fargate에서도 관리해야 하며 이는 ECS on EC2에서도 동일하다.

차이는 Task를 실행하기 위한 EC2 Capacity 관리 여부이다.

현재 서비스는 기존 대비 약 80배 이상 성장했으며 트래픽이 계속 증가하고 있다. 또한 인프라 운영 인원 2명이 DB, 네트워크, 모니터링, 장애 대응을 함께 담당하고 있다.

따라서 EC2 Capacity 관리까지 직접 수행하기보다 해당 영역을 AWS에 위임하고 Task와 서비스 운영에 집중하는 방향을 선택하였다.

---

	EC2 (c5a.large)	ECS 관리형 인스턴스 (c5a.large)	Fargate
2 vCPU / 4 GiB 시간당	$0.086	$0.09632	$0.11356
월 비용	$61.29	$69.35	$81

단위 자원 기준으로는 Fargate가 가장 비싸다.

하지만 현재 설계에서 메모리와 여유 Capacity를 확보하려면 c5a.large 3대가 필요하다.

구성	필요 자원	월 비용
ECS on EC2	c5a.large × 3	$183.87
Fargate	3.5 vCPU / 7 GiB	$141.75

현재 구성에서는 EC2의 유휴 Capacity로 인해 Fargate가 약 $42.12/월 저렴하다.

다만 트래픽이 빠르게 증가할 경우 Fargate의 비용이 EC2보다 높아질 수 있다.

---

결론: ECS Fargate를 선택한다.

앞서 검토한 현재 인프라의 한계와 서비스 운영 조건을 기준으로 다음과 같이 판단하였다.

판단 기준	ECS on EC2 선정 시 문제	Fargate 선택 근거
Capacity 관리	트래픽 성장에 따라 EC2 기본 Capacity, 여유 Capacity 및 인스턴스 구성을 지속적으로 조정해야 함	Task 실행에 필요한 EC2 Capacity 관리를 AWS에 위임
장애 대응 Capacity	EC2 장애 시 Task를 즉시 재배치하려면 평상시에도 여유 EC2 Capacity 확보가 필요함	Task 실행을 위한 EC2 여유 Capacity를 직접 확보·관리할 필요가 없음
자원 활용	EC2의 OS, ECS Agent가 자원을 점유하여 Task 배치 시 실제 가용 자원을 별도로 고려해야 함	Task에 필요한 CPU/Memory를 직접 지정하여 EC2 시스템 자원을 고려한 배치 불필요
Task 배치	제한된 EC2 Capacity 내에서 여러 서비스의 Task 배치와 호스트 장애 영향을 고려해야 함	EC2 인스턴스 단위의 Task 배치 및 호스트 Capacity 관리 부담을 AWS에 위임
운영 복잡도	인프라 담당 2명이 DB, 네트워크, 모니터링, 장애 대응과 EC2 Capacity 운영을 함께 담당해야 함	EC2 운영 계층을 제거하여 Task 및 서비스 운영에 집중
서비스 성장	기존 대비 약 80배 성장했으며 향후 요구 Capacity도 지속적으로 변화할 가능성이 있음	EC2 Capacity Planning 없이 Task 수와 자원 요구량을 중심으로 확장 가능
현재 비용	여유 Capacity와 Task 배치를 위해 c5a.large 3대가 필요하여 월 약 $183.87 발생	현재 필요한 Task 자원 기준 월 약 $141.75로 현재 구성에서는 약 $42.12 절감

현재 구성에서는 Capacity 관리 부담, 운영 복잡도 측면에서 현재 요구사항에 더 적합하다고 판단했다.

EC2 Capacity 관리와 Task 배치에 대한 관리 부담을 AWS에 위임하고, 인프라 운영 시 Task와 서비스 운영에 집중할 수 있다는 점을 주요 선정 근거로 판단하였다.

다만 서비스 규모가 더욱 증가하여 Fargate의 Task 단위 비용이 EC2 Capacity를 직접 운영하는 비용보다 커질 경우, ECS on EC2 전환을 다시 검토한다.

따라서 현재 성장 단계에서는 EC2 Capacity를 직접 최적화하는 것보다 관리 계층을 줄이는 것이 더 적합하다고 판단하였다.