Amazon ECS 용량 및 가용성 최적화 - Amazon Elastic Container Service
규모 조정 속도 극대화수요 충격 처리

Amazon ECS 용량 및 가용성 최적화

애플리케이션 가용성은 오류 없는 환경을 제공하고 애플리케이션 지연 시간을 최소화하는 데 매우 중요합니다. 가용성은 수요를 충족할 수 있는 충분한 용량의 사용 가능한 리소스를 확보하는 데 달려 있습니다. AWS는 가용성을 관리하기 위한 몇 가지 메커니즘을 제공합니다. Amazon ECS에서 호스팅되는 애플리케이션의 경우 Auto Scaling 및 가용 영역이 포함됩니다. Auto Scaling은 정의한 지표를 기반으로 태스크 또는 인스턴스 수를 관리하는 반면, 가용 영역을 사용하면 격리되어 있지만 지리적으로 가까운 위치에서 애플리케이션을 호스팅할 수 있습니다.

태스크 크기와 마찬가지로 용량과 가용성에는 반드시 고려해야 할 몇 가지 단점이 있습니다. 이상적으로는 용량이 수요에 완벽하게 일치하는 것이 좋습니다. 낮은 지연 시간과 오류율 등 서비스 수준 목표(SLO)를 충족하기 위해 요청을 처리하고 작업을 처리할 수 있는 충분한 용량을 언제나 확보할 수 있습니다. 용량이 너무 높아서 과도한 비용이 발생하거나, 너무 낮아서 지연 시간과 오류율이 높아져서는 안 됩니다.

Auto Scaling은 잠재적인 프로세스입니다. 먼저 실시간 지표를 CloudWatch에 전달해야 합니다. 그런 다음 분석을 위해 집계해야 하며 지표의 세분성에 따라 최대 몇 분이 걸릴 수 있습니다. CloudWatch는 지표를 경보 임계값과 비교하여 리소스 부족 또는 초과를 식별합니다. 불안정성을 방지하려면 설정된 임계값을 넘은 후 몇 분 후에 경보가 울리도록 구성하세요. 또한 새 태스크를 프로비저닝하고 더 이상 필요하지 않은 태스크를 종료하는 데에도 시간이 걸립니다.

설명한 시스템의 이러한 잠재적인 지연으로 인해 오버프로비저닝을 통해 여유 공간을 유지하는 것이 중요합니다. 이는 단기적으로 급증하는 수요를 수용하는 데 도움이 될 수 있습니다. 또한 애플리케이션이 포화 상태에 도달하지 않고 추가 요청을 처리하는 데 도움이 됩니다. 일반적으로 규모 조정 목표치를 사용률의 60~80% 사이로 설정하는 것을 권장합니다. 이렇게 하면 여전히 추가 용량을 프로비저닝하는 동안 애플리케이션이 급증하는 추가 수요를 더 잘 처리할 수 있습니다.

오버프로비저닝을 권장하는 또 다른 이유는 가용 영역 장애에 신속하게 대응하기 위해서입니다. 프로덕션 워크로드를 여러 가용 영역에서 제공할 것을 권장합니다. 이는 가용 영역 장애가 발생하더라도 나머지 가용 영역에서 실행 중인 태스크가 계속해서 수요를 충족할 수 있기 때문입니다. 애플리케이션이 두 개의 가용 영역에서 실행되는 경우 일반 태스크 수를 두 배로 늘려야 합니다. 이는 잠재적인 장애 발생 시 즉시 용량을 제공할 수 있도록 하기 위한 것입니다. 애플리케이션이 3개의 가용 영역에서 실행되는 경우 일반 태스크 수의 1.5배를 실행하는 것이 좋습니다. 즉, 일반적인 제공에 필요한 태스크 2개당 3개의 태스크를 실행합니다.

규모 조정 속도 극대화

Auto Scaling은 적용되는 데 시간이 걸리는 반응형 프로세스입니다. 그러나 스케일 아웃하는 데 필요한 시간을 최소화하는 데 도움이 되는 몇 가지 방법이 있습니다.

이미지 크기를 최소화하세요. 이미지가 클수록 이미지 저장소에서 다운로드하고 압축을 푸는 데 시간이 오래 걸립니다. 따라서 이미지 크기를 더 작게 유지하면 컨테이너를 시작하는 데 필요한 시간이 줄어듭니다. 이미지 크기를 줄이려면 다음 구체적인 권장 사항을 따르세요.

  • 정적 바이너리를 빌드하거나 Golang을 사용할 수 있는 경우 이미지 FROM 스크래치를 빌드하고 결과 이미지에 바이너리 애플리케이션만 포함하세요.

  • Amazon Linux 또는 Ubuntu와 같은 업스트림 배포판 공급업체의 최소화된 기본 이미지를 사용하세요.

  • 최종 이미지에 빌드 아티팩트를 포함하지 마세요. 다단계 빌드를 사용하는 것이 도움이 될 수 있습니다.

  • 가능하다면 RUN 단계를 간소화합니다. 각 RUN 단계는 새 이미지 레이어를 생성하므로 레이어를 다운로드하는 데 추가 왕복 시간이 소요됩니다. 여러 명령이 &&로 결합된 단일 RUN 단계는 여러 RUN 단계가 있는 경우보다 레이어 수가 적습니다.

  • ML 추론 데이터와 같은 데이터를 최종 이미지에 포함하려면 시작하고 트래픽 제공을 시작하는 데 필요한 데이터만 포함하세요. 서비스에 영향을 주지 않고 Amazon S3 또는 기타 스토리지에서 온디맨드 방식으로 데이터를 가져오는 경우 해당 위치에 데이터를 저장하세요.

