본문 바로가기
프로젝트&&스터디/AWES 3기 (2025.01~)

[AEWS-3기] AWS EKS Fargate 개요

by james_janghun 2025. 2. 8.

 

이 포스팅은 가시다(gasida)님이 진행하는 AEWS(Amazon EKS Workshop Study) 3기에서 학습한 내용을 정리하고 제가 스스로 공부한 내용을 기록하고자 하는 포스팅입니다.

EKS Fargate 시리즈

[AEWS] AWS EKS Fargate 개요 (현재글)

[AEWS] AWS EKS Fargate 사용하기

 

AWS Fargate란 무엇인가?

아주 간단히 말해 Fargate는 AWS에서 제공하는 서버리스 컨테이너 엔진이다. 

그렇기 때문에 잘알려진 컨테이너 서비스 ECS와 EKS 모두에서 제공한다.

 

우리가 가져갈 핵심은 서버리스 + 컨테이너 이렇게 두가지로 볼 수 있다.

 

서버리스 컨테이너이기 때문에 별도의 서버 컴퓨팅 자원을 관리하지 않고도 애플리케이션을 바로바로 띄워서 사용할 수 있다는 장점이 있다.

또한 클라우드 특성상 사용량 만큼 과금되는 방식어서 요금도 저렴하다.

애플리케이션을 별도로 격리하면서도 다양한 자원을 캐시로 남기지 않기 때문에 보안적으로도 우수하다고 볼 수 있다.

 

Fargate의 작동방식

AWS Fargate의 작동방식을 찾아보면 아래와 같은 이미지 들이 나온다.

별도의 작동 방식이라기 보다는 우리가 컨테이너를 띄울때 결국은 서버 운영체제 위에서 작동시키지만 Fargate를 사용하면 서버 없이도 그냥 컨테이너만 띄울 수 있다. 그래서 우리는 컨테이너 이미지만 가지고 있으면 언제든 쉽게 컨테이너를 띄울 수 있어! 라고 말하는 그림들이 주를 이루고 있다. 

 

따라서 처음에 언급한 서버리스, 컨테이너의 장점이 필요하다면 이 서비스를 적극 활용하는 것을 추천한다.

https://aws.amazon.com/ko/fargate/
https://www.eksworkshop.com/docs/fundamentals/fargate/

 

 

Fargate 단점은 없나?

당연히 있다. 서버리스의 단점을 가지고 있다.

1. 속도가 느리다.

응? 서버리스, 컨테이너 인데 속도가 느리다고? 그렇다. 기반이 되는 별도의 서버를 가지고 있지 않아도 된다는 장점이 있지만 컨테이너 1대를 띄우려면 매우 느리다는 단점 또한 존재한다.

 

철저히 운영해본 입장에서 느리다고 느껴진다. 우리가 도커를 띄우거나 쿠버네티스를 사용할때 로컬에서 띄우면 컨테이너기 때문에 부팅속도가 엄-청나게 초고속인걸 알 수 있다. 하지만 Fargate는 어디까지나 Amazon에서 제공하는 컴퓨팅 어딘가에서 조용히 격리되서 띄워지게 될 것이다. AWS는 당연히 모든 사람에게 이 자원을 할당하지 않고 지속적으로 최적화하고 있을 것이다. 그렇기 때문에 우리가 Fargate를 만드는 순간 그쪽에서도 우리에게 Fargate를 제공하기 위한 로직이 작동하는 시간이 필요하게 된다.

그래서 단순히 노드에서 Pod를 하나 띄우는게 2-3초 걸리는게 EKS Fargate에서 pod하나가 올라오려면 최소 2분 - 3분 이상이 걸린다.

 

 

2. 과연 Fargate가 저렴한가?

이건 계산기를 반드시 두드려볼 문제다.

https://aws.amazon.com/ko/fargate/pricing/

 

서버리스 컴퓨팅 엔진 - AWS Fargate 요금 - Amazon Web Services

오늘 원하는 내용을 찾으셨나요? 페이지의 콘텐츠 품질을 개선할 수 있도록 피드백을 보내 주세요.

aws.amazon.com

AWS 비용을 따져보면 Fargate의 과금체계는 다음과 같다.

1) vCPU 당 과금, 메모리 GB당 과금

- 컨테이너를 모두 Fargate로 운영할 경우 vCPU와 메모리의 크기 정보와 노드 그룹으로 운영할 경우를 모두 비교해서 계산해봐야한다.

 

2) Fargate 임시 스토리지 요금

- 기본 용량은 20GB라고 하는데 그 이상 될 경우 GB 당 과금이 된다.

 

단순히 1,2개 운영한다고 하면 저렴하다고 보일 수 있다. 그러나 갯수가 많아지면 과연 Fargate를 운용하는게 맞는지에 대해서 한번쯤은 생각해봐야한다.

 

다만 이전 회사에서 배운 것 중 비용 절감에 좋았던 점은 Fargate는 필요 없으면 삭제하고, 필요할때 띄우면된다는 것이다. 즉, 개발 환경의 경우 업무시간에 켜놓고 그 외에 삭제하는 방법으로 비용축소하는 사례가 있었다.

 

 

3. 서버리스 안전한가?

솔직히 이건 운영해본 입장에서 안정적이라고 본다. EC2도 결국 아마존에서 네트워크 문제나 인프라 문제가 크게 생기면 장애가 날 수 있기에 단순히 Fargate가 서버리스라고 불안정하다는 것은 옛말이라고 생각한다.

 

다만, Fargate는 AWS에서 관리하기 때문에 컨테이너 취약점을 아주 빠르게 반영한다. 무슨말이냐면 한 달에 한번씩 취약점 업데이트를 한다. 운영자 입장에서 prod 환경에 pod가 한 달에 한 번씩 교체된다는건 정말 치명적인 문제였다. 취약점 업데이트 바로 반영해줘서 고마운데 이건 운영자가 선택할 수 없고 강제로 변경해야한다. (기간내 변경 안하면 아마존에서 일괄로 교체한다. blue/green으로 문제없게 한다고 하지만 어쨌든 컨테이너가 변경되는 과정에 손실은 회사가 감당해야한다)

 

 

4. Fargate EKS 운영 쉽지 않아...

EKS Fargate에서는 Fargate pod는 사실 node로 인식된다. 쿠버네티스 버전에 맞게 Fargate 노드를 가지게 된다. 따라서 노드그룹의 버전업데이트 처럼 Fargate도 버전업을 해줘야 한다.

 

만약 날잡고 운영환경의 EKS를 1.24 -> 1.25 -> 1.26으로 업그레이드한다고 하자. Fargate를 운영하는 회사에서는 다음과 같이 진행한다. 여기에 노드그룹까지 같이하면 3개를 같이 올려줘야한다. Fargate가 pod 역할을 하지만 node 정보도 같이 가져가기 때문에 1.24의 노드 정보를 가지고 있을 경우 1.26으로 바로 업그레이드 할 수 없다.

 

1) EKS를 1.24 -> 1.25로 업그레이드 한다.

2) Fargate 노드를 전부 재실행하여 1.25로 업그레이드한다.

3) EKS를 1.25 -> 1.26으로 업그레이드 한다.

4) Fargate 노드를 전부 재실행하여 1.26으로 업그레이드 한다.