Amazon SAA-C03: Bazy danych i buforowanie — Przewodnik do nauki

By Laurynas Brazys · 18 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Część AWS SAA-C03 — Kompletny przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Amazon RDS: Zarządzane silniki relacyjne

Amazon RDS udostępnia sześć zarządzanych silników — MySQL, PostgreSQL, MariaDB, Oracle, SQL Server i Amazon Aurora (kompatybilny z MySQL i PostgreSQL) — abstrakcjonując od łatania, tworzenia kopii zapasowych, topologii replikacji i przełączania awaryjnego (failover). Wybór silnika wpływa na licencjonowanie, semantykę kopii zapasowych i dostępność funkcji: Oracle i SQL Server oferują rozróżnienie na model BYOL (Bring Your Own License) i z licencją w cenie (License Included), SQL Server obsługuje do pięciu replik do odczytu za pomocą natywnej replikacji, a repliki do odczytu w Oracle wymagają wersji Enterprise Edition z Active Data Guard.

Dwie funkcje RDS najczęściej wykorzystywane do zapewnienia dostępności i skalowalności — i jednocześnie dwie najczęściej mylone — to wdrożenia Multi-AZ oraz repliki do odczytu. Są to rozwiązania ortogonalne, komplementarne i nie są wzajemnie wymienne.

Multi-AZ tworzy synchroniczną replikę zapasową (standby) w drugiej Strefie Dostępności. Każda operacja zapisu jest zatwierdzana zarówno na instancji podstawowej, jak i zapasowej, zanim zostanie potwierdzona, co daje RPO na poziomie praktycznie zerowym i RTO wynoszące 60–120 sekund podczas automatycznego przełączania awaryjnego. Replika zapasowa nie przyjmuje żadnego ruchu — istnieje wyłącznie na potrzeby przełączania awaryjnego. Gdy instancja podstawowa ulegnie awarii, wystąpi problem ze Strefą Dostępności lub konserwacja będzie wymagać restartu, RDS przełącza rekord CNAME w DNS na replikę zapasową, a aplikacje ponownie łączą się w sposób przezroczysty przez ten sam punkt końcowy. Multi-AZ to najprostsze rozwiązanie problemu pojedynczego punktu awarii w jednej Strefie Dostępności: jest to opcja konfiguracyjna, nie wymaga zmian w schemacie ani aplikacji i zachowuje ten sam punkt końcowy. Nowsze wdrożenie klastra Multi-AZ to topologia trójwęzłowa (jeden węzeł do zapisu, dwa czytelne węzły zapasowe) wykorzystująca replikację semi-synchroniczną z opóźnieniem zatwierdzenia na poziomie około jednej sekundy, co zapewnia wysoką dostępność (HA) oraz ograniczone odciążenie zapytań odczytu.

Repliki do odczytu wykorzystują natywną, asynchroniczną replikację silnika (binlog w MySQL, streaming WAL w PostgreSQL). Są one właściwym narzędziem do skalowania odczytu — zapytań analitycznych, pulpitów raportowych, doraźnych zapytań SELECT — które w przeciwnym razie obciążałyby nadmiernie operacje OLTP na instancji podstawowej. Kanoniczny scenariusz: baza danych przetwarzająca zamówienia, w której występują przekroczenia limitu czasu, ponieważ pracownicy uruchamiają długie raporty na koniec miesiąca. Dodanie repliki do odczytu i skierowanie na jej punkt końcowy narzędzia raportowego izoluje obciążenie analityczne bez konieczności zwiększania mocy instancji podstawowej. Repliki do odczytu mogą być międzyregionalne i mogą być ręcznie promowane do statusu samodzielnych baz danych, ale promocja nigdy nie jest automatyczna, a wszelkie transakcje, które nie zostały jeszcze zreplikowane w momencie awarii, są tracone.

W tym obszarze powtarzają się dwie pułapki. Po pierwsze, traktowanie replik do odczytu jako rozwiązania HA jest błędne z wielu powodów: replikacja jest asynchroniczna (potencjalna utrata danych), nie ma automatycznej promocji, punkt końcowy zmienia się po promocji, a transakcje w toku znikają. Jeśli projekt obiecuje „zerową utratę danych” i wskazuje na replikę do odczytu jako cel przełączenia awaryjnego, ta obietnica jest fałszywa. Po drugie, udostępnianie Multi-AZ do obsługi ruchu odczytu to marnotrawstwo pieniędzy, ponieważ w standardowej topologii replika zapasowa nie jest czytelna. Multi-AZ rozwiązuje problem dostępności; repliki do odczytu rozwiązują problem skalowania odczytu; często potrzebne są oba te rozwiązania.

