Zarządzanie obciążeniami produkcyjnymi w hostowanych bazach danych

Dostarczone przez Usługi internetowe Amazon

AWS oferuje wiele opcji hostowania baz danych obsługujących obciążenia OLTP – hostuj własną zarządzaną bazę danych na Amazonka EC2 instancje lub użycie Amazon RDS zarządzany przez AWS. RDS zarządza wysoką dostępnością, automatycznymi kopiami zapasowymi, aktualizacjami baz danych, poprawkami systemu operacyjnego, zabezpieczeniami i repliką do odczytu. RDS oferuje również opcję natywną dla chmury Amazonka-Aurora silnik bazy danych, który jest kompatybilny z MySQL i PostgreSQL. Aurora zapewnia wyższą przepustowość w porównaniu ze standardowymi bazami danych MySQL i PostgreSQL.

Podczas uruchamiania obciążeń produkcyjnych na hostowanych bazach danych za pomocą Amazon RDS lub Amazon EC2 możesz napotkać następujące pytania:

• Jakie są najlepsze opcje typu przechowywania bazy danych?
• Jak rozwiązać problemy z wydajnością pamięci masowej?
• Jakie są opcje konfiguracji RAID dla baz danych hostowanych przez instancję EC2?
• Jakie są modyfikacje aplikacji w celu uzyskania optymalnej wydajności?
• Jak rozwiązywać problemy z wydajnością pamięci masowej za pomocą Amazon CloudWatch ?
• Wydajność operacyjna Amazon RDS czy Aurora?

W tym poście przedstawiam najlepsze praktyki przechowywania w zakresie uruchamiania obciążeń produkcyjnych w bazach danych hostowanych przez instancje Amazon RDS lub EC2.

W porównaniu ze środowiskami testowymi, QA lub pomostowymi obciążenia produkcyjne wymagają szybkiej i spójnej wydajności we/wy. Chociaż relacyjnych baz danych można używać do wielu celów, ich najczęstszym przypadkiem użycia jest hostowanie obciążenia przetwarzania transakcji online (OLTP). Bazy danych hostowane przez RDS, EC2 i Aurora wykorzystują różne rodzaje technik przechowywania, jak pokazano poniżej:

• Korzystają instancje bazy danych Amazon RDS Amazon EBS woluminy do przechowywania.
• Instancje Aurora używają zastrzeżonych woluminów pamięci masowej AWS.
• Instancje EC2 udostępniają różne opcje przechowywania.

Najlepsze opcje typu przechowywania bazy danych

Amazon RDS zapewnia trzy rodzaje przechowywania :

• Dysk SSD ogólnego przeznaczenia (znany również jako woluminy gp2 )
• Udostępniony dysk SSD IOPS (znany również jako io1 )
• Magnetyczny

Wydajność we/wy instancji zależy od typu i rozmiaru pamięci instancji. Jeśli instancja DB jest skonfigurowana z woluminem gp2, bazowa pojemność IOPS jest trzykrotnie większa niż pojemność GiB. Jeśli instancja DB przydzieliła wolumin gp2 o przepustowości 100 GiB, bazowa pojemność IOPS wynosi 300. Im więcej pamięci alokujesz, tym wyższa pojemność IOPS.

Oprócz podstawowej pojemności IOPS, wolumeny gp2 zapewniają również pojemność burst do 3000 IOPS przez dłuższy czas. Funkcja serii jest ograniczona do woluminów równych lub mniejszych niż 1 TiB pamięci masowej. Instancje bazy danych dla MySQL, MariaDB, Oracle i PostgreSQL można skonfigurować z 20 GiB–32 TiB, ale maksymalna bazowa liczba IOPS jest ograniczona od 100 do 16 000 IOPS. Tak więc wolumen gp2 wynoszący 5,34 TiB lub więcej zapewnia ten sam poziom bazowy: 16 000 IOPS.

Jeśli obciążenie produkcyjne wymaga wysokiego OLTP i szybkiej, niezmiennie wysokiej przepustowości, należy skonfigurować wystąpienie bazy danych z woluminami io1. W porównaniu z woluminami gp2, które zapewniają maksymalną linię bazową 16 000 IOPS, woluminy io1 mogą zapewnić do 40 000 IOPS dla instancji DB dla MySQL, MariaDB, Oracle i PostgreSQL oraz do 32 000 dla instancji SQL Server.

Jeśli zauważysz, że wzorzec wykorzystania IOPS stale przekracza 16 000, powinieneś: zmodyfikuj DB wystąpieniei zmień typ pamięci z gp2 na io1. Amazon RDS oferuje również pamięć magnetyczną, ale nie jest odpowiednia dla obciążenia OLTP wymagającego stałej wydajności we/wy i małych opóźnień.

