[AWS] EC2 Container Service

Heejeong Choi·2021년 12월 7일
0

Amazon Web Services

목록 보기
6/7
해당 포스팅은 Amazon ECS/ECR을 활용하여 마이크로서비스 구성하기 - 김기완 (AWS 솔루션즈아키텍트) 를 보고 작성되었습니다.

Amazon EC2 Container Service

→ 별도의 어플리케이션이 필요없는 컨테이너 운영 관리 서비스이다.

→ 모든 규모의 컨테이너 관리가 가능하고, 유연한 컨테이너 배치 기능과, AWS에서 플랫폼으로 통합도 가능하다.

→ 앞서 도커 컨테이너 고려사항에서, 컴퓨팅 자원들을 가용성이 높게 관리하기 위해 오케스트레이션을 고려해야 한다고 했는데, 이 때 쿠버네티스나 도커 스웝을 사용한다면 AWS에서 따로 구축을 해서 포함해야하지만, AWS ECS를 사용하면 개발자나 DevOps가 측면에서 그럴 필요가 없음.

Amazon ECS 구성 요소

  1. Clusters : 작업이 실행되는 EC2 인스턴스들의 덩어리

    → Available zone 안에 있는 Task가 운영되고 있는 각각의 EC2 인스턴스들. 이 클러스터들은 ECS 에이전트들을 갖고있고, 이 에이전트들이 에이전트 전달 서비스로 클러스터 관리 엔진과 통신을 한다.

  2. Task Definitions : 작업에 대한 컨테이너 및 환경에 대한 정의를 해둔 것

    → Volume def와 Container def로 나누어진다.

    → Container def : 컨테이너가 어디에 위치하는지 등에 대한 정보를 넣어둔 곳. JSON으로 정의하면 자동화하여 배포할 수 있음 특히 테스트 환경에서

  3. Task : 인스턴스에서 실행되는 실제 컨테이너 작업

    → ECS 클러스터에서 업무를 수행하는 단위

    → ECS 클러스터에 속하는 인스턴스에 배포함

    → Task definitions들을 가지고 EC2 인스턴스에 스케줄링을 하는건데, 이 스케줄링은 EC2 정해진틀에 맞춰 배치가 되어지는 것.

  4. Cluster management engine : 클러스터 리소스 및 작업 상태 관리

  5. Scheduler : 클러스터 상태를 고려한 작업물 배치

  6. Agents : EC2 인스턴스 및 매니저와 통신

  7. Service : 요청을 받고 응답을 주는 서비스

    → 작업정의와 작업 개수를 기반으로 클러스터 내 서비스를 생성하는것 (하나의 서비스를 배포하는데 두개의 서로다른 AZ에 각각에 2개씩 EC2 인스턴스를 배포하겠다라는 뜻)

    → 설정한 작업 개수로 컨테이너 이상시 자동으로 복구됨(특정한 개수에 문제가 생겨서 컨테이너가 응답을 안하면, desired 컨테이너 수 만큼 복구시켜주는 것)

    → Elastic Load Balancing을 통한 컨테이너 부하 분산 설정 가능

    → Auto Scaling 설정 가능

    → how to create? AWS 콘솔 > ECS > Clusters > Services > Create에서 Configure service에서 수치를 맞게끔 설정하여 만들 수 있다.

스케줄링

✔ AWS 콘솔 → ECS → Clusters → Services → Create → Task Placement에서 컨테이너 배치 전략을 지정할 수 있음

  1. 컨테이너 배치
    • 클러스터 제약 조건(CPU, 메모리 및 포트 요구 사항)에 따라 컨테이너가 못들어 갈 수 있음
    • 커스텀 제약 조건(위치, 인스턴스 유형, AMI, 사용자 정의 속성 제약에 대한 필터링)에 따라서 다른 컨테이너로 배치될 수 있다
    • 배치 전략 → 8개의 서비스가 있고, EC2 인스턴스가 4개 있을때, 최소한 1개 이상의 컨테이너에는 배치되게끔 하라는 등의 충족하게끔 전략에 따라 배치될 수 있음
    • 필터 적용 → 배치 할 최종 컨테이너 인스턴스를 선택하는 것
  2. 컨테이너 배치 전략
    • Binpacking : 최대한 자원을 아껴쓰는 것 인스턴스가 2개 있더라도 첫번째 인스턴스에 꽉꽉채운 후에 두번째 인스턴스에 서비스를 배포하는 것
    • Spread : 최대한 많은 AZ으로 펼쳐서 배포하는 것 가용성 UP!
    • Affinity : 특정한 task는 특정한 인스턴스로 배포되었으면 하는 것. 특정 인스턴스 제약은 아님. 특정 tasks가 같은 인스턴스내에 배포되었을 때 이점을 볼 때
    • Distinct Instance : 인스턴스 별로 서로 떨어져서 운영되도록 하는 것

Amazon ECS Architecture

profile
Welcome to my velog! I love learning something new to build up my ability in development field. I don't think it is shame not to know, but it is shame to pretend to know about something you don't know.

0개의 댓글