Silniki RDS i klasy instancji

Amazon RDS obsługuje sześć silników baz danych: MySQL, PostgreSQL, MariaDB, Oracle, Microsoft SQL Server oraz Amazon Aurora. Każdy silnik jest w pełni zarządzaną wersją znanej już Państwu otwartoźródłowej lub komercyjnej bazy danych. AWS zajmuje się instalowaniem poprawek, kopiami zapasowymi i przełączaniem awaryjnym, dzięki czemu mogą się Państwo skupić na logice aplikacji.

Wybór odpowiedniego silnika zależy od wymagań istniejącej aplikacji, kosztów licencji oraz funkcji oferowanych przez poszczególne silniki. Aurora to natywna dla chmury opcja AWS zaprojektowana z myślą o wydajności i dostępności.

MySQL to najpopularniejsza na świecie otwartoźródłowa relacyjna baza danych, naturalnie pasująca do aplikacji internetowych i systemów CMS. PostgreSQL oferuje zaawansowaną zgodność ze standardem SQL, szeroką obsługę JSONB oraz rozbudowany ekosystem rozszerzeń, dzięki czemu jest popularny w zadaniach analitycznych i geoprzestrzennych.

Oba silniki w RDS obsługują automatyczne kopie zapasowe, wdrożenia Multi-AZ i Read Replicas. Read Replicas PostgreSQL mogą obejmować wiele regionów, natomiast MySQL z Aurora MySQL obsługuje do 15 replik międzyregionowych.

MariaDB to rozwijany przez społeczność fork MySQL, w pełni zgodny z klientami MySQL na poziomie protokołu komunikacyjnego. Oferuje dodatkowe silniki składowania, lepszą wydajność w niektórych obciążeniach oraz otwarty model rozwoju, bez funkcji własnościowych.

W RDS MariaDB jest bezpośrednim zamiennikiem MySQL, jeśli chcą Państwo uniknąć licencjonowania MySQL przez Oracle lub preferują fork rozwijany przez społeczność. Obsługuje te same funkcje automatycznych kopii zapasowych, Multi-AZ i Read Replicas co MySQL.

Oracle Database w RDS obsługuje modele License Included (LI) i Bring Your Own License (BYOL). W modelu LI licencja Oracle SE2 jest wliczona w stawkę godzinową, natomiast BYOL pozwala użyć posiadanej licencji Enterprise Edition z funkcjami takimi jak partycjonowanie i Advanced Security.

Microsoft SQL Server w RDS oferuje podobnie edycje LI (Express, Web, Standard, Enterprise) oraz BYOL. Oba silniki obsługują Multi-AZ z użyciem synchronicznego dublowania, ale nie obsługują Read Replicas w taki sam sposób jak silniki otwartoźródłowe.

Amazon Aurora to natywna dla chmury relacyjna baza danych zgodna zarówno z MySQL, jak i PostgreSQL. Aurora zapewnia do 5 razy większą przepustowość niż MySQL i do 3 razy większą przepustowość niż PostgreSQL na tym samym sprzęcie, wykorzystując rozproszoną warstwę składowania, która automatycznie replikuje dane w sześciu kopiach w trzech strefach dostępności.

Pojemność składowania Aurora zwiększa się automatycznie przyrostami po 10 GB, maksymalnie do 128 TiB, co eliminuje konieczność ręcznego przydzielania miejsca. Oddzielenie warstwy obliczeniowej od warstwy składowania pozwala także usłudze Aurora Serverless automatycznie zwiększać i zmniejszać pojemność.

Klasy instancji RDS stosują tę samą konwencję nazewnictwa co EC2, ale zamiast samej litery rodziny mają prefiks db. Główne rodziny to:

• db.t — wydajność skalowana, opłacalna w środowiskach deweloperskich i testowych (np. db.t3.micro, db.t4g.small)
• db.m — zastosowania ogólne, zrównoważone zasoby procesora i pamięci (np. db.m6g.large)
• db.r — zoptymalizowane pod kątem pamięci, do dużych pamięci podręcznych i tabel przechowywanych w pamięci (np. db.r6g.xlarge)
• db.x — bardzo duża ilość pamięci, do Oracle i SQL Server z obciążeniami SAP

Proszę wybrać db.t na potrzeby programowania, db.m dla typowych środowisk produkcyjnych, a db.r dla baz danych z dużym zbiorem roboczym.

