Container
ECS
개요
Elastic Container Service
AWS에서 컨테이너를 실행하면 ECS 클러스터에 ECS 태스크를 실행하는 형태로 동작한다.
EC2 시작 유형
ECS 클러스터에 여러 EC2 인스턴스를 두는 방식이다.
인프라를 직접 프로비저닝하고 유지해야 한다.
ECS 인스턴스에는 각각 ECS 에이전트를 실행해야 한다. ECS 에이전트는 각 EC2 인스턴스를 Amazon ECS 서비스와 ECS 클러스터에 등록한다.
ECS 태스크를 수행하기 시작하면 AWS가 컨테이너를 시작하거나 멈출 수 있다. 새 도커 컨테이너가 생기면 미리 프로비저닝된 EC2 인스턴스에 자동으로 배정된다.
Fargate 시작 유형
인프라를 프로비저닝하지 않아 EC2 인스턴스 등 인프라를 관리하지 않아도 된다. (Serverless)
EC2 시작 유형보다 관리가 쉽다.
ECS 클러스터가 있을 때 ECS 태스크를 정의하는 태스크 정의만 생성하면 필요한 CPU나 RAM에 따라 ECS 태스크를 AWS가 대신 실행한다.
도커 컨테이너를 실행하면 어디서 실행되는지 알리지 않고 그냥 실행된다.
인프라를 확장하려면 간단하게 태스크 수만 늘리면 된다.
IAM 역할
EC2 Instance Profile
EC2 시작 유형을 사용하여 EC2 인스턴스가 도커에 ECS 에이전트를 실행할 때, ECS 에이전트만이 EC2 인스턴스 프로파일을 통해 ECS 서비스의 API를 호출하도록 하기 위해 사용된다.
CloudWatch 로그에 API 호출을 해서 컨테이너 로그를 보낼 수 있다.
ECR로부터 도커 이미지를 가져온다.
Secrets Manager나 SSM Parameter Store에서 민감 데이터를 참조한다.
ECS Task Role
EC2와 Fargate 시작 유형에 모두 해당되며 태스크마다 특정 역할을 할당할 수 있다. IAM 역할을 부여하여 다른 AWS 서비스 API에 요청을 보내는 권한을 준다.
각 역할은 서로 다른 ECS 서비스에 연결한다. 예를 들어 EC2 태스크 A 역할은 태스크 A가 Amazon S3에 API 호출을 실행할 수 있도록 한다면 태스크 B 역할은 DynamoDB에 API 호출을 실행할 수 있도록 한다.
ECS 서비스의 태스크 정의에서 태스크의 역할이 정의된다.
로드 밸런서 통합
ALB: 여러 ECS 태스크들이 ECS 클러스터 안에서 실행될 때, ECS 태스크의 HTTP나 HTTPS 엔드 포인트를 로드밸런서를 통해 호출하도록 한다.
NLB: 처리량이 매우 많거나 높은 성능이 요구될 때, 혹은 AWS Private Link와 사용할 때 권장된다.
ELB: 구세대 로드밸런서로 고급 기능이 없고 Fargate에 연결할 수 없어 권장하지 않는다.
데이터 볼륨
데이터 지속성을 위해 데이터 볼륨을 사용할 수 있다.
EFS 파일 시스템을 ECS 태스크에 마운트할 수 있다.
EC2 인스턴스, Fargate 시작 유형 모두 지원한다.
어떤 AZ에서 태스크가 실행되든 동일한 EFS의 데이터를 공유할 수 있다.
Fargate ECS 태스크를 실행하고 파일 시스템 지속성을 위해 Amazon EFS를 사용하면 완전한 서버리스로 관리된다.
EFS와 ECS를 함께 사용해서 다중 AZ가 공유하는 컨테이너의 영구 스토리지를 구성할 수 있다.
Amazon S3는 ECS 태스크에 파일 시스템으로 마운트될 수 없다.
오토 스케일링
태스크 수를 수동으로 스케일링할 수도 있지만, 자동으로 늘리거나 줄일 수도 있다.
이를 위해서는 AWS의 Auto Scaling이라는 서비스를 사용하면 된다.
다음 세 개의 지표에 대해 확장이 가능하다.
ECS 서비스의 CPU 사용률
ECS 서비스의 메모리 사용률
ALB 관련 지표인 타겟당 요청 수
대상 추적(Target Tracking) 스케일링
특정 타겟을 추적하는
단계(Step) 스케일링
예약(Scheduled) 스케일링
미리 ECS 서비스 확장을 설정
태스크 레벨에서의 ECS 서비스 확장은 EC2 인스턴스 클러스터의 확장과 다르다!
EC2 인스턴스 사용 시 오토 스케일링 방식은 두 방식 중 하나를 사용할 수 있다.
Auto Scaling Group Scaling
백엔드의 EC2 인스턴스를 ASG를 통해 확장한다.
CPU 사용률이 급등할 때 EC2 인스턴스를 추가할 수 있다.
ECS 클러스터 용량 공급자
새 태스크를 실행할 용량이 부족하면 자동으로 ASG를 확장한다.
오토 스케일링 그룹과 함께 사용되며 RAM이나 CPU가 모자랄 때 EC2 인스턴스를 추가한다.
권장되는 방식이다.
아키텍처
Fargate와 다른 AWS 서비스를 통합하여 서버리스로 아키텍처를 구성할 수 있다.
EventBridge를 통한 태스크 호출
EventBridge가 ECS 태스크를 호출해 특정 작업을 수행하도록 할 수 있다.
예를 들어 Amazon Fargate로 구성된 ECS 클러스터가 있고 S3 버킷에 파일이 업로드되었다는 알람이 EventBridge로 들어오면, ECS 태스크를 수행하여 S3의 데이터를 DynamoDB로 업로드하도록 아키텍처를 구성할 수 있다.
EventBridge Schedule에 의한 주기적 ECS 태스크 호출
Amazon EventBridge에서 1시간마다 트리거되는 규칙을 스케줄링하여 Fargate에서 ECS 태스크를 실행하게 할 수 있다.
예를 들어 태스크에서 Amazon S3의 특정 파일들에 대한 배치 프로세싱을 1시간마다 수행할 수 있다.
SQS Queue로부터 폴링하는 ECS 태스크
메시지가 SQS Queue로 전송되면, ECS 태스크는 SQS Queue로부터 메시지를 가져와서 처리한다.
ECS 서비스 오토 스케일링을 활성화한다면, SQS Queue에 메시지가 많이 쌓이게 될 때 스케일 아웃을 통해 더 많은 태스크가 동작하도록 할 수 있다.
ECS 태스크를 가로채어 활용
EventBridge를 사용하여 실제로 여러분의 ECS 클러스터 안에서 발생한 이벤트를 가로챌 수 있다.
태스크가 종료되거나 시작되면 EventBridge에서 이벤트로 트리거하도록 한다. 해당 정보를 SNS 토픽으로 보내 관리자에게 이메일을 전송할 수 있다. 이를 통해 ECS 클러스터에 있는 컨테이너들의 라이프사이클을 모니터링할 수 있다.
ECR
Elastic Container Registry
AWS에 도커 이미지를 저장하고 관리하는 데 사용된다.
일부 계정에 한해 이미지를 비공개로 저장해 접근하거나, 퍼블릭 저장소를 사용해 Amazon ECR Public Gallery에 게시할 수 있다.
Amazon ECS와 완전히 통합되어 있다.
이미지는 내부적으로 Amazon S3에 저장된다.
ECS 클러스터의 EC2 인스턴스에 ECR 이미지를 끌어오기 위해서는 EC2 인스턴스에 IAM 역할을 지정해야 한다. ECR에 권한 에러가 생긴다면 정책을 확인해야 한다.
이미지의 취약점 스캐닝, 버저닝 태그 및 수명 주기 확인 기능을 지원한다.
EKS
Amazon Elastic Kubernetes Service
AWS에 관리형 Kubernetes 클러스터를 실행할 수 있는 서비스이다.
Kubernetes는 오픈 소스 시스템으로 Docker로 컨테이너화한 애플리케이션의 자동 배포, 확장, 관리를 지원한다.
워커 노드를 배포하고 싶을 때 EC2 인스턴스를 사용할 수 있으며, EKS 클러스터에 서버리스 컨테이너를 배포하고 싶을 땐 Fargate 모드를 사용하면 된다.
보통 회사가 온프레미스나 클라우드에서 Kubernetes나 Kubernetes API를 사용 중일 때 Kubernetes 클러스터를 관리하기 위해 Amazon EKS를 사용한다.
Kubernetes는 cloud-agnostic으로, Azure, Google Cloud 등 모든 클라우드에서 지원된다. 따라서 클라우드 또는 컨테이너 간 마이그레이션을 실행하는 경우 Amazon EKS가 간단한 솔루션이 될 수 있다.
CloudWatch Container Insights를 사용해 로그와 메트릭을 수집할 수 있다.
EKS 워커 노드를 생성하면 EC2 인스턴스가 구성된다. 각 노드는 EKS 파드를 실행한다.
EKS 파드가 실행되는 EKS 노드는 오토 스케일링 그룹으로 관리할 수 있다.
ECS와 유사하게 EKS 서비스를 노출할 때는 프라이빗 로드 밸런서나 퍼블릭 로드 밸런서를 설정해 웹에 연결해야 한다.
노드 타입
관리형 노드 그룹
AWS로 노드(EC2 인스턴스)를 생성하고 관리한다.
노드들은 EKS가 관리하는 ASG에 속한다.
온디맨드 인스턴스와 스팟 인스턴스를 지원한다.
자체 관리형 노드
사용자 지정 사항이 많고 제어 대상이 많은 경우 직접 노드를 생성하고 EKS 클러스터에 등록한 다음 ASG의 일부로 관리해야 한다.
사전 빌드된 AMI인 Amazon EKS 최적화 AMI를 사용하여 구동 시간을 절약할 수 있다.
온디맨드 인스턴스와 스팟 인스턴스를 지원한다.
AWS Fargate
유지보수가 필요 없고 노드를 관리하지 않아도 된다.
Amazon EKS에서 컨테이너를 실행하기만 하면 된다.
데이터 볼륨
데이터 볼륨을 연결하려면 EKS 클러스터에 스토리지 클래스 매니페스트를 지정해야 한다.
컨테이너 스토리지 인터페이스(CSI)라는 규격 드라이버를 활용해 데이터 볼륨을 추가할 수 있다.
Amazon EBS, Amazon EFS(Fargate 모드가 작동하는 유일한 스토리지 클래스 유형), Amazon FSx for Lustre, Amazon FSx for NetApp ONTAP을 지원한다.
App Runner
완전 관리형 서비스로 규모에 따라 웹 애플리케이션, API 배포를 쉽게 할 수 있도록 해준다.
인프라 관리 경험 없이도 누구나 AWS에 배포를 할 수 있다.
소스 코드나 Docker 컨테이너 이미지를 기반으로 하여, vCPU의 수나 컨테이너 메모리의 크기, 오토 스케일링 여부 상태 확인을 설정하면 된다.
이후에는 App Runner 서비스가 애플리케이션 혹은 컨테이너를 빌드하고 배포한다.
API나 웹 앱이 배포된 다음엔 URL을 통해 바로 액세스할 수 있다.
오토 스케일링이 가능하고 가용성이 높으며 로드 밸런싱 및 암호화 기능을 지원한다.
애플리케이션 혹은 컨테이너가 VPC에 접근할 수 있어, AWS에서 지원하는 데이터베이스, 캐시, 메시지 대기열 서비스에 연결할 수 있다.
빨리 배포해야 하는 웹 앱, API 그리고 마이크로서비스 배포에 적합하다.
App2Container
Java 및 .NET 웹 애플리케이션을 Docker 컨테이너로 마이그레이션하고 현대화하는 데에 사용되는 CLI 도구이다.
온프레미스 환경의 베어메탈이나 가상 머신 혹은 다른 클라우드에 구동중인 애플리케이션을 AWS에서 동작하도록 Lift-and-shift 마이그레이션할 수 있다.
코드를 변경하지 않고 레거시 앱을 클라우드로 마이그레이션할 수 있다.
컴퓨팅, 네트워크 등을 위한 CloudFormation 템플릿을 생성한다. 이후 Docker 컨테이너를 생성해 ECR에 등록한다.
ECS, EKS 또는 App Runner에 배포하도록 선택할 수 있다.
사전 구축된 CI/CD 파이프라인도 지원한다.
내부적으로는 다음과 같이 동작한다.
CLI를 사용하여 마이그레이션할 수 있는 앱을 검색하고 분석한다.
애플리케이션을 의존성과 함께 추출하여 컨테이너화한다.
배포 아티팩트가 생성된다. ECS 작업 및 EKS pod 정의, 모든 CI/CD 및 기타 인프라가 포함된 CloudFormation 템플릿이 만들어진다.
AWS 로 배포된다. Docker 컨테이너의 이미지는 Amazon ECR에 저장되며, ECS, EKS 또는 App Runner에 배포할 수 있다.
Last updated
