Section 16. ECS, ECR 및 Fargate - AWS의 도커

Docker란?

도커는 앱 배포를 위한 소프트웨어 개발 플랫폼이다.
컨테이너에 앱이 패키징되는데 컨테이너는 표준화되어있어서 아무 운영체제에나 실행할 수 있다!!
행위 특성도 예측이 가능해서 작업을 덜어주고, 유지 및 배포가 쉬우며, 언어, 운영체제, 기술에 상관 없이 실행이 가능하다는 장점이 있다.

Docker images stored

도커 에이전트를 실행하면 도커 컨테이너를 실행할 수 있다.

• 도커 이미지는 도커 리포지토리에 저장된다.
• 여러 리포지토리들을 알아보자
  1. Docker Hub
     • 퍼블릭 리포지토리로 많은 기술에 맞는 기본 이미지를 찾을 수 있다.
  2. Amazon ECR
     • 프라이빗 리포지토리
     • 퍼블릭 리포지토리로는 'Amazon ECR Public Gallery'가 있다.

Docker vs. Virtual Machines

도커도 가상화 기술이긴 하지만 순수한 가상화 기술은 아니다.

리소스가 호스트와 공유되어 하나의 서버에서 많은 컨테이너를 공유할 수 있다.

 

가상 머신과 도커의 아키텍쳐는 아래와 같다.

• 가상 머신의 EC2 인스턴스는 각자 분리되어 있는 구조이며 리소스를 공유하지 않는다.
• 도커 컨테이너의 경우에는 인프라와 EC2 인스턴스 같은 호스트 OS가 있고 도커 데몬 위에 많은 컨테이너가 있다.
  • 도커 데몬으로 컨테이너는 네트워킹이나 데이터 등을 공유할 수도 있다!

가상 머신(좌)과 도커 컨테이너(우)

 

Docker 시작하기

도커를 시작하기 위해서는 도커파일을 작성해야 한다.

• 베이스 도커 이미지에 몇 가지 파일을 추가해서 구축하면 도커 이미지가 된다.
• 도커 이미지는 푸쉬하여 도커 리포지토리에 저장할 수가 있다.
• 도커 허브에 푸쉬하거나 Amazon ECR에 넣을 수 있다.

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

1. Amazon ECS(Amazon Elastic Container Service)
   • 도커 관리를 위한 전용 플랫폼이다.
2. Amazon EKS(Amazon Elastic Kubernetes Service)
   • 쿠버네티스의 관리형 버전으로 오픈 소스 프로젝트이다.
3. AWS Fargate
   • 아마존의 서버리스 컨테이너 플랫폼으로 ECS와 EKS 둘 다 함께 작동할 수 있다.
4. AWS ECR(Elastic Container Resitry)
   • 컨테이너 이미지를 저장하는 데 사용된다.

---

Amazon ECS

ECS 시작 유형에는 여러 가지가 있다. 다양한 유형을 알아보자!

1. EC2 Launch Type

AWS에서 도커 문서를 실행하면 ECS 클러스터에서 ECS 태스크를 실행하는 것이다.

• ECS 클러스터는 여러 요소로 이루어지는데 EC2 시작 유형을 사용할 때는 EC2 인스턴스가 그 요소에 해당한다.
• EC2 시작 유형으로 ECS 클러스터를 사용하는 경우 인프라를 직접 프로비저닝 및 관리해야 한다!
• 아래와 같이 인스턴스를 준비하고 ECS 태스크를 시작하면 AWS에서 컨테이너 시작과 중지를 처리한다.
  • 즉 새로운 도커 컨테이너가 추가되면 시간에 따라 각각의 인스턴스에 배포된다.

2. Fargate Launch Type

• AWS에 도커 컨테이너를 실행하는 것은 동일하지만 인프라를 프로비저닝하지 않는다!
  • 따라서 관리할 EC2 인스턴스가 없다.
  • 모두 서버리스라는 것이다.
