ECS

ECS란?

• ECS(Elastic Container Service)는 컨테이너들의 헬스를 체크하고 일정수준 이상의 컨테이너들이 동작하도록 도와주는 서비스
  • 쿠버네티스의 아마존 버전이라고 생각하면 얼추 맞음

• ECS는 완전 관리형 컨테이너 오케스트레이션 서비스
  • ECS의 장점은 다양한 AWS 기능과 통합이 쉽고 다른 서비스에 비해서 쉽게 적용이 가능

Tip!

• 컨테이너 오케스트레이션 도구에는 Docker에서 만든 Docker Swarm, 구글의 Kubernetes, 하시코프의 Nomad 등 다양한 오케스트레이션 도구가 있음

시작 유형

FARGATE

• 컨테이너에 적합한 서버리스 컴퓨팅 엔진으로 ECS 및 EKS에 사용할 수 있으며 서버를 관리 할 필요 없이 어플리케이션 별로 리소스를 지정하여 관리 비용을 지불하는 방식으로 앱에 집중하여 인프라가 아닌 어플리케이션을 배포 관리 할 수 있음
  • Lambda와 매우 유사한데 AWS에 가지고 있는 Fargate Pool에서 하나를 가지고와서 도커 이미지를 실행
  • Lambda처럼 초당 과금이지만 상대적으로 많이 비싸며 프리티어 대상도 아님

• FARGATE가 적합한 경우
  • 단기간에 엄청난 CPU 연산이 필요한 상황
  • 15분을 넘겨 Lambda에서는 실행이 불가능한 상황
  • 주기적으로 실행되는 스크립트

EC2

• EC2 컨테이너 인스턴스를 연결하여 ECS 서비스 구성하기 때문에 위의 FARGATE 보다 비용이 저렴하나 설정이 복잡하고 인프라 확장이 FARGATE 에 비해서 적음

• EC2가 적합한 경우
  • 각 컨테이너들이 동일한 디스크를 공유해야 하는 상황
  • 세밀한 인스턴스 세팅이 필요한 상황
  • 항상 실행되는 스크립트

ECS 사용 이점

• 간단한 API 호출을 사용하여 컨테이너 기반 애플리케이션을 시작 및 중지할 수 있음
• 중앙 집중식 서비스를 사용하여 클러스터 상태를 확인할 수 있음
• 다수의 친숙한 EC2 기능에 액세스할 수 있음
• 일관된 배포 및 구축 환경을 생성하고, 배치 및 ETL(Extract-Transform-Load) 워크로드를 관리 및 크기 조정하고, 마이크로 서비스 모델에 정교한 애플리케이션 아키텍처를 구축할 수 있음

ECS의 작동 방식

• ECS의 구성 요소는 크게 5가지
  • Task(작업)
  • Task Definition(작업 정의)
  • Service(서비스)
  • Continer Instacne(컨테이너 인스턴스)
  • Cluster(클러스터)

① Task

• ECS의 최소 단위는 task
  • 1개 이상의 컨테이너가 task에 구성됨

② Task Definition

• task의 구성 요소는 task definition에 JSON 형식으로 작성되어 있음
  • 작성된 내용을 참고로 task가 구성됨
• task definition에서 작업 및 컨테이너가 참고할 이미지, 사용할 리소스 양, 시작 유형, 로깅 구성 등 다양한 매개변수를 정의할 수 있음

③ Service

• task definition을 참고하여 task를 실행
  • 또한 원하는 수의 task를 유지 관리하는 스케줄러 역할을 함
• 선택적으로 로드 밸런서 뒤에서 실행하여 로드 밸런싱과 오토 스케일링 기능을 할 수 있음

④ Container Instance

• ECS 컨테이너 에이전트를 실행하고 cluster에 등록된 EC2 인스턴스
  • 리눅스, 윈도우 OS를 지원하며 온프레미스 VM 등의 다른 OS도 지원
• Fargate 시작 유형을 사용하는 task는 서버리스로 배포되므로 container instance는 적용되지 않음

⑤ Cluster

• container instance(Fargate라면 task)의 논리적 그룹

작업 순서

• ⑴ 컨테이너의 이미지를 저장소(ECR)에 커밋
• ⑵ task definition에서 사용할 이미지 및 시작 유형, 리소스 정의
• ⑶ cluster 생성
• ⑷ service가 task definition을 참고하여 task 생성
• ⑸ ELB에 들어온 요청에 따라 오토 스케일링 및 로드 밸런싱

