AWS 기술 블로그

다양한 AWS 네이티브 서비스를 사용하여 Amazon ECS를 스케일링하기

본 게시물은 AWS Container Blog에 게시된 “Scale your Amazon ECS using different AWS native services!” by by Arun Chandapillai and Shak Kathir을 한국어 번역 및 편집하였습니다.

컨테이너는 애플리케이션 개발을 가속화하고 환경 전반에 걸쳐 배포 일관성을 향상시켜, 조직이 생산성과 민첩성을 향상시킬 수 있게 해줍니다. Amazon Elastic Container Service (Amazon ECS)와 같은 AWS 컨테이너 서비스는 애플리케이션 관리를 용이하게 하여 혁신과 비즈니스 요구에 집중할 수 있도록 해줍니다.

고객 경험은 조직이 애플리케이션 성능을 측정하는 가장 중요한 기준입니다. 다양한 요청 패턴을 맞닥뜨린 상황에서 신뢰할 수 있고 일관된 최종 사용자 경험을 유지하는 것은 모든 조직이 직면하는 도전입니다. 모범 사례로, Amazon ECS 서비스의 원하는 작업 (Task) 수를 자동으로 증가(스케일 아웃) 또는 감소(스케일 인)시키는 오토 스케일링을 사용할 수 있습니다. 이는 트래픽 급증에 실시간으로 수동으로 대응할 필요를 없애줍니다. 오토 스케일링은 AWS 서비스를 사용할 때 사용량과 비용 효율성을 최적화하여 실제로 필요한 자원에 대해서만 비용을 지불하게 해줍니다.

AWS는 Amazon ECS 서비스의 오토 스케일링을 위해 활용할 수 있는 여러 기능을 제공합니다. 올바른 옵션을 사용하면 애플리케이션의 전반적인 신뢰성을 향상시키고, 운영 비용과 복잡성을 줄이며, 최종 사용자 경험을 향상시킬 수 있습니다. 이 글에서는 AWS Application Auto Scaling을 통해 Amazon ECS 서비스의 오토 스케일링을 구성하는 방법을 배웁니다. 또한, 애플리케이션 오토 스케일링에 사용될 수 있는 Amazon ECS Service ConnectAWS Distro for OpenTelemetry (ADOT)의 사용 방법도 배웁니다.

Application Auto Scaling

