한 회사에서 고객 주문을 처리하는 3계층 웹 애플리케이션을 운영하고 있습니다. 웹 계층은 Application Load Balancer 뒤의 Amazon EC2 인스턴스를 사용합니다. 처리 계층은 EC2 인스턴스를 사용합니다. 이 회사는 Amazon Simple Queue Service(Amazon SQS)를 사용하여 웹 계층과 처리 계층을 분리했습니다. 스토리지 계층은 Amazon DynamoDB입니다. 피크 시간 동안 일부 사용자는 주문 처리 지연을 보고합니다. 이러한 지연 동안 EC2 인스턴스는 CPU 사용률이 100%에 도달하고 SQS 큐가 백업됩니다. 피크는 가변적이고 예측할 수 없습니다. 이 회사는 애플리케이션 성능을 개선해야 합니다. 다음 중 어떤 솔루션이 이러한 요구 사항을 충족합니까?

정답은 처리 계층 인스턴스를 스케일 아웃하기 위해 Amazon EC2 Auto Scaling 대상 추적 정책을 사용하고, 스케일링 시점을 결정하는 데 ApproximateNumberOfMessages 속성을 사용하는 것입니다. 주문 처리 지연은 처리 계층의 인스턴스가 SQS 큐의 메시지를 제때 처리하지 못하여 발생하며, 이는 SQS 큐가 백업되고 EC2 CPU 사용률이 100%에 도달하는 것으로 나타납니다. SQS의 ApproximateNumberOfMessages는 큐에 있는 메시지 수를 나타내므로, 이 지표를 사용하여 Auto Scaling 대상 추적 정책을 구성하면 큐의 메시지 수가 증가할 때 처리 계층 인스턴스를 자동으로 스케일 아웃하여 처리량을 늘릴 수 있습니다. 피크가 가변적이고 예측할 수 없으므로, 대상 추적 정책은 동적이고 효율적인 스케일링을 제공합니다. 오답 설명: 예약된 스케일링은 피크가 예측 가능할 때 적합하지만, 문제에서는 피크가 가변적이고 예측할 수 없다고 명시되어 있어 부적합합니다. CPU Utilization 지표를 사용하는 것은 가능하지만, SQS 큐가 백업되는 근본적인 원인인 메시지 처리 지연을 직접적으로 해결하지 못할 수 있습니다. Amazon ElastiCache for Redis는 DynamoDB 앞의 캐싱 솔루션으로, 데이터베이스 읽기 성능을 향상시키지만, 현재 문제는 처리 계층의 병목 현상과 SQS 큐 백업에 있습니다. Amazon CloudFront는 웹 계층의 응답을 캐시하여 사용자에게 더 빠르게 콘텐츠를 제공하지만, 이는 처리 계층의 주문 처리 지연 문제와는 직접적인 관련이 없습니다.