성장 중인 음식 배달 회사에 두 개의 Amazon EC2 인스턴스 Auto Scaling 그룹이 있습니다. 한 그룹은 주문을 수집하고(빠르게), 다른 그룹은 주문을 처리합니다(처리 시간이 더 김). 스케일링 이벤트 중에는 데이터가 손실되어서는 안 됩니다. 이 솔루션은 피크 시간 동안 두 프로세스가 모두 적절하게 확장되고 AWS 리소스 사용을 최적화할 수 있도록 해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족할까요?

정답은 Amazon SQS 대기열을 사용하여 주문 수집 및 처리를 분리하고, 인스턴스당 백로그 지표를 기반으로 Auto Scaling 그룹을 확장하는 것입니다. SQS는 두 프로세스 간의 결합도를 낮추고, 스케일링 이벤트 중 데이터 손실을 방지하며, 비동기 처리를 통해 처리 시간이 긴 주문 처리 프로세스의 안정성을 높입니다. 인스턴스당 백로그 지표는 각 인스턴스가 처리해야 할 작업량을 정확하게 반영하므로, 이를 기반으로 Auto Scaling을 구성하면 리소스 사용을 최적화하면서 피크 워크로드에 효과적으로 대응할 수 있습니다. 오답 해설: CPU 모니터링 및 최소 용량 구성: CPU 사용률은 워크로드의 직접적인 지표가 아닐 수 있으며, 특히 처리 시간이 긴 작업의 경우 CPU가 낮아도 백로그가 쌓일 수 있습니다. 최소 용량만으로는 피크 워크로드에 유연하게 대응하기 어렵습니다. CloudWatch 경보를 통해 추가 Auto Scaling 그룹 생성: 새로운 Auto Scaling 그룹을 동적으로 생성하는 것은 복잡하고 비효율적이며, 기존 그룹의 스케일링 정책을 활용하는 것이 더 적절합니다. SQS 대기열 알림 기반 Auto Scaling: SQS 대기열 알림은 메시지 도착을 알리지만, 인스턴스당 처리해야 할 실제 백로그를 정확히 반영하지 못하여 효율적인 스케일링이 어려울 수 있습니다.