[AWS] EC2 대신 Fargate를 도입해야 할까? 비용 분석 및 실무 사용기

AWS에서 컨테이너 서비스를 구축할 때 가장 큰 고민은 "EC2 모드로 할 것인가, Fargate 모드로 할 것인가?"입니다. 직접 서비스를 운영하며 느꼈던 장단점과, 많은 분이 오해하고 있는 비용 효율성에 대해 정리해 드립니다.

---

1. Fargate란 무엇인가? (EC2와 차이점)

   가장 쉽게 설명하면 "서버 관리의 주도권"이 누구에게 있느냐의 차이입니다.

   • EC2 Launch Type: 내가 직접 서버(Node)를 띄우고, 그 위에 컨테이너를 올립니다. OS 패치, 오토 스케일링 설정, 보안 그룹 관리 등을 직접 해야 합니다.
   • Fargate Launch Type: AWS가 서버를 관리해 줍니다. 나는 "CPU 2GB, 메모리 4GB 주세요"라고 주문만 하면 컨테이너가 뜹니다.

---

2. 비용 분석: Fargate는 정말 비싼가?

   "Fargate는 편한 대신 비싸다"는 인식이 있습니다. 반은 맞고 반은 틀립니다.

   • 24시간 풀로 돌아가는 대규모 클러스터: EC2(Reserved Instances/Savings Plans)가 더 저렴합니다.
   • 트래픽이 들쭉날쭉하거나, 개발/테스트 환경, 배치 작업: Fargate가 유리할 수 있습니다.

   실제 경험상 Fargate가 비용 효율적인 구간:

   1. 유휴 자원(빈 공간)이 많은 경우: EC2는 꽉 채워 쓰지 않아도 인스턴스 비용을 다 내지만, Fargate는 딱 쓴 만큼만 냅니다.
   2. 운영 인건비: 서버 관리(OS 업데이트, 에이전트 관리)에 들어가는 엔지니어의 시간을 돈으로 환산하면 Fargate가 압도적으로 저렴합니다.

---

3. 실무 도입 시 겪었던 이슈와 해결 팁

   Fargate를 처음 도입할 때 가장 당황했던 포인트들과 해결책입니다.

   A. 로그 확인이 어렵다?
   EC2는 접속해서 로그 파일을 까보면 되지만, Fargate는 서버에 접속할 수 없습니다(기본적으로).

   • 해결: awslogs 드라이버를 사용하여 CloudWatch Logs로 로그를 쏘는 설정이 필수입니다. 최근에는 ECS Exec 기능을 통해 Fargate 컨테이너 내부로 쉘 접속도 가능해져 디버깅이 쉬워졌습니다.

   B. 이미지가 너무 크면 느리다
   Fargate는 매번 새로운 VM 위에서 컨테이너를 띄우는 방식이므로, 도커 이미지를 다운로드(Pull)하는 시간이 곧 부팅 시간입니다.

   • 해결: 이미지를 최대한 경량화(Alpine 리눅스 사용 등)하고, 불필요한 레이어를 줄여야 빠른 스케일 아웃이 가능합니다. 그렇지만 대비시간은 늦기는 합니다..^^;;

   C. Timezone 설정
   기본적으로 UTC 시간을 따릅니다. 한국 시간(KST)이 필요하다면 Dockerfile에서 설정하거나, 환경 변수 TZ=Asia/Seoul을 주입해야 합니다.

---

4. 결론: 언제 Fargate를 써야 할까?

   이런 경우 Fargate를 강력 추천합니다.

   • 인프라 전담 엔지니어(DevOps)가 따로 없는 소규모 팀
   • 트래픽 예측이 어렵거나 급격히 변하는 서비스
   • CI/CD 파이프라인용 일회성 빌드 에이전트

   이런 경우 EC2를 고려하세요.

   • GPU가 필요한 고성능 컴퓨팅 작업 (Fargate GPU는 제한적/비쌈)
   • 이미 예약 인스턴스(RI)를 많이 구매해 둔 경우
   • 커널 레벨의 튜닝이 필요한 특수 목적 애플리케이션

아래는 제가 만든건 아니지만, 실제 적용되어 있던 json 의 형태입니다.

    1 {
    2   "family": "alpha-squad-api-task",
    3   "networkMode": "awsvpc",
    4   "requiresCompatibilities": [
    5     "FARGATE"
    6   ],
    7   "cpu": "256",
    8   "memory": "512",
    9   "containerDefinitions": [
   10     {
   11       "name": "api-container",
   12       "image": "YOUR_ACCOUNT_ID.dkr.ecr.ap-northeast-2.amazonaws.com/alpha-squad:latest",
   13       "portMappings": [
   14         {
   15           "containerPort": 8080,
   16           "hostPort": 8080,
   17           "protocol": "tcp"
   18         }
   19       ],
   20       "environment": [
   21         {
   22           "name": "TZ",
   23           "value": "Asia/Seoul"
   24         },
   25         {
   26           "name": "SPRING_PROFILES_ACTIVE",
   27           "value": "prod"
   28         }
   29       ],
   30       "logConfiguration": {
   31         "logDriver": "awslogs",
   32         "options": {
   33           "awslogs-group": "/ecs/alpha-squad-api",
   34           "awslogs-region": "ap-northeast-2",
   35           "awslogs-stream-prefix": "ecs"
   36         }
   37       },
   38       "essential": true
   39     }
   40   ]
   41 }

• cpu & memory: Fargate는 CPU와 메모리 조합이 정해져 있습니다. 위 설정(256, 512)은 가장 저렴한 최소 사양 조합입니다.
• networkMode: Fargate는 반드시 awsvpc 모드를 사용해야 합니다. 각 태스크가 고유한 ENI(탄력적 네트워크 인터페이스)를 할당받아 보안 그룹 제어가 정교해집니다.
• logConfiguration: 서버에 접속할 수 없는 Fargate 특성상, awslogs 드라이버를 통해 CloudWatch Logs로 로그를 보내는 작업은 필수입니다.
• environment (TZ): 본문에서 언급한 대로 시스템 타임존을 한국 시간으로 맞추기 위해 환경변수를 주입한 예시입니다.