Repliki do odczytu nie pomagają również w skalowaniu zapisu — każdy zapis nadal trafia do instancji podstawowej, a repliki muszą go odtworzyć. Aby skalować zapis, należy zastosować sharding, przejść na Aurorę (z oddzieloną warstwą pamięci masowej) lub przeprojektować rozwiązanie w kierunku DynamoDB.

Dobór odpowiedniego rozmiaru replik do odczytu

Replika nie musi mieć tej samej klasy instancji co instancja podstawowa. Instancja podstawowa obsługuje pełne obciążenie zapisu oraz odczyty; replika obsługuje tylko te odczyty, które do niej trafiają. Połączenie instancji podstawowej db.r6i.4xlarge z repliką db.r6i.large do nocnego zadania raportowego jest całkowicie uzasadnione — pod warunkiem, że replika nadąża z operacjami I/O replikacji. Metodologia jest następująca: zmierz rzeczywiste zużycie procesora, pamięci i opóźnienie replikacji (replica lag) repliki, a następnie dobierz jej rozmiar do tego obciążenia. Jedno zastrzeżenie: jeśli zamierzasz promować replikę na instancję podstawową podczas odtwarzania awaryjnego (DR), musi ona być zwymiarowana tak, aby obsłużyć obciążenie zapisu. Niedowymiarowane repliki nie są kandydatami do promocji.

Wdrożenia Blue/Green i pamięć masowa

Wdrożenia RDS Blue/Green tworzą pełną kopię przejściową (stagingową) środowiska produkcyjnego (zielonego), która pozostaje z nim zsynchronizowana za pomocą replikacji logicznej. Na środowisku zielonym można zaktualizować wersję silnika, zmienić grupy parametrów lub zmodyfikować schematy, przetestować je, a następnie przełączyć ruch w czasie krótszym niż minuta dzięki automatycznej zmianie nazw punktów końcowych. Eliminuje to klasyczne ryzyko związane z aktualizacją w miejscu (in-place), gdzie nieudana aktualizacja do wyższej wersji wymusza przywracanie ze zrzutu (snapshotu).

Wybór pamięci masowej ma równie duże znaczenie co klasa instancji dla systemów OLTP o dużej intensywności zapisu. Taksonomia gp3/io2:

Udoskonalenie gp3 w stosunku do gp2 polega na oddzieleniu liczby IOPS od rozmiaru — nie trzeba już nadmiarowo alokować pojemności w celu uzyskania wydajności. Wybierz io2, gdy utrzymywana liczba IOPS przekracza limit gp3 lub gdy wymagana jest trwałość na poziomie 99,999%. Multi-Attach pozwala na podłączenie jednego woluminu io2 do maksymalnie 16 instancji Nitro, ale system plików lub aplikacja musi być świadoma istnienia klastra; nie jest to substytut replikacji. Ukryta pułapka prowadząca do awarii: alokowanie stałej przestrzeni dyskowej bez włączonego autoskalowania pamięci masowej lub bez alarmu CloudWatch dla metryki FreeStorageSpace. Gdy wolne miejsce spadnie do zera, RDS przechodzi w stan storage-full i odrzuca operacje zapisu.

Amazon Aurora: Architektura i endpointy

Aurora implementuje na nowo warstwę storage dla MySQL i PostgreSQL jako rozproszony wolumen o strukturze dziennika (log-structured), replikowany sześciokrotnie w trzech Strefach Dostępności (AZ). Węzły obliczeniowe są bezstanowe w odniesieniu do warstwy storage, więc replika Aurora odczytuje dane z tego samego wolumenu co instancja zapisująca, zamiast odtwarzać dziennik transakcji. Opóźnienie replikacji (replication lag) wynosi zazwyczaj 10–20 ms, w porównaniu do sekund w przypadku standardowych replik RDS, a klaster obsługuje do 15 replik, które można awansować na instancję zapisującą w około 30 sekund.

Aurora udostępnia cztery typy endpointów:

Niestandardowe endpointy mają znaczenie, gdy repliki są heterogeniczne. Jeśli trzy z sześciu replik to db.r6g.8xlarge przeznaczone do raportowania analitycznego, a reszta obsługuje odczyty OLTP, ogólny endpoint odczytu może czasami kierować zapytania raportowe do mniejszych węzłów, co szkodzi przewidywalności. Niestandardowy endpoint ograniczony tylko do dużych replik zapewnia deterministyczną izolację obciążeń:

aws rds create-db-cluster-endpoint \
  --db-cluster-identifier prod-aurora \
  --db-cluster-endpoint-identifier reporting \
  --endpoint-type READER \
  --static-members reporting-node-1 reporting-node-2 reporting-node-3

Należy pamiętać, że TTL dla DNS endpointów Aurora wynosi 5 sekund; dłuższe buforowanie connection stringów niweczy działanie mechanizmu failover.

Aurora Auto Scaling dodaje i usuwa repliki odczytu na podstawie docelowych metryk użycia CPU lub liczby połączeń, co jest kanoniczną odpowiedzią na potrzeby nieprzewidywalnych, intensywnych pod względem odczytów obciążeń, które muszą pozostać wysoko dostępne:

TargetTrackingScalingPolicyConfiguration:
  PredefinedMetricSpecification:
    PredefinedMetricType: RDSReaderAverageCPUUtilization
  TargetValue: 60.0
  ScaleInCooldown: 300
  ScaleOutCooldown: 60

Gdy repliki odczytu RDS MySQL nie są w stanie utrzymać opóźnienia replikacji poniżej jednej sekundy w okresach szczytowego obciążenia, prostym rozwiązaniem jest migracja do Aurora MySQL — connection stringi prawie się nie zmieniają, a replikacja na poziomie storage eliminuje opóźnienie.

Aurora Serverless v2 i klonowanie

Aurora Serverless v2 skaluje moc obliczeniową wertykalnie w precyzyjnych jednostkach Aurora Capacity Units (ACU, każda 2 GiB pamięci) w czasie około pół sekundy, bez rozłączania sesji. Nadaje się do zmiennych obciążeń o znanej bazowej zajętości pamięci — na przykład po migracji lokalnej bazy MySQL, która zawsze zużywa co najmniej 2 GiB. Ustawiając minimum na 1 ACU i maksimum na 32 ACU, klaster elastycznie dostosowuje się bez potrzeby administracji. Aurora w trybie Provisioned pozostaje lepszym wyborem, gdy obciążenie jest stałe i przewidywalne, ponieważ Serverless v2 wiąże się z dodatkową opłatą za każdą jednostkę ACU.

Klonowanie Aurora tworzy nowy klaster, który współdzieli strony storage z klastrem źródłowym za pomocą mechanizmu copy-on-write. Klony pojawiają się w ciągu kilku sekund i nie generują kosztów, dopóki dane nie zaczną się różnić, co czyni je idealnymi dla środowisk deweloperskich/testowych (staging), ryzykownych migracji lub do umożliwienia analitykom intensywnej pracy na kopii produkcyjnej. Przywracanie z migawki fizycznie odtwarza dane i może trwać godzinami; klonowanie wygrywa, gdy liczy się szybkość.

Aurora Global Database

Aurora Global Database rozszerza klaster na maksymalnie pięć regionów drugorzędnych (secondary), wykorzystując dedykowaną infrastrukturę replikacji na poziomie warstwy storage, a nie przesyłanie binlogów. Typowe opóźnienie replikacji jest poniżej jednej sekundy, RPO (Recovery Point Objective) jest poniżej jednej sekundy, a zarządzany failover awansuje region drugorzędny w mniej niż minutę.

Dwie kluczowe kwestie: regiony drugorzędne są tylko do odczytu podczas normalnej pracy, a Global Database jest zaprojektowana z myślą o odzyskiwaniu po awarii z niskim RPO i zdalnych odczytach o niskim opóźnieniu, a nie o architekturze active-active multi-master. Założenie, że globalna baza danych „automatycznie obsługuje zapisy w regionie drugorzędnym” jest błędne — zapisy w tym regionie wymagają jawnego, zarządzanego przełączenia awaryjnego (failover) lub operacji odłączenia i awansowania (detach-and-promote). Dla podanego wymagania 5-minutowego RPO / 20-minutowego RTO między regionami przy minimalnym narzucie operacyjnym, Aurora Global Database jest kanoniczną odpowiedzią.

