Amazon Aurora MySQL - tips & tricks - czyli najlpsze praktyki podczas konfiguracji

Aurora to w pełni zarządzany silnik relacyjnej bazy danych zgodny z MySQL. Istnieje jeszcze Amazon Aurora PostgreSQL, która jest zgodna z  PostgreSQL. MySQL i PostgreSQL łączą szybkość i niezawodność wysokiej klasy komercyjnych baz danych, z prostotą i opłacalnością baz danych typu open source. Przy niektórych obciążeniach, Aurora może zapewnić nawet pięciokrotnie większą wydajność niż MySQL i nawet trzykrotnie większą niż PostgreSQL, bez konieczności wprowadzania zmian w większości istniejących aplikacji.

Aurora korzysta z dystrybuowanej, odpornej na awarie i samoleczącej się przestrzeni dyskowej. Dysk podstawowy rośnie automatycznie w miarę potrzeb – nawet do 64 terabajtów. Aurora automatyzuje i standaryzuje tworzenie klastrów i replikację baz danych, które zazwyczaj należą do najtrudniejszych aspektów konfiguracji i administrowania bazami danych.

Do największych zalet Aurory należą:

• Wysoka wydajność – do 5 razy większa niż referencyjnego MySQL’a. Aurora korzysta z najbardziej zaawansowanych rozwiązań technologicznych, aby zapewnić, że silnik bazy danych jest w stanie w pełni wykorzystać dostępne możliwości obliczeniowe, pamięć i sieć.
• Automatyczne skalowanie przestrzeni dyskowej – usługa automatycznie zwiększy rozmiar woluminu bazy danych, w miarę wzrostu zapotrzebowania bazy na dane.
  
• Amazon Aurora Serverless to unikalna konfiguracja automatycznego skalowania na żądanie dla usługi Amazon Aurora. Podczas jej użycia baza danych zostanie automatycznie uruchomiona, zastopowana i zwiększy lub zmniejszy pojemność, w zależności od potrzeb aplikacji.
  
• Odporna na usterki i “samolecząca się” – jest odporna na błędy. W przejrzysty sposób obsługuje utratę do dwóch kopii danych, bez wpływu na dostępność zapisu w bazie danych i do trzech kopii, bez wpływu na dostępność odczytu.
  
• Wysoce bezpieczna – Aurora działa w VPC. Dzięki temu pozwala na izolowanie bazy danych we własnej sieci wirtualnej i łączenie się z lokalną infrastrukturą IT, przy użyciu standardowych, szyfrowanych połączeń VPN. Ponadto zintegrowana z AWS IAM, zapewnia możliwość kontrolowania działań grup i użytkowników. Umożliwia szyfrowanie danych za pomocą AWS KMS. Możesz także monitorować aktywność, wysyłając dzienniki kontroli do Amazon CloudWatch.
  
• Jest doskonałym wsparciem dla migracji – Amazon Aurora łączy bezpieczeństwo klasy korporacyjnej, wydajność, wysoką dostępność i trwałość, z niskim kosztem i łatwością obsługi MySQL. To sprawia, że jest to dobry cel migracji, podczas przenoszenia baz danych z drogich komercyjnych baz danych do AWS.
  
• Posiada  wbudowany mechanizm szyfrowania – umożliwia szyfrowanie baz danych za pomocą kluczy, które tworzy się i kontroluje za pomocą usługi zarządzania kluczami AWS (KMS). Zabezpieczone pozostają dane przechowywane w spoczynku, jak również snapshoty, kopie zapasowe i repliki, znajdujące się w tym samym klastrze. Amazon Aurora używa SSL (AES-256) do zabezpieczenia danych w tranzycie.
  
• Opłacalna – koszty kalkulowane są w oparciu o  stawkę godzinową, za każdą uruchomioną instancję. Wraz z zakończeniem jej używania, można ją łatwo usunąć. Szczegóły dostępne w  cenniku i dostępność usługi w poszczególnych regionach.
  

Ponieważ Amazon Aurora nie jest już tajemnicą, warto zgłębić wiedzę w zakresie najlepszych praktyk z nią związanych i jej konfiguracją.

