AWS 컨테이너 ( ECS, EKS, 파게이트, ECR )

 

 

 

ECR에 대해서 듣게 되어서 간단한 개념이라도 찾아보고자 유튜브 강의를 보았다!

해당 영상은 Elastic Container Service (ECS), Elastic Kubernetes Service (EKS), EC2 vs Fargate, Elastic Container Registry (ECR)에 대해 자세히 설명해주는 영상으로 전체적으로 이해하는데 많이 도움이 되었다.

 

모든 글과 캡쳐는 다음의 영상을 듣고 정리하였다!🙌

↓

 

https://www.youtube.com/watch?v=AYAh6YDXuho

 

 

 

 

 

 

 

 

 

Container Orchestration의 필요성

MSA환경을 구성하는 경우 여러 다른 app을 배포해야하거나 Third Party를 이용하기 위해 또다른 app을 배포하여 상황에 따라 여러개의 container를 운영해야 하는 상황이 발생할 수 있다. 만약, 모든 컨테이너를 EC2에 배포한다고 했을 때 여러개의 컨테이너를 관리하고, 자원이 아직 사용가능한지, 다음 컨테이너를 스케줄링할 수 있는지, 어떤 컨테이너가 중단되었고 여러개의 복제를 어떻게 삭제할 것 인지 등 모두 개발자가 관여해야 한다면 매우 복잡하고 어려운 문제일 것이다. 이러한 문제를 해결하기 위해 복수의 컨테이너를 사용하였을 때 발생할 수 있는 관리 역할의 자동화 툴(Container Orchestration Tool)을 통해 해결할 수 있다.

 

즉, 보다 손쉽게 복수의 컨테이너를 관리하고 확장하고 배포하기 위해서 ECS, Docker Swarm, Kubernetes, Mesos, Nomad와 같은 컨테이너 Orchestration Tool을 사용한다.

 

 

 

 

 

 

 

 

 

Elastic Container Service (ECS)

ECR은 Container Orchestration Service로 컨테이너의 라이프사이클을 관리하는 역할을 담당한다. 컨테이너들을 관리하는 서비스를 포함하여 생성부터 종료 시점까지 컨테이너를 스케줄링하고 관리하는 Control Plane 역할을 하게 된다. 

 

 

 

 

 

 

 

ECS가 일하는 방식

AWS에서 컨테이너화된 application 클러스터를 실행하면 ECS 클러스터가 활성화 된다.

 

ECS 클러스터는 EC2 인스턴스 Virtual Machine에 호스트 되어 실행되고 있는 서비스들을 관리하게 되고, 해당 각각의 EC2 인스턴스에서 컨테이너 런타임에 Docker Agent가 실행되는 것과 동시에 Control Plane 소통을 위해 EC2 Agent도 함께 실행된다.

 

ECS Agent가 EC2 인스턴스에 호스트되어 컨테이너들을 관리할 수 있지만, 여전히 Docker와 같은 Virtual Machine(실행환경)을 관리해야 하는 문제를 가지고 있다. 이러한 문제를 해결하기 위해서 AWS Fargate와 함께 사용된다.

 

 

 

 

 

 

 

ECS with AWS Fargate

AWS Fargate란 EC2 인스턴스의 대안으로 기존에 VM에 EC2를 올려 실행환경을 확인 했던 것과 달리 Fargate를 통해 실행함으로서 VM등의 실행환경 설정을 Fargate가 담당하도록 하는 것이다.

 

 

 

 

 

 

Fargate 동작방식

Fargate는 컨테이너를 Serverless 방식으로 시작하는데, Serverless 방식이란 사용자의 AWS account에 서버를 올리는 방식이 아닌 AWS account의 서버를 사용하는 방식을 말한다. 즉, EC2 인스턴스 클러스터 및 작업 노드를 관리할 필요없이 작업 정의만을 통해 컨테이너를 실행할 수 있는 서비스이다.

 

Fargate의 동작 절차는 다음과 같다.

1. Fargate를 이용해서 컨테이너를 시작을 요청
2. 배포하고 운영하기 위해서 어느정도의 CPU, RAM, 저장소 등이 필요한지 파악
3. Fargate가 수요에 따라서 provision 서버 자원에 운영

 

 

 

 

 

Fargate의 장점

Fargate를 사용하면 서버를 중간에 provision하거나 어느정도의 리소스가 남았는지 등의 관리가 필요 없어지고, 컨테이너 배포 전에 provision을 통해 컨테이너를 실행하기 위한 최소한의 자원만 사용하여 운영할 수 있다. 즉, 이를 통해서 사용하는 만큼만 비용을 지불할 수 있고 이전에 지정된 자원을 수정하는 행위 없이 손쉽게 scale up, down이 가능해진다. 결과적으로 이전에 EC2인스턴스를 사용하였을 때 전체 서버의 비용을 전부 지출하게 되었던 것과 달리 AWS Fargate를 통해서 얼마나 오래사용하고 어느정도의 용량만을 차지하는지에 대해서만 비용을 지불하면 된다.

 

결과적으로 ECS와 Fargate를 이용하여 AWS에 의해서 Infrastructure와 컨테이너가 관리되어 개발자는 오직 application을 관리하는 데만 집중할 수 있게 된다. 단, Infrastructur에 대해서 통제상황이 많은 경우나 유연하게 대처해야 하는 경우에는 EC2 인스턴스를 사용하여 접근하는 것이 좋다.

 