RDS Proxy i zarządzanie połączeniami

Obciążenia bezserwerowe i o wysokiej współbieżności potęgują klasyczny problem: burze połączeń (connection storms). Funkcja Lambda skalująca się do 3000 współbieżnych wykonań otwiera 3000 gniazd, przekraczając limit max_connections i powodując awarie kaskadowe — dokładnie wtedy, gdy system jest pod największym obciążeniem. Pule połączeń wewnątrz funkcji nie pomagają, ponieważ każde współbieżne środowisko wykonawcze jest izolowane.

RDS Proxy działa jako pośrednik między klientami a bazą danych, utrzymując „rozgrzaną” pulę połączeń i multipleksując na nich sesje klientów. Rozwiązuje dwa problemy:

1. Burze połączeń. Tysiące sesji klienckich są multipleksowane na małą pulę połączeń z bazą danych.
2. Czas przełączenia awaryjnego (failover). Proxy utrzymuje otwarte połączenia klienckie podczas ponownego nawiązywania połączenia z bazą danych, skracając postrzegany czas przełączenia nawet o 66% i eliminując potrzebę ponownego nawiązywania połączeń TCP/TLS oraz ponownego rozwiązywania nazw DNS po stronie klienta.

Integruje się z IAM i Secrets Manager w celu obsługi poświadczeń, eliminując zaszyte na stałe sekrety z kodu aplikacji.

DBProxy:
  Type: AWS::RDS::DBProxy
  Properties:
    EngineFamily: POSTGRESQL
    RequireTLS: true
    IdleClientTimeout: 1800
    Auth:
      - AuthScheme: SECRETS
        SecretArn: !Ref DBSecret
        IAMAuth: REQUIRED

Aplikacje łączą się z endpointem proxy, a nie z endpointem klastra. Każda architektura typu Lambda-do-RDS lub o wysokim stopniu rozproszenia (high-fan-out) powinna używać RDS Proxy, chyba że istnieją konkretne przeciwwskazania. Uruchomienie własnego poolera (np. PgBouncer, ProxySQL) na EC2 jest możliwe, ale dodaje narzut operacyjny, który proxy ma na celu wyeliminować.

DynamoDB: Tryby pojemności

DynamoDB to zarządzany magazyn klucz-wartość/dokumentów o opóźnieniach na poziomie jednocyfrowych milisekund przy dowolnej skali, partycjonowany horyzontalnie według klucza skrótu (hash key). Oferuje dwa tryby pojemności:

Tryb na żądanie jest znacznie prostszy, ale kosztuje około 6–7 razy więcej za żądanie niż dobrze wykorzystana pojemność aprowizowana. W przypadku nocnego, 4-godzinnego zadania wsadowego o wydajności 500 WCU, tryb na żądanie generuje znaczną nadpłatę — pojemność aprowizowana z planowanym skalowaniem lub pojemnością rezerwowaną jest znacznie tańsza. Z drugiej strony, użycie pojemności aprowizowanej dla nieprzewidywalnego obciążenia związanego z publicznym uruchomieniem produktu prowadzi do dławienia (throttlingu). Dla stałych obciążeń o umiarkowanej zmienności, pojemność aprowizowana z auto-scalingiem typu target-tracking ustawionym na około 70% wykorzystania jest znacząco tańsza niż tryb na żądanie — często o 50–70%:

TargetTrackingScalingPolicyConfiguration:
  TargetValue: 70.0
  PredefinedMetricSpecification:
    PredefinedMetricType: DynamoDBReadCapacityUtilization
  ScaleInCooldown: 60
  ScaleOutCooldown: 60

Tryby można przełączać raz na 24 godziny. Zakładanie, że tryb na żądanie jest uniwersalnie tańszy, to kosztowny błąd; podobnie jak zakładanie, że tryb aprowizowany jest zawsze odpowiedni dla ruchu o charakterze szczytowym.

DynamoDB: Spójność, Strumienie, Tabele Globalne