서비스 오토 스케일링을 사용하면 Amazon ECS 서비스에서 원하는 작업 수를 자동으로 증가시키거나 감소시킬 수 있습니다. Amazon ECS는 이 기능을 제공하기 위해 Application Auto Scaling 서비스를 활용합니다. 기본적으로 Amazon ECS는 CPU 및 메모리 사용량을 Amazon CloudWatch에 게시합니다. 이러한 메트릭 또는 다른 사용자 정의 CloudWatch 메트릭을 사용하여 서비스를 스케일링할 수 있습니다. Amazon ECS 서비스 오토 스케일링은 다음 유형의 오토 스케일링을 지원합니다.

  • 대상 추적 조정 정책 – 특정 메트릭에 대한 대상 값에 기반하여 서비스가 실행하는 작업 수를 증가시키거나 감소시킬 수 있습니다. 예를 들어, CPU 사용량이 임계치인 75%를 초과하면 서비스에 더 많은 작업을 추가하고, CPU 사용량이 임계치인 75% 미만으로 떨어지면 서비스에서 작업을 제거하는 스케일링 정책을 정의할 수 있습니다. 경우에 따라, 서비스된 요청 수 또는 다른 AWS 서비스에서 게시한 메트릭과 같은 애플리케이션 특정 메트릭을 기반으로 스케일링하고 싶을 수 있습니다. 이 경우, 대상 추적 조정 정책과 함께 사용되는 메트릭을 사용자 정의하기 위해 산술 연산과 수학적 함수를 사용할 수 있습니다. 사용자 정의 메트릭을 기반으로 한 자동 스케일링에 대해 자세히 알아보려면 이 글을 참조하세요. 다음 스크린샷은 샘플의 대상 추적 조정 정책을 보여줍니다.
  • 단계별 조정 정책 – 경보 위반 규모에 따라 변하는 일련의 스케일 조정, 즉 단계 조정을 기반으로 서비스가 실행하는 작업 수를 증가시키거나 감소시킬 수 있습니다. 단계별 조정 정책을 사용하여, 메트릭 임계값과 추가 또는 제거할 리소스의 양을 선택할 수 있습니다. 예를 들어, CPU 사용량이 50%에서 75% 사이인 경우 서비스를 두 개의 작업으로 스케일 아웃하고, CPU 사용량이 25% 아래로 떨어지면 서비스를 두 개의 작업으로 스케일 인할 수 있는 스케일링 정책을 정의할 수 있습니다. 다음 스크린샷은 샘플의 단계별 스케일링 정책을 보여줍니다.
  • 예약된 조정 – 날짜와 시간을 기준으로 서비스에서 실행되는 작업 수를 늘리거나 줄일 수 있습니다. 예를 들어, 트래픽이 많은 시간에는 서비스에서 실행되는 작업 수를 늘리고 사용량이 적은 시간에는 작업 수를 줄이도록 일정을 설정할 수 있습니다. 예약된 스케일링과 스케일링 정책을 함께 사용하여 스케일링에 대한 사전 예방적 및 사후 대응적 접근 방식의 이점을 얻을 수 있으며, AWS Command Line Interface (AWS CLI)를 사용하여 스케일링 스케일링을 구성할 수 있습니다. 예약된 스케일링 작업이 실행된 후에도 스케일링 정책은 용량을 추가로 확장할지 여부를 계속 결정할 수 있습니다. 이를 통해 애플리케이션의 부하를 처리할 수 있는 충분한 용량을 확보할 수 있습니다.

서비스 오토 스케일링은 Amazon ECS 서비스를 확장하는 가장 쉬운 방법이며, AWS Management Console, AWS CLI 및 AWS SDK를 사용하여 확장을 구성할 수 있습니다.

스케일링 정책은 스케일링이 적용될 때까지 대기하는 시간(초)인 쿨다운 기간을 지원합니다. 스케일 아웃 이벤트 중에는 작업이 지속적으로 증가하는 반면, 스케일 인 이벤트 중에는 작업이 보수적으로 감소합니다. 애플리케이션의 가용성을 보호하기 위해 스케일인 활동은 쿨다운 기간이 만료될 때까지 차단됩니다.

다음 다이어그램은 대상 추적 스케일링 정책의 예시를 보여줍니다.

Application Auto Scaling 비용

이 기능을 사용하는 데 추가 요금은 없습니다. 애플리케이션을 저장하고 실행하기 위해 생성하는 AWS 리소스에 대한 비용을 지불합니다. 사용한 만큼만 비용을 지불하면 되며, 최소 요금은 없습니다.

Amazon ECS Service Connect

Amazon ECS Service Connect는 애플리케이션 코드를 변경하지 않고도 서비스 간 원활한 연결과 풍부한 트래픽 원격 분석 기능을 제공합니다. 이는 Amazon ECS에서 Service Discovery과 Service Mesh를 모두 구축하여 수행됩니다. Service Connect 구성을 사용할 때, Amazon ECS는 새 작업이 시작될 때마다 사이드카 프록시 컨테이너를 자동으로 주입합니다. Amazon ECS가 이 구성을 관리합니다.