Typ magazynu magnetycznego nie jest zalecany w przypadku obciążeń intensywnie korzystających z operacji we/wy, ponieważ maksymalna pamięć jest mniejsza niż w przypadku gp2 lub io1. Pojemność IOPS jest również ograniczona do maksymalnie 1000 IOPS.

Problemy z wydajnością pamięci masowej

Używanie pamięci gp2 jest idealne dla szerokiej gamy obciążeń DB. W przypadku tego typu magazynu architekt obciążenia odczytu i zapisu bazy danych w taki sposób, aby suma CzytajIOPS oraz Zapis IOPS wartości nie przekraczają w żadnym momencie bazowej pojemności IOPS.

Pojemność serii może być dostępna przez dłuższy czas. Jednak po wykorzystaniu pojemności serii, stała wysoka wartość IOPS odczytu i zapisu obniża wydajność instancji. Degradację tę można zaobserwować poprzez zwiększenie Opóźnienie zapisu lub Przeczytaj Opóźnienie wartości. Idealnie, pamięć gp2 jest dobra dla jednocyfrowych milisekund opóźnienia, ale nadużywanie IOPS może spowodować opóźnienie >10 ms.

Poniższe obrazy pokazują wzrost Opóźnienie zapisu wartości, ponieważ WriteIOPS konsekwentnie zużywa podstawową pojemność 300 IOPS w wystąpieniu Amazon RDS DB. W tym przykładzie instancja Amazon RDS PostgreSQL jest hostowana na instancji t2.small z woluminem gp2 o przepustowości 100 GiB.

Powyższy obraz pokazuje, że Write IOPS stale zużywa 300 IOPS, co stanowi podstawową wydajność.

Powyższy obraz pokazuje, że opóźnienie zapisu zwiększyło się do 25 milisekund z powodu nadmiernego wykorzystania IOPS.

W ramach najlepszej praktyki upewnij się, że obciążenie nie wykracza poza pojemność IOPS instancji. Niektóre sposoby na zmniejszenie CzytajIOPS wartości to:

• Użyj repliki do odczytu Amazon RDS.
• Użyj większej pamięci RAM.

Korzystanie z repliki do odczytu Amazon RDS

Oferta instancji Amazon RDS DB dla MySQL, MariaDB, Oracle i PostgreSQL Repliki odczytu RDS . Te instancje to oddzielne instancje bazy danych zsynchronizowane ze źródłową instancją bazy danych przez odtwarzanie dzienników transakcyjnych bazy danych. Wszelkie modyfikacje danych w źródłowej instancji bazy danych są stosowane do repliki do odczytu. Replika do odczytu zmniejsza obciążenie źródłowej instancji bazy danych, kierując zapytania odczytu z aplikacji do repliki do odczytu. Zwalniasz również pojemność IOPS na dodatkową aktywność zapisu w źródłowej instancji bazy danych.

W przypadku replik do odczytu ważne jest monitorowanie opóźnienia replikacji. Ogólnie duże opóźnienie replikacji jest spowodowane dużą aktywnością zapisu w źródłowej instancji bazy danych.

W instancjach Amazon RDS DB możesz monitorować opóźnienie repliki za pomocą metryki CloudWatch ReplikaOpóźnienie . Jeśli zauważysz duże opóźnienie repliki, powinieneś również monitorować aktywność zapisu w źródłowej instancji bazy danych. Można to osiągnąć poprzez monitorowanie metryk CloudWatch Zapis IOPS oraz Przepustowość zapisu . Jeśli źródłowa instancja bazy danych ma niedobór IOPS (czyli cała pojemność IOPS jest wykorzystywana przez obciążenie zapisu i odczytu), replika również pozostaje w tyle.

Jedną z przyczyn opóźnionych replik jest to, że w większości silników DB odzyskiwanie replik do odczytu obejmuje procesy jednobieżne. Oznacza to, że im większe obciążenie w instancji głównej, tym wykładniczo wolniejsze odzyskiwanie w replikach do odczytu. Każda dodatkowa wysoka aktywność zapisu w źródłowej instancji bazy danych wykładniczo zwiększa opóźnienie repliki odczytu. Oprócz metryk CloudWatch, z ReplikaOpóźnienie możesz również monitorować lag za pomocą zapytań SQL.

W PostgreSQL opóźnienie repliki odczytu można obliczyć za pomocą następującego zapytania:

|_+_|

W MySQL możesz sprawdzić stan replikacji za pomocą następującego polecenia:

|_+_|

W przypadku repliki do odczytu Amazon RDS skonfiguruj klienta w taki sposób, aby pewien poziom opóźnienia lub błąd replikacji znaleziony w replice powodował próbę połączenia z innym punktem końcowym repliki.

Dobrym sposobem na upewnienie się, że Twoja aplikacja może znaleźć najzdrowszą replikę, jest wywołanie metryk CloudWatch w celu znalezienia bieżących wartości ReplikaOpóźnienie oraz opóźnienie odczytu/zapisu. Opóźnienie replikacji można znaleźć za pomocą poleceń SQL, jak pokazano w poprzednich przykładach. Aktualny stan repliki można również znaleźć, wywołując Interfejs wiersza poleceń AWS (AWS CLI) polecenie opisz-db-instancje. Jeśli aktualny stan repliki jest inny niż replikacja, klient powinien spróbować połączyć się z inną repliką.

Oprócz korzyści związanych z dystrybucją transakcji odczytu, repliki do odczytu mogą być również używane do fragmentowania danych. Zgodnie z architekturą shardów bez udostępniania, możesz tworzyć repliki do odczytu odpowiadające każdemu z Twoich fragmentów i promować je, gdy zdecydujesz się przekonwertować je na samodzielne fragmenty.

Korzystanie z większej pamięci RAM

Instancje Amazon RDS DB powinny mieć wystarczającą ilość pamięci RAM, aby cały zestaw roboczy znajdował się w pamięci. Ponieważ zapytania odczytu mogą odczytywać dane z pamięci, ogranicza to komunikację z woluminami pamięci masowej. W związku z tym zmniejsza zużycie CzytajIOPS pojemność, którą można wykorzystać do celów zapisu.

Nie ma prostego sposobu na znalezienie rozmiaru działającego zestawu danych. Spójrz na zapytania odczytu i dowiedz się, ile danych zostało trafionych. Na przykład, jeśli rozmiar bazy danych wynosi 100 GiB, a zestaw roboczy to 20 GiB, należy użyć Instancja Amazon RDS DB z co najmniej 20 GiB pamięci. To pozwala mieć w pamięci cały zestaw roboczy.

Opcje konfiguracji RAID dla baz danych hostowanych przez instancję EC2

Woluminy EBS to woluminy pamięci masowej na poziomie bloków, które zapewniają trwałą blokową pamięć masową. Te woluminy są woluminami magazynu o wysokiej dostępności i można je dołączyć do wystąpienia EC2 w tej samej strefie dostępności. Woluminy EBS są idealne dla baz danych hostowanych na instancji EC2. Używanie pamięci efemerycznej instancji EC2 dla bazy danych nie jest zalecane.

Używając woluminów pamięci masowej EBS z instancjami EC2, możesz konfigurować woluminy z dowolnymi poziomami RAID. Na przykład, aby uzyskać większą wydajność we/wy, możesz wybrać macierz RAID 0, która może łączyć wiele woluminów razem. RAID 1 może być używany do nadmiarowości danych, ponieważ odzwierciedla dwa woluminy razem.

Niezależnie od konfiguracji RAID dane wolumenu EBS są replikowane na serwerach pomocniczych, aby uniknąć utraty danych. RAID 5 i RAID 6 nie są zalecane w bazach danych hostowanych przez instancję EC2, ponieważ wydajność we/wy nie jest tak dobra, jak RAID 0 lub RAID 1.

Poniższa tabela przedstawia zalety i wady korzystania z tych dwóch różnych konfiguracji macierzy RAID oraz sugeruje możliwe przypadki użycia.

Konfiguracja	Zalety	Niedogodności	Przypadek użycia
RAID 0	Lepsza wydajność we/wy w porównaniu z odpornością na błędy	Utrata jednego woluminu powoduje całkowitą utratę danych	Jeśli baza danych wymaga większej przepustowości w porównaniu z dostępnością danych, a dane są odtwarzalne
RAID 1	Odporność na awarie jest lepsza w porównaniu z wydajnością we/wy	Niska wydajność zapisu	Jeśli dane są krytyczne, a odporność na błędy bazy danych jest ważniejsza niż wydajność we/wy

Modyfikacje aplikacji dla optymalnej wydajności

Jeśli instancja bazy danych napotyka problemy z pamięcią masową i napotyka problemy, takie jak długi czas zatwierdzania i duże opóźnienia, czasami zmiany w aplikacji mogą złagodzić tę degradację. Możesz modyfikować aplikacje, aby włączyć wykładnicze wycofywanie lub ponawianie błędów.