Odczyty domyślnie są ostatecznie spójne (mogą zwrócić nieaktualne dane w ciągu ~1 sekundy, kosztują 0,5 RCU). Ustawienie ConsistentRead=true zwraca najnowszą zatwierdzoną wartość za podwójny koszt. Silnie spójne odczyty nie są obsługiwane przez globalne indeksy wtórne (global secondary indexes) ani przez DAX — te ścieżki zawsze zwracają dane ostatecznie spójne.

DynamoDB Streams przechwytują zmiany na poziomie elementów jako uporządkowany log przechowywany przez 24 godziny, wyzwalając Lambdę do dalszego przetwarzania (indeksowanie w wyszukiwarkach, powiadomienia, denormalizacja między tabelami) bez konieczności odpytywania (polling).

Global Tables bazują na Strumieniach, aby zapewnić replikację multi-active, multi-Region z rozwiązywaniem konfliktów metodą „last-writer-wins” (ostatni zapisujący wygrywa). Są właściwym rozwiązaniem, gdy odczyty i zapisy muszą być lokalne w wielu regionach. Jednakże, mniej więcej podwajają koszty przechowywania i zapisu — każdy zapis to WCU w każdym regionie repliki — i osłabiają spójność między regionami. Pułapką jest włączanie Global Tables, gdy pojedynczy region spełnia wymagania dostępności: DynamoDB w jednym regionie jest już replikowane w trzech strefach dostępności (AZ) z dostępnością na poziomie 99,99%. Efektywnym kosztowo rozwiązaniem wysokiej dostępności (HA) w jednym regionie jest tabela w jednym regionie z włączonym PITR i, w razie potrzeby, aprowizowaną pojemnością z auto-scalingiem.

Point-in-Time Recovery (PITR) zapewnia ciągłe kopie zapasowe z granularnością odtwarzania co do sekundy za ostatnie 35 dni przy znikomym narzucie. Włącz tę funkcję na każdej tabeli produkcyjnej — spełnia ona typowe wymagania RPO rzędu minut, a nie godzin. W celu dłuższego przechowywania danych (wymogi regulacyjne), zintegruj AWS Backup w celu tworzenia zaplanowanych, zarządzanych cyklem życia i możliwych do kopiowania między regionami kopii zapasowych.

TTL pozwala określić atrybut zawierający czas wygaśnięcia w formacie Unix epoch; DynamoDB asynchronicznie usuwa wygasłe elementy bez dodatkowych kosztów, co jest idealne dla magazynów sesji, tokenów efemerycznych lub pamięci podręcznych zdarzeń. Usunięcia TTL przepływają przez Strumienie w celu dalszej archiwizacji:

TTLSpecification:
  AttributeName: expireAt
  Enabled: true

Do celów analitycznych, eksport do S3 tworzy migawkę w punkcie w czasie, którą można odczytać za pomocą Athena, Redshift Spectrum lub EMR bez zużywania pojemności tabeli — jest to znacznie lepszy wzorzec niż skanowanie tabeli.

DAX: DynamoDB Accelerator

DAX to w pełni zarządzana, pamięć podręczna typu in-memory i write-through, przeznaczona specjalnie dla DynamoDB, zapewniająca opóźnienie odczytu na poziomie mikrosekund w porównaniu do bazowego opóźnienia DynamoDB na poziomie jednocyfrowych milisekund. Jego wyróżniającą cechą jest kompatybilność API: klient DAX jest bezpośrednim zamiennikiem klienta SDK DynamoDB, więc aplikacje adaptują go poprzez zmianę konfiguracji punktu końcowego, a nie przepisywanie logiki zapytań:

import amazondax
dax = amazondax.AmazonDaxClient(
    endpoint_url='dax://cluster.abc.dax-clusters.us-east-1.amazonaws.com')
table = dax.Table('Products')
resp = table.get_item(Key={'sku': '1234'})  # microsecond hit path

DAX utrzymuje dwie pamięci podręczne: pamięć podręczną elementów (item cache) dla wyników GetItem/BatchGetItem oraz pamięć podręczną zapytań (query cache) dla wyników Query/Scan. Zapisy są typu write-through — DAX działa jako proxy do DynamoDB i aktualizuje swoją pamięć podręczną elementów po pomyślnym zapisie — ale pamięć podręczna zapytań opiera się na TTL, więc wyniki zapytań mogą stać się nieaktualne nawet dla świeżo zapisanych elementów.