Tip! 추가 내용

Task - Service 관계

Task Definition

• 원하는 Docker 컨테이너를 생성할 때 어떤 설정으로 몇 개 이상 생성 할 지를 정의한 세트
  • 컨테이너의 이미지, CPU•메모리 리소스 할당 설정, Port 매핑, Volume 설정 같은 것들이 포함되며 기존 docker run 명령에서 가능했던 대부분 옵션이 설정 가능
  • 컨테이너 오케스트레이션에서는 컨테이너가 필요에 따라서 자동적으로 실행되거나 종료될 수 있음
    • 따라서 매번 이러한 설정들을 지정하기보다는 미리 설정들의 집합을 하나의 단위로 정의해놓고 사용함
    • 이 단위가 바로 task definition
  • 한 번 task definition을 만들면 이 task definition을 기반으로 특정 설정을 변경할 수 있음

• task definition에는 한 개 이상의 컨테이너에 대해 정의가 가능하며 task definition 내부에 정의된 컨테이너 사이는 link 설정으로 연결 가능

• task definition에서 정의된 대로 실제 생성된 container set들을 task라고 부름

Task

• task definition에서 정의된 대로 배포된 container set을 task라고 부름
  • 즉 task 안에는 한 개 이상의 컨테이너들이 포함되어 있으며 ECS에서 컨테이너를 실행하는 최소 단위는 task

• task는 cluster에 속한 container instance(EC2 instance)에 배포되게 됨
  • 또한 task는 여러 container instance(EC2 instace)에 배포 가능

Service

• task들의 life cycle을 관리하는 부분을 service라고 함
• 각 task들은 각자 다른 서비스
• task를 cluster에 몇 개나 배포할 것인지 결정하고 실제 task들을 외부에 서비스 하기 위해 ELB에 연동 되는 부분을 관리하게 됨
  • 만약 실행 중인 task가 어떤 이유로 작동이 중지 되면 이것을 자동으로 감지해 새로운 task를 cluster에 배포 하는 고가용성에 대한 정책도 service에서 관리
  • 즉, 오토 스케일링과 로드 밸런싱을 관리하는 역할

Container Instance (EC2 Instance)

• ECS는 container 배포(task 배포)를 EC2 instance 기반에 올리도록 설계 되어 있음
  • task를 올리기 위해 등록된 EC2 instance를 container instance라고 부른다.
• ECS를 처음 시작하면 생성되는 default cluster에는 container instance를 자동으로 할당 시켜 주기도 하지만
  새롭게 cluster를 생성하게 되면 직접 container instance를 만들어야 함
• container instance용 AMI 이미지는 AWS 측에서 제공해 주기 때문에 어렵지 않게 생성이 가능
• 하나의 container instace 내부에는 각각의 다른 task가 여러 개 있을 수 있음

Cluster

• task가 배포되는 container instance들은 논리적인 그룹으로 묶이게 되는데 이 단위를 cluster라고 부름
• task를 배포하기 위한 instance는 반드시 cluster에 등록되어야 함

Cluster - Container Instance와 Task - Service의 관계

ECS의 구조적 특징 및 주의사항

ECS의 Docker Host 역할은 EC2 Instance가 담당

• 컨테이너는 보통 물리 서버에 Docker Daemon을 설치하고 그 위에 컨테이너를 하나씩 배포하게 되는데, Hypervisor 기반에서 동작되는 VM 보다 훨씬 더 많은 서비스를 올릴 수 있는게 큰 장점 중 하나
  • 하지만 AWS는 ECS를 위한 Container 전용 서버팜을 따로 구성하지 않고, VM 형태의 EC2 instance에서 Container 를 동작시키는 방법을 택했음
  • 이유는 무엇일까?

• AWS의 전체 서비스 설계를 보면 EC2 instance를 중심으로 다양한 서비스들이 연계되는 모양새를 갖추고 있는데, 이는 AWS의 가장 큰 장점이기도 함
  • Network 서비스인 VPC와 ELB, EIP 에서 부터 Auto scaling, Cloud Formation 등 수십가지의 서비스가 조직적으로 엮여 있으며 이 중심에는 사용자들이 가장 많이 사용하는 EC2 Instance가 있음
  • 만약, AWS가 ECS 서비스를 위해 새로운 Container 서버팜 환경을 구성하고 설계했다면, 기존 EC2 를 중심으로 한 다양한 서비스들과의 연계에 대하여 굉장히 많은 고민을 할 수 밖에 없을 것
  • 차라리 컨테이너를 EC2 instance에 올림으로서, EC2 중심으로 엮여 있는 기존의 서비스를 이용하는 장점을 흡수하는게 훨씬 이득이 많았을 것이라 추측

