한 회사에서 단순 스케일링 정책을 사용하는 Auto Scaling 그룹의 EC2 인스턴스 3개에서 실행되는 워커 애플리케이션으로 메시지를 처리합니다. 워커는 Amazon SQS 대기열에서 메시지를 폴링합니다. 메시지의 산발적인 급증으로 인해 처리 성능이 저하되고 있으며, SysOps 관리자는 더 높은 대기열 볼륨을 처리하기 위해 Auto Scaling 그룹을 확장해야 합니다. 다음 접근 방식 중 이 요구 사항을 가장 잘 충족하는 것은 무엇입니까?

정답은 SQS 대기열의 인스턴스당 보이는 메시지 수를 기반으로 대상 추적 스케일링 정책을 사용하는 것입니다. 이 방법은 Auto Scaling 그룹이 SQS 대기열의 현재 부하에 비례하여 확장되도록 하여 메시지 급증 시 처리량을 효과적으로 늘립니다. 가장 오래된 메시지 연령을 추정하는 것은 대기열 백로그를 나타낼 수 있지만, 인스턴스당 메시지 수만큼 직접적인 확장 지표는 아닙니다. Application Load Balancer(ALB)를 사용하고 ALBRequestCountPerTarget 지표를 사용하는 것은 워커 애플리케이션이 SQS에서 직접 메시지를 폴링하므로 적절하지 않습니다. 예약된 스케일링 정책은 예측 가능한 부하에 적합하지만, 메시지의 "산발적인 급증"과 같은 동적인 부하 변화에는 효과적이지 않습니다.