Elastic Container Service - 용어 정리

ECS를 구축, 관리하기 위해서는 그 안에서 사용되는 용어를 이해해야 합니다. 이번 글에서 ECS에서 통용되는 용어들의 개념을 이해하도록 합니다.

---

 

자원 개념

위에서 아래로 내려갈수록 큰 개념으로 생각하시면 됩니다. container는 ECS에서 가장 작은 단위, cluster가 가장 큰 단위입니다.

# container

• 단순히 시야가 제한된 리눅스 프로세스입니다.
  • namespace 분리로 컨테이너 환경 안에서 호스트의 프로세스 목록을 볼 수 없고,
  • 루트 디렉터리 변경으로 호스트의 디렉터리를 볼 수 없도록 제한합니다. (chroot)
  • 끝으로 제어 그룹을 통해 컨테이너가 접근할 수 있는 자원을 제어합니다. (control group)
• 우리가 알고 있는 바로 그 컨테이너의 원리죠?

# task definition

• ECS에서 동작하는 작업 환경의 정의입니다. 환경의 네트워크, CPU, Memory를 설정할 수 있고 미리 생성한 컨테이너를 1~N개까지 포함시키게 됩니다. 이 공간 안에서 실행되는 컨테이너는 네트워크 자원을 공유합니다.
• task definition 안에 컨테이너를 몇 개 포함시킬지는 설계하기 나름이지만, 보통 세트로 움직이는 컨테이너를 묶습니다. 예를 들어, 컨테이너는 한 개의 역할(목적)에 집중하는 프로세스로 정의하고 해당 프로세스에서 발생하는 로그를 별도의 공간(CloudWatch 등)으로 처리하는 프로세스(fluentd 등)를 한 개의 task definition으로 정의할 수 있겠습니다.

# task

• ECS에서 실제 수행되는 단위입니다. task definition이 작업 정의였다면 task는 수행되고 있는 단위입니다. kubernetes가 친숙하신 분들께는 pod로 비유하는 게 좋겠네요!

# service

• kubernetes 이야기가 나온 김에 여기도 비유를 하자면 kube에 namespace와 같습니다.
• 물리적인 환경 위에 구분된 논리적인 영역입니다. 말이 어렵죠? 컨테이너 오케스트레이션의 등장 배경과 맞물려 있는데 결국은 물리적인 환경(여러 대의 EC2, 가상머신, 물리 머신 등)을 마치 한 대의 거대한 서버로 바라보고 그 안에서 논리적인 영역을 나눠 프로그램을 돌리는 개념입니다. 역시 더 모호하죠? 다음 그림을 살펴봅시다.

• 클러스터 내에 3대의 인스턴스가 존재하고 이것들을 서비스(빨간색 점선 테두리)가 묶고 있는 구조입니다.
• 이 서비스 안에 서로 다른 N개의 task가 동작할 수 있어요. 여기 그림에서는 한 종류의 task(my-task)만 존재하네요.
• 그럼 cluster == service 아닌가? 하는 의문이 생길 수 있는데요, 그렇지 않습니다. 클러스터는 N개의 서비스를 가질 수 있거든요. 서로 유사한 부류의 서비스를 한 개의 클러스터에 놓고 관리하게 됩니다.
• 그럼 또 의문이 들죠. AWS 계정에 1개의 클러스터만 생성하고 그 안에 서비스를 다 때려 넣으면 되는 게 아닌가? 아닙니다. 서비스의 종류에 따라 분리하는 게 관리적인 차원에서 좋고, 더욱이 어떤 서비스의 경우에는 물리적으로 독립된 환경에서 구동되어야 하는 경우가 존재합니다. (법적인 문제도 같이 얽혀있었던 것 같은데…)

# container instance

• 일반적인 instance 입니다. 여기에 1) ecs-agent를 설치 2) 클러스터에 묶이도록 설정 3) 정상적인 설정의 경우 클러스터에 묶임. 이 과정이 통과된 인스턴스를 container instance라고 부릅니다.
• ecs-agent는 인스턴스 안에서 동작하는 task와 container의 상태를 관리하는 역할을 합니다. agent 덕분에 우리는 ECS를 콘솔에서 모니터링/관리할 수 있습니다.

# cluster

• 이미 다뤄졌지만 정리하자면, 클러스터는 물리적인 인스턴스의 묶음 단위입니다.
• Capacity provider를 통해 인스턴스 개수를 수평 확장(scale-out) 할 수 있습니다.

 

기타 개념

# Fargate

• ECS의 서버리스를 담당하고 있는 서비스입니다. task를 생성할 때 EC2, Fargate를 복수 선택할 수 있는데요, Fargate는 물리적인 EC2의 존재를 사용자가 인지할 필요 없이 task 운영을 가능하게 해 줍니다.
• EC2 만으로 ECS를 운영하는 경우 예측 가능한 트래픽이 아니면 인스턴스 scale-out에 필요한 최소한의 시간이 보장되어야 합니다. Fargate는 인스턴스 부팅에 필요한 시간이 없기 때문에 스파이크 트래픽에 보다 안정적으로 대응이 가능합니다.
• 다만, 가격이 EC2로 운영하는 것 대비해서 비쌉니다. 인스턴스나 서비스 운영의 관리 여건이 안될 때 사용하면 유리하겠네요.

# auto-scaling

• 우리가 알고 있는 그 개념이 맞습니다. 수평 확장 기능으로, service와 cluster에서 설정할 수 있습니다.
• service의 auto-scaling은 task의 수를 조절하고,
• cluster의 auto-scaling은 container instances의 수를 조절합니다.
• cluster auto-scaling은 크게 고민할 필요가 없는데 service의 auto-scaling의 경우 물리적인 인스턴스 메모리 제약을 계산해서 최소/최대를 설정해야 합니다. service 안에 있는 task 1개가 1 GiB 메모리를 사용한다고 가정하고, 최소 task 개수를 16개로 설정한다고 생각해봅시다. 그럼 container instances는 몇 대가 운영되어야 할까요? 4 GiB 인스턴스라면 최소 4대 이상은 돼야 모든 task를 운영할 수 있을 겁니다. 이렇듯 cluster의 물리적인 자원 한계도 인지하고 있어야 합니다. 물론, 돈이 많다면 cluster에 container instances 대수는 팍팍 늘겠지만 부족한 기술력을 돈으로 메꾸면 안 되겠죠. 최적화된 프로그램을 만드는 게 중요합니다 (뜬금없지만)