Po pierwsze, warto pamiętać,  o grupach parametrów Aurora. Istnieją dwa typy grup parametrów Aurora MySQL: grupy parametrów DB i grupy parametrów klastra DB. Niektóre parametry wpływają na konfigurację całego klastra DB, np. format dziennika binarnego, strefa czasowa i ustawienia domyślne zestawu znaków. Inne ograniczają swój zasięg do pojedynczej instancji DB. Ważnym aspektem jest, jak parametry wpływają na zachowanie, stabilność i funkcjonalność klastra Aurora, a które wpływają na wydajność po jego zmodyfikowaniu. Należy pamiętać, że oba typy parametrów tworzone są ustawieniami domyślnymi, a niektóre parametry umożliwiają modyfikację. Aby zgłębić temat warto zajrzeć do następujących dokumentów: Working with DB Parameter Groups and DB Cluster Parameter Groups i Aurora MySQL Parameters. 

Po drugie, zanim przejdziemy do wdrożenia zmiany na produkcji, oczywistym jest konieczność  sprawdzenia ich w środowisku testowym. tworzymy kopię środowiska produkcyjnego na środowisku testowym lub tworząc snapshot instancji produkcyjnej. W ten sposób konfiguracja będzie jak najbardziej zbliżona do środowiska produkcyjnego. Pamiętajmy o wygenerowaniu obciążenia dla instancji testowej, które będzie odwzorowywać  obciążenie produkcyjne. Sprawdzamy wydajność systemu pod kątem kluczowych wskaźników wydajności, takich jak wykorzystanie procesora, liczba połączeń z bazą danych, wykorzystanie pamięci, wskaźniki trafień w pamięci podręcznej, szybkość zapytań oraz opóźnienia. Należy zmieniać tylko jeden parametr jednocześnie, aby mieć pewność jego wpływu na całość rozwiązania.Warto udokumentować, który parametr miał negatywny wpływ, a przy wdrożeniu którego kluczowe wskaźniki wydajności wykazały poprawę.

Po trzecie, pamiętajmy o domyślnych wartościach parametrów i ich znaczeniu. Niektóre parametry instancji DB zawierają zmienne lub formuły, w których wartość jest określona przez stałe. Przykładami są rozmiar instancji i wielkość pamięci, port sieciowy dla instancji oraz przydzielona pamięć. Najlepiej pozostawić je bez zmian, ponieważ dostosowują się automatycznie, gdy wykonywana jest operacja skalowania lub zmniejszania instancji.

Po czwarte, zwracamy uwagę na symptomy i diagnozę nieprawidłowo ustawionych wartości parametrów. Gdy niektóre parametry są źle skonfigurowane, mogą dawać  objawy stanu braku pamięci, który jest rejestrowany w dzienniku błędów MySQL. W tym przypadku instancja przechodzi w stan ponownego uruchamiania i generuje dzienniki zdarzeń. Możemy wówczas uzyskać następujący komunikat:

2018-12-29 19:05:16 UTC  [-]MySQL has been crashing due to incompatible parameters. Please 
check your memory parameters, in particular the max_connections, innodb_buffer_pool_size, 
key_buffer_size, query_cache_size, tmp_table_size, innodb_additional_mem_pool_size and 
innodb_log_buffer_size. Modify the memory parameter and reboot the instance.

Po piąte – ważna jest klasyfikacja parametrów. Można je sklasyfikować w dwojaki sposób:

• Parametry, które kontrolują zachowanie i funkcjonalność bazy danych, ale nie mają wpływu na wykorzystanie zasobów i stabilność instancji.
• Parametry, które mogą wpływać na wydajność, poprzez zarządzanie przydzielaniem zasobów, takich jak buforowanie i wewnętrzne bufory pamięci, w instancji.

Polecamy post Fabio Higa (Database Specialist Technical Account Manager w AWS), który wymienia przykłady takich klasyfikacji parametrów oraz w przystępny sposób, opisuje ich wpływ na bazę danych.

Pewnym jest, że wdrożenie rozwiązań opartych o Amazon Aurora  jest opłacalne w wielu aspektach. Przede wszystkim tymi, związanymi z optymalizacją kosztów, jej wydajnością i skalowalnością. W odniesieniu do najlepszych praktyk związanych z konfiguracją, ważnym staje się odpowiedni dobór parametrów. Aby wykonać prawidłową konfigurację, przekładającą się na mierzalny wzrost wydajności, dobrą praktyką jest eksperymentowanie, ustalenie linii bazowej i porównanie wyników po wprowadzeniu zmian. Warto skorzystać z  tego scenariusza i przetestować wszystkie zmiany, które chcemy wdrożyć na produkcję.