Istotne są dwa ograniczenia. Po pierwsze, DAX przyspiesza tylko odczyty ostatecznie spójne; silnie spójne odczyty omijają pamięć podręczną. Po drugie, inni zapisujący, którzy omijają DAX, powodują nieaktualność danych. Dla strony ze szczegółami produktu odwiedzanej miliony razy dziennie, DAX jest akceleratorem o najmniejszym narzucie operacyjnym — bez kodu do unieważniania pamięci podręcznej, bez oddzielnego zarządzania klastrem. ElastiCache przed DynamoDB zadziałałby, ale wymaga logiki cache-aside, którą DAX czyni zbędną.

ElastiCache: Redis i Memcached

ElastiCache dostarcza dostęp do danych w pamięci z opóźnieniem poniżej milisekundy jako usługa zarządzana, uruchamiając Redis lub Memcached. Wybór silnika zależy od wymaganych funkcji:

• Memcached — czysta, wielowątkowa pamięć podręczna typu klucz-wartość z shardingiem horyzontalnym, bez trwałości, bez replikacji, bez pub/sub. Używaj tylko do efemerycznego buforowania, gdzie utrata całej pamięci podręcznej jest akceptowalna.
• Redis — obsługuje replikację, Multi-AZ z automatycznym przełączaniem awaryjnym (failover), tryb klastra do shardingu, trwałość, pub/sub, posortowane zbiory (sorted sets), transakcje oraz szyfrowanie danych w tranzycie i w spoczynku. Wymagany do wszystkiego, co wymaga trwałości lub złożonych typów danych.

Dominują dwa kanoniczne wzorce.

Scentralizowany magazyn sesji. Gdy ALB rozdziela ruch pomiędzy bezstanowe instancje EC2 lub ECS, lokalne przechowywanie sesji wymusza sesje lepkie (sticky sessions), co prowadzi do nierównomiernego obciążenia i powoduje problemy podczas skalowania w dół (scale-in), wdrożeń i awarii Stref Dostępności (AZ). Przeniesienie sesji na zewnątrz do Redis pozwala każdej instancji obsłużyć dowolne żądanie, a sesje przetrwają awarię hosta:

import redis, json
r = redis.Redis(host='sessions.abc123.ng.0001.use1.cache.amazonaws.com',
                port=6379, ssl=True)

def save_session(sid, data, ttl=1800):
    r.setex(f"sess:{sid}", ttl, json.dumps(data))

Odciążenie odczytu dla kosztownych zapytań — tablice wyników (posortowane zbiory Redis za pomocą ZADD/ZREVRANGE), wyszukiwania w katalogach, agregacje. Strategie buforowania muszą odpowiadać potrzebom spójności danych:

• Leniwe ładowanie (cache-aside): aplikacja odczytuje dane z pamięci podręcznej; w przypadku braku trafienia (cache miss), odczytuje je z bazy danych i umieszcza w pamięci podręcznej z określonym czasem życia (TTL). Proste, ale zimne starty (cold misses) są kosztowne, a dane mogą być nieaktualne.
• Zapis bezpośredni (write-through): aplikacja zapisuje dane do pamięci podręcznej i bazy danych w tej samej operacji. Pamięć podręczna pozostaje aktualna, ale zapisy są wolniejsze, a nieużywane dane nadal zajmują pamięć.
• Zapis z opóźnieniem (write-back / write-behind): zapisy trafiają najpierw do pamięci podręcznej, a następnie są asynchronicznie zapisywane w bazie danych. Najszybsze zapisy, ale awaria pamięci podręcznej powoduje utratę danych.

data = r.get(f"product:{sku}")
if data is None:
    data = db.query("SELECT * FROM products WHERE sku=%s", sku)
    r.setex(f"product:{sku}", 300, serialize(data))

Poleganie na jakiejkolwiek warstwie buforowania bez strategii unieważniania — TTL, jawne DEL przy aktualizacji lub write-through — prowadzi do odczytów nieaktualnych danych. Tryb awarii jest cichy: aplikacja wydaje się działać poprawnie, dopóki użytkownicy nie zauważą rozbieżności. Buforowanie jest również często najtańszym sposobem na skalowanie odczytów ponad to, co wygodnie obsługują repliki do odczytu (read replicas) i chroni główną bazę danych (primary) podczas gwałtownych wzrostów ruchu.