이 외에도 CloudWatch(모니터링), IAM(사용자 권한제한), Elastic Load Balancer(로드밸런싱), VPC(네트워크)등이 존재한다.

 

 

 

 

 

 

 

 

 

 

Amazon Elastic Kubernetes Service (EKS)

AWS 환경에서 쿠버네티스 클러스터를 관리하기 위한 툴로 ECS의 역할을 대신한다. ECS와 동일하게 컨테이너들을 관리하는 역할을 하지만 ECS는 AWS에 특정되어있고 다른 플랫폼으로의 이동이 어렵기 때문에 상대적으로 덜 복잡한 application에 어울리는 장점이 있는 반면에 EKS의 경우 쿠버네티스 API를 그대로 이용하여 사용이 가능하며 독립적이기 때문에 다른 플랫폼으로의 이동에 유리하기 때문에 Helm Charts 사용과 같은 큰 커뮤니티에 어울린다. 단, 다른 AWS 서비스를 사용하고 있는 경우 이동이 어려울 수 있다.

 

분류	EKS	ECS
공통점	컨테이너들을 관리하는 역할을 수행
특징	쿠버네티스 API를 그대로 이용하여 사용이 가능	AWS에 특정되어있어 다른 플랫폼으로의 이동이 어려움
	Helm Charts 사용과 같은 큰 커뮤니티에 어울림	덜 복잡한 application에 어울림
	독립적이기 때문에 다른 플랫폼으로의 이동에 유리 (단, 다른 AWS 서비스를 사용하는 경우 이동이 어려울 수 있음)

 

 

 

 

 

 

EKS 동작 방식

기본적으로 ECS와 비슷하지만 EKS는 쿠버네티스의 마스터 노드를 배포하고 관리하는 방식으로 동작한다. 마스터 노드의 경우 가용 지역끼리 넘어서 복제되기 때문에 가용성이 높고 Etcd에 master process의 현재 상태 내용이 기록되기 때문에 configuration이나 데이터 정보를 잃지 않을 수 있다. 또한, EKS가 적절하게 데이터를 저장하고 복제하고 백업하는 등의 작업을 담당하기 때문에 개발자는 더이상 Master node에 대해서 걱정하지 않아도 된다.

 

실제 컨테이너를 실행시키는 환경은 ECS와 동일하게 진행된다. compute fleet이라 불리는 여러개의 Virtual Server를 가진 EC2 인스턴스, 즉 Worker Nodes를 생성하고 이를 EKS 클러스터와 연결한다.

 

ECS가 Docker Agent와 ECS Agent를 함꼐 가지고 있었듯이, EKS도 Docker Agent와 K8s 프로세스를 함께 가지게 된다.

 

그렇다면 ECS - Fargate 처럼 역할을 위임할 수 있을까?

 

EKS 와 EC2 인스턴스의 경우 Worker node의 실행환경을 스스로 관리해야 하지만, EKS와 Nodegroup을 사용하면 Nodegroup이 인스턴스의 생성과 삭제를 담당해주지만 이를 위한 설정이 필요하기 때문에 중간정도의 관리를 담당해줄 수 있다. ECS와 같이 Fargate를 함께 사용하면 관리 역할을 담당해주기 때문에 스스로 관리하지 않고 운영이 가능하다.

 

분류	EKS with EC2 Instances	EKS with Nodegroup	EKS with Fargate
관리 정도	self - managed	semi - managed	fully - managed
특징	worker 노드 스스로 실행환경을 관리	인스턴스의 생성과 삭제를 담당 -> 이를 위한 설청이 필요 (중간정도의 관리)	관리 역할을 완전히 담당

 

ECS처럼 EC2와 Fargate를 같이 사용하여 컨테이너 서비스 Combination으로 사용할 수도 있다.

 

 

 

 

 

 

 

 

 

Elastic Container Registry (ECR)

도커 이미지를 위한 저장소로 도커 컨테이너 이미지를 저장, 관리 배포하는 역할을 담당한다. 도커 이미지를 저장하는 Docker hub나 Nexus를 대신해서 사용된다. EKS나 다른 AWS 서비스와도 잘 호환되어 연결하고 설정하는 것이 쉽고 새로운 이미지가 등록되거나 이미지를 pull할 때 알려주는 역할을 담당한다.

 

 

 

 

 

ECR의 동작 방식

생성된 도커 이미지를 private 저장소에 저장하고 이를 EKS 클러스터나 ECS 클러스터에 전달하는 방식으로 진행된다.

 

 

 

 

 

 

 

완성 ✨

 

 

 

 

(참고할 사이트)

https://velog.io/@ragnarok_code/AWS%EC%9D%98-%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88-ECS-Fargate-ECR-%EB%B0%8F-EKS

AWS의 컨테이너: ECS, Fargate, ECR 및 EKS

https://bosungtea9416.tistory.com/entry/AWS-AWS-ECS-%EB%B0%8F-EKS-%EA%B0%9C%EB%85%90-%EC%A0%95%EB%A6%AC-EC2-%EB%B0%A9%EC%8B%9D-Fargate-%EB%B0%A9%EC%8B%9D

[AWS] AWS ECS 및 EKS 개념 정리

https://bluese05.tistory.com/51

AWS EC2 Container Registry(ECR) 어렵지 않아요