Firma tworzy prototyp witryny e-commerce na AWS. Witryna składa się z Application Load Balancer, grupy Auto Scaling instancji Amazon EC2 dla serwerów WWW oraz instancji Amazon RDS for MySQL DB działającej w konfiguracji Single-AZ. Witryna wolno odpowiada podczas wyszukiwania w katalogu produktów. Katalog produktów to grupa tabel w bazie danych MySQL, które firma rzadko aktualizuje. Architekt rozwiązań ustalił, że wykorzystanie procesora na instancji DB jest wysokie podczas wyszukiwania w katalogu produktów. Co powinien zalecić architekt rozwiązań, aby poprawić wydajność witryny podczas wyszukiwania w katalogu produktów?

Wdrożenie klastra Amazon ElastiCache for Redis do buforowania katalogu produktów jest najlepszym rozwiązaniem. Ponieważ katalog produktów jest rzadko aktualizowany, buforowanie go w ElastiCache znacznie zmniejszy obciążenie bazy danych RDS, przenosząc operacje odczytu do szybkiej pamięci podręcznej. Leniwe ładowanie (lazy loading) efektywnie wypełni pamięć podręczną tylko wtedy, gdy dane są potrzebne, optymalizując wykorzystanie zasobów. Migracja do Amazon Redshift jest nieodpowiednia, ponieważ Redshift jest hurtownią danych analitycznych, a nie bazą danych do obsługi transakcji online (OLTP) dla katalogu produktów. Dodanie polityki skalowania do grupy Auto Scaling dla instancji EC2 nie rozwiąże problemu wysokiego zużycia procesora w bazie danych. Włączenie Multi-AZ dla instancji DB poprawia dostępność i odporność na awarie, ale nie skaluje wydajności odczytu ani nie zmniejsza obciążenia procesora w bazie danych. Ograniczanie zapytań tylko pogorszy doświadczenie użytkownika.