AWS Fargate: 서버 없이 컨테이너를 실행하는 시대

들어가며: EC2 관리라는 마지막 짐

이전 글에서 ECS가 컨테이너의 배치·복구·스케일링·배포를 자동화한다고 설명했다. 하지만 ECS를 EC2 런치 타입으로 사용하면, 여전히 한 가지 짐이 남는다 — EC2 인스턴스 관리.

ECS가 컨테이너를 관리해 주지만, 그 컨테이너가 돌아갈 EC2 인스턴스는 여전히 당신의 몫이다:

• 인스턴스 타입은 뭘 쓸까? (t3.large? m5.xlarge?)
• 인스턴스를 몇 대 띄워야 할까?
• OS 보안 패치는 누가 할까?
• 인스턴스의 디스크가 꽉 차면?
• 컨테이너가 늘어나면 인스턴스도 같이 늘려야 하는데, 두 레이어의 스케일링을 어떻게 조율할까?

이 마지막 질문이 특히 골치 아프다. ECS 서비스가 태스크를 10개로 늘리려 하는데, EC2 인스턴스에 빈 자원이 없으면? 새 인스턴스를 띄워야 하는데, EC2 Auto Scaling은 별도로 설정해야 한다. 두 레이어의 스케일링을 동기화하는 것은 운영의 복잡성을 크게 높인다.

"컨테이너만 정의하면, 그 아래의 서버는 알아서 처리되면 안 되나?"

2017년 AWS re:Invent에서 공개된 Fargate가 정확히 이 질문에 답한다.

1. Fargate란 무엇인가

정의

AWS Fargate는 ECS(또는 EKS)에서 컨테이너를 실행할 때, EC2 인스턴스를 프로비저닝하거나 관리할 필요 없이 컨테이너를 직접 실행하는 서버리스 컴퓨팅 엔진이다.

핵심 개념: Fargate는 ECS의 대체가 아니라 런치 타입(Launch Type) 이다.

• ECS + EC2 런치 타입: "내가 관리하는 EC2 위에서 컨테이너 실행"
• ECS + Fargate 런치 타입: "서버 관리 없이 컨테이너 실행"

태스크 정의, 서비스, 클러스터 — ECS의 모든 개념이 동일하다. 달라지는 것은 누가 인프라를 관리하는가뿐이다.

비유로 이해하기

이전 글들의 비유를 이어가면:

2. 서버리스 컨테이너라는 개념은 어디서 왔는가

"서버리스"의 진화

서버리스(Serverless)라는 용어가 처음 주목받은 것은 2014년 AWS Lambda의 출시다. "코드 조각을 올리면 서버 없이 실행된다"는 개념이었다. 하지만 Lambda에는 제약이 있었다:

• 실행 시간 제한 (초기 5분, 현재 15분)
• 특정 런타임만 지원 (Node.js, Python 등)
• 패키지 크기 제한
• 콜드 스타트 지연

Fargate는 서버리스의 개념을 컨테이너에 적용한 것이다. Lambda의 제약 없이 — 어떤 언어든, 어떤 프레임워크든, 얼마나 오래 실행하든 — Docker 컨테이너를 서버리스로 실행할 수 있다.

학술적 맥락: "관리의 추상화" 연구

UC Berkeley의 연구팀은 2019년 논문 "Cloud Programming Simplified: A Berkeley View on Serverless Computing"에서 서버리스의 본질을 이렇게 정의했다:

서버리스 컴퓨팅의 핵심은 자원 관리와 운영의 책임을 클라우드 사업자에게 이전하는 것이다.

이 논문은 서버리스가 단순히 "서버가 없다"는 것이 아니라, 운영 복잡성의 추상화 레벨을 한 단계 올리는 것이라고 설명한다. EC2가 하드웨어를 추상화했고, ECS가 컨테이너 배치를 추상화했고, Fargate가 서버 관리 자체를 추상화했다.

3. Fargate는 어떻게 작동하는가

내부 구조

Fargate의 내부 작동 방식은 AWS가 2019년 re:Invent 및 2020년 USENIX ATC에서 일부 공개했다.

핵심 기술: Firecracker

2018년, AWS는 Firecracker라는 오픈소스 경량 가상화 기술을 공개했다. Lambda와 Fargate의 기반이다.

Firecracker는 microVM — 초경량 가상 머신을 생성한다. 각 Fargate 태스크는 전용 Firecracker microVM 안에서 실행된다.

왜 microVM인가? 일반 컨테이너는 커널을 공유하므로 격리가 완벽하지 않다. 멀티테넌트 환경(여러 고객의 워크로드가 같은 서버에서 실행)에서는 하드웨어 수준의 격리가 필요하다. Firecracker는 컨테이너의 가벼움과 VM의 보안성을 결합했다.

태스크 실행 흐름

