Firma hostuje aplikację internetową na RDS for MySQL z podstawową instancją DB i pięcioma replikami do odczytu. Opóźnienie replik nie może przekraczać 1 sekundy w stosunku do instancji podstawowej. Baza danych uruchamia zaplanowane procedury składowane, a repliki doświadczają większego opóźnienia podczas szczytowego obciążenia. Architekt rozwiązań musi zredukować opóźnienie replikacji w jak największym stopniu, minimalizując jednocześnie zmiany w kodzie aplikacji i bieżące koszty operacyjne. Które rozwiązanie spełnia te wymagania?

Prawidłowa odpowiedź to migracja do Amazon Aurora MySQL. Aurora jest zoptymalizowana pod kątem wysokiej wydajności i niskich opóźnień replikacji, często poniżej 100 ms, co spełnia wymaganie 1 sekundy. Repliki Aurora są logicznymi widokami tego samego woluminu danych, co eliminuje opóźnienia związane z fizyczną replikacją danych. Aurora Auto Scaling automatycznie dostosowuje liczbę replik, zapewniając wydajność podczas szczytowego obciążenia. Zastąpienie procedur składowanych natywnymi funkcjami Aurora MySQL jest minimalną zmianą, ponieważ Aurora jest kompatybilna z MySQL. Wdrożenie ElastiCache wymagałoby znacznych zmian w kodzie aplikacji i nie rozwiązałoby problemu opóźnień replikacji dla danych, które nie są buforowane. Migracja do MySQL na EC2 zwiększyłaby koszty operacyjne i złożoność zarządzania, a także nie gwarantowałaby niskich opóźnień replikacji bez zaawansowanej konfiguracji. Migracja do DynamoDB wymagałaby całkowitego przeprojektowania aplikacji i bazy danych ze względu na różnice w modelu danych, co jest niezgodne z minimalizacją zmian w kodzie.