Grupy replikacji Redis ElastiCache i tryb klastra

Grupa replikacji ElastiCache to logiczne grupowanie jednego głównego węzła Redis i maksymalnie 5 replik do odczytu. Węzeł główny obsługuje wszystkie operacje zapisu, a repliki otrzymują asynchronicznie replikowane dane z węzła głównego i obsługują ruch odczytu. Grupy replikacji zapewniają dwie kluczowe funkcje: skalowanie odczytu (rozłożenie żądań odczytu na wiele replik) oraz wysoką dostępność z automatycznym przełączaniem awaryjnym (promowanie repliki do roli głównej w przypadku awarii węzła głównego). Wszystkie węzły w grupie replikacji współdzielą ten sam zestaw danych.

ElastiCache udostępnia dwa punkty końcowe DNS dla grupy replikacji: punkt końcowy główny zawsze wskazuje bieżący węzeł główny (jest automatycznie aktualizowany podczas przełączania awaryjnego) — należy go używać do wszystkich operacji zapisu. Punkt końcowy odbiorcy równoważy obciążenie żądań odczytu między wszystkimi dostępnymi replikami — należy go używać do operacji odczytu w celu rozłożenia obciążenia. Aplikacja powinna utrzymywać dwie pule połączeń: jedną dla punktu końcowego głównego na potrzeby zapisów oraz drugą dla punktu końcowego odbiorcy na potrzeby odczytów. Jest to zalecany schemat połączeń dla grup replikacji ElastiCache Redis.

Gdy węzeł główny ulegnie awarii (ElastiCache wykrywa ją w ciągu kilku sekund za pomocą kontroli stanu), automatyczne przełączanie awaryjne wybiera jedną z replik do odczytu i promuje ją do roli głównej. Proces promowania przebiega następująco: (1) wybrana replika zostaje promowana do roli głównej, (2) rekord DNS głównego punktu końcowego zostaje zaktualizowany tak, aby wskazywał nowy węzeł główny (TTL około 1 sekundy), (3) stary węzeł główny zostaje zastąpiony nową repliką. Całkowity czas przełączania awaryjnego wynosi zwykle 30–60 sekund. Aplikacje korzystające z DNS głównego punktu końcowego automatycznie nawiązują połączenie ponownie po propagacji DNS — nie trzeba wpisywać adresów IP na stałe.

Aby uzyskać maksymalną odporność, należy rozmieścić repliki w wielu strefach dostępności. Po włączeniu Multi-AZ dla grupy replikacji ElastiCache automatycznie umieszcza węzeł główny i repliki w różnych strefach AZ. Jeśli cała strefa AZ przestanie działać, przełączanie awaryjne promuje replikę ze strefy, która nadal działa. Podczas tworzenia grupy replikacji można również jawnie określić preferowane strefy AZ dla każdego węzła, używając opcji --preferred-cache-cluster-a-zs.

Redis Cluster Mode Enabled (CME) dzieli zestaw danych między wiele grup węzłów (fragmentów), z których każda zawiera węzeł główny i maksymalnie 5 replik. Jest to rozwiązanie Redis do fragmentowania horyzontalnego. Tryb klastra pozwala przekroczyć limit pamięci pojedynczego węzła — można utworzyć maksymalnie 500 grup węzłów, z których każda ma 500 GB, co pozwala pojedynczemu klastrowi Redis przechowywać do 500 × 500 GB = 250 TB danych. Tryb klastra zwiększa również przepustowość zapisu, ponieważ każda grupa węzłów niezależnie przetwarza zapisy dla przypisanego jej zakresu kluczy.

Tryb klastra Redis dzieli przestrzeń kluczy na 16 384 sloty haszowania. Każda grupa węzłów posiada ciągły zakres slotów haszowania. Podczas zapisu klucza Redis oblicza CRC16(key) % 16384, aby określić slot haszowania, a tym samym grupę węzłów odpowiedzialną za jego obsługę. Aplikacja musi używać klienta Redis świadomego klastra (takiego jak redis-py-cluster lub Jedis w trybie klastra), który zna mapę slotów i kieruje każde polecenie do właściwego węzła. Standardowi klienci zwrócą błędy przekierowania MOVED, jeśli wyślą klucz do niewłaściwego fragmentu.