Fargate에서 태스크가 실행되는 과정:

사용자 관점에서 달라지는 것은 거의 없다. 태스크 정의에서 "requiresCompatibilities": ["FARGATE"]를 지정하고, cpu와 memory를 Fargate 지원 조합으로 설정하면 된다.

4. EC2 런치 타입 vs Fargate: 무엇을 선택할 것인가

비용 비교

Fargate의 가격은 EC2보다 단위 자원 기준으로 20~40% 비싸다. 하지만 총 소유 비용(TCO)은 다른 이야기다.

상황별 선택 가이드

Fargate를 선택하라:

• 인프라 엔지니어가 없거나 적은 팀
• 트래픽 변동이 큰 서비스 (유휴 자원 낭비 방지)
• 배치 작업, 크론 작업처럼 간헐적으로 실행되는 워크로드
• 빠르게 프로토타입을 배포하고 싶은 경우
• 보안 요구사항이 높아 OS 패치 부담을 줄이고 싶은 경우

EC2 런치 타입을 선택하라:

• 대규모로 항상 실행되는 워크로드 (비용 효율 중요)
• GPU가 필요한 AI/ML 워크로드 (Fargate는 GPU 미지원)
• 호스트 레벨 접근이 필요한 경우 (커스텀 모니터링 에이전트 등)
• 스팟 인스턴스를 적극 활용하여 비용을 극단적으로 줄이고 싶은 경우
• Windows 컨테이너 (Fargate의 Windows 지원은 제한적)

5. Fargate 실전 구성

태스크 정의 (Fargate용)

EC2 런치 타입과 거의 동일하지만, 몇 가지 차이가 있다:

