[AWS] ECS (Elastic Container Service)

ECS

• 컨테이너화된 애플리케이션의 손쉬운 배포, 관리 및 조정에 도움이 되는 완전관리형 컨테이너 오케스트레이션 서비스
• AWS Fargate의 서버리스 기술을 활용하여 자율 컨테이너 운영을 제공
• 구성, 패치 적용 및 보안에 소요되는 시간을 줄일 수 있음

 

ECS 장점

• 클러스터를 관리하기 위한 별도의 인스턴스를 구성 & 관리하지 않아도 되고, 클러스터 관리에 대한 추가 비용이 없음
• AWS에서 만든 서비스이기 때문에 다른 AWS 서비스와 연동 지원
• AWS Fargate의 서버리스 기술을 활용하여 자율 컨테이너 운영을 제공

 

ECS 주요 개념

Cluster

• 도커 컨테이너를 실행할 수 있는 컨테이너 인스턴스의 논리적인 공간
  • 컨테이너 인스턴스? 도커가 설치된 컨테이너 인스턴스에서 도커 컨테이너가 실행됨
• 컨테이너 인스턴스를 클러스터에 연결 시키고 명령을 전달 즉 오케스트레이션 하기 위해서는 AWS에서 제공하는 ECS Agent가 컨테이너 인스턴스에 설치되어 있어야함
  • 기본적으로 ECS Agent가 설치된 AMI로 EC2가 자동 생성되어 클러스터와 연결

 

Task Definition & Task

Task

• 컨테이너를 실행하는 최소 단위
• 1개 이상의 컨테이너로 구성될 수 있으며, 해당 Task 내의 컨테이너는 모두 같은 ECS 클러스터 인스턴스 내에서 실행되도록 보장
• docker-compose와 비슷한 개념

Task Definition

• Task를 정의한 작업 정의
• Task 실행 시 Task Role, Docker Network Mode, Docker 실행 명령, CPU/Memory 제한, Logging Driver, Volumn Mount 등의 옵션 설정
• 생성 또는 업데이트 된 Task Definition은 모두 Revision Version이 저장되므로, 특정 Revision Version으로 Task를 롤백할 때 유용

Service

• Task를 실행하는 방식
  • 직접 Task Definition을 이용한 실행
    • Task에 대한 관리가 되지 않으며, AWS에서 제공하는 다른 서비스 (ELB, AutoScale)를 이용할 수 없으므로 대부분 사용 X
  • Service를 이용한 실행
    • Task Definition을 이용하여 Task를 시작 및 유지 관리
    • Task 실행 유형(EC2 or Fargate), 타입(복제 or 데몬), Task가 실행되어야 할 작업 개수, 배포 방식(롤링 or Blue/Green), AutoSale(작업의 개수를 조정)  및 ELB(작업의 개수를 유지) 설정
• Task를 관리하는 상위 그룹
• 서비스 검색
  • 컨테이너화된 서비스들이 손쉽게 서로를 검색하고 연결할 수 있도록 지원하는 통합된 서비스 검색 기능
• Auto Scaling
  • 클라우드의 유연성을 돋보이게 하는 핵심 기술로 CPU, 메모리, 디스크, 네트워크 트래픽과 같은 시스템 메트릭(Metric) 값을 모니터링하여 서비스의 사이즈를 자동으로 조절
  • 동작 원리
    • 특정 주기마다 네트워크와 서비스의 시스템 메트릭 정보들을 모니터링 서비스(Cloud Watch)로부터 수집
    • 모니터링 서비스에서 지정한 임계치 조건을 벗어나는 것을 감지하면 오토스케일링 그룹으로 알람을 발송
    • 오토스케일링 그룹에서 오토스케일링 정책에 따라 서비스 수를 늘리거나 줄임
      • 지정된 서비스 수만큼 프로비저닝 작업을 시작
    • ELB에서 생성된 신규 서비스의 상태를 확인
    • 서버 상태 확인이 완료되면 해당 서비스를 로드밸런서에 추가하여 다른 서버와 동일하게 클라이언트의 요구 트래픽을 처리

 

컨테이너 배포 

• 새로운 버전의 애플리케이션 작업 정의를 업로드 하면, Amazon ECS 스케줄러가 자동으로 업데이트된 이미지를 사용하는 새로운 컨테이너를 시작하고 이전 버전을 실행하는 컨테이너를 중지
• 배포 방식
  • Rolling
    • 컨테이너를 한 개씩 구 버전에서 새 버전으로 교체해가는 전략
    • 구 버전에서 새 버전으로 트래픽을 점진적으로 전환
    • 서버 수의 제약이 있을 경우 유용하나 배포 중 인스턴스가 감소되므로 서버 처리 용량을 미리 고려해야함
  • Blue/Green
    • 구 버전에서 새 버전으로 일제히 전환하는 전략
    • 구 버전의 서비스와 새 버전의 서비스들을 동시에 나란히 구성하고 배포 시점이 되면 트래픽을 일제히 전환
    • 하나의 버전만 프로덕션 되므로 버전 관리 문제를 방지할 수 있고 빠른 롤백이 가능
    • 운영 환경에 영향을 주지 않고 실제 서비스 환경에서 새 버전 테스트 가능
      • 구 버전과 새 버전을 모두 구성하고 포트를 다르게 주거나 도메인 이름을 다르게 주어서 새 버전으로 접근하도록 설정하여 테스트 진행