• Fargate 유형에서 ECS 클러스터를 사용하는 경우 ECS 태스크만 정의하고 나면 AWS에서 CPU와 RAM 요구사항을 토대로 ECS 태스크를 실행한다.
• EC2 인스턴스를 관리할 필요가 없고, 확장을 원한다면 태스크 수만 간단히 늘리면 된다!

---

IAM Roles for ECS

ECS에 대한 IAM 역할을 알아보자!

예시는 EC2 시작 유형으로 진행해 보이겠다.

• EC2 인스턴스가 도커의 ECS 에이전트를 실행 중이다.
  • 이 경우 EC2 인스턴스 프로필을 생성할 수 있는데 이는 EC2 시작 유형을 사용할 때만 적용되고 ECS 에이전트에서만 사용된다.
  • ECS 에이전트는 EC2 인스턴스 프로필을 사용해 ECS 서비스에 인스턴스를 복원하는 API 호출을 보내고 CloudWatch에 컨테이너 로그를 전송하는  API 호출을 보내고 ECR에서 도커 이미지를 가져오는 API 호출을 보내고 시크릿 매니저나 SSM Parameter Store에서 민감한 데이터를 참조한다.
  • ECS 태스크는 ECS 태스크 역할 역할을 사용한다. 이것은 EC2와 Fargate 시작 유형 모두에 적용이 된다!
  • 아래 예시에는 두 가지 태스크가 있는데 태스크별로 구체적인 역할을 생성할 수 있다.
    • 첫 번째는 EC2 태스크 A 역할이고 두 번째는 태스크 B 역할을 한다.
  • 각 역할을 서로 다른 서비스에 연결할 수 있다.

Load Balancer Integrations

1. ALB를 클러스터 앞에서 실행하면 사용자들은 ALB와 함께 백엔드의 ECS 태스크에 직접 연결하게 된다.
2. NLB는 높은 처리량이나 성능이 요구되는 활용 사례나 AWS PrivateLink를 사용하는 경우에만 권장된다.
3. ELB는 사용할 수는 있지만 고급 기능이 없고 Fargate에 ELB를 연결할 수 없기에 권장되지 않는다.

Data Volumes(EFS)

ECS 태스크에 파일 시스템을 마운트한다고 하자. 이때 EFS 파일 시스템을 사용한다!

네트워크 파일 시스템이어서 EC2와 Fargate 시작 유형 모두와 호환된고 ECS 태스크에 파일 시스템을 바로 마운트할 수 있다.

 그 이유는 EFS 파일 시스템에 연결되어 있으면 어떠한 AZ에서 실행 중인 태스크는 데이터를 공유하고 파일 시스템을 통해 서로 통신할 수 있기 때문이다!

• 최상의 조합으로는 Fargate를 이용해 서버리스 방식으로 ECS 태스크를 실행하고 EFS를 파일 시스템 지속성에 이용하는 방법이다.
• EFS도 서버리스 방식이어서 서버를 관리할 필요가 없고, 사용량을 기반으로 요금이 청구되고 사전에 프로비저닝하면 사용이 가능하다!

EFS와 ECS를 함께 사용하는 사례로는 영구 다중 AZ 공유 스토리지를 사용하는 방식이 있다.

 

※ 유의사항!

Amazon S3를 ECS 태스크에 파일 시스템으로 마운트할 수 없다는 점을 기억하자!

---

ECS Service

Auto Scaling

태스크의 수는 수동으로 늘릴 수도 있지만 자동으로 늘리거나 줄일 수도 있다!
이는 Auto Scaling이라는 서비스를 사용하면 간단히 구현할 수 있다.
다음 세 가지 방법으로 확장이 가능하다.
1. ECS 서비스의 CPU 사용률 확장
2. 메모리 사용률, ECS 서비스의 RAM을 사용
3. ALB의 타켓당 요청 수를 확장

• Auto Scaling의 방법들
  1. Target Tracking | 특정 타켓을 추적
  2. Step Scaling | CloudWatch 알람을 통해 스케일링
  3. Scheduled Scaling | 미리 ECS 서비스 확장을 설정하는 예약 스케일링
