woongs dogfoot

Docker Containers Management on AWS

• Amazon Elastic Container Service (Amazon ECS) : Amazon의 container 플랫폼
• Amazon Elastic Kubernetes Service (Amazon EKS) : Amazon에서 관리되는 Kubernetes
• Amazon Fargate : Amazon의 서버리스 Container 플랫폼, ECS/EKS와 함께 동작 가능
• Amazon ECR : Container Image 저장
  
  
  

Amazon ECS

• AWS에서 docker container 실행 = ECS Cluster에서 ECS task 실행 (task = container, 생성된 task로 서비스를 배포하는 작업이 추가로 진행되어야 함 -> cluster에서 server 생성 후 맞는 type을 선택하고 Family로 사전 생성한 task를 선택하면 됨 -> 사전에 서비스 배포가 되었기 때문에 해당 task의 갯수가 늘어나면, container의 갯수도 늘어나게됨)
  
  
  

• ECS Cluster의 Launch Type (task 생성 시, 선택)

1. EC2 인스턴스
   • infra를 직접 provisioning하고 유지해야함
   • EC2 인스턴스는 각각 ECS Agent를 실행해야 함 -> ECS 클러스터 등록
   • ECS task가 실행되면 AWS가 container를 실행하거나 중단시킴 -> 새로운 Docker Container가 생성되면 임의로 ECS Cluster에 등록된 EC2 인스턴스를 선택하여 배포함

2. Fargate
   • AWS에서 docker container를 실행하는데, infra를 provisioning 하지않아서 관리할 EC2인스턴스는 없음 -> 서버리스 (서버를 관리하지 않아서)
   • ECS task 정의만 생성하면 필요한 CPU/RAM에 맞게 ECS task를 AWS가 대신 실행 (관리자는 어느 서버에서 실행되는지 모름)
   • 확장이 필요하면 ECS task만 더 생성하면 됨

• IAM Roles

1. EC2 인스턴스 profile
   • EC2 type에만 활용됨
   • ECS Agent만 EC2 인스턴스의 profile을 관리하고, 이를 활용하여 ECS API 호출 -> ECS 서비스가 CloudWatch log에 API 호출하여 Container log를 보냄 -> ECR로부터 docker image 수신
   • Secret Manager나 SSM Parameter Store에서 민감 데이터를 참고하기도 함
2. ECS Task Role
   • ECS task는 Task Role을 가짐
   • EC2 및 Fargate type에 모두 활용됨
   • 만약 두 개의 task가 있다면, 각각에 특정 Role을 만들 수 있음
   • ECS task role은 각자 다른 ECS 서비스를 이용할 수 있음 (ex. task A는 S3 API 호출, task B는 DynamoDB에 API 호출)
   • task를 정의하여 생성할 때, Role을 정의할 수 있음

• Load Balancer Integrations

1. EC2 및 Fargate type 모두 가능
2. ECS 클러스터 내부에 많은 ECS task가 실행됨
3. 많은 ECS task는 HTTP/HTTPS endpoint로 활용되길 원함 -> ALB 활용 -> 사용자는 ALB를 경유하여 ECS task에 연결될 수 있음
4. ALB대신 NLB가 사용될 수도 있는데, 해당 경우는 처리량이 많거나 높은 성능이 요구될 때 권장 (AWS Private Link와 사용할 때 권장)

• Data Volumes (EFS)

1. EC2 task에 File System을 마운트하여 데이터 공유 원함 -> EFS 활용
2. EFS는 EC2 및 Fargate 모두에 호환됨
3. EFS를 마운트한다면, 가용영역이 달라도 데이터를 공유할 수 있음 (EFS의 특징)
4. EFS를 활용하여 다른 task와도 연결 가능
5. EFS내부의 Fargate를 쓸 때 좋음 (EFS도 서버리스이기 때문)
6. Use case : Multi-AZ에 걸쳐 배포된 Container의 영구적인 Storage
7. Amazon S3는 ECS에 의해 마운트될 수 없음

ECS Auto Scaling

• ECS Auto Scaling : ECS task의 수를 자동으로 늘려주고 줄여줌
  
  
  

• Scaled Metrics

1. ECS의 CPU 사용률
2. ECS의 RAM 사용률
3. ALB의 target당 요청 수
   
   
   

• Scaling Types

1. Target Tracking : CloudWatch의 특정 값 기준
2. Step Scaling : CloudWatch의 특정 알람 기반
3. Scheduled Scaling : 트래픽의 변화가 예측되는 정해진 시간 기준
   
   
   

• ECS Auto Scaling (task level) != EC2 Auto Scaling (EC2 Instance level) -> EC2 Auto Scaling 기능이 없다면, Fargate로 전환 후 ECS Auto Scaling을 쓰는 것이 좋음 -> 서버리스
  
  
  

• EC2 Instance Auto Scaling 방법 (launch type이 EC2일 때)

1. EC2 Auto Scaling Group
2. ECS Cluster Capacity Provider : 새 task를 실행할 용량이 부족하면, 자동으로 ASG 확장 (with ASG, ECS Cluster CPU/RAM사용량 기반)
   
   
   

