Redis a Memcached: wybór właściwego silnika

Amazon ElastiCache to w pełni zarządzana usługa buforowania w pamięci, która ułatwia wdrażanie, zarządzanie i skalowanie popularnych, otwartoźródłowych magazynów danych w pamięci w chmurze. Obsługuje dwa silniki: Redis i Memcached. Udostępniając często żądane dane z pamięci zamiast z bazy danych, ElastiCache może zmniejszyć obciążenie bazy danych o rzędy wielkości oraz skrócić opóźnienie odpowiedzi z milisekund do mikrosekund. Wybór między Redis i Memcached to częste pytanie na egzaminie SAA-C03.

Memcached to rozproszony magazyn klucz-wartość w pamięci, skoncentrowany na prostocie i skalowaniu horyzontalnym. Najważniejsze cechy: wielowątkowość (może korzystać ze wszystkich rdzeni procesora w jednym węźle), prosty magazyn klucz-wartość (wyłącznie ciągi znaków, bez złożonych struktur danych), brak trwałości (dane są tracone po ponownym uruchomieniu węzła), brak replikacji (brak węzła zapasowego i replik) oraz fragmentowanie horyzontalne za pomocą haszowania spójnego po stronie klienta. Memcached jest właściwym wyborem, gdy potrzebują Państwo prostego bufora na dużą skalę i nie wymagają trwałości, złożonych typów danych ani wysokiej dostępności.

Redis (Remote Dictionary Server) to jednowątkowy (w ramach instancji), bogaty w funkcje magazyn struktur danych w pamięci, obsługujący ciągi znaków, hasze, listy, zbiory, zbiory uporządkowane, bitmapy, HyperLogLogs, strumienie i indeksy geoprzestrzenne. Najważniejsze zalety w porównaniu z Memcached: opcjonalna trwałość (migawki AOF i RDB), replikacja (repliki do odczytu i automatyczne przełączanie awaryjne), komunikacja pub/sub, skrypty Lua, transakcje (MULTI/EXEC) oraz tryb klastra na potrzeby fragmentowania horyzontalnego. Redis jest właściwym wyborem w większości rzeczywistych scenariuszy buforowania.

Redis obsługuje dwa mechanizmy trwałości: RDB (Redis Database) — okresowe migawki stanu z określonego momentu, zapisywane na dysku w konfigurowalnych odstępach czasu (szybkie ponowne uruchamianie, ale możliwość utraty danych zapisanych między migawkami). AOF (Append-Only File) — rejestruje każdą operację zapisu; po ponownym uruchomieniu Redis odtwarza dziennik, aby odbudować stan (trwałość kosztem większych plików i wolniejszego ponownego uruchamiania). W ElastiCache można włączyć AOF, aby zachować dane po ponownym uruchomieniu węzłów. Ma to kluczowe znaczenie, gdy ElastiCache jest używany nie tylko jako bufor, ale także jako główny magazyn danych, na przykład do przechowywania danych sesji.

Redis obsługuje grupy replikacji z jednym węzłem głównym, który obsługuje wszystkie zapisy, oraz maksymalnie 5 replikami do odczytu, które obsługują odczyty. Po włączeniu funkcji Multi-AZ i automatycznego przełączania awaryjnego ElastiCache automatycznie promuje replikę do odczytu do roli głównej, gdy węzeł główny ulegnie awarii — zwykle przełączanie kończy się w czasie krótszym niż 60 sekund. Zapewnia to aplikacjom korzystającym z Redis wysoką dostępność, której Memcached nie może zaoferować (Memcached nie obsługuje replikacji). W przypadku aplikacji produkcyjnych wymagających buforowania o wysokiej dostępności należy zawsze używać Redis z automatycznym przełączaniem awaryjnym.

Posortowane zbiory to jedna z najpotężniejszych struktur danych Redis. Każdy element ma powiązany wynik zmiennoprzecinkowy, a elementy są zawsze przechowywane w uporządkowanej kolejności. Dzięki temu posortowane zbiory idealnie nadają się do tworzenia rankingów (sortowanie według wyniku), kolejek priorytetowych (najpierw przetwarzane są zadania o najwyższym priorytecie) oraz ograniczania częstotliwości (przesuwane okno czasowe z sygnaturami czasowymi jako wynikami). Operacje ZADD, ZRANGE, ZREVRANGE, ZRANK i ZRANGEBYSCORE mają złożoność O(log n) — są niezwykle wydajne nawet w przypadku milionów wpisów.