Wykładnicze wycofywanie pozwala aplikacjom stopniowo wydłużać czas oczekiwania między kolejnymi próbami na kolejne odpowiedzi na błędy. Podczas gdy niektóre algorytmy wykorzystują opóźnienie przyrostowe, większość algorytmów wykładniczego odczekiwania wykorzystuje opóźnienie losowe. Oto przykłady innego algorytmu:

Losowe opóźnienie:

1. Aplikacja inicjuje żądanie.
2. Jeśli żądanie nie powiedzie się, odczekaj rand(1000,3000) milisekund i zainicjuj żądanie ponownie.
3. Jeśli żądanie nie powiedzie się, odczekaj rand(1000,3000) milisekund i zainicjuj żądanie ponownie.
4. Jeśli żądanie nie powiedzie się, odczekaj rand(1000,3000) milisekund i zainicjuj żądanie ponownie.

Opóźnienie przyrostowe:

1. Aplikacja inicjuje żądanie.
2. Jeśli żądanie nie powiedzie się, odczekaj 1 = 1000 milisekund i zainicjuj żądanie ponownie.
3. Jeśli żądanie nie powiedzie się, odczekaj 2 = odczekaj 1 + 1000 milisekund i zainicjuj żądanie ponownie.
4. Jeśli żądanie się nie powiedzie, odczekaj 3 = odczekaj 2 + 1000 milisekund i zainicjuj żądanie ponownie.

Skorzystaj z pewnych najlepszych praktyk, aby uzyskać szybsze przełączanie awaryjne w instancjach Amazon RDS Multi-AZ i klastrach Aurora. Włącz parametry utrzymywania aktywności protokołu TCP i ustaw je agresywnie, aby zapewnić, że jeśli klient nie będzie już mógł łączyć się z instancją bazy danych, wszystkie aktywne połączenia zostaną szybko zamknięte. Ta modyfikacja umożliwia również aplikacjom szybsze reagowanie na przełączanie awaryjne i szybkie łączenie się z nowym punktem końcowym.

Możesz także skrócić limit czasu buforowania DNS na kliencie. Połączenia odczytu i zapisu są nawiązywane szybko z odpowiednimi punktami końcowymi. Niektóre parametry ustawień TCP serwera można również modyfikować. Te zmiany pomagają w szybszym przełączaniu awaryjnym. Na przykład w PostgreSQL można to kontrolować za pomocą tcp_keepalives_count, tcp_keepalives_idle i tcp_keepalives_interval parametry .

Rozwiązywanie problemów z wydajnością pamięci masowej za pomocą CloudWatch

Regularne monitorowanie kondycji magazynu instancji pozwala zidentyfikować wczesne wystąpienie problemów z wydajnością, zanim będą one miały poważny wpływ na wydajność bazy danych. Niektóre metryki pamięci masowej związane z CloudWatch, które należy regularnie monitorować, są wymienione tutaj.

Operacje zapisu

• Napisz IOPS: Mierzona z szybkością zliczeń na sekundę, ta metryka CloudWatch określa średnią liczbę operacji zapisu na dysku we/wy na sekundę. Skoncentruj się na tej metryce, jeśli instancja bazy danych jest skonfigurowana z ustawieniem Multi-AZ.
  Za pomocą Multi-AZ instancja dodatkowa jest tworzona w innej strefie dostępności z taką samą konfiguracją instancji, jak główny i dołączony wolumin pamięci masowej EBS. Ten magazyn jest synchronizowany synchronicznie z magazynem instancji głównej. W przypadku nadmiarowości danych domyślnie dane z każdego wolumenu EBS są kopiowane do innego, pomocniczego wolumenu EBS znajdującego się w tej samej strefie dostępności. Oznacza to, że transakcja zapisu musi zostać zatwierdzona w czterech miejscach przed wysłaniem potwierdzenia do klienta. Masowa aktywność zapisu powyżej IOPS i przepustowości instancji pogarsza ogólną wydajność.
• Przepustowość zapisu: Ta metryka CloudWatch reprezentuje średnią liczbę bajtów zapisanych na dysku na sekundę. Przekroczenie przepustowości wystąpienia lub limitu przepustowości magazynu zmniejsza wydajność wystąpienia. Sugeruję monitorowanie aktywności zapisu i rozłożenie obciążenia związanego z zapisem z odpowiednim opóźnieniem, aby zoptymalizować wydajność.
• Opóźnienie zapisu: Jest to średni czas trwania operacji we/wy dysku. Większość czasu Opóźnienie zapisu wzrosty wynikają z nadużywania zasobów instancji, takich jak procesor, IOPS i przepustowość.

Operacje odczytu