W przeciwieństwie do DAX, ElastiCache jest niezależny od silnika — jesteś odpowiedzialny za logikę unieważniania — dlatego DAX wygrywa pod względem prostoty operacyjnej, gdy bazą danych jest DynamoDB.

Migracja: DMS i SCT

AWS Database Migration Service (DMS) replikuje dane między silnikami homogenicznymi (Oracle→Oracle, MySQL→Aurora MySQL) lub heterogenicznymi (Oracle→Aurora PostgreSQL, SQL Server→RDS MySQL, on-prem→DynamoDB). Zadanie DMS składa się z trzech faz:

1. Pełne ładowanie (Full load) — masowe kopiowanie istniejących wierszy.
2. CDC (change data capture) — śledzenie dziennika transakcji źródła i aplikowanie bieżących zmian.
3. Pełne ładowanie + CDC — popularny wzorzec minimalizujący przestoje: źródło pozostaje online, DMS utrzymuje synchronizację celu, a przełączenie (cutover) to krótka zmiana w DNS.

aws dms create-replication-task \
  --replication-task-identifier ora-to-aurora \
  --source-endpoint-arn $SRC --target-endpoint-arn $TGT \
  --migration-type full-load-and-cdc \
  --table-mappings file://mappings.json \
  --replication-instance-arn $RI

DMS Serverless eliminuje potrzebę dobierania rozmiaru i zarządzania instancjami replikacyjnymi — pojemność jest automatycznie przydzielana w zależności od obciążenia, co jest idealne dla zmiennych lub długotrwałych zadań CDC. Silniki źródłowe muszą mieć włączone logowanie uzupełniające (supplemental logging w Oracle) lub logowanie binarne w formacie ROW (MySQL). Dla bardzo dużych zestawów danych początkowych, DMS integruje się z Snowball Edge w celu ładowania offline.

DMS przenosi dane, a nie schemat. W przypadku migracji heterogenicznych używa się go w parze z AWS Schema Conversion Tool (SCT), który konwertuje procedury składowane, widoki, wyzwalacze, sekwencje i typy specyficzne dla danego dialektu — na przykład Oracle PL/SQL na PostgreSQL PL/pgSQL lub T-SQL na Aurora MySQL. SCT generuje raport oceniający, który wskazuje obiekty wymagające ręcznej poprawy (zazwyczaj 5–20% w przypadku złożonych baz kodu). Używanie samego DMS do migracji między silnikami to częsty błąd: chociaż DMS potrafi tworzyć podstawowe tabele docelowe, nie tłumaczy poprawnie procedur ani typów własnościowych. W przypadku migracji homogenicznych SCT jest niepotrzebny — wystarczą natywne narzędzia (mysqldump, pg_dump, RMAN) w połączeniu z DMS CDC.

Pełny wzorzec migracji między silnikami:

1. SCT: convert schema, apply to target RDS/Aurora
2. DMS full-load task: bulk copy existing data
3. DMS CDC task: capture ongoing changes from source
4. Cutover: stop writes at source, wait for CDC lag = 0, redirect app

Kopie zapasowe i odzyskiwanie do punktu w czasie (Point-in-Time Recovery)

Automatyczne kopie zapasowe RDS łączą codzienne migawki (snapshots) z kopiami dziennika transakcji wykonywanymi co 5 minut, umożliwiając odzyskiwanie do punktu w czasie (PITR) z dokładnością do sekundy w ramach okna retencji (1–35 dni, domyślnie 7). Odtwarzanie tworzy nową instancję — nie można odtworzyć danych w miejscu istniejącej instancji — więc punkty końcowe aplikacji lub rekordy CNAME muszą zostać zaktualizowane. Ręczne migawki są przechowywane dłużej niż okres retencji i przetrwają usunięcie instancji (zależnie od ustawienia tworzenia końcowej migawki), mogą być kopiowane między regionami w celach odtwarzania po awarii (DR) i udostępniane między kontami.

Fast Snapshot Restore (FSR) dla migawek opartych na EBS eliminuje karę za wydajność związaną z leniwym ładowaniem (lazy-load), zapewniając odtworzonym woluminom natychmiastową pełną wydajność — przydatne przy szybkim uruchamianiu wielu środowisk z jednej migawki pod presją czasu. Klonowanie w Aurora całkowicie omija migawki przy tworzeniu kopii w tym samym regionie. PITR w DynamoDB to analogiczna funkcja, którą należy włączyć dla każdej tabeli i która podczas odtwarzania tworzy nową tabelę.