• 확실히 알고 넘어가야 할 점은 ECS Service Auto Scaling과 EC2 Auto Scaling은 다르다는 것이다!!
  • EC2 Auto Scaling이 필요하지 않다면 Fargate를 사용하는 것이 더 유용하다!

EC2 Launch Type - Auto Scaling EC2 Instances

EC2 시작 유형에서의  Auto Scaling 방법

1. Auto Scaling Group Scaling
   1. CPU 사용률에 따라 ASG를 확장한다고 가정하였을 때, CPU 사용률이 급등할 때 EC2 인스턴스를 확장한다.
2. ECS Cluster Capacity Provider(권장!)
   1. ECS 태스크를 실행할 용량이 부족하면 자동으로 ASG를 사용한다.
   2. Capacity Provider는 ASG와 함께 사용된다. 그리고 RAM이나 CPU가 모자랄 때 EC2 인스턴스를 추가한다.

ECS Rolling Updates

ECS 서비스를 V1에서 V2로 업데이트할 때는 한 번에 얼마나 많은 태스크가 어떤 순서로 시작되고 중단될지 제어할 수 있다.

Minimum Healthy Percent | 최소 태스크가 유지되어야 하는 퍼센티지

Maximum Percent | 태스크가 추가되어도 유지 가능한 퍼센티지

  ex. v1이 4개이고 Maximum Percent가 150이라면 2개의 v2가 추가로 들어올 수 있음!

 

ECS Solution Architecture

ECS에서 만날 수 있는 몇 가지 솔루션 아키텍쳐를 알아보자!

1. ECS tasks invoked by Event Bridge

2. ECS tasks invoked by Event Bridge Schedule

3. SQS Queue Example

4. Intercept Stopped Tasks using EventBridge

ECS - Task Definitions

Json 형식으로 정의가 되며 콘솔에 있는 UI를 통해 JSON을 생성할 수 있으며, 태스크 정의는 ECS 서비스에서 한 개 이상의 도커 컨테이너를 실행하는 방법을 알려준다.

태스크 정의에 들어가는 내용
1. 이미지 이름
2. 컨테이너와 호스트에 바인딩된 포트
3. 요구되는 메모리와 CPU
4. 환경 변수
5. 네트워킹 정보
6. IAM durgkf
7. 로깅 구성(CloudWatch)

태스크 정의 당 최대 10 개의 컨테이너를 정의할 수 있다.

 

Load Balancing(EC2 Launch Type)

• 로드 밸런서를 사용할 때, 만약 태스트 정의 내에 컨테이너 포트만을 정의한다면, 동적 호스트 포트 매핑을 얻는다.
• ALB가 ECS 서비스에 연결되어 있을 때에는 동적 호스트 매핑 기능 덕분에 올바른 포트로 연결할 수 있다.
  • ECS 서비스 덕분에 ALB는 두 개의 다른 인스턴스 상에 있는 두 개의 다른 포트에 자동으로 연결이 될 수 있다.
• 보안 관점에서는 호스트 포트 매핑이 어떻게 될지 모르기 때문에 EC2 인스턴스 보안 그룹이 ALB 보안 그룹으로부터의 모든 포트를 포트를 허용해야 한다.

Load Balancing(Fargate)

• Fargate 형식은 각 ECS 태스크가 고유 프라이빗 IP를 갖는다.
• Fargate에게는 호스트가 없기 때문에 컨테이너 포트만을 정의하면 된다!
• 아래의 그림에서는 ECS ENI 보안 그룹은 ALB로부터 포트 80만 허용하면 되고,
  ALB 보안 그룹은 웹으로부터 포트 80과 443을 허용하면 된다.

Amazon ECS One IAM Role per Task Definition

• 태스크 정의가 있는 경우에는 여기에 ECS 태스크 역할을 할당한다.
  • 그러면 태스크 정의를 통해 ECS 태스크가 S3 서비스로 액세스할 수 있게 된다.
• 시험에서는 ECS 태스크에 대한 IAM 역할을 어디서 지정하냐 물어보는데 답은 '태스크 정의 상'이라고 말하면 된다!

Amazon ECS - Environment Variables