짧은 지연 시간 요구 사항이 있고 새 클라이언트 수, 인바운드 요청 수, 오류율 또는 실패한 TLS 연결 수와 같은 메트릭을 모니터링해야 하는 경우 ECS Service Connect를 구성하는 것이 좋습니다. ECS Service Connect는 트래픽 라우팅 및 관리를 위해 중앙 집중식 서비스 메시 아키텍처를 사용합니다. Amazon ECS Service Connect에서 생성된 트래픽 통합 가시성 메트릭은 Amazon ECS 콘솔에서 직접 볼 수 있으며, 이러한 메트릭은 CloudWatch에도 전송됩니다. CloudWatch에서 이러한 메트릭을 사용할 수 있게 되면, 이를 사용하여 Amazon ECS 서비스 작업의 오토 스케일링을 구성할 수 있습니다.

다음은 Amazon ECS Service Connect를 통해 제공되는 가장 일반적으로 사용되는 메트릭이며, 전체 목록은 다음과 같습니다.

ActiveConnectionCount The total number of concurrent connections active from clients
NewConnectionCount The total number of new connections established from clients
TargetResponseTime The latency of the application request processing
ClientTLSNegotiationErrorCount The total number of times the TLS connection failed
HTTPCode_Target_5XX_Count The number of HTTP response codes with numbers 500 to 599

ECS Service Connect를 사용하면 AWS Cloud Map에서 제공하는 네임스페이스를 사용하여 논리적 이름으로 서비스를 참조하고 연결할 수 있으며 로드 밸런서를 배포 및 구성하지 않고도 Amazon ECS 작업 간에 트래픽을 자동으로 분산할 수 있습니다. 또한 Amazon ECS 콘솔은 운영 편의성과 간소화된 디버깅을 위해 실시간 네트워크 트래픽 메트릭이 포함된 사용하기 쉬운 대시보드를 제공합니다. 다음 다이어그램은 ECS Service Connect를 사용한 요청의 수명 주기 및 CloudWatch에 메트릭이 게시되는 방법을 보여줍니다.

다음 스크린샷은 Service Connect에서 측정한 트래픽의 스냅샷을 제공하는 트래픽 상태 보기를 보여줍니다. 이 보기에는 서비스 내의 모든 작업에 대해 Service Connect를 통한 활성 연결 수와 완료된 연결의 HTTP 상태가 표시됩니다. ECS Service Connect는 인프라 프로비저닝, 코드 배포 및 서비스 모니터링을 위해 AWS CloudFormation, AWS Cloud Development Kit (AWS CDK), AWS Copilot, 그리고 AWS Proton에서 완벽하게 지원됩니다.

Amazon ECS Service Connect 비용

ECS Service Connect에서 생성된 서비스 검색, 연결 기능 또는 트래픽 원격 분석에 대한 추가 요금은 없습니다. ECS Service Connect agent가 소비하는 리소스에 대한 비용만 지불하면 됩니다. Service Connect 컨테이너를 위한 작업에 256개의 CPU 유닛과 64MB의 메모리를 추가하는 것이 좋습니다. 이는 별도로 구성하는 것이 아니라 작업 할당을 수행할 때 고려됩니다. 유휴 상태에서 Service Connect 에이전트는 약 100개의 CPU 유닛과 40MB의 메모리를 사용하는 것으로 관찰됩니다.

ADOT

The OpenTelemetry (OTEL) 수집기에는 CloudWatch와 같은 다양한 데이터 소스로 데이터를 내보내기 위한 구성 요소가 포함되어 있습니다. AWS Distro for OpenTelemetry Collector (ADOT Collector)는 AWS에서 배포 및 지원하는 업스트림 OTEL 수집기의 AWS 지원 버전입니다. 이 구성 요소를 사용하면 CloudWatch 및 기타 지원되는 모니터링 솔루션으로 텔레메트리 데이터를 전송할 수 있습니다.

ADOT를 사용하여 Amazon ECS에서 통합 가시성을 활성화하는 것은 두 단계로 구성됩니다:

  1. 애플리케이션 계측 – 하나 이상의 모니터링 솔루션에 상호 연관된 로그, 메트릭 및 추적을 전송합니다. 코드를 변경하지 않고도 프로그래밍 언어 기반 에이전트로 앱을 활성화하여 자동 계측을 사용할 수 있습니다.
  2. 다음 두 가지 방법 중 하나를 사용하여 ADOT Collector를 배포합니다:
    1. 사이드카 패턴
    2. Amazon ECS 서비스 패턴

