Публичное розничное веб-приложение использует Application Load Balancer (ALB) перед инстансами EC2 в нескольких AZ и бэкенд Amazon RDS MySQL Multi-AZ. Проверки работоспособности целевой группы используют HTTP и указывают на страницу каталога товаров. Auto Scaling поддерживает веб-флот на основе проверок работоспособности ALB. Недавно приложение столкнулось с простоем; Auto Scaling неоднократно заменял инстансы, в то время как метрики веб-сервера выглядели нормально. Расследование показало, что база данных была сильно загружена, а запросы выполнялись очень медленно. Какие два изменения вместе решат проблему и улучшат мониторинг общей доступности и функциональности приложения для будущего роста? (Выберите два.)

Проблема заключалась в том, что проверки работоспособности ALB использовали страницу каталога товаров, которая зависела от перегруженной базы данных. Это приводило к ложным срабатываниям Auto Scaling, заменяющего здоровые инстансы. Изменение проверки работоспособности ALB на статическую HTML-страницу позволит Auto Scaling корректно управлять инстансами, не реагируя на проблемы с базой данных. Добавление проверки работоспособности Route 53 для страницы продукта обеспечит комплексный мониторинг доступности и функциональности приложения, включая зависимость от базы данных. Развертывание Amazon ElastiCache снизит нагрузку на базу данных RDS, кэшируя часто запрашиваемые данные, что улучшит производительность и масштабируемость приложения. Создание реплик для чтения RDS не решит проблему с проверками работоспособности ALB и не уменьшит нагрузку на основную базу данных для операций записи. Изменение проверки работоспособности ALB на TCP не проверяет работоспособность приложения на уровне HTTP. Оповещения CloudWatch для RDS не предотвращают проблему, а лишь уведомляют о ней.