AWS의 컨테이너

ECS (Elastic Container Service)

EC2 시작 유형

• AWS에서 컨테이너를 실행하면 ECS 클러스터에 이른바 ECS 태스크를 실행하는 것이다.
• ECS 클러스터에는 들어있는 게 있는데 EC2 시작 유형을 사용하면 EC2 인스턴스가 들어있겠죠
• EC2 시작 유형으로 EC2 클러스터를 사용할 때는 인프라를 직접 프로비저닝하고 유지해야 한다.
• 즉 Amazon ECS 및 ECS 클러스터가 여러 EC2 인스턴스로 구성된다.
• 이때 ECS 인스턴스는 특별하게 각각 ECS 에이전트(Agent)를 실행해야 한다.
• 그럼 ECS 에이전트가 각각의 EC2 인스턴스를 Amazon ECS 서비스와 지정된 ECS 클러스터에 등록한다.
• 이후에 ECS 태스크를 수행하기 시작하면 AWS가 컨테이너를 시작하거나 멈춘다.
• 즉 새 컨테이너가 생기면 미리 프로비저닝한 EC2 인스턴스에 지정된다.
• ECS 태스크를 시작하거나 멈추면 자동으로 위치가 지정도니다.

Fargate 시작 유형

• Fargate 유형은 AWS에 컨테이너를 실행하는데 인프라를 프로비저닝하지 않아 관리할 EC2 인스턴스가 없다.
• 서버를 관리하지 않아 서버리스라 부르는데 서버가 없는 건 아니다.
• Fargate 유형은 ECS 클러스터가 있을 때 ECS 태스크를 정의하는 태스크 정의만 생성하면 필요한 CPU나 RAM에 따라 ECS 태스크를 AWS가 대신 실행한다.
• 즉 새 도커 컨테이너를 실행하면 어디서 실행되는지 알리지 않고 그냥 실행된다.
• 작업을 위해 EC2 인스턴스가 생성, 관리할 필요도 없고, 확장하려면 간단하게 태스크 수만 늘리면 된다.
• 시험에서는 서버리스인 Fargate를 사용하라는 게 자주 나온다.

IAM Roles for ECS

EC2 Instance Profile 

• EC2 시작 유형에서만 사용 가능하다. 먼저 EC2 인스턴스가 도커에 ECS 에이전트를 실행한다.
• EC2 시작 유형을 사용한다면 EC2 인스턴스 프로필을 생성한다.
• ECS 에이전트만이 EC2 인스턴스 프로필을 사용하며 그 EC2 인스턴스 프로필을 이용해 API 호출 한다.
• 그럼 인스턴스가 저장된 ECS 서비스가 CloudWatch 로그에 API 호출을 해서 컨테이너 로그를 보내고 ECR로부터 도커 이미지를 가져온다.
• Secrets Manager나 SSM Parameter Store에서 민감한 데이터를 참고하기도 한다.

EC2 Task Role

• ECS 태스크는 ECS 태스크 역할을 가진다.
• EC2와 Fargate 시작 유형에 모두 해당되며 두 개의 태스크가 있다면 각자에 특정 역할을 만들 수 있다.
• 역할을 다르게 하는 이유는 무엇일까? 역할이 각자 다른 ECS 서비스에 연결할 수 있기 위함이다.
• ECS 서비스의 태스크 정의에서 태스크의 역할을 정의한다.

이러한 EC2 인스턴스 프로파일 역할과 ECS 태스크 역할의 차이점을 기억하자.

로드 밸런서와 통합

• HTTP나 HTTPS 엔드 포인트로 태스크를 활용하기 위해 애플리케이션 로드 밸런서(ALB)를 앞에서 실행하면 모든 사용자가 ALB 및 백엔드의 ECS 태스크에 직접 연결된다.
• NLB는 처리량이 매우 많거나 높은 성능이 요구될 때만 권장한다. AWS Private Link와 사용할 때도 권장되는 옵션이다.
• ALB는 Fargate와도 사용 가능. CLB는 불가능.

Data Volumes

• EFS가 자주 사용된다.
• 네트워크 파일 시스템이라 EC2와 Fargate 시작 유형 모두 호환이 되며 EC2 태스크에 파일 시스템을 직접 마운트할 수 있다.
• 어느 AZ에 실행되는 태스크든 Amazon EFS에 연결되어 있다면 데이터를 공유할 수 있고 원한다면 파일 시스템을 통해 다른 태스크와 연결할 수 있다.
• Fargate로 서버리스 방식으로 ECS 태스크를 실행하고 파일 시스템 지속성을 위해서는 Amazon EFS를 사용하는 방식이 좋다.
• EFS 역시 서버리스이기 때문에 서버를 관리할 필요 없고 미리 비용을 지불한다. 미리 프로비저닝하기만 하면 바로 사용할 수 있다.
• 사용 사례로는 EFS와 ECS를 함께 사용해서 다중 AZ가 공유하는 컨테이너의 영구 스토리지가 있다.
• Amazon S3는 ECS 태스크에 파일 시스템으로 마운트될 수 없다.

ECR (Elastic Container Registry)

