[AWS] ECS 개념

목차 

앱을 배포하기전에 간단하게 ECS란 무엇인지 개념을 공부해보겠다. 

 

컨테이너 오케스트레이션 도구 ECS란?

엔지니어나 개발자는 Docker 컨네이너를 이용하여 인프라를 관리해 본 경험이 있을 것이다. Docker를 이용하여 여러개의 서비스를 구축하다 보면 여러가지 고려 해야할 사항도 많고 관리하는데 어려움을 느낀적이 있을 것이다. 이런 문제를 보안하기 위하여 우리는 컨테이너를 적절하게 배치하고 관리할 수 있게 도와주는 컨테이너 오케스트레이션 도구의 필요성을 느낀다. AWS에서는 현재 컨테이너 오케스트레이션 서비스로 EKS와 ECS를 제공하는데 그 중 ECS에 대해 정리해보려 한다. 
EKS와 ECS의 차이는 Kubernetes 기반으로 관리하냐 Docker기반으로 관리하냐에 차이점이 있다. 굳이 왜 컨테이너 오케스트레이션 도구를 두가지나 제공하였을까? 의문이 좀 들긴 하였다. 공식 문서를 참고하면 ECS는 AWS자체의 고유한 서비스이기 때문에 상대적으로 Kubernetes를 도입한 EKS보다는 AWS와 연동성이 좋다는 장점이 있습니다.
한마디로 정리하면 EKS는 Kubernetes의 강력한 기능을 활용하고자 하는 경우에 적합하며, ECS는 AWS 서비스와 간단한 애플리케이션을 위한 간단한 솔루션으로 유용할 수 있다. 

ECS의 작동 방식

ECS의 구성 요소는 크게 5가지로 나눌수 있다. 

• Task Definition(작업 정의)
• Task(작업)
• Continer Instacne(컨테이너 인스턴스)
• Service(서비스)
• Cluster(클러스터)

• Task Definition(작업 정의)
  실제 서버에서 Docker를 빌드할때 Docker run 명령어에 옵션을 추가하여 CPU/메모리 리소스, port 매핑등을 설정한 경험이 있을 것이다. 이 Task Definition은 마찬가지로 컨테이너의 CPU/메모리 리소스 할당 설정, port 매핑, volume설정 정의해주는 역할을 한다. 이러한 설정을 기반으로 만든 container set이 바로 Task이다. 
  미리 설정을 집합시켜 매우 편리하게 관리할 수 있다는 장점이 있고, Task definition에는 한개이상의 컨테이너에 대한 정의가 가능하다. 
• Task(작업)
  kubernetes의 Pod라고 생각하면 된다. ECS에서 컨네이너를 실행하는 최소 단위로 Task안에는 한개 이상의 컨테이너들을 포함하고 있다. 
  Service가 Task Definition(작업 정의)를 참조하여 Container instance(EC2 Instance)에 Task를 배포한다. 또한 한번에 여러 Container instance(EC2 Instance)에 배포 가능하다. 
• Service(서비스)
  Task들의 Life cycle을 관리한다고 생각하면 된다. Task를 Cluster에 몇 개나 배포할지 결정하고, 실제 Task들을 외부에 서비스 하기 위해 ELB에 연동 되는 부분을 관리한다. 
  또한 Task의 대한 고가용성인 오토스케일링 또한 제공한다. 
  정리하면 Service는 오토스케일링, Task관리, 로드밸런싱 역할을 한다고 이해하면 된다. 
• Container Instance(EC2 instance)
  Task는 Container Instance(EC2 instance)에 배포된다. Task를 올리기 위해 등록된 EC2 instance를 Container Instance라고 지칭한다. Container Instance는 개별적으로 생성가능하고 Cluster를 처음 생성할 대 자동으로 할당 받을 수도 있다. Service에는 하나의 Task만 정의될 수 있지만 Container Instance내부에는 각각의 다른 Task를 배포할 수 있습니다. 또한, ECS Insatnce에 AMI를 활용하여 오토 스케일링을 진행한다. 
• Cluster(클러스터)
  Container Instance들의 논리적인 그룹을 Cluster라고 부른다. 
  Task를 배포하기 위한 Instance는 반드시 Cluster에 등록되어야지 운영이 가능하다. 

EC2와 Fargate 방식

ECS에서는 EC2와 Fargate로 나눠서 관리할 수 있다. 
Fargate는 서버를 관리하지 않고 애플리케이션 구축에만 집중할 수 있게 해주는 서버리스 컴퓨터 엔진이다. Fargate는 애플리케이션에 필요한 정확한 CPU와 메모리를 선택하므로 EC2보다 더 효과적으로 제어할 수 있다는 장점이 있다. 

또한, Fargate에서 용량 스케일 아웃을 처리하므로 트래픽 급증에 대한 걱정할필요가 없으며 EC2 Instance보다 운영 부담이 줄어든다. 하지만 가격적인 부분에선 EC2 Instance가 더 비싸다는 단점이 있다. 
그래서 Fargate방식은 낮은 운영 오버헤드가 필요한 대규모 워크로드나 가끔 버스트가 발생하는 소규모 워크로드등 손이 많이 가지 않는 애플리케이션을 위주로 모델링 하는 것이 적절하다고 생각한다. 

 

EC2 Instace 방식은 앞서 말한것처럼 Instance에 Task를 배포하여 관리하는 방법이다. EC2 Instance는 AWS에서 자체적으로 관리해주는 서버리스 Fargate방식에 비해 운영자가 직접 관리를 해줘야하므로 더 손이 많이 간다는 단점이 있다. 예를 들어 인스턴스에 대한 보안 패치 등을 직접 관리해야 한다. 하지만 인스턴스에 대해 직접 Full 컨트롤을 가질 수 있으며 Fargate보다 더세부적인 설정을 할 수 있다는 장점이 있다. 그래서 꾸준하게 세부적인 사항을 관리해줘야 하는 애플리케이션에 적절한 모델링이라고 생각한다. 

 

Fargate방식과 EC2 Instance방식을 섞어서 사용할 수 있으므로 애플리케이션에 맞게 적절하게 섞어 배치하는 것이 중요할 것이다. 이 글에선 ECS에 대한 전반적인 지식을 기록하였다. 이 지식을 기반으로 간단하게 Fargate 방식과 EC2 Instance 방식으로 배포를 해보겠다.