Conceptly
← 전체 목록
🚀

AWS Fargate

컴퓨팅서버리스 컨테이너 실행 환경

Fargate는 컨테이너를 실행하되 그 아래 서버 노드를 직접 운영하지 않게 해주는 서버리스 실행 환경입니다. 팀은 태스크에 필요한 자원만 선언하고, 실제 호스트 준비와 관리 책임은 AWS가 집니다.

아키텍처 다이어그램

🔍 구조 다이어그램

점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다

왜 필요한가요?

컨테이너는 쓰고 싶은데 노드 패치, 용량 계획, 클러스터 서버 운영까지 함께 떠안으면 팀이 얻는 이점이 줄어듭니다. 애플리케이션보다 컨테이너를 올릴 서버 관리가 더 큰 일이 되면 배포 속도가 다시 느려집니다.

왜 이런 방식이 등장했나요?

컨테이너를 도입한 뒤에도 노드 운영이라는 부담은 그대로 남았습니다. EC2 기반 클러스터를 쓰면 보안 패치를 주기적으로 적용해야 하고, 용량 계획을 잘못 잡으면 노드가 부족해 배포가 막히거나 과잉 프로비저닝으로 비용이 낭비됩니다. 야간이나 휴일에 노드 장애가 나면 인프라 담당자가 직접 대응해야 했습니다. 컨테이너의 패키징과 배포 장점은 유지하면서 이런 서버 관리 부담을 없애기 위해 Fargate 같은 서버리스 실행 모델이 필요해졌습니다.

내부적으로 어떻게 동작하나요?

Fargate는 ECS 태스크에 필요한 CPU와 메모리만 선언하면, AWS가 컨테이너를 올릴 실행 환경을 대신 준비합니다. 이미지는 ECR에서 가져오고, 네트워크와 로깅은 VPC와 CloudWatch, 트래픽은 ELB와 연결해 서버 운영 없이 컨테이너를 실행합니다.

경계와 구분

Fargate와 EC2는 둘 다 애플리케이션을 실행하지만 책임 분담이 다릅니다. Fargate는 서버 운영을 감추고 컨테이너 태스크 실행에 집중하게 해주고, EC2는 서버 자체를 직접 다루게 합니다. 컨테이너는 쓰되 노드 패치와 용량 계획을 줄이고 싶으면 Fargate를 보고, OS와 서버 수준 설정까지 직접 제어해야 하면 EC2를 보면 됩니다.

언제 쓰나요?

예를 들어 인프라 전담 엔지니어가 없는 소규모 팀이 마이크로서비스 여러 개를 운영할 때, 노드 관리 없이 태스크 정의만으로 배포할 수 있어 적합합니다. 트래픽 변동이 큰 이벤트 워커나 야간 배치 태스크처럼 필요할 때만 자원을 쓰고 종료하는 패턴에서도 비용 효율이 높습니다. OS 커널 튜닝이나 GPU 직접 제어 같은 서버 수준 조작이 필요한 경우에는 맞지 않습니다.

마이크로서비스배치 처리CI/CD 빌드웹 애플리케이션