Компания электронной коммерции запускает свое приложение на AWS. Приложение использует кластер Amazon Aurora PostgreSQL в режиме Multi-AZ для базы данных. Во время недавней рекламной кампании приложение столкнулось с высокой нагрузкой на чтение и запись. Пользователи столкнулись с проблемами тайм-аута при доступе к приложению. Архитектору решений необходимо сделать архитектуру приложения более масштабируемой и высокодоступной с МИНИМАЛЬНЫМ временем простоя. Какое решение удовлетворит этим требованиям?

Приложение столкнулось с высокой нагрузкой на чтение и запись, что привело к тайм-аутам. Добавление дополнительных экземпляров чтения в кластер Aurora распределяет нагрузку на чтение, повышая масштабируемость и доступность для операций чтения. Amazon RDS Proxy обеспечивает высокую доступность и масштабируемость для операций записи, управляя пулом соединений и автоматически переключаясь на резервный экземпляр базы данных в случае сбоя, что минимизирует время простоя. Неправильные варианты: EventBridge и Lambda для мониторинга состояния кластера не решают проблему масштабируемости и высокой нагрузки. Zero-downtime restart (ZDR) и Database Activity Streams не предназначены для масштабирования нагрузки на чтение/запись, а ZDR в основном для обновлений. ElastiCache for Redis с AWS DMS для репликации данных из Aurora в Redis усложняет архитектуру и не является оптимальным решением для масштабирования транзакционной базы данных Aurora PostgreSQL с минимальным временем простоя, особенно для операций записи.