Firma uruchamia trójwarstwową aplikację internetową w chmurze AWS, która działa w trzech strefach dostępności. Architektura aplikacji obejmuje Application Load Balancer, serwer WWW Amazon EC2, który przechowuje stany sesji użytkowników, oraz bazę danych MySQL działającą na instancji EC2. Firma przewiduje nagłe wzrosty ruchu w aplikacji. Firma chce mieć możliwość skalowania w celu zaspokojenia przyszłych wymagań dotyczących pojemności aplikacji oraz zapewnienia wysokiej dostępności we wszystkich trzech strefach dostępności. Które rozwiązanie spełni te wymagania?

Prawidłowa odpowiedź zapewnia wysoką dostępność i skalowalność. Migracja bazy danych MySQL do Amazon RDS for MySQL z wdrożeniem Multi-AZ DB Cluster gwarantuje automatyczne przełączanie awaryjne i replikację danych w wielu strefach dostępności. Użycie Amazon ElastiCache for Redis z wysoką dostępnością do przechowywania danych sesji i buforowania odczytów odciąża serwery WWW i zapewnia szybki dostęp do danych sesji, co jest kluczowe dla bezstanowych aplikacji internetowych. Migracja serwera WWW do grupy Auto Scaling obejmującej trzy strefy dostępności umożliwia automatyczne skalowanie w górę i w dół w zależności od zapotrzebowania, a także zapewnia odporność na awarie strefy dostępności. Nieprawidłowe opcje: ElastiCache for Memcached nie obsługuje trwałości danych ani złożonych struktur danych tak dobrze jak Redis, co czyni go mniej odpowiednim do przechowywania danych sesji, które mogą wymagać większej elastyczności. DynamoDB jest bazą danych NoSQL, a migracja z MySQL do DynamoDB wymagałaby znaczących zmian w architekturze aplikacji, co nie jest optymalnym rozwiązaniem, jeśli wymagana jest baza relacyjna. DAX jest przeznaczony dla DynamoDB, nie dla MySQL. Pojedyncza strefa dostępności w RDS for MySQL nie zapewnia wysokiej dostępności i odporności na awarie strefy dostępności, co jest niezgodne z wymaganiami.