• Czytaj IOPS: Mierzona z szybkością zliczeń na sekundę, ta metryka CloudWatch określa średnią liczbę operacji we/wy odczytu dysku na sekundę. Zwiększona wartość CzytajIOPS sugeruje, że albo obciążenie odczytu jest duże, albo instancja wymaga więcej wolnej pamięci.
• CzytajPrzepustowość: Ta metryka reprezentuje średnią liczbę bajtów odczytanych z dysku na sekundę. Przekroczenie limitów instancji i EBS może zwiększyć opóźnienia.
• Opóźnienie odczytu: Jest to średni czas trwania operacji we/wy dysku. Jeśli masz wysoką wartość dla tej metryki, spójrz na obciążenie odczytu i upewnij się, że nie nadużywa ono zasobów instancji.

Inne metryki

Wraz z wcześniej wymienionymi metrykami powinieneś również monitorować następujące metryki CloudWatch:

• Głębokość kolejki dysku reprezentuje liczbę oczekujących we/wy (żądań odczytu/zapisu) oczekujących na dostęp do dysku. Zazwyczaj jest to wynikiem dużego obciążenia pracą.
• Wolna przestrzeń do przechowywania określa ilość dostępnej przestrzeni dyskowej. Jako najlepszą praktykę należy ustawić Alerty CloudWatch dzięki czemu możesz otrzymywać powiadomienia SNS, gdy tylko wolna pamięć instancji spadnie poniżej wartości progowej, takiej jak 15%.

Wydajność operacyjna Amazon RDS vs. Aurora

Jak wspomniano wcześniej, instancje Amazon RDS DB i instancje EC2 mają zależność IOPS od woluminów pamięci masowej. Typy pamięci gp2 i io1 mają własne limity IOPS.

Jeśli Twoje obciążenie wymaga wyższej wydajności IOPS i większej przepustowości, możesz zaplanować migrację do Aurora, która jest wysokowydajnym, wysoce dostępnym i ekonomicznym rozwiązaniem odpowiednim dla obciążeń o wysokiej przepustowości. W tej chwili, Świt oferuje silniki kompatybilne z MySQL i PostgreSQL.

Korzystając z Aurory, upewnij się, że technicznie nie ma limitu IOPS, ale przepustowość może być ograniczona do instrumentu bazowego Instancja zorzy polarnej limit. Aby uzyskać lepszą przepustowość, wybierz wyższą klasę instancji Aurora.

Aurora najlepiej nadaje się do aplikacji wymagających niewielkiego lub zerowego opóźnienia dla dowolnego IOPS. Został zaprojektowany do obsługi dużej prędkości danych, zapewniając wyższą przepustowość w porównaniu z tradycyjnymi silnikami MySQL i PostgreSQL. Będąc bazą danych z magazynem wierszy, idealnie nadaje się do obsługi dużych, jednoczesnych obciążeń OLTP.

Innym przypadkiem użycia Aurory jest hybrydowe przetwarzanie analityczne transakcji (HTAP). Aurora obsługuje do 15 replik. Każda z tych replik działa w ciągu 15–20 milisekund od wystąpienia zapisu. Z ostatnio dodanymi Funkcja zapytań równoległych Amazon Aurora , przetwarzanie zapytań jest później przekazywane do magazynu Aurora. Zapytanie wykorzystuje potencjalnie tysiące węzłów magazynowania w klastrze Aurora do przetwarzania, udoskonalania i agregowania danych przed wysłaniem ich do węzła obliczeniowego.

Wniosek

W tym poście poznałeś najlepsze praktyki przechowywania danych w zakresie uruchamiania obciążenia produkcyjnego na instancji Amazon RDS DB i bazach danych hostowanych przez instancję EC2. Praktyki te obejmowały:

• Przydzielanie obciążeń odczytu do repliki do odczytu.
• Zrozumienie pojemności IOPS i jej zależności od rozmiaru i typu pamięci.
• Zmiana architektury aplikacji.
• Badanie opcji RAID.
• Monitorowanie metryk CloudWatch.

Dowiedziałeś się również o Aurorze i o tym, jak jej zastrzeżone przechowywanie działa inaczej niż woluminy EBS. Cała ta wiedza pomaga w płynnym i bezproblemowym uruchamianiu obciążenia produkcyjnego na bazach danych AWS. Możesz również przyjrzeć się szczegółom, w jaki sposób Aurora obsługuje szybkość i dostępność bazy danych przy użyciu warstwy pamięci masowej w tym wpisie na blogu dotyczącym bazy danych: Przedstawiamy silnik pamięci masowej Aurora.

ukryć