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

2023년 6월 3일

컨테이너

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 서비스까지 연결할 수 있다