ADOT 수집기는 ECS 메타데이터 엔드포인트를 스크랩하고 컨테이너 메트릭(예: CPU, 메모리, 네트워크, 디스크)을 수집합니다. ADOT를 CloudWatch와 통합하면 CloudWatch 콘솔에서 직접 이러한 메트릭을 수집, 분석 및 시각화할 수 있습니다. 다음 다이어그램은 애플리케이션을 계측하는 데 ADOT SDK를 사용하는 방법, ADOT 수집기가 메트릭을 스크랩하는 방법, CloudWatch EMF exporter가 이러한 메트릭을 CloudWatch로 전송하는 방법에 대한 개략적인 흐름도를 보여줍니다.

ADOT 수집기는 메트릭 수집을 활성화하는 기본 구성을 기본으로 제공합니다. 기본 구성은 메트릭 파이프라인에서 AWS EMF exporter (awsemfexporter)를 활성화합니다. 이 기능은 CloudWatch로 전송하기 전에 OTEL 메트릭을 CloudWatch EMF 일괄 로그로 변환합니다. 이제 CloudWatch 콘솔에서 로그를 쿼리하고, 대시보드를 통해 시각화하고, 메트릭 알람을 생성할 수 있습니다.

ECS 호스팅 애플리케이션이 CloudWatch로 전송할 수 있는 메트릭 유형을 사용자 지정할 수도 있습니다. 예를 들어, 다음과 같은 메트릭을 수집할 수 있습니다. ecs.task.memory.utilized, ecs.task.memory.reserved, ecs.task.cpu.utilized, ecs.task.cpu.reserved, ecs.task.network.rate.rx, ecs.task.network.rate.tx, ecs.task.storage.read.bytes, cs.task.storage.write.bytes

CloudWatch에서 이러한 메트릭을 사용할 수 있게 되면, 이를 사용하여 Amazon ECS 서비스 작업의 오토 스케일링을 구성할 수 있습니다.

ADOT 비용

AWS Distro for OpenTelemetry를 사용하는 데는 비용은 발생하지 않습니다. CloudWatch로 전송되는 트레이스, 로그 및 메트릭에 대한 비용만 지불하면 됩니다. CloudWatch를 사용하면 선불 약정이나 최소 요금이 없습니다. 사용한 만큼만 비용을 지불하면 됩니다. 자세한 내용은 CloudWatch 요금 페이지를 참조하세요.

Conclusion

이 게시물에서는 Amazon ECS 서비스를 확장하는 데 활용할 수 있는 기본 AWS 확장 옵션에 대해 알아보았습니다. 다양한 규모의 회사에서 이 접근 방식을 채택하여 안정적이고 일관된 최종 사용자 경험을 유지하기 위한 전략의 일부로 Amazon ECS 서비스를 스케일링할 수 있습니다. 올바른 메커니즘은 배포 민첩성, 선제적/대응적/예측적 확장, 가격 책정 등의 고려 사항에 따라 달라집니다.

자세한 내용은 AWS Well-Architected Framework, Best Practices for running your application with Amazon ECS, Security in Amazon Elastic Container Service을 참조하세요. 추가 지원이 필요하시면 AWS Support 팀 및 AWS 계정 팀에 문의하시기 바랍니다.

Jungseob Shin

Jungseob Shin

신정섭 Solutions Architect는 다양한 분야의 Backend 서버 개발 경험을 바탕으로 Startup 고객이 비즈니스 목표를 달성하도록 AWS 서비스의 효율적인 사용을 위한 아키텍처 설계 가이드와 기술을 지원하는 역할을 수행하고 있습니다. 컨테이너와 서버리스 기술에 관심이 많습니다.