{
  "family": "my-api",
  "requiresCompatibilities": ["FARGATE"],
  "networkMode": "awsvpc",
  "cpu": "512",
  "memory": "1024",
  "executionRoleArn": "arn:aws:iam::role/ecsTaskExecutionRole",
  "containerDefinitions": [
    {
      "name": "api",
      "image": "123456789.dkr.ecr.ap-northeast-2.amazonaws.com/my-api:1.0",
      "portMappings": [
        { "containerPort": 8080, "protocol": "tcp" }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/my-api",
          "awslogs-region": "ap-northeast-2",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ]
}

Fargate 전용 설정:

• requiresCompatibilities: ["FARGATE"] 필수
• networkMode: awsvpc 필수 (각 태스크가 고유 IP 확보)
• cpu/memory: Fargate가 지원하는 조합만 사용 가능

Fargate CPU/메모리 조합

Fargate는 임의의 CPU/메모리 조합을 쓸 수 없다. 지원되는 조합이 정해져 있다:

서비스 생성 (Fargate)

aws ecs create-service \
  --cluster my-cluster \
  --service-name my-api \
  --task-definition my-api:1 \
  --desired-count 3 \
  --launch-type FARGATE \
  --network-configuration '{
    "awsvpcConfiguration": {
      "subnets": ["subnet-abc", "subnet-def"],
      "securityGroups": ["sg-123"],
      "assignPublicIp": "DISABLED"
    }
  }' \
  --load-balancers '[{
    "targetGroupArn": "arn:aws:...",
    "containerName": "api",
    "containerPort": 8080
  }]'

EC2 런치 타입과 비교했을 때 추가되는 것은 networkConfiguration뿐이다. 서브넷, 보안그룹, 퍼블릭 IP 할당 여부를 지정한다.

Fargate Spot — 서버리스에서도 비용 절감

2019년에 도입된 Fargate Spot은 EC2 스팟 인스턴스의 개념을 Fargate에 적용한 것이다. AWS의 유휴 Fargate 용량을 최대 70% 할인된 가격에 사용할 수 있다.

EC2 스팟과 마찬가지로 AWS가 용량을 필요로 하면 2분 전 통보 후 회수할 수 있다. 하지만 ECS 서비스의 자동 복구 기능과 결합하면 실용적이다:

• Capacity Provider 전략 예시: "Fargate 온디맨드 2개 + Fargate Spot 최대 8개"
• 기본 트래픽은 온디맨드로 보장, 추가 트래픽은 Spot으로 저렴하게 처리
• Spot이 회수되면 ECS가 자동으로 새 태스크를 시작

{
  "capacityProviderStrategy": [
    { "capacityProvider": "FARGATE", "base": 2, "weight": 1 },
    { "capacityProvider": "FARGATE_SPOT", "weight": 3 }
  ]
}

이 설정이면 최소 2개는 온디맨드로 보장하고, 추가 태스크는 75% 확률로 Spot에 배치된다.

6. 실제 사례

사례 1: 스타트업의 전형적인 Fargate 여정

시드 단계 (팀원 3~5명):

• Fargate + ALB로 API 서버 1~2개 실행
• 월 비용: $3050
• 인프라 전담 인력: 0명

시리즈 A (팀원 15~30명):

• Fargate 서비스 5~10개 (API, 웹, 워커, 스케줄러)
• 오토스케일링으로 피크 대응
• 월 비용: $3001,000
• 인프라 전담: 여전히 0명, 개발자가 겸임

시리즈 B 이후 (팀원 50명+):

• 비용 최적화 필요 → 일부 워크로드를 EC2 런치 타입이나 Graviton으로 전환
• 또는 그대로 Fargate 유지 (인건비 대비 컴퓨팅 비용이 미미한 경우)

사례 2: 배치 처리 — Fargate의 숨은 강점

Fargate는 항상 실행되는 서비스뿐 아니라 간헐적 배치 작업에 특히 강하다.

예: 매일 새벽 3시에 데이터 분석 작업을 실행해야 한다. 30분 걸리는 작업이다.

EC2로 하면:

• 24시간 돌아가는 인스턴스 비용 지불 (23.5시간은 유휴)
• 또는 작업 전에 인스턴스를 시작하고 끝나면 종료하는 자동화 구축

Fargate로 하면:

• EventBridge 스케줄러가 ECS RunTask를 호출
• Fargate 태스크가 시작, 작업 수행, 완료 후 자동 종료
• 30분분의 비용만 과금

이것이 Fargate의 진짜 강점이다. 항상 실행되는 서비스에서는 EC2와 비용 차이가 크지 않지만, 실행 시간이 짧은 간헐적 워크로드에서는 압도적으로 저렴하다.

사례 3: CI/CD 파이프라인

GitHub Actions이나 CodeBuild에서 빌드한 이미지를 Fargate에 배포하는 전형적인 파이프라인:

전체 과정이 5~10분. 개발자가 코드를 Push하면 자동으로 프로덕션까지 배포된다. 서버 접속, 수동 배포, 서비스 재시작 — 이런 것이 전혀 필요 없다.

7. Fargate 운영 팁

콜드 스타트 최소화

Fargate 태스크는 시작 시 이미지를 Pull해야 한다. 이미지가 크면 시작이 느려진다.

• 작은 이미지 사용: Alpine 기반, 멀티스테이지 빌드로 이미지 크기 최소화
• ECR 같은 리전: 이미지 레지스트리와 Fargate가 같은 리전이면 Pull 속도가 빠르다
• Seekable OCI (SOCI): 이미지를 전부 다운로드하지 않고 필요한 레이어만 지연 로딩하는 AWS 기술. 대형 이미지의 시작 시간을 최대 70% 단축

로깅과 모니터링

Fargate에서는 SSH로 서버에 접속할 수 없다. 로깅과 모니터링이 더욱 중요하다:

• CloudWatch Logs: 태스크 정의에서 awslogs 드라이버 설정 (필수)
• CloudWatch Container Insights: CPU, 메모리, 네트워크, 스토리지 메트릭 자동 수집
• X-Ray: 분산 트레이싱. 서비스 간 호출 추적
• ECS Exec: 필요 시 실행 중인 컨테이너에 셸 접속 (디버깅용)

# ECS Exec으로 실행 중인 컨테이너에 접속
aws ecs execute-command \
  --cluster my-cluster \
  --task arn:aws:ecs:... \
  --container api \
  --interactive \
  --command "/bin/sh"

비용 모니터링

Fargate 비용을 추적하는 핵심:

• 태그 기반 비용 할당: 서비스별로 태그를 붙여 Cost Explorer에서 분석
• 적정 사이즈: CloudWatch 메트릭에서 실제 CPU/메모리 사용률을 확인하고, 태스크 정의의 자원 할당을 최적화
• Fargate Spot 활용: 중단 가능한 워크로드는 Spot으로 전환

마치며: 인프라의 최종 목표 — 보이지 않는 것

이 시리즈를 통해 우리는 인프라의 추상화가 어떻게 진화해 왔는지를 따라왔다:

각 단계에서 개발자가 신경 써야 할 것이 하나씩 줄어들었다. Fargate에 이르면 개발자가 관리하는 것은 Docker 이미지와 태스크 정의뿐이다. 서버가 몇 대인지, 어떤 OS인지, 어떤 패치가 필요한지 — 이 모든 것이 보이지 않는다.

클라우드 글에서 말했듯, 인프라는 보이지 않을수록 좋다. Fargate는 그 비전에 가장 가까운 현재의 도달점이다.

코어닷투데이의 AI 서비스들 — 추론 API, 데이터 파이프라인, 모니터링 시스템 — 이 Fargate 위에서 실행될 때, 개발팀은 인프라 관리 대신 AI 모델의 품질과 사용자 경험에 집중할 수 있다. 그것이 바로 서버리스 컨테이너의 진짜 가치다.