Funkcja pub/sub Redis umożliwia nadawcom rozsyłanie komunikatów do kanałów bez wiedzy o tym, kto jest subskrybentem. Subskrybenci otrzymują w czasie rzeczywistym wszystkie komunikaty publikowane w kanałach, które subskrybują. Komunikaty pub/sub nie są utrwalane — jeśli subskrybent jest offline, nie otrzyma komunikatu. W przypadku trwałej komunikacji z gwarancją dostarczenia należy użyć Redis Streams (bardziej zaawansowanej struktury danych dodanej w Redis 5) lub wyspecjalizowanej usługi komunikatów, takiej jak SQS albo SNS. Na egzaminie SAA-C03 funkcja pub/sub Redis jest opcją do lekkich powiadomień w czasie rzeczywistym między usługami.

Na egzaminie SAA-C03 należy zastosować następujące zasady wyboru: wybierz Memcached, gdy potrzebujesz prostego bufora bez wymogu wysokiej dostępności, wydajności wielowątkowej oraz skalowania horyzontalnego przez dodawanie węzłów (czysty bufor). Wybierz Redis, gdy potrzebujesz: trwałości (magazyn sesji), replikacji i przełączania awaryjnego (wysoka dostępność), złożonych typów danych (posortowane zbiory na potrzeby rankingów, zbiory, listy), pub/sub, transakcji Lua lub trybu klastra do horyzontalnego skalowania z użyciem wielu fragmentów. Jeśli treść pytania egzaminacyjnego wspomina o dowolnej funkcji wykraczającej poza proste buforowanie klucz-wartość, odpowiedzią niemal zawsze jest Redis.

ElastiCache oferuje kilka rodzin typów węzłów: r7g (Graviton 3, zoptymalizowane pod kątem pamięci — najlepszy stosunek ceny do wydajności, zalecane w przypadku większości zastosowań buforowania), m7g (zrównoważone zasoby obliczeniowe i pamięć) oraz t4g (z możliwością zwiększania wydajności, niski koszt w środowiskach programistycznych i testowych). Rozmiary węzłów wahają się od cache.t4g.micro (500 MB) do cache.r7g.16xlarge (425 GB). W środowisku produkcyjnym należy wybrać rozmiar węzła, który pozwoli przechowywać cały zestaw danych w pamięci, pozostawiając 20–25% zapasu. Wyczerpanie pamięci powoduje eksmisję danych (Memcached) lub błędy OOM (Redis).

ElastiCache jest wdrażany w obrębie VPC, a grupy zabezpieczeń kontrolują dostęp — domyślnie nie ma dostępu z publicznego Internetu. W przypadku Redis należy włączyć tokeny AUTH (hasło, które klienci muszą podać) oraz szyfrowanie podczas przesyłania (TLS) dla połączeń, a także szyfrowanie danych w spoczynku za pomocą KMS. W przypadku Memcached dostępne jest wyłącznie szyfrowanie TLS podczas przesyłania (brak szyfrowania danych w spoczynku i AUTH). Podczas migracji z nieszyfrowanego Redis do szyfrowanego nie ma możliwości migracji w miejscu — należy utworzyć nowy zaszyfrowany klaster i wstępnie go wypełnić.

Gdy bufor Redis lub Memcached jest pełny, zasada eksmisji określa, które klucze zostaną usunięte, aby zrobić miejsce. Typowe zasady eksmisji Redis: noeviction (zwraca błąd OOM — dobre rozwiązanie, gdy bufor jest głównym magazynem), allkeys-lru (usuwa najdawniej używane klucze spośród wszystkich kluczy — dobre rozwiązanie dla bufora ogólnego przeznaczenia), volatile-lru (LRU wśród kluczy z ustawionym TTL — zachowuje klucze bez terminu wygaśnięcia), allkeys-random (losowa eksmisja) oraz allkeys-lfu (usuwa najrzadziej używane klucze). W typowych zastosowaniach buforowania zalecane są allkeys-lru lub allkeys-lfu.

Sprawdź swoją wiedzę na temat zagadnień AWS Solutions Architect (SAA-C03) z tej lekcji.

W tej lekcji nauczyłeś się, że: Memcached jest prosty, wielowątkowy i nie zapewnia wysokiej dostępności — najlepiej nadaje się do czystego skalowania horyzontalnego prostych buforów; Redis obsługuje złożone struktury danych, trwałość, pub/sub i przełączanie awaryjne Multi-AZ — najlepiej sprawdza się w większości produkcyjnych scenariuszy buforowania; a posortowane zbiory sprawiają, że Redis jest naturalnym wyborem do rankingów i kolejek priorytetowych. Następnie omówimy grupy replikacji Redis i tryb klastra na potrzeby fragmentowania horyzontalnego.