amazon ecs
이제 아마존 ECS 에 관해 얘기해보죠.
Amazon ECS — EC2 Launch Type
EC2 Launch Type 은 Amazon ECS 에서 컨테이너 화 된 애플리케이션을 관리하는 전통적인 방법입니다. 이 방법을 사용하면 Amazon EC2 인스턴스를 직접 관리하면서 컨테이너를 실행할 수 있습니다.
- 인스턴스 관리
- 사용자는 EC2 인스턴스를 직접 관리하고, 이 인스턴스 에 ECS 에이전트를 설치하여 ECS 클러스터에 등록해야 합니다.
- 인스턴스 유형, 크기, AMI, 네트워킹, 보안 그룹 등을 직접 선택하고 구성합니다. - 스케일링
- EC2 인스턴스 기반에서는 수동으로 또는 Auto Scaling 을 사용하여 인스턴스의 수를 조절해야 합니다.
- 컨테이너와 인스턴스 모두에 대한 스케일링 전략을 설정할 수 있습니다. - 리소스 관리
- EC2 인스턴스에서는 메모리 및 CPU 사용량 등 리소스 할당을 세부적으로 관리할 수 있습니다.
- 사용자는 컨테이너에 필요한 리소스를 정의하고, ECS가 적절한 EC2 인스턴스에 작업을 배치하도록 할 수 있습니다. - 비용
- EC2 Launch Type 은 사용하는 EC2 인스턴스에 대한 비용을 지불 합니다.
- 인스턴스 사이즈와 사용 시간에 따라 비용이 결정되며, 리저브드 인스턴스나 스팟 인스턴스를 사용하여 비용을 절감할 수 있습니다. - 네트워킹
- ECS 에서 실행되는 컨테이너는 EC2 인스턴스의 네트워크 및 보안 설정을 활용합니다.
- VPC, 서브넷, ELB 등을 사용하여 네트워크를 구성할 수 있습니다. - 저장소
- EC2 인스턴스에 연결된 EBS 볼륨이나 EFS를 사용하여 컨테이너에 지속적인 저장소를 제공할 수 있습니다.
EC2 Launch Type 은 고도의 컨트롤과 리소스 관리가 필요한 시나리오에 적합하고, 복잡한 네트워킹 구성이나 대규모 스토리지 가 필요한 애플리케이션에 유리합니다. 또한 리소스 사용량이 예측 가능하고, 비용 절감을 위해 리저브드 또는 스팟 인스턴스 를 활용하고자 할 때 적합합니다.
Amazon ECS — Fargate LaunchType
Amazon ECS (Elastic Container Service)에서 Fargate Launch Type 은 서버리스 컴퓨팅 모델을 제공하여, 사용자가 컨테이너를 실행할 때 서버 인스턴스 관리에 대한 부담 없이 컨테이너를 실행할 수 있게 합니다. Fargate Launch Type 을 사용하면, 컨테이너를 위한 서버를 프로비저닝 하거나 관리할 필요가 없습니다.
- 서버 관리 불필요
- Fargate 는 서버 인스턴스를 관리할 필요 없이 컨테이너를 실행합니다. 사용자는 컨테이너의 메모리와 CPU 만 지정하면 됩니다. - 간편한 스케일링
- Fargate 는 필요에 따라 자동으로 스케일링됩니다. 애플리케이션의 부하가 증가하면, Fargate 는 추가 컨테이너를 자동으로 시작하여 부하를 분산시킵니다. - 간단한 비용 구조
- 사용자는 실행한 컨테이너의 CPU 와 메모리 사용량에 따라 비용을 지불합니다. 전통적인 EC2 인스턴스와 달리 예약 인스턴스나 스팟 인스턴스에 대해 걱정할 필요가 없습니다. - 보안
- 각 Fargate 태스크는 격리된 환경에서 실행되며, 다른 태스크와의 리소스 공유가 없어 보안이 강화됩니다. - 통합 및 호환성
- AWS의 다른 서비스들과 쉽게 통합됩니다. 예를 들어, Amazon RDS, Amazon VPC, ELB와의 연결이 간편합니다.
Fargate 는 각각의 마이크로서비스를 독립적인 컨테이너로 실행하기에 적합하고, 일시적인 배치 작업이나 백그라운드 작업에 Fargate 를 사용할 수 있습니다. 또한 웹 서버나 Restful API 를 호스팅하는 데 Fargate 를 사용할 수 있습니다.
Amazon ECS — IAM Roles for ECS
Amazon Elastic Container Service (ECS)에서의 IAM (Identity and Access Management) 역할은 Amazon ECS 에서 컨테이너 및 컨테이너 인스턴스 가 AWS 리소스에 접근하고 상호 작용하는 방식을 관리하는 데 중요한 역할을 합니다. IAM 역할을 통해 컨테이너가 필요한 AWS 서비스 및 리소스에 안전하게 접근할 수 있도록 구성할 수 있습니다.
ECS Task (role)는 컨테이너가 실행 중인 동안 필요한 AWS API 호출을 수행할 수 있도록 합니다. 예를 들어, ECS Task 는 S3 버킷에서 파일을 읽거나 쓰고, DynamoDB 테이블에 접근하고, CloudWatch Logs 에 로그를 기록하는 등의 작업을 수행할 수 있습니다. 이 역할은 Task 정의에서 지정 하며, 각 컨테이너가 Task 역할을 공유합니다.
ECS 서비스(role)는 ECS 가 클러스터 내에서 Task 나 서비스를 관리하는 데 필요한 권한을 제공합니다. 예를 들어, ECS 서비스 역할을 사용하여 ELB(Elastic Load Balancing)와 의 통합을 관리하거나, 서비스 오토 스케일링을 설정할 수 있습니다.
EC2 인스턴스(role)는 ECS 에이전트가 ECS API 에 접근하여 컨테이너 인스턴스를 클러스터에 등록하고 Task 를 관리하는 데 필요한 권한을 제공합니다. 이 역할은 ECS 컨테이너 인스턴스를 호스팅하는 EC2 인스턴스에 연결되어 있습니다.
IAM 역할 설정 방법에 대해서 알아 볼게요.
첫번째, IAM 콘솔에서 역할 생성은 AWS IAM 콘솔로 이동하여 새 역할을 생성합니다. 사용 사례에 따라 ECS Task, ECS Service 또는 EC2 Role을 선택합니다. 그리고 필요한 권한 정책을 역할에 연결합니다.
두번째, ECS Task 정의에 역할 지정은 ECS Task 정의를 생성하거나 수정할 때 taskRoleArn 필드에 IAM Task 역할의 ARN 을 지정합니다.
세번째, ECS 서비스에 역할 지정은 ECS 서비스를 생성하거나 업데이트할 때 필요한 경우 서비스 역할을 지정합니다.
Amazon ECS — Load Balancer Integrations
Amazon Elastic Container Service (ECS) 는 로드 밸런서와의 통합을 지원하여, 컨테이너화된 애플리케이션의 트래픽 관리 및 확장성을 향상시키는 데 도움을 줍니다. ECS 와 로드 밸런서 를 통합하면, 인바운드 트래픽을 여러 컨테이너 인스턴스 및 서비스에 자동으로 분산시킬 수 있습니다. Amazon ECS 는 주로 두 가지 유형의 로드 밸런서와 통합됩니다: Application Load Balancer (ALB) 및 Network Load Balancer (NLB).
ALB 는 HTTP/HTTPS 트래픽에 최적화되어 있으며, 고급 라우팅 기능(호스트 기반 라우팅, 경로 기반 라우팅)을 제공하며, ECS 서비스에 직접 통합되어, 동적 포트 매핑 을 지원합니다. 이는 여러 개의 태스크가 같은 컨테이너 인스턴스에서 서로 다른 포트를 사용하여 실행될 수 있음 을 의미합니다. 또한 ALB 는 태스크 수준의 Health check 검사를 수행하여, 태스크의 상태에 따라 트래픽을 자동으로 조절합니다.
NLB 는 TCP 트래픽에 최적화되어 있으며, 초 저지연 및 초 고 처리량 트래픽을 처리하는 데 적합하며, 각 NLB 리스너에 대해 정적 IP 주소를 할당할 수 있어, IP 주소 기반의 통합이 필요한 경우 유용합니다. 또한 NLB 는 여러 가용 영역에 걸쳐 트래픽을 분산시킬 수 있습니다.
Load Balancer 통합 설정 방법은 크게 Load Balancer 생성, ECS 서비스 구성, Task 정의 구성으로 볼 수 있습니다.
- Load Balancer 생성 : AWS 콘솔에서 ALB 또는 NLB 를 생성합니다. 로드 밸런서 에 리스너와 타겟 그룹을 설정합니다.
- ECS 서비스 구성 : ECS 서비스를 생성하거나 업데이트할 때, 생성된 Load Balancer 를 서비스에 연결합니다. 타겟 그룹에는 ECS 서비스의 Task 세트가 자동으로 등록됩니다.
- Task 정의 구성 : ECS Task 정의에 컨테이너 정의를 추가하고, 필요한 경우 ALB 의 경우 컨테이너 포트와 Load Balancer 포트를 매핑 합니다.
Amazon ECS — Data Volumes (EFS)
Amazon Elastic Container Service (ECS)에서는 Elastic File System (EFS)을 데이터 볼륨으로 사용하여 컨테이너 간에 파일 시스템을 공유하거나, 데이터를 영구적으로 저장하는 기능을 제공합니다. 이는 특히 상태를 유지하는 애플리케이션 또는 여러 컨테이너가 액세스해야 하는 공유 데이터에 유용합니다.
EFS 볼륨은 다수의 컨테이너가 동시에 액세스할 수 있는 지속적인 스토리지를 제공합니다. 컨테이너가 재 시작 되거나 새로 배포되어도 데이터가 유지됩니다. EFS 는 사용량에 따라 자동으로 스케일링 되므로, 스토리지 관리에 대한 부담이 줄고, 대용량 데이터를 처리하는 애플리케이션에 적합합니다. EFS는 여러 가용 영역에 걸쳐 데이터를 복제하여 높은 가용성과 내구성을 제공합니다.
Amazon ECS 에서 EFS 볼륨 구성 방법은 AWS 관리 콘솔 을 통해 EFS 파일 시스템을 생성한 후 VPC 및 서브넷 설정을 구성하여 EC2 인스턴스 또는 Fargate와 네트워크 연결을 설정합니다. 그리고 ECS Task 정의에서 볼륨 섹션을 추가하고, EFS 파일 시스템의 ID를 볼륨 소스로 지정하고 컨테이너 정의에서 마운트 포인트를 설정하여, 볼륨을 컨테이너 내부의 특정 경로에 마운트 합니다. 그리고 Task 정의를 기반으로 ECS 서비스를 생성하거나, 단일 Task 를 실행한후 ECS 는 컨테이너가 실행될 때 EFS 볼륨을 마운트 합니다.
ECS Service Auto Scaling
Amazon Elastic Container Service (ECS) 의 서비스 Auto Scaling 기능은 애플리케이션의 트래픽 변화에 따라 자동으로 컨테이너 인스턴스 의 수를 조절합니다. 이 기능을 사용하면 트래픽이 증가할 때 자동으로 더 많은 컨테이너 인스턴스를 추가하고, 트래픽이 감소하면 인스턴스 수를 줄여 리소스를 효율적으로 관리할 수 있습니다.
ECS 서비스 Auto Scaling 은 다양한 스케일링 정책을 제공합니다. 이를 통해 CPU 사용량, 메모리 사용량, 사용자 정의 메트릭스 등에 기반 하여 Task 수 를 자동 조절할 수 있습니다.
ECS 서비스 Auto Scaling 설정 방법은 우선, AWS CloudWatch에서 ECS 서비스에 대한 메트릭스(예: CPUUtilization, MemoryUtilization)를 기반으로 알람을 설정하고, ECS 서비스에서 스케일링 정책을 정의합니다. 예를 들어, CPU 사용량이 특정 임계값을 초과하면 Task 수를 증가시키는 정책을 설정할 수 있습니다. 그리고 생성한 스케일링 정책을 ECS 서비스에 연결하여, CloudWatch 알람이 트리거 될 때 자동으로 Task 수를 조절하도록 설정합니다.
ECS Scaling — Service CPU Usage Example
두 가지 작업과 CPU 사용 서비스가 있고 앱 자동 배율에 따라 자동으로 배율될 겁니다. 하지만 사용자가 더 많다고 가정해보면 CPU 사용량이 증가할 겁니다.
다음은 CloudWatch Metric 입니다. 서비스 레벨에서 CPU 사용을 모니터하는 CloudWatch Metric 이 울리면 CloudWatch 알람이 울리고 자동으로 서비스 스케일링 액티비가 발생합니다. 그러면 원하는 용량이 증가하고 새로운 Task 가 생성됩니다.
그리고 선택적으로 이 서비스가 EC2 시작 유형에서 실행된다면 EC2 인스턴스로 백업된 클러스터 용량을 공급자가 조정할 수 있도록 돕습니다.
ECS tasks invoked by Event Bridge
AWS 에서 ECS(Elastic Container Service) Task 를 Event Bridge를 통해 호출하는 것은 자동화된 워크플로우 를 구성하는 데 매우 유용한 방법입니다. 이를 통해 특정 이벤트가 발생했을 때 컨테이너화된 어플리케이션을 실행할 수 있습니다.
Amazon ECS 와 접할 수 있는 솔루션 아키텍처에 대해 얘기해 봅시다.
첫 번째는 Event Bridge 에 의해 실행되는 ECS 작업이죠. 예를 들어 Fargate 가 지원하는 Amazon ECS 클러스터가 있고 S3 Bucket 이 있다고 해보면, 사용자는 S3 Bucket 에 개체를 업로드할 텐데 이 S3 Bucket 은 예를 들어 Amazon EventBridge 와 통합되어 모든 이벤트를 보낼 수 있습니다.
Amazon EventBridge 는 업무를 실시간으로 처리하는 규칙을 만들었죠. 이제 Task 가 생성되고, 작업 자체와 관련해서 ECS Task Role 을 맡습니다. 이 앱은 객체를 가져다가 처리하고 ECS Task Role 이 관련되 있기 때문에 결과를 Amazon DynamoDB 에 보낼 수 있어요.
Docker 컨테이너를 이용해 이미지나 S3 버킷 에서 개체를 처리하기 위해 서버 없는 아키텍처를 만들었습니다. Fargate 모드에서 Amazon EventBridge ECS 를 사용하고 Amazon S3와 Amazon DynamoDB 와 통신하기 위한 ECS Task Role 도 사용하죠.
Event Bridge 를 사용하여 ECS Task 를 호출하는 프로세스는 대략적으로 다음과 같습니다.
1. 특정 AWS 서비스 또는 사용자 정의 이벤트가 Event Bridge 에 발생합니다. 2. Event Bridge 에는 이벤트를 감지하고 특정 조건에 맞는 경우 액션을 취하는 규칙이 설정 됩니다.
3. 이 규칙 중 하나는 ECS Task 를 실행하는 것일 수 있습니다. 예를 들어, 특정 S3 버킷에 파일이 업로드 되면, 해당 이벤트를 감지하여 ECS Task 를 트리거 할 수 있습니다.
4. Event Bridge 규칙에 의해 실행된 ECS Task 는 컨테이너화된 어플리케이션 을 실행합니다. 이 어플리케이션은 필요한 작업을 수행할 수 있습니다(예: 데이터 처리, 배치 작업 등)
ECS tasks invoked by Event Bridge Schedule
AWS Event Bridge 스케줄을 사용하여 ECS(Elastic Container Service) Task 를 호출하는 것은 정기적으로 컨테이너화된 작업을 자동으로 실행하는 데 사용됩니다. 이 방법은 크론 작업이나 스케줄링된 배치 작업과 유사한 개념으로, Event Bridge 를 사용하여 정해진 시간에 ECS Task 를 실행할 수 있습니다.
Fargate 와 Amazon EventBridge 의 지원을 받는 아마존 ECS 클러스터가 있고 1시간마다 작동하는 규칙을 설정했습니다. 이 규칙은 Fargate 에서 작업을 실행합니다. 그 말은 매 시간마다 Fargate Cluster 에 새 작업이 생성된다는 겁니다. 작업은 우리가 원하는 건 뭐든 할 수 있습니다. 예를 들어 Amazon S3 에 액세스하는 ECS Task Role 을 만들 수 있고, Task Docker 컨테이너는 Amazon S3 의 일부 파일에 대한 일괄 처리를 1시간마다 할 수 있습니다.
AWS Event Bridge 스케줄을 사용하여 ECS(Elastic Container Service) 태스크를 호출 프로세스는 대략적으로 다음과 같습니다.
- ECS Task 정의 : 실행할 컨테이너화된 어플리케이션에 대한 ECS Task 정의를 생성 합니다.
- Event Bridge 규칙 생성 : Event Bridge 에서 새 규칙을 생성하고, 스케줄 표현식(시간 또는 크론)을 설정 합니다.
- ECS Task 를 대상으로 지정 : 생성한 규칙의 대상으로 ECS Task (또는 ECS 서비스)를 지정합니다. 이 때, 필요한 파라미터(예: 클러스터 이름, Task 정의)를 제공합니다.
- 규칙 활성화 : 규칙을 활성화하여 정해진 스케줄에 따라 ECS Task 가 실행되도록 합니다.
활용 사례
- 데이터 처리 : 매일 정해진 시간에 데이터 처리를 위한 배치 작업을 실행합니다.
- 보고서 생성 : 매주 자동으로 보고서를 생성하고 저장하는 작업을 수행합니다.
- 시스템 유지보수 : 정기적인 유지보수 작업을 자동으로 실행합니다.
ECS — SQS Queue Example
메시지가 SQS 큐에 보내지면 서비스가 각 SQS 큐에서 메시지를 가져와서 처리합니다. 이 서비스 위에 ECS Service Auto Scaling 을 활성화할 수 있습니다. 그 말은, 예를 들어 SQS 큐에 메시지가 더 많을수록 Auto Scaling 덕분에 서비스에 작업도 더 많아진다는 겁니다.
ECS — Intercept Stopped Tasks using EventBridge
AWS EventBridge 를 사용하여 ECS(Elastic Container Service)에서 중지된 Task 를 감지하고 그에 대응하는 것은, 특정 ECS Task 의 수명 주기 이벤트에 반응하도록 시스템을 설정하는 데 매우 유용한 방법입니다. 이 방식을 통해 ECS Task 가 중지될 때 자동으로 특정 작업을 수행하도록 구성할 수 있습니다.
ECS 에서 Task 의 상태 변경은 다양한 이벤트로 표현됩니다. 이 중 하나가 Task 가 중지되는 이벤트입니다. Task 가 중지될 때 발생하는 이벤트는 다양한 원인(예: 정상 완료, 오류, 리소스 부족)에 기인할 수 있습니다.
EventBridge 를 사용하여 ECS Task 가 중지될 때 이를 감지하고, 필요한 조치를 취할 수 있습니다. 예를 들어, Task 가 실패로 인해 중지 되었을 때 경고를 보내거나, 자동으로 다시 시작하는 로직을 실행할 수 있습니다.
AWS EventBridge 를 사용하여 ECS(Elastic Container Service)에서 중지된 Task 를 감지하고 그에 대응하는 프로세스는 대략적으로 다음과 같습니다.
- EventBridge 규칙 설정 : EventBridge 에서 ECS Task 상태 변경과 관련된 이벤트를 감지할 규칙을 생성합니다. 특히, Task 가 중지되었을 때 발생하는 이벤트에 집중합니다.
- 이벤트 패턴 정의 : 해당 규칙에 대한 이벤트 패턴을 정의하여, ECS Task
STOPPED상태 이벤트만을 필터링 합니다. - 대상 설정 : 이벤트가 감지 되었을 때 실행할 대상을 지정합니다. 이 대상은 Lambda 함수일 수도 있고, SNS 토픽, SQS 큐 등 다른 AWS 서비스일 수도 있습니다.
- 응답 로직 구현 : 설정된 대상에서 필요한 작업을 수행하도록 로직을 구현합니다. 예를 들어, Lambda 함수 에서는 중지된 Task 의 상세 정보를 분석하고 필요한 조치를 취합니다.
활용 사례
- 오류 모니터링과 알림 : Task 가 예기치 않게 중지되었을 때 관리자에게 알림을 보냅니다.
- 자동 복구 : 중지된 Task 를 자동으로 재시작 하여 시스템의 복원력을 높입니다.
- 로그 분석 : 중지된 Task 의 로그를 분석하여 문제의 원인을 파악합니다.
ECS — Logging with “awslogs” driver
작업에 대한 로깅 과 CloudWatch Logs 로 로그를 보내는 방법을 살펴보겠습니다. 컨테이너가 있으면 결과에 로그가 생성되고, 이 앱 로그는 CloudWatch Logs 직접 전송됩니다.
이걸 위해 작업을 시작할 때 log driver 를 활성화 하고, 작업 정의에 로그 구성 매개 변수를 설정 함으로써 작업이 됩니다.
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/fargate-task-definition",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "ecs"
}
}위 구성으로 진행을 잘 되면, 컨테이너에서 나온 로그가 CloudWatch Logs 로 직접 전송되고 스트리밍되죠.
이제 Fargate Launch Type 을 사용 한다면 CloudWatch Logs 를 처리 하기 위해서 Fargate Task 실행 롤 이 필요한 권한을 갖는지 확인해야 합니다.
ECS — Logging with Sidecar Container
AWS ECS(Elastic Container Service)에서 사이드카(Sidecar) 컨테이너를 사용한 로깅 은 마이크로서비스 아키텍처에서 로그 관리를 용이하게 하는 일반적인 패턴입니다. 사이드카 컨테이너는 주 컨테이너와 함께 배치 되어 로깅, 모니터링, 네트워킹과 같은 보조 기능을 제공합니다.
주 컨테이너 옆에 두 번째 컨테이너가 있는데, 파일 시스템으로 가거나 로그를 찾아 로그 저장소로 보내는 컨테이너 입니다.
두 컨테이너의 차이점은 작업의 일부인 컨테이너는 작업 자체에 대한 결과로서 로그를 생성하지 않는다는 겁니다. 하지만 파일 시스템에 많은 로그 파일은 생성할 수 있습니다. 그런 경우 패턴에 따라 사용 사례가 다르므로, Sidecar Container 를 시작해 파일 시스템에서 파일을 수집해 클라우드워치 로그로 전송합니다.
사이드카 컨테이너의 역할
- 로그 수집 : 주 컨테이너에서 생성된 로그를 수집하고 중앙화된 로그 저장소로 전송합니다.
- 로그 처리 : 로그 데이터를 필터링, 변환 또는 풍부화(enrich)합니다.
- 모니터링 : 주 컨테이너의 성능을 모니터링하고 메트릭을 수집 합니다.
ECS에서 사이드카 컨테이너를 사용하여 로깅을 구현하는 방법은 다음과 같습니다.
- 로깅 컨테이너 이미지 준비 : 로그를 수집하고 전송할 수 있는 컨테이너 이미지를 준비합니다. 예를 들어, Fluentd 나 Logstash 와 같은 로그 수집 에이전트를 사용할 수 있습니다.
- Task 정의 설정 : ECS Task 정의에서 주 컨테이너와 로깅 사이드카 컨테이너를 함께 정의합니다. 이때 두 컨테이너 간에 볼륨을 공유하여 로그 파일에 접근할 수 있도록 설정합니다.
- 로그 전송 경로 설정 : 사이드카 컨테이너는 로그를 수집하여 Amazon CloudWatch Logs, Amazon S3, Elasticsearch 등 중앙 집중식 로그 저장소로 전송 합니다.
- ECS Task 실행 : Task 를 실행하면 주 컨테이너와 사이드카 컨테이너가 함께 시작됩니다. 주 컨테이너는 애플리케이션 로직을 실행하고 로그를 생성 하며, 사이드카 컨테이너는 이 로그를 수집하고 처리합니다.
장점
- 분리와 독립성 : 로그 수집 및 처리 기능이 애플리케이션 컨테이너와 분리되어 있어, 애플리케이션과 로그 처리 간의 독립성을 유지할 수 있습니다.
- 유연성과 확장성 : 다양한 로그 처리 방식과 저장소를 쉽게 통합하고 변경할 수 있습니다.
- 중앙 집중식 관리 : 모든 로그를 중앙에서 관리하고 분석할 수 있어 효율적인 로그 관리가 가능합니다.