• AWS에 도커 이미지를 저장하고 관리하는 데 사용되며, ECR에는 두 가지 옵션이 있다.
• 첫 번째는 계정에 한 해 이미지를 비공개로 저장하는 건데 여러 계정으로 설정할 수도 있다.
• 혹은 퍼블릭 저장소를 사용해 Amazon ECR Public Gallery에 게시하는 방법이 있다.
• ECR은 Amazon ECS와 완전히 통합되어 있고 이미지는 백그라운드에서 Amazon S3에 저장된다.
• ECR 저장소에 여러 도커 이미지가 있는데 ECS 클러스터의 EC2 인스턴스에 이미지를 끌어오기 위해서는EC2 인스턴스에 IAM 역할을 지정하면 된다.
• IAM 역할이 도커 이미지를 인스턴스에 끌어온다. ECR에 대한 모든 접근은 IAM이 보호하고 있다.
• ECR에 권한 에러가 생긴다면 정책을 살펴봐야 한다.
• EC2 인스턴스에 이미지를 끌어온 후에는 컨테이너가 시작된다.
• Amazon ECR은 단순히 저장하는 리포지토리에 그치지 않고 이미지의 취약점 스캐닝, 버저닝 태그 및 수명 주기 확인을 지원한다.

EKS (Elastic Kubernetes Service)

• AWS에 관리형 Kubernetes 클러스터를 실행할 수 있는 서비스다.
• EKS에는 두 가지 실행 모드가 있다.
  • EC2 시작 모드는 EC2 인스턴스에서처럼 작업자 모드를 배포할 때 사용하고
  • Fargate 모드는 EKS 클러스터에 서버리스 컨테이너를 배포할 때 사용한다.
• 클라우드 또는 컨테이너 간 마이그레이션을 실행하는 경우 Amazon EKS가 솔루션이 될 수 있다.
• EKS Node는 ASG로 관리할 수 있다.
• EKS 서비스나 Kubernetes 서비스를 노출할 때는 프라이빗 로드 밸런서나 퍼블릭 로드 밸런서를 설정해 웹에 연결해야 한다.

EKS 노드 유형

• 관리형 노드 그룹은 AWS로 노드, 즉 EC2 인스턴스를 생성하고 관리한다.
  • 노드는 EKS 서비스로 관리되는 오토 스케일링 그룹의 일부다.
  • 온디맨드 인스턴스와 스팟 인스턴스를 지원한ㄴ다.
• 자체 관리형 노드 그룹은 사용자 지정 사항이 많고 제어 대상이 많은 경우 직접 노드를 생성하고 EKS 클러스터에 등록한 다음 ASG의 일부로 관리해야 한다.
  • 사전 빌드된 AMI인 Amazon EKS 최적화 AMI를 사용하면 시간을 절약할 수 있다.
  • 자체 AMI를 빌드해도 되지만 복잡하다.
  • 온디맨드 인스턴스와 스팟 인스턴스를 지원한다.
• 끝으로 노드를 원치 않는 경우에는 Amazon EKS가 지원하는 Fargate 모드를 선택하면 유지 관리도 필요 없고 노드를 관리하지 않아도 되며 Amazon EKS에서 컨테이너만 실행하면 된다.
• Amazon EKS 클러스터에 데이터 볼륨을 연결하려면 EKS 클러스터에 스토리지 클래스 매니페스트를 지정해야 한다.
• 컨테이너 스토리지 인터페이스(CSI)라는 규격 드라이버를 활용하는데 시험에 나올 만한 키워드다.
• Amazon EBS와 Fargate 모드가 작동하는 유일한 스토리지 클래스 유형인 Amazon EFS를 지원하고 Amazon FSx for Lustre와 Amazon FSx for NetApp ONTAP을 지원한다.

App Runner

• 이 서비스로는 누구나 AWS에 배포를 할 수 있다. 인프라나 컨테이너, 소스 코드 등을 알 필요가 없기 때문이다.
• 먼저 소스 코드나 Docker 컨테이너 이미지를 가지고 원하는 구성을 설정한다.
• vCPU의 수나 컨테이너 메모리의 크기 오토 스케일링 여부 상태 확인을 설정하면 된다.
• 웹 애플리케이션이나 API에 들어갈 기본 설정을 설정하는 것이다.
• 다음 작업은 자동으로 이뤄진다.
  • App Runner 서비스가 웹 앱을 빌드하고 배포한다. 또는 컨테이너가 생성되고 배포된다.
  • API나 웹 앱이 배포된 다음엔 URL을 통해 바로 액세스할 수 있다.
• 배후에서 AWS 서비스가 사용되는 것이겠지만 사용자는 굳이 몰라도 빠른 배포를 할 수 있다.
• 오토 스케일링이 가능하고 가용성이 높으며 로드 밸런싱 및 암호화 기능을 지원한다.
• 애플리케이션, 즉 컨테이너가 VPC에 액세스할 수도 있어서 데이터베이스와 캐시 메시지 대기열 서비스에 연결할 수 있다.
• 사용 사례로는 빨리 배포해야 하는 웹 앱, API 그리고 마이크로서비스가 있다.
• 신속한 프로덕션 배포가 필요할 때도 가장 좋은 방법은 AWS App Runner 서비스를 사용하는 것이다.