EC2, Fargate 차이점

EC2를 사용하면 직접 EC2를 사용하기 위한 자원을 할당하고, OS 업데이트와 보안 패치 적용, 서버가 제대로 작동하는지 확인하기 위한 모니터링 등 안전하게 지원을 관리할 책임이 부가된다. 그 대신 사용자의 요건에 맞게 설계가 가능하다.
Fargate를 사용하면 호스트를 관리할 필요가 없다. 서버 확장, 패치 적용, 보호, 관리와 같은 운영 오버헤드가 발생하지 않는다. Fargate의 컨테이너 실행 환경은 aws에서 언제나 최신 상태를 유지해준다. 하지만 단점으로는 EC2보다 가격이 높고 사용자가 직접 OS를 조작할 수 없다. 또 한 CPU/ 메모리 할당에 제한이 있으며, 컨테이너 기동 시간이 다소 오래 걸린다.

비용, 확장성, 신뢰성, 엔지리어링 관점

• ECS on EC2

1. 비용: ECS에서는 EC2 인스턴스와 EBS 볼륨에 대해 서비스 이용 비용이 발생하며 EC2 인스턴스는 실행되는 시간 만큼만 발생된다.(인스턴스가 커질수록 시간당 단가가 커진다.) 운영 비용은 EC2의 유지보수가 발생하기 때문에 비용이 높은 편이다. (자원, OS 업데이트나 보안 패치를 적용하는 것 모두 이용자의 업무가 된다.)
2. 확장성: EC2는 배포할 때 이용하는 이미지 캐시를 EC2 호스트에 저장할 수 있기 때문에 컨테이너 저장소에서 컨테이너 이미지를 다운로드 받는 시간을 줄일 수 있어 배포의 신속성은 우수하다. 하지만 수평 스케일링은 확보한 용량까지만 수평 스케일링이 가능하기 때문에 약한편이다.
   신뢰성: ECS는 관리형 서비스이므로 장애 복구는 AWS의 책임이 된다. EC2에 무언가가 문제가 발생한다면 SSH로 서버에 로그인해서 원인을 조사할 수 있다.

• ECS on Fargate

1. 비용: 주로 Fargate 비용이다. 컨테이너 애플리케이션에 필요한 vCPU와 메모리 자원에 대한 비용이 발생한다. vCPU와 메모리 자원은 컨테이너 이미지를 취득한 시점부터 ECS 종료될 때 까지를 계산해 초 단위로 과금한다. EC2보다 다소 비싼 편이다. 운영 비용은 인프라 관리 비용이 들지 않기 때문에 상당히 낮다.
2. 확장성: 배포의 신속성은 우수하지 않다. Fargate에서 가동하는 컨테이너는 컨테이너 별로 ENI(Elastic Network Interface)를 연결해야 하기 때문이다. 또한 Fargate는 EC2와 달리 이미지 캐시가 불가능하다. 수평적 확장은 Fargate가 쉽게 조절할 수 있으나 자원 확장은 몇 가지 제약이 있다.
   휘발성 스토리지는 21년 9월 기준 200GB다. 이 용량은 늘릴 수 없다. EFS 볼륨을 사용하는 방법이 있는데 21년 9월 기준으로 4vCPU, 30GB 메모리가 최대다.
3. 신뢰성: Fargate는 AWS가 관리하는 호스트이기 때문에 기본적으로 SSH 등을 통해 호스트에 접근할 수 없다. (sshd를 실행해 컨테이너에 직접 로그인하는 방법이 있긴 하지만 권장되지 않는다.) ECS Exec를 이용하면 컨테이너에 대화형 셸을 이용해 조작하거나 명령을 할 수 있다. 이를 통해 Fargate 장애 조사가 가능하다.

• EKS on EC2

1. 비용: EKS에서는 제어플레인인 EKS에도 비용이 발생한다. (21년 9월 기준 서울 리전에서 1개의 EKS 클러스터를 이용하는 비용은 1시간당 0.1달러다.) 운영 비용에서는 EC2의 운영 비용에 쿠버네티스 운영 비용이 포함된다. 쿠버네티스는 약 3개월에 한 번 마이너 버전이 나온다. EKS의 마이너 버전은 출시 후 약 12개월간 지원된다. 즉 컨테이너 플랫폼 버전을 정기적으로 업데이트하는 운영이 필요하다. (버전업은 제어 플레인과 데이터 플레인 둘 다 대상)
2. 확장성: ECS와 동일하다.
3. 신뢰성: 장애 복구 측면은 ECS와 동일하다. 하지만 EKS는 쿠버네티스가 기반인 서비스이기 때문에 쿠버네티스 자체에 문제가 발생한 경우 AWS에서 해결할 수 없는 문제가 된다.

• EKS on Fargate

1. 비용: EKS에서 데이터 플레인은 모두 Fargate로 하지 않는다. 상주 실행이 필요한 처리를 위해 EC2를 준비하고, 스팟 처리가 필요한 경우에는 Fargate를 이용한다. Fargate를 이용하는 Pod는 Fargate 프로필에 의해 결정된다. 운영 비용은 EKS on EC2에서느 제어 플레인과 데이터 플레인 모두 버전업을 해야 했으나 EKS on Fargate는 데이터 프레인의 버전업 작업은 불필요하다.

Pod와 노드의 관계
EKS on EC2에서는 노드인 EC2 위에 여러 Pod를 만들 수 있으나, EKS on Fargate에서는 Fargate 노드 위헤 1개의 Pod만 만들 수 있다. (DaemonSet을 이용할 수 없다. 데몬이 필요한 경우 별도의 사이드카 컨테이너를 구축해 데몬을 실행시켜야 한다.)

관리 권한 커네이너 이용
Fargate 노드에서는 관리 권한 컨테이너를 이용할 수 없다. kubectl apply 명령 자체는 실행이 되지만 Pending 인 상태가 지속된다.

클러스터 위부로부터의 통신이 가능한 로드 밸런서
EKS의 엔드포인트를 클러스터 외부에 공개할 때 ELB를 이용한다. EKS on EC2에는 다음 Service와 Ingress를 로드 밸러서로 이용할 수 있다. EKS on Fargate에서는 CLB를 지원하지 않는다.

• Service
  CLB(Classic Load Balancer)
  NLB(Network Load Balancer)
• Ingress
  AWS Load Balancer Controller
  NLB(Network Load Balancer)

2. 확장성: ECS와 동일하다.
3. 신뢰성: 제어 플레인은 EKS on EC2와 같으며, 데이터 플레인은 ECS on Fargate와 같다.