이미지를 가까이 두세요. 네트워크 지연 시간이 길수록 이미지를 다운로드하는 데 시간이 더 오래 걸립니다. 워크로드가 있는 것과 동일한 리전의 리포지토리에 이미지를 호스팅하세요. Amazon ECR은 Amazon ECS를 사용할 수 있는 모든 리전에서 사용할 수 있는 고성능 이미지 리포지토리입니다. 컨테이너 이미지를 다운로드하기 위해 인터넷이나 VPN 링크를 거치지 마세요. 동일한 리전에서 이미지를 호스팅하면 전반적인 신뢰성이 향상됩니다. 다른 리전의 네트워크 연결 문제 및 가용성 문제의 위험을 완화합니다. 또는 Amazon ECR 리전 간 복제를 구현하여 이를 지원할 수도 있습니다.

로드 밸런서 상태 확인 임계값을 줄입니다. 로드 밸런서는 애플리케이션에 트래픽을 보내기 전에 상태 확인을 수행합니다. 대상 그룹에 대한 기본 상태 확인 구성은 90초 이상 걸릴 수 있습니다. 이 과정에서 로드 밸런서는 상태를 확인하고 요청을 수신합니다. 상태 확인 간격과 임계값 수를 낮추면 애플리케이션이 트래픽을 더 빠르게 수용하고 다른 태스크에 대한 로드를 줄일 수 있습니다.

콜드 스타트 성능을 고려하세요. Java와 같은 일부 애플리케이션은 JIT(Just-In-Time) 컴파일을 수행하는 런타임을 사용합니다. 컴파일 프로세스가 시작될 때 애플리케이션 성능을 확인할 수 있습니다. 해결 방법은 워크로드에서 지연 시간이 중요한 부분을 콜드 스타트 성능 저하를 부과하지 않는 언어로 다시 작성하는 것입니다.

타겟 추적 규모 조정 정책이 아닌 단계 규모 조정 정책을 사용하세요. 태스크를 위한 여러 Application Auto Scaling 옵션이 있습니다. 대상 추적이 가장 사용하기 쉬운 모드입니다. 이 옵션을 사용하는 경우 CPU 평균 사용률과 같은 지표의 목표 값을 설정하기만 하면 됩니다. 그러면 자동 스케일러가 해당 값을 달성하는 데 필요한 작업 수를 자동으로 관리합니다. 단계 조정을 사용하면 조정 지표의 특정 임계값과 임계값을 초과했을 때 추가 또는 제거할 작업 수를 정의하므로 수요 변화에 더 빠르게 대응할 수 있습니다. 더욱이 임계값 경보를 위반하는 시간을 최소화하여 수요 변화에 매우 빠르게 대응할 수 있습니다. 자세한 내용은 서비스 Auto Scaling을 참조하세요.

클러스터 용량을 제공하기 위해 Amazon EC2 인스턴스를 사용하는 경우 다음 권장 사항을 고려하세요.

더 큰 Amazon EC2 인스턴스와 더 빠른 Amazon EBS 볼륨을 사용하세요. 더 큰 Amazon EC2 인스턴스와 더 빠른 Amazon EBS 볼륨을 사용하면 이미지 다운로드 및 준비 속도를 향상할 수 있습니다. 주어진 인스턴스 패밀리 내에서 네트워크 및 Amazon EBS 최대 처리량은 인스턴스 크기가 증가함에 따라 증가합니다(예: m5.xlarge에서 m5.2xlarge로). 또한 Amazon EBS 볼륨을 사용자 지정하여 처리량과 IOPS를 늘릴 수도 있습니다. 예를 들어 gp2 볼륨을 사용하는 경우 기준 처리량을 더 많이 제공하는 더 큰 볼륨을 사용하세요. gp3 볼륨을 사용하는 경우 볼륨을 생성할 때 처리량과 IOPS를 지정하세요.