Wybór klasy instancji RDS wymaga przeanalizowania wykorzystania procesora, zużycia pamięci, wymagań dotyczących IOPS oraz przepustowości sieci dla danego obciążenia. AWS Compute Optimizer i narzędzie RDS Performance Insights pomagają ustalić, czy bieżąca instancja ma przydzielone zbyt duże, czy zbyt małe zasoby.

Typowy schemat polega na rozpoczęciu od db.t3 podczas tworzenia prototypu, przejściu na db.m6g po ustabilizowaniu obciążenia i wyborze db.r6g, gdy zapytania zyskują na większym buforze. Instancje oparte na Graviton2 (db.m6g, db.r6g) zazwyczaj oferują do 35% lepszy stosunek ceny do wydajności niż ich odpowiedniki x86.

RDS oferuje trzy typy składowania, które w tle odpowiadają wolumenom EBS:

• gp2 / gp3 — uniwersalne dyski SSD; gp3 pozwala niezależnie przydzielać IOPS i przepustowość bez płacenia za dodatkową przestrzeń
• io1 / io2 — dyski SSD z aprowizowanymi IOPS, przeznaczone dla wrażliwych na opóźnienia baz OLTP wymagających stałego czasu odpowiedzi poniżej milisekundy
• st1 — dysk HDD zoptymalizowany pod kątem przepustowości, dostępny tylko dla określonych silników i obciążeń testowych

W przypadku większości produkcyjnych wdrożeń RDS zalecanym wyborem domyślnym jest gp3, ponieważ oferuje 3000 IOPS bez dodatkowych opłat i można go skalować niezależnie od rozmiaru składowania.

RDS obsługuje dwa wymiary skalowania. Skalowanie pionowe (zmiana klasy instancji) wymaga krótkiego okna przestoju, chyba że włączono Multi-AZ — w takim przypadku przełączenie awaryjne pozwala niemal wyeliminować przestój podczas zmiany rozmiaru. Modyfikację można zaplanować na najbliższe okno konserwacji lub zastosować natychmiast.

Skalowanie poziome dotyczy wyłącznie odczytu: można dodać Read Replicas, aby rozdzielić zapytania SELECT i odciążyć instancję główną. Read Replicas korzystają z replikacji asynchronicznej, dlatego występuje niewielkie opóźnienie replikacji, które aplikacja musi tolerować.

Wybierając między Aurora a społecznościowymi silnikami MySQL/PostgreSQL, proszę uwzględnić następujące kompromisy:

• Aurora: większa przepustowość, automatyczna replikacja w 6 kopiach, szybkie przełączanie awaryjne (~30 s), brak ręcznego zarządzania składowaniem, wyższy koszt godzinowy
• MySQL/PostgreSQL: niższy koszt, szerszy wybór rozszerzeń społeczności, opcja BYOL, znane narzędzia operacyjne

W scenariuszach egzaminacyjnych Aurora jest preferowana, gdy pytanie podkreśla wysoką dostępność, automatyczne zwiększanie przestrzeni lub wydajność zbliżoną do komercyjnych baz danych przy cenie oprogramowania otwartoźródłowego. Silniki społecznościowe wygrywają, gdy priorytetem jest minimalizacja kosztów lub zgodność funkcjonalna ze środowiskiem lokalnym.

RDS rozróżnia aktualizacje wersji podrzędnej (np. MySQL 8.0.32 → 8.0.36) od aktualizacji wersji głównej (np. MySQL 5.7 → 8.0). Aktualizacje podrzędne można skonfigurować tak, aby były stosowane automatycznie podczas okna konserwacji, włączając --auto-minor-version-upgrade. Aktualizacje główne wykonuje się ręcznie i mogą one wymagać przetestowania zgodności aplikacji.

Przed aktualizacją wersji głównej zawsze należy najpierw przeprowadzić testy w środowisku przejściowym. Przed aktualizacją można utworzyć migawkę bazy danych, aby w razie problemów przywrócić poprzedni stan. Klastry Aurora obsługują aktualizacje wersji głównej w miejscu, przy minimalnych zakłóceniach.

Sprawdź swoją znajomość zagadnień AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.

W tej lekcji nauczyli się Państwo, że: RDS obsługuje sześć silników (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Aurora), klasy instancji odpowiadają profilom obciążenia (db.t do programowania i testów, db.m do zastosowań ogólnych, db.r do obciążeń intensywnie korzystających z pamięci), a Aurora oferuje większą przepustowość i automatyczne skalowanie przestrzeni w porównaniu z silnikami społecznościowymi. W następnej kolejności omówimy wdrożenia Multi-AZ i automatyczne kopie zapasowe zapewniające wysoką dostępność.