• 환경 변수 방식
  • 하드코딩 | 예를 들어 태스크 정의 내에 직접 설정하여 고정된  퍼블릭 URL을 가질 수 있다.
  • SSM Parameter Store | 예민한 변수들을 저장하고 ECS 태스크를 시작할 때 정의 내부에서 이들을 참조할 수 있다.
• 환경 파일(bulk) - S3
  • ECS 환경 변수를 S3 버킷으로부터 직접 로드하는 방법.

Amazon ECS - Data Volumes

• 같은 태스크 정의 내에서 다수의 컨테이너들 사이 데이터를 공유할 수 있다!
• 로깅이나 지표에 유용하다.
• 데이터 볼륨을 두 컨테이너 모두에 마운팅하여 데이터를 공유하도록 한다.
• 바인드 마운트를 EC2와 Fargate 태스크 모두 가능하다!
  • EC2 Tasks | EC2 인스턴스 스토리지를 사용한다.
  • Fargate Tasks | 임시 스토리지를 사용하여 데이터는 컨테이너의 수명에 연결이 된다.
    • 이는 Fargate 태스크가 사라질 때마다 컨테이너도 같이 사라지는 구조이다.
    • 20 ~ 200 Gib까지의 공유 스토리지가 제공된다.

ECS - Tasks Placement

EC2 유형의 태스크를 생성하게 되면, ECS는 대상 EC2 인스턴스의 사용가능한 메모리와 CPU, 포트를 확인할 수 있어야 한다.
유사하게도, 서비스를 스케일 인 할 때, ECS는 어떤 태스크를 삭제할지 결정할 필요가 있다.
이 결정을 돕기 위해, 사용자는 태스크 배치 전략과 태스크 배치 제한을 정의할 수 있다!

이는 EC2 인스턴스 상에 시작된 ECS가 있을 때에만 유효하고 Fargate를 사용할 시에는 해당되지 않는다.

 

1. ECS Task Placement Process

• 태스크 배치시, 전략을 구성하는 것은 가장 최선의 선택이다.
• ECS가 태스크를 배치할 때 다음의 과정을 거쳐 배치를 하게 된다.
  1. 태스크 정의 내의 CPU, 메모리, 포트 조건을 만족하는 인스턴스를 식별한다.
  2. 태스크 배치 제한을 확인한다.
  3. 태스크 배치 전략에 가장 적합한 인스턴스를 식별하기 위해 시도한다.
  4. 태스크 배치를 위한 인스턴스를 선택해 그 인스턴스에 태스크를 배치한다.

2. ECS Task Placement Strategies

• Binpack
  • 가장 많이 채워져 있는 CPU나 메모리에 태스크를 배치하려 시도한다.
  • 사용되는 인스턴스의 수를 최소화하는 역할을 한다.
  • 사용중인 EC2 인스턴스의 수를 최소화하고, EC2 인스턴스의 활용도를 최대로 끌어올리기 때문에 가장 큰 비용 절감 효과를 누릴 수 있다!

• Random
  • 말 그대로 태스크를 무작위로 배치한다.
  • 논리가 없는 잘 작동하는 전략이다.
• Spread
  • 분산 전략을 사용하면, 태스크가 특정 값을 기반으로 하여 분산되어 배치된다.
  • 특정 값은 instanceld일 수도 있고, ecs:availability-zone일 수도 있다.