Na egzaminie SAA-C03 wybierz tryb bez klastra, gdy: dane mieszczą się na pojedynczym węźle (< ~400 GB po uwzględnieniu zapasu), potrzebujesz prostego układu węzeł główny/replika lub aplikacja korzysta ze złożonych operacji obejmujących wiele kluczy (transakcje obejmujące wiele kluczy wymagają, aby wszystkie klucze znajdowały się w tym samym slocie). Wybierz tryb klastra, gdy: zestaw danych przekracza pojemność pamięci pojedynczego węzła, potrzebujesz skalowania horyzontalnego przepustowości zapisu lub przewidujesz przyszły wzrost wymagający zmiany fragmentowania online. Tryb klastra obsługuje dodawanie fragmentów bez przestojów (zmiana fragmentowania online).

ElastiCache Global Datastore rozszerza replikację Redis na wiele regionów AWS. Wyznaczają Państwo jeden region jako klaster główny i dodają klastry pomocnicze w innych regionach. Operacje zapisu trafiają do klastra głównego, a klastry pomocnicze otrzymują replikację asynchroniczną, której typowe opóźnienie wynosi mniej niż 1 sekundę. Klastry pomocnicze mogą obsługiwać lokalne odczyty z bardzo małym opóźnieniem. Global Datastore umożliwia tworzenie aplikacji globalnych, w których użytkownicy z różnych kontynentów odczytują dane z najbliższego regionu, oraz zapewnia odtwarzanie po awarii między regionami, dzięki któremu można awansować klaster pomocniczy do roli głównego, jeśli główny region ulegnie awarii.

W niesklasteryzowanej grupie replikacji Redis komunikaty pub/sub są rozsyłane do wszystkich replik — każdy subskrybent w dowolnym węźle otrzymuje komunikaty publikowane na kanale. Jednak w Cluster Mode pub/sub jest ograniczone do powiadomień keyspace, a pub/sub oparte na kanałach działa tylko w obrębie pojedynczego fragmentu, chyba że używają Państwo Redis 7+ z mechanizmem shardingu Pub/Sub (SSUBSCRIBE / SPUBLISH do obsługi pub/sub uwzględniającej fragmenty). Jest to istotne ograniczenie podczas projektowania pub/sub na dużą skalę w trybie klastra.

Należy monitorować metrykę CloudWatch ReplicationLag na replikach odczytu, aby upewnić się, że nadążają za klastrem głównym. Opóźnienie przekraczające kilka sekund wskazuje na wąskie gardło po stronie repliki (przeciążony węzeł, problemy z siecią lub zbyt wiele operacji zapisu do przetworzenia przez replikę). W scenariuszach z globalnym magazynem danych należy monitorować GlobalDatastoreReplicationLag. Duże opóźnienie replikacji oznacza, że repliki odczytu mogą zwracać nieaktualne dane — ma to znaczenie w przypadku aplikacji, które oczekują spójności ostatecznej w ściśle określonych granicach.

Mogą Państwo skalować pionowo (zmienić typ węzła) lub skalować poziomo (dodać albo usunąć repliki). Zmiana typu węzła wymaga wywołania modify-replication-group i przy natychmiastowym zastosowaniu powoduje krótkie przełączenie awaryjne — klaster główny zostaje zastąpiony nowym węzłem wybranego typu. Dodawanie replik odbywa się online, bez przestoju. Podczas przechodzenia z trybu niesklasteryzowanego do trybu klastra należy utworzyć nową grupę w trybie klastra i przeprowadzić migrację — nie ma możliwości konwersji między trybem klastra a trybem niesklasteryzowanym w miejscu.

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

W tej lekcji nauczyli się Państwo, że grupy replikacji zapewniają skalowanie odczytu za pomocą replik oraz wysoką dostępność dzięki automatycznemu przełączaniu awaryjnemu z użyciem endpointów głównego klastra i odczytu, Cluster Mode dzieli dane na fragmenty w maksymalnie 500 grupach węzłów, wykorzystując 16 384 sloty hashujące, aby umożliwić skalowanie poziome wykraczające poza pamięć pojedynczego węzła, a Global Datastore replikuje dane między regionami, zapewniając globalne odczyty z małym opóźnieniem oraz odtwarzanie po awarii między regionami. W następnej części omówimy strategie buforowania: lazy loading i write-through.