Amazon EC2 인스턴스에서 실행되는 태스크에는 브리지 네트워크 모드를 사용하세요. Amazon EC2에서 bridge 네트워크 모드를 사용하는 태스크는 awsvpc 네트워크 모드를 사용하는 태스크보다 빠르게 시작됩니다. awsvpc 네트워크 모드를 사용하는 경우 Amazon ECS는 작업을 시작하기 전에 탄력적 네트워크 인터페이스(ENI)를 인스턴스에 연결합니다. 이로 인해 지연 시간이 추가됩니다. 그러나 브리지 네트워킹을 사용하는 데에는 몇 가지 상충 관계가 있습니다. 이러한 태스크에는 자체 보안 그룹이 없으며 로드 밸런싱에 몇 가지 영향이 있습니다. 자세한 내용은 탄력적 로드 밸런싱 사용 설명서의 로드 밸런서 대상 그룹을 참조하세요.

수요 충격 처리

일부 애플리케이션은 갑자기 큰 수요 충격을 받기도 합니다. 이는 뉴스 이벤트, 대규모 세일, 미디어 이벤트, 입소문을 타고 매우 짧은 시간 내에 트래픽이 빠르고 크게 증가하는 기타 이벤트 등 다양한 이유로 발생합니다. 계획하지 않으면 수요가 가용 리소스를 빠르게 초과할 수 있습니다.

수요 충격을 처리하는 가장 좋은 방법은 수요 충격을 예상하고 그에 따라 계획을 세우는 것입니다. Auto Scaling에는 시간이 걸릴 수 있으므로 수요 충격이 시작되기 전에 애플리케이션을 스케일 아웃하는 것이 좋습니다. 최상의 결과를 얻으려면 공유 캘린더를 사용하는 팀 간의 긴밀한 협업을 포함하는 비즈니스 계획을 세우는 것이 좋습니다. 이벤트를 기획하는 팀은 사전에 애플리케이션 담당 팀과 긴밀하게 협력해야 합니다. 이를 통해 해당 팀은 명확한 일정 계획을 세울 수 있는 충분한 시간을 확보할 수 있습니다. 이벤트 전에 용량을 스케일 아웃하고 이벤트 후에 용량을 스케일 인하도록 예약할 수 있습니다. 자세한 내용은 Application Auto Scaling 사용 설명서의 예약된 조정을 참조하세요.

Enterprise Support 플랜을 사용하는 경우에는 기술 계정 관리자(TAM)와도 협력하세요. TAM은 서비스 할당량을 확인하고 이벤트가 시작되기 전에 필요한 할당량을 늘리도록 할 수 있습니다. 이렇게 하면 실수로 서비스 할당량을 초과하지 않습니다. 또한 로드 밸런서와 같은 서비스를 미리 준비하여 이벤트가 원활하게 진행될 수 있도록 지원할 수 있습니다.

예상하지 못한 수요 충격을 처리하는 것은 더 어려운 문제입니다. 예상하지 못한 충격의 진폭이 충분히 크면 수요가 빠르게 용량을 초과할 수 있습니다. 또한 Auto Scaling이 반응하는 기능을 능가할 수도 있습니다. 예상하지 못한 충격에 대비하는 가장 좋은 방법은 리소스를 오버프로비저닝하는 것입니다. 언제든지 예상되는 최대 트래픽 수요를 처리할 수 있는 충분한 리소스를 확보해야 합니다.

예상하지 못한 수요 충격에 대비해 최대 용량을 유지하는 것은 비용이 많이 들 수 있습니다. 비용 영향을 완화하려면 대규모 수요 충격이 임박했음을 예측할 수 있는 선행 지표나 이벤트를 찾아보세요. 지표 또는 이벤트가 중요한 사전 알림을 안정적으로 제공하는 경우 이벤트가 발생하거나 지표가 설정한 특정 임계값을 초과하는 즉시 스케일 아웃 프로세스를 시작합니다.

애플리케이션이 예상하지 못한 갑작스러운 수요 충격을 받기 쉬운 경우에는 중요하지 않은 기능을 희생하면서도 고객을 위해 중요한 기능은 유지하는 고성능 모드를 애플리케이션에 추가하는 것을 고려하세요. 예를 들어 애플리케이션이 비용이 많이 드는 사용자 지정 응답 생성에서 정적 응답 페이지 제공으로 전환할 수 있다고 가정합니다. 이 시나리오에서는 애플리케이션의 규모를 전혀 조정하지 않고도 처리량을 크게 늘릴 수 있습니다.

수요 충격에 더 잘 대처하기 위해 모놀리식 서비스를 분리하는 것을 고려할 수 있습니다. 애플리케이션이 실행 비용이 많이 들고 규모 조정 속도가 느린 모놀리식 서비스인 경우 성능에 중요한 부분을 추출하거나 재작성하여 별도의 서비스로 실행할 수 있습니다. 그러면 이러한 새로운 서비스는 덜 중요한 구성 요소와 독립적으로 규모를 조정할 수 있습니다. 애플리케이션의 다른 부분과 별도로 성능에 중요한 기능을 유연하게 스케일 아웃할 수 있으면 용량을 추가하는 데 걸리는 시간을 줄이고 비용을 절약할 수 있습니다.