"placementStrategy": [
	{
    	// binpack
    	"field": "memory",
        "type": "binpack"
        
        // random
        "type": "random"
        
        // spread
        "field": "attribute:ecs.avilability-zone",
        "type": "spread"
]

이 전략들은 적절히 섞어서 사용할 수도 있다.

각 전략의 차이점에 대해 잘 알아놓을 것!

 

3. ECS Task Placement Constraints

1. distinctInstance | 다른 컨테이너 인스턴스에 각 태스크를 배치한다.
   • 동일 인스턴스 상에 두 개의 태스크를 배치할 수가 없는 것이다.
2. memberOf | 표현을 만족시키는 인스턴스의 태스크를 배치한다.
   • 클러스터 쿼리 언어를 사용하여 정의된 표현식을 만족하는 인스턴스 상에만 배치한다.

"placementConstraints": [
	{
    	// distinctInstance
    	"type": "distinctInstance"
        
        // memberOf
        "expression": "attributes:ecs.instance-type =~ t2.*",
        "type": "memberOf"
]

---

AWS ECR

ECR은 Elastic Container Registry의 줄임말로 도커 이미지를 저장하고 관리하는데 사용된다.
ECR에는 두 가지 옵션이 있다.
1. 계정에 한해 이미지를 비공개로 저장하는 방법으로 여러 계정으로 설정할 수 있다.
2. Amazon ECR Public Gallery에 게시하는 방법이 있다.

ECR은 단순히 저장하는 리포지토리가 아닌 이미지 취약점 스캐닝, 버저닝 태그 및 수명 주기 확인 등을 지원한다.

Amazon ECR - Using AWS CLI

이미지를 풀 및 푸시하는 방법

1. Login Command
2. Docker Commands

//push
docker push aws_account_id.dkr.ecr.region.amazonaws.com/demo:latest

//pull
docker pull aws_account_id.dkr.ecr.region.amazonaws.com/demo:latest

---

AWS Copilot

Copilot은 서비스가 아니다!
컨테이너화된 production-ready 애플리케이션을 빌드 및 릴리즈하고 동작시키는데 사용되는 CLI 도구이다.
AppRunner, ECS와 Fargate에서 앱을 실행할 때의 어려움을 없애기 위해 이 환경을 배포한다.

특징
명령어 하나만으로도 컨테이너를 자동으로 배포할 수 있다.
어플리케이션의 문제 해결, 로그, 건강상태를 확인할 수 있다.

---

Amazon EKS

EKS는 AWS에서 컨테이너를 실행하는 다른 방법이다.

EKS는 Elastic Kubernetes Service의 약자로 관리형 Kubernetes 클러스터를 AWS에서 시작하기 위한 수단이다.
쿠버네티스란 컨테이너화된 애플리케이션의 자동 배포, 스케일링 및 관리를 위한 오픈 소스 시스템이다.

ECS를 대체할 수 있는 시스템으로 컨테이너를 실행하는 목적은 비슷하지만 다른 API를 제공한다.

• EKS는 2개의 시작 모드를 지원한다.
  1. 워커 노드를 배포하고 싶다면 EC2 인스턴스를 선택할 수 있다.
  2. EKS 클러스터에 서버리스 컨테이너를 배포하고 싶다면 Fargate 모드를 선택할 수 있다.
• 사용 사례로는 회사가 이미 쿠버네티스를 사용하고 있거나 단지 쿠버네티스 API를 이용하고 싶은 경우, AWS를 이용해 쿠버네티스 클러스터를 관리하고 싶은 경우가 있다.
• 쿠버네티스는 클라우드 에그노스틱이다.(어느 클라우드에서도 사용이 가능!)

1. Node Types

1. Managed Node Groups
   • 사용자를 위한 노드(EC2 인스턴스)를 만들고 관리한다.
   • 노드들은 EKS에 의해 관리되는 오토 스케일링 그룹의 일부이다.
   • 온디맨드 및 스팟 인스턴스를 지원한다.
2. Self-Managed Nodes
   • 노드를 직접 생성한 다음 EKS 클러스터에 등록하고, ASG에 의해 관리된다.
   • 최적화된 AMI를 사용할 수 있어서 시간을 절약할 수 있다.
   • 온디맨드 및 스팟 인스턴스를 지원한다.
3. AWS Fargate
   • 아무런 노드도 관리하지 않기에 관리가 필요없다.
   • 단지 EKS에서 컨테이너를 실행하기만 하면 된다!

2. Data Volumes

• 우선 EKS 클러스터에 StorageClass 매니페스트를 지정해야 한다.
  • 이때 CSI 호환 드라이버라는 것을 활용한다.
• EKS가 지원하는 EBS, EFS(Fargate와 함께 작동하는 유일 스토리지 클래스), FSx for Lustre, FSx for NetApp ONTAP이 있다는 것을 알아둘 것!