Specjalizowane bazy danych

Wybór specjalizowanego silnika, gdy wymagają tego wzorce dostępu, zapobiega kosztownej re-architekturze. Amazon Neptune to zarządzana grafowa baza danych obsługująca Gremlin, openCypher i SPARQL — odpowiednia, gdy zapytania przechodzą przez relacje (siatki oszustw, grafy społeczne, grafy wiedzy), gdzie rekurencyjne złączenia (joins) w silniku relacyjnym byłyby zaporowo kosztowne. Amazon QLDB to niezmienny, kryptograficznie weryfikowalny rejestr (ledger) z dziennikiem tylko do dopisywania (append-only), odpowiedni dla systemów źródłowych (systems of record) wymagających audytu odpornego na manipulacje — śledzenie pochodzenia w łańcuchu dostaw, transakcje finansowe, ewidencja pojazdów. DynamoDB jest domyślnym wyborem dla dostępu do danych klucz-wartość lub dokumentów w dowolnej skali z opóźnieniem rzędu kilku milisekund, używając wzorców takich jak projekt jednej tabeli (single-table design), złożone klucze sortowania (composite sort keys) do dostępu hierarchicznego oraz GSI do alternatywnych ścieżek dostępu. Wpychanie tych obciążeń do RDS tworzy rywalizację o blokady (zapisy do rejestru), złożoność zapytań (przechodzenie po grafie) lub limity skalowalności (wysokoprzepustowe operacje klucz-wartość) — każdy z tych problemów jest znacznie droższy do naprawienia w późniejszym etapie niż dokonanie właściwego wyboru na etapie projektowania.

Podsumowanie pułapek

• Read replicas jako rozwiązanie HA. Replikacja asynchroniczna, brak automatycznego promowania, zmiana punktu końcowego (endpoint) po promowaniu, utrata transakcji w toku. Odpowiedzią na potrzeby HA jest Multi-AZ.
• Multi-AZ do skalowania odczytu. Instancja standby nie jest dostępna do odczytu w standardowym wdrożeniu RDS Multi-AZ. Należy używać replik odczytu (read replicas) lub replik Aurora.
• Produkcja w Single-AZ. Brak celu przełączania awaryjnego (failover); utrata dostępności podczas dowolnego zdarzenia w AZ lub restartu instancji. Multi-AZ to około 2x wyższy koszt za jakościowy skok dostępności.
• Replika domyślnie tego samego rozmiaru co instancja główna. Replikom często wystarczają znacznie mniejsze zasoby; należy dobrać ich rozmiar do zmierzonego obciążenia, chyba że replika ma być celem promowania.
• DynamoDB On-demand zawsze tańsze. Koszt per żądanie jest około 6-7x wyższy; dla stabilnych obciążeń korzystniejszy jest tryb provisioned z auto-scalingiem.
• Global Tables dla potrzeb jednego regionu. Podwaja koszt i osłabia spójność bez żadnych korzyści, chyba że wymagana jest bliskość użytkowników w wielu regionach lub DR (Disaster Recovery).
• Drugorzędne bazy danych Aurora Global Database obsługują zapisy. Są one dostępne tylko do odczytu, dopóki zarządzane przełączenie awaryjne (failover) ich nie promuje.
• Lambda → RDS bez RDS Proxy. Burza połączeń (connection storm) wyczerpuje limit max_connections; pule połączeń wewnątrz funkcji nie pomagają przy współbieżnych środowiskach wykonawczych.
• Sam DMS do migracji heterogenicznych. Przenosi dane, ale nie schemat. Należy używać go w parze z SCT.
• Stały rozmiar pamięci masowej RDS bez autoskalowania lub alarmów FreeStorageSpace. Ukryta przyczyna awarii — stan storage-full odrzuca operacje zapisu.
• Cache’owanie bez strategii unieważniania. Ciche starzenie się danych (silent staleness). Czas życia (TTL), zapis przelotowy (write-through) lub jawne unieważnianie są nieodzowne.
• Silnie spójne odczyty przez DAX lub GSI. Obie te ścieżki zapewniają jedynie dane ostatecznie spójne (eventually consistent).

← Dostarczanie treści · Wszystkie domeny · Analityka →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Amazon →