Tip! 서버팜이란?

• 서버팜은 한곳에 집단으로 수용되어 동작되는 일련의 컴퓨터군을 말함
  • 서버팜은 때로 서버 클러스터라고 불리기도 함
• 웹서버팜은 하나 이상의 서버를 가지고 있는 웹사이트 또는 다중 서버를 사용하여 웹호스팅 서비스를 제공하는 ISP를 지칭

Overlay Network가 아닌 ELB를 이용한 Network 구조

• Docker를 사용하려는 사람들이 늘어나면서 컨테이너를 대규모로 운영하려는 시도가 점점 많아지고, 자연스럽게 다수의 Docker Host 를 Clustering 형태로 통합 관리하려는 필요성이 커지게 됨
  • Host에 Container를 어떻게 배포할 것인지에 대한 스케줄링 관련 문제, 다른 Host에 배포된 Container 사이의 통신 문제, 동일 Port를 사용하는 컨테이너들을 동시 수용할 때의 Host 포트 맵핑 이슈 등이 대표적인 문제들

• 주목 받고 있는 컨테이너 Orchestration 시스템인 Kubernetes나 Docker Swarm의 경우 위와 같은 이슈를 해결하기 위해 Overlay Network 구조를 추가해 이런 문제를 해결하고 있음
  • Host간 네트워크를 논리적으로 묶어서 연결해 주는 Overlay Network는 컨테이너 Orchestration을 위한 중요 구성 요소로 고려되고 있는 추세

• 그렇다면 ECS의 Host Clustering을 위한 Network 구조는 어떠할까?
  • ECS의 cluster는 매우 단순
  • cluster는 Docker Host의 논리적 묶음일 뿐이지, 이를 위해 추가적인 Network 설계 구조가 들어가지 않은 것으로 보임

• Overlay Network가 없다면 다른 Host에 상주한 컨테이너 사이에는 컨테이너에 할당된 Private IP를 이용해 Native하게 통신하게 어려우며, 대신 외부 통신과 동일하게 각 Host IP로 컨테이너에 맵핑된 Port를 이용하는 방법 밖엔 없음
  • 이는 컨테이너간 통신을 빈번히 요구 하는 Application을 올리는 경우에 상당히 어려움을 겪을 수 있음
  • Host 사이를 논리적으로 묶어줄 Network 구조가 없다면 결국 컨테이너 사이 통신을 위해서는 각 컨테이너가 상주한 Host의 정보를 추가로 알아야만 통신이 가능하기 때문
  • 하지만 ECS는 이러한 문제를 기존 서비스 중 하나로 어느정도 해소했는데 바로 ELB

• ECS는 service 내부에 여러 개의 task가 배포될때 ELB의 밸런싱 그룹에 task들이 자동으로 들어가도록 설계되어 있음
  • 즉, service 사이의 통신은 ELB를 통해 통신을 함으로서 task의 life cycle을 유연하게 관리할 수 있게 만든 구조
  • 같은 service에 속한 task들이 다른 Host에 있게 된다면 이들 사이의 통신은 여전히 어렵다는 한계는 있지만, 굳이 동일한 service 안에 동일한 task끼리 통신할 일은 많지 않을 것이기에 큰 문제는 없을 것으로 보임
    • 보통 Web 서버가 WAS나 DB와 통신하지, 굳이 동일한 일을 하는 Web 서버 끼리는 통신을 주고 받을 일이 없음

하나의 Host에는 한 개의 Task만 수용 가능

• 컨테이너가 Host의 특정 Port를 점유 해야만 하는 구조는 결국 같은 Port로 서비스 하려는 컨테이너가 한 Host에 한 개 밖에 올라갈 수 없다는 의미
• ECS 구조적 측면에서 보면 service 안에 task를 올릴 수 있는 최대 숫자는 cluster에 등록된 container instance 개수 이상이 될 수 없다는 것
  • 예를 들어, service 안에 Apache 컨테이너가 정의된 task를 2개 올리고 싶다면 반드시 Host는 두대 이상이 필요하다는 뜻
  • 이는 컨테이너 집적도가 그만큼 낮아질 수 밖에 없는 구조적 한계