• Example : ECS Cluster Capacity Provider를 활용하는 Service의 트래픽이 증가할 경우, CloudWatch가 CPU사용량 증가를 인식하고 Alarm을 발생시킴 -> CloudWatch Alarm은 scale out 요청을 하게되고, Capacity Provider는 희망용량을 증가시켜 task가 자동으로 증가됨 -> task가 증가됨에 따라 EC2인스턴스가 증가됨

• Event Bridge에 의한 ECS
  : EventBridge는 수신된 Event를 전달하는 역할 -> Event를 받으면 ECS task를 실행시키기 위한 rule이 설정되어 있을 경우, ECS task 실행에 대한 요청을 ECS Cluster에 보냄 -> ECS task Role에 따라 처리

• Event Bridge Schedule에 의한 ECS
  : 1시간마다 스케줄링되는 EventBridge에 의해 특정 ECS Task가 실행됨 -> 생성되는 task Role에 맞는 작업 진행 -> 서버리스

• SQS Queue에 의한 ECS
  : 서비스가 SQS Queue로부터 메세지를 직접 가져와 처리

• Intercept StoppedTasks using EventBridge
  : EventBridge를 통한 ECS Cluster내에서 Event를 가로채는 방식 -> ECS Cluster내에서 task에 관한 Event가 발생될 경우, EventBridge에 트리거됨 (json형태의 데이터 전송) -> 해당 트리거를 이용하여 SNS topic에 메세지를 전송하고, 관리자에게 메일을 전송하는 등의 case에 활용될 수 있음

Amazon ECR

• Amazon ECR : Elastic Container Registry, AWS에 Docker image를 저장하고 관리하는데 사용
  
  
  

• 계정에 한해 image를 비공개로 저장 -> 여러 계정으로 권한 확대할 수 있음

• public으로 image를 저장할 수도 있음

• image는 background에서 S3에 저장됨

• ECS Cluster내 EC2 IAM Role을 통해 ECR로부터 Docker image를 가져올 수 있음 (ECR에 대한 모든 접근은 IAM이 보호)

• image의 단순 저장뿐만 아니라 image 취약점 스캐닝, versioning, tag 및 life cycle 확인 지원

Amazon EKS

• Amazon EKS : Elastic Kubernetes Service, AWS에서 kubernetes를 실행할 수 있는 service
  
  
  

• Amazon ECS와 비슷하지만, 사용하는 API가 다름

• EKS Launch Modes

1. EC2 Instance : EC2에 Worker Node 배포
2. Fargate : EKS Cluster에 서버리스 Container 배포
   
   
   

• 특징

1. kuberentes는 모든 Cloud에서 지원 (Azure, Google Cloud 등) -> 클라우드간 마이그레이션에 유용
2. Use Case : 회사가 온프레미스나 클라우드에서 Kubernetes or Kuberentes API를 사용중일 때, 해당 Kubernetes를 관리하기 위해 Amazon EKS를 활용

• Node Types

1. Managed Node Groups : AWS로 노드(EC2 Instance)를 생성하고 관리
   • 노드는 EKS로 관리되는 ASG의 일부
   • 온디맨드 인스턴스와 Spot 인스턴스를 지원
2. Self-Managed Nodes : 노드를 직접 생성하고 EKS Cluster에 등록하여 Cluster내 ASG에 의해 관리
   • 사용자 지정사항 or 제어대상이 많은 경우 사용
   • 최적화된 Amazon EKS AMI를 사용하면 부팅시간을 줄일 수 있음
   • 온디맨드 인스턴스와 Spot 인스턴스를 지원
3. Fargate
   • 노드를 원하지 않는 경우 사용
   • 유지관리 필요 없음
     
     
     

• Data Volumes

1. EKS Cluster에 Storage Class manifest를 지정해야 함
2. CSI (Container Storage Interface)라는 규격의 드라이버 사용 -> Cluster 설정의 Add-ons에서 해당 드라이버 설정 필요
3. Amazon EBS, Fargate모드를 지원하는 유일한 유형인 Amazon EKS, Amazon FSx for Lustre, Amazon FSx NetAPP ONTAP 지원
   
   
   

AWS App Runner

• AWS App Runner : 인프라나 소스코드를 알 필요 없이 누구나 AWS에 배포할 수 있음

• 완전 관리형 서비스로 서비스 규모에 따라 Web Application, API 배포를 지원
  
  
  

• 배포 방법

1. Docker image or Source code를 가지고 원하는 구성 설정 -> CPU/RAM 설정, ASG여부 등
2. 설정을 기반으로 Container에 자동 배포
3. URL이 생성되면 해당 URL로 접근 가능

• 장점

1. Auto Scaling 가능
2. 고가용성
3. Load Balancing
4. 암호화 기능 지원
5. custom VPC 배포 지원
6. DB, 캐시, 메세징 서비스 등에 연결 가능
   
   
   

• Use case : 웹앱 application의 신속한 배포가 필요한 경우