AWS 컨테이너 ECS, Fargate, ECR과 EKS

컨테이너

Docker

• 앱 배포를 위한 소프트웨어 개발 플랫폼
• 컨테이너에 앱이 패키징되는데 컨테이너는 표준화되어있어 어느 OS에서나 같은 방식으로 실행 가능
  • 기기와 상관없이 실행 가능
  • 호환성 문제 없음
  • 행위 특성 예측 가능
  • 유지 배포 쉽다
  • 모든 언어 운영체제 기술과 호환
• 마이크로서비스 아키텍쳐, 온프레미스 환경에서 클라우드로 앱을 리프트앤시프트

 

Docker on an OS

• 서버(EC2 인스턴스 입장에서는 모두 도커 컨테이너로 보인다)

 

도커 이미지가 저장되는 곳

• 도커 리포지토리에 저장되며 여러가지가 있다
• Docker Hub
  • 퍼블릭 리포지토리
  • 기본 이미지를 찾을 수 있다
• Amazon ECR(Amazon Elastic Container Registry)
  • 비공개/공개 리포지토리 둘다 있다

 

Docker vs Virtual Machines

• 완전한 가상화 기술은 아니다
• 리소스가 호스트와 공유되어 한 서버에서 다수의 컨테이너를 공유 가능
• 가상머신 아키텍쳐는 Hypervisor를 통해 게스트 OS를 설치해서 앱을 올림
  • EC2가 이러한 가상 머신의 개념을 사용한다
    • 가상 머신의 EC2 인스턴스는 하나의 호스트에서 각자 분리됨
    • 리소스를 공유하지 않는다
  • VMWare를 통해 설치해보며 과정을 이해했다
• 도커는 호스트를 EC2같은 가상 머신에서도 사용 가능
  • 가볍게 실행되는 컨테이너라 공존 가능
  • 네트워킹이나 데이터도 공유가 가능
  • 덜 안전하지만 하나의 서버에 더 많은 컨테이너를 실행 가능

 

도커를 실행하는 방법

 

AWS에서 Docker 컨테이너를 관리하는 방법

Amazon Elastic Container Service (Amazon ECS)

• 도커 컨테이너 관리를 위한 전용 플랫폼

 

Amazon Elastic Kubernetes Service (Amazon EKS)

• 쿠버네티스의 관리형 버전으로 오픈소스

 

AWS Fargate

• 아마존 서버리스 컨테이너 플랫폼 ECS, EKS와 같이 동작 가능

 

Amazon ECR

• 컨테이너 이미지를 저장하는데 사용

 

 

Amazon ECS(Elastic Container Service)

ECS 클러스터에 ECS 태스크를 실행하는 것

EC2 런치타으로 ECS 클러스터를 실행하는 경우 프로비저닝과 인프라(EC2 인스턴스들)를 직접 관리해야한다

 

EC2 Launch Type

• EC2 인스턴스는 특별하게 각각 ECS 에이전트를 실행해야 한다
• 실행되면 ECS 에이전트가 각각의 인스턴스를 지정된 ECS 클러스터에 등록한다
• 이후 ECS 태스크를 수행하기 시작하면 AWS가 컨테이너를 시작하거나 멈춘다
• 새 컨테이너가 생기면 시간에 따라 EC2에 지정되고 자동적으로 실행됨

 

Fargate Launch Type

• AWS에 도커 컨테이너를 실행하는데 인프라를 프로비저닝하지않아 관리할 EC2가 없다 → 서버리스의 기능
• ECS 클러스터에 ECS 태스크를 정의하는 태스크 정의만 생성하면 ECS 태스크를 AWS가 알아서 실행한다
• 작업을 위해 백엔드에 EC2 인스턴스가 생성될 필요도 없다
• 확장을 위해선 단순히 태스크만 수정해주면 된다
• EC2 런치타입보다 훨신 간단하다

 

IAM Roles for ECS (두가지 차이점을 알아둬야 함)

IAM Task Role은 AWS 서비스의 API를 사용할 수 있도록 함

 

EC2 Instance Profile(EC2 런치타입 해당)

• ECS 에이전트만이 EC2 인스턴스 profile을 사용
• EC2 인스턴스 프로파일을 이용해 ECS로 API 호출
• CloudWatch Logs API를 통해 컨테이너 로그를 보냄
• ECR에서 도커 이미지를 가져옴
• Secrets Manager or SSM Parameter Store에서 민감 데이터를 참고

 

ECS Task Role (EC2 and Fargate Launch Type 모두 해당)

• 각각의 태스크에 서로 다른 특정 역할을 만들 수 있다
• 다른 역할을 만드는 이유는 각자 다른 ECS 서비스에 연결될 수 있도록 하기 위함
• ECS의 태스크 정의에서 태스크의 역할을 정의

 

로드밸런서와 통합

EC2와 Fargate 유형 마찬가지로 구성된다

여러 ECS 태스크들이 ECS 클러스터에 포함

• ALB는 대부분의 유스케이스에서 사용되는 좋은 옵션이다
• NLB은 처리량이 매우 많거나 높은 성능이 요구될 때만 권장된다
  • AWS Private Link와 연동시 권장
• ELB는 추천되지 않는다 Fargate와 연결 불가

 

데이터 지속성(EFS)

컨테이너가 유지되기 위해선 Data Volume이 필요하다

• EFS는 런치타입과 관계없이 EC2 and Fargate 둘다 호환됨
• EC2 태스크에 파일 시스템을 직접 마운트 가능
• Fargate + EFS = Serverless
• EFS + ECS를 사용하여 다중 AZ를 통해 공유되는 컨테이너의 영구 스토리지로 사용 가능
• S3는 EFS로 마운트 될 수 없다

 

실습

ECS 클러스터 타입을 Fargate와 EC2 런치타입을 동시에 생성할 수 있다.

이후 태스크를 정의할 때 EC2 인스턴스와 Fargate 형식을 통해 정의 가능

실습은 컨테이너를 실행시킬 때 Fargate 방식을 통해 간단하게 실행시킴

 

ECS Auto Scaling

• 태스크 수를 자동으로 늘리거나 줄일 수 있다
• ECS Auto Scaling은 AWS Application Auto Scaling을 사용함
  • CPU 사용률 - 메모리 사용률 - ALB 관련 지표인 타겟당 요청 수
• Target Tracking(대상 추적) → CloudWatch 지표의 특정 타겟에 따라 스케일링
• Step Scaling → CloudWatch 알람에 따라 단계적 수행
• Scheduled Scaling → 스케쥴된 스케일링

ECS Auto Scaling(태스크 레벨) ≠ EC2 Auto Scaling(인스턴스 레벨)

오토 스케일링이 필요없거나 백엔드에 EC2 인스턴스가 없다면 Fargate가 유용 * 서버리스

 

EC2 Launch Type – Auto Scaling EC2 Instances

• EC2 인스턴스를 스케일링하는 것이다
• 오토 스케일링 그룹
  • CPU 사용률 등에 따라 EC2 인스턴스 추가
• ECS Cluster Capacity Provider(ECS 클러스터 용량 공급자) ← 추천됨
  • 새 태스크를 실행할 용량이 부족하면 자동으로 ASG 확장
  • Capacity Provider는 오토 스케일링 그룹과 함께 사용
  • RAM CPU가 부족할 때 EC2 인스턴스 추가

 

ECS tasks invoked by Event Bridge

이벤트 브릿지로 작동하는 ECS 태스크

 

ECS tasks invoked by Event Bridge Schedule

 

 

Amazon ECR(Elastic Container Registry)

• AWS에 도커 이미지를 저장하고 관리하는데 사용
• 계정에 한해 이미지를 비공개로 저장 여러 계정 설정 가능
• Amazon ECR Public Gallery에 공개 설정 가능
• ECS와 완전히 통합되며 백그라운드에서 S3에 저장된다
• 이미지를 가져오기 위해서 EC2 인스턴스에 IAM Role 할당하면 된다
• ECR에 대한 모든 접근은 IAM이 보호하고 있다
• 단순히 이미지를 저장하는 역할을 넘어 많은 역할을 지원한다
  • 이미지의 취약점 스캐닝, 버저닝 태그 및 수명 주기 확인

 

Amazon EKS(Elastic Kubernetes Service)

• AWS에 관리형 쿠버네티스 클러스터를 실행할 수 있는 서비스
• 오픈 소스 시스템으로 Docker로 컨테이너화한 애플리케이션의 자동 배포, 확장, 관리를 지원
• ECS와 비슷하지만 사용하느 API가 매우 다르다
  • 오픈소스이며 여러 클라우드 제공자가 사용하므로 표준화가 가능
• EC2 시작 모드
  • EC2 인스턴스에서 처럼 작업자 노드를 배포할 때 사용
• Fargate 모드
  • EKS 클러스터에 서버리스 컨테이너를 배포할 때 사용
• EKS UseCase
  • 온프레미스나 클라우드에서 쿠버네티스나 쿠버네티스 API를 사용 중일때 쿠버네티스 클러스터를 관리하기 위해 EKS를 사용
• 모든 클라우드 서비스에서 사용 가능하며 클라우드 또는 컨테이너간 마이크레이션을 실행하려는 경우 EKS가 솔루션이 될 수 있다

 

• 각 노드가 만들어지고 노드는 EKS Pods를 실행한다 - Pods를 발견하면 쿠버네티스 관련
• EKS 노드는 오토스케일링 크룹으로 관리 가능
  • 프라이빗 로드 밸런서 혹은 퍼블릭 로드 밸런서를 설정해 웹에 연결해야 한다

 

Amazon EKS – Node Type

Managed Node Groups(관리형 노드 그룹)

• AWS로 노드, EC2를 생성하고 관리
• 노드는 EKS 서비스로 관리되는 ASG의 일부
• 온디맨드 인스턴스와 스팟 인스턴스를 지원

 

Self-Managed Nodes

• 커스텀한 생성 가능 EKS 클러스터를 등록하고 ASG로 관리해야함
• Amazon EKS 최적화 AMI를 사용할 수 있으며 시간 절약을 가능
• 온디맨드와 스팟 인스턴스 지원

 

AWS Fargate

• 유지관리와 노드 관리가 없다

 

데이터볼륨

• 볼륨을 사용하려면 EKS 클러스터에 스토리지 매니페스트를 지정해야함
• 컨테이너 스토리지 인터페이스(CSI)라는 규격 드라이버 활용
• EBS와 Fargate모드만 EFS를 지원
• FSx Lustre, NetAPP ONTAP 지원

 

실습

프리티어에 적용되지 않아 상당한 비용 청구 주의

 

AWS App Runner

• 완전 관리형 서비스로 규모에 따라 웹 애플리케이션, API 배포를 돕는다
• 누구나 AWS에 배포를 할 수 있다 → 인프라, 컨테이너, 소스 코드 개념을 몰라도 됨
• 소스코드나 Docker 컨테이너 이미지를 가지고 환경 설정만 하면 된다
• 자동으로 배포되어 컨테이너가 실행된다 이후 URL을 통해 엑세스 가능
• 오토스케일링과 가용성, 로드밸런싱, 암호화
• VPC 엑세스도 지원하며 db, 캐시, 메시지 큐 서비스도 연결 가능
• 웹, micro service, 빠른 배포가 필요한 서비스

 

실습

vercel처럼 배포가 가능하고 여기에 AWS 서비스까지 연결할 수 있다