• Kubernetes의 경우 Overlay Network과 Pods - Service 라는 논리적 개념으로 이러한 문제를 해결한 것과 비교하면 아쉬운 부분

• 대신 Host 마다 다른 task들이 공존하도록 만들어 집적도를 올리는 방법이 단점을 상쇄하는 방법으로 보임
  • 아래 그림과 같이 container instance는 두 대이지만, 각각 다른 포트를 사용하는 service를 여러 개 올려 컨테이너 집적도를 높일 수 있음

ECS 특성에 맞는 Application 설계

• ECS 기반으로 Application을 잘 운영하려면 task와 service 개념의 구조적 특징을 이해하고 Application을 설계 해야 함

① Task Definition에는 단일 Tier 속성의 컨테이너만 정의하는게 유리

• task에는 여러 컨테이너를 정의할 수 있음
• 하지만 최소 배포 단위가 task 단위 이므로 단일한 속성의 컨테이너 하나만 정의하는 게 좋은 설계 방향일 것
  • 예를 들어, task definition 에 Web - WAS - DB 컨테이너를 한꺼번에 정의했다고 가정
  • 만약 task가 하나인 상황에서는 큰 문제가 없을 것
  • 하지만 task를 추가로 늘리려고 한다면, task에 속한 Web - WAS - DB 셋이 한꺼번에 늘어나게 됨

• 보통 서비스에 부하가 일어나면, 각 Tier 별로 어떤 구간에서 스트레스를 받는지 판단 후 해당 Tier 의 서버만 추가하여 LB에 넣는 방식으로 해결 ( = Scale-Out )

• 하지만 task에 모든 Tier 를 혼합시켜 구성하면 Scale-Out 형태의 증설은 불가능할 것
  • 따라서, task의 Scale-Out 구조를 고려하여 task를 Tier 단위로 분리해서 정의하는게 좋음

② 용도에 맞게 Container Instance를 VPC로 구분해 사용하면 보안성을 높일 수 있음

• 컨테이너를 올릴 Host는 EC2를 사용함으로 EC2에 적용되는 다양한 서비스들을 그대로 이용할 수 있음

• 따라서 VPC와 같은 기능을 이용하여 컨테이너가 올라가게 될 EC2를 구분해 사용한다면 더욱 보안성을 높일 수 있음
  • 예를 들어, cluster A는 외부로 노출할 Web 컨테이너들을 배포하고 cluster B에는 외부 노출을 하지 않는 WAS 컨테이너를 배포한다고 가정
  • 이때 cluster A에 속하는 EC2 instance들은 VPC의 Public Subnet 에 속하도록 하고, cluster B 에 속하는 EC2 instance들은 VPC의 Private Subnet에 속하도록 구성할 수 있음
  • 단, Private Subnet에 배포된 EC2 instance들은 외부 통신과 단절되게 되므로, ECS를 사용하려면 NAT Gateway 와 같은 서비스를 이용해 아웃바운드 트래픽에 대한 처리를 추가해 주어야 함

③ 컨테이너 특성상 DB와 같은 Stateful한 서버는 컨테이너 보다는 EC2나 RDS를 이용해 연계해서 사용

• 컨테이너는 기존의 인프라 방식에 비해 생성과 소멸에 좀 더 유연
  • 바꿔 말하면 컨테이너는 언제든 삭제 될 수 있음을 전제로 해야함

• 그러므로 Data Store가 목적인 DB는 컨테이너의 컨셉과는 상반된 형태임을 고려해야 함
  • 따라서 컨테이너의 특성상 Stateless한 성격의 Web이나 WAS 서버에 이용하기를 권장
• DB의 경우 AWS의 RDS와 같은 서비스를 이용해 컨테이너와 함께 쓴다면 안전하면서도 유연한 인프라 구성을 갖출 수 있을 것

④ ECR과 같은 컨테이너 서비스들과 연계하여 사용하면 좋음

• AWS에는 ECS 말고도 컨테이너 이미지 Repository 서비스인 ECR도 서비스 하고 있음
  • 이를 ECS와 엮어서 사용한다면 더욱 좋을 것