Amazon DVA-C02: Bazy danych i buforowanie (RDS, Aurora, ElastiCache, Timestream, Proxy) — Przewodnik do nauki

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Część AWS Developer Associate DVA-C02 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

RDS i Aurora: projektowanie, skalowanie i szyfrowanie

Projektowanie relacyjnych baz danych na RDS lub Aurora zaczyna się od analizy kompromisów związanych z obciążeniem, porównując jednowęzłową, provisioned instancję RDS z rozproszoną warstwą storage w Aurora. Wybierz Aurora, gdy potrzebujesz wysokiej skalowalności odczytów i szybkiego przełączania awaryjnego (failover): repliki Aurora współdzielą wolumen klastra, więc ich promocja jest szybka, podczas gdy repliki odczytu (read replicas) RDS dla MySQL/Postgres używają asynchronicznej replikacji opartej na binlogu i mogą mieć opóźnienia. Aby skalować odczyty, dodaj repliki odczytu i kieruj na nie ruch odczytu z aplikacji; w Aurora użyj endpointów typu reader, aby automatycznie równoważyć obciążenie między replikami. W przypadku zapisów liczy się skalowanie wertykalne (klasa instancji) oraz staranne projektowanie schematu i indeksów. Zawsze włączaj szyfrowanie w spoczynku (at rest) za pomocą klucza CMK z KMS w momencie tworzenia zasobu — późniejsze włączenie szyfrowania wymaga wykonania snapshotu i odtworzenia go jako nowej, zaszyfrowanej instancji; to częsta pułapka. W celu ochrony danych w trakcie przesyłania (in-transit) wymuszaj połączenia TLS/SSL (RDS dostarcza pakiety CA). Do zarządzania danymi uwierzytelniającymi preferuj AWS Secrets Manager z automatyczną rotacją, używając wbudowanego szablonu Lambda do rotacji dla RDS; programistycznie pobieraj sekrety za pomocą SecretsManager.getSecretValue() w SDK. Rozważ uwierzytelnianie IAM dla bazy danych, aby wyeliminować statyczne hasła: wygeneruj token za pomocą RDS.Signer (SDK) lub rds.generate-db-auth-token, a następnie połącz się, używając krótkożyjącego tokenu. Instrumentuj za pomocą Performance Insights, Enhanced Monitoring i CloudWatch; używaj logów wolnych zapytań (slow query logs) i EXPLAIN do identyfikacji wąskich gardeł (hotspotów).

Pule połączeń, RDS Proxy i wzorce serverless

Funkcje serverless i aplikacje o dużej liczbie połączeń często wyczerpują limity połączeń bazy danych. Prosty wzorzec w Node.js polega na umieszczeniu puli połączeń mysql2/promise w globalnym zasięgu (scope) funkcji Lambda i ponownym jej wykorzystywaniu między wywołaniami, ale nie rozwiązuje to problemu masowego skalowania współbieżnego. Zarządzaną odpowiedzią jest RDS Proxy: utwórz proxy za pomocą create_db_proxy, powiąż je z sekretami z Secrets Manager i docelowymi instancjami RDS/Aurora, a następnie użyj endpointu proxy w swojej aplikacji. RDS Proxy obsługuje multipleksowanie połączeń, integrację z uwierzytelnianiem IAM oraz przełączanie awaryjne (failover). W przypadku Aurora Serverless lub gdy preferujesz wywołania w stylu HTTP, użyj RDS Data API: wywołanie rdsdataservice.executeStatement({resourceArn, secretArn, sql, database}) pozwala funkcjom Lambda wykonywać zapytania SQL bez utrzymywania trwałych połączeń TCP. Częstym haczykiem jest mieszanie Data API z klastrami provisioned — Data API jest przeznaczone dla klastrów serverless i ma inną semantykę opóźnień i transakcji. Pamiętaj również, że RDS Proxy wprowadza connection pool timeout i max_connections; dostosuj idle client timeout i mechanizm zapożyczania połączeń (connection borrowing) pod kątem nagłych wzrostów ruchu (bursts) z Lambdy. Używaj SecretsManager.getSecretValue() do pobierania danych uwierzytelniających i rotuj je za pomocą rotateSecret lub włącz automatyczną rotację w konsoli/SDK.

Strategie buforowania: ElastiCache, DAX i projektowanie cache’u

Wybór strategii buforowania zależy od magazynu danych i wzorców dostępu. Dla DynamoDB, DAX zapewnia mikrosekundowe opóźnienia odczytu i przezroczystą integrację z SDK poprzez AmazonDaxClient, który opakowuje DynamoDB.DocumentClient; jest to idealne rozwiązanie dla obciążeń z dużą ilością odczytów, opartych na modelu eventual consistency. Do buforowania danych relacyjnych lub dowolnych danych typu klucz-wartość, użyj ElastiCache Redis dla zaawansowanych struktur danych, trwałości (snapshoty AOF/RDB), replikacji i shardingu w trybie klastra, lub Memcached dla prostego, horyzontalnie skalowalnego buforowania. Zaimplementuj wzorzec cache-aside dla odczytów, a write-through/write-behind tylko wtedy, gdy jest to akceptowalne pod względem spójności i złożoności. Projektowanie kluczy jest kluczowe: dodawaj do nich prefiksy z nazwą aplikacji i wersją, używaj rozsądnych wartości TTL i unikaj nieograniczonej kardynalności. Radź sobie z nawałnicami na cache (cache stampedes) za pomocą wzorców typu lock-and-refresh (SETNX lub Redlock) lub probabilistycznego wczesnego odświeżania TTL. Skonfiguruj Redis z multi-AZ i automatycznym failover; twórz grupy replikacyjne (replication groups) z automatycznym failover i snapshotami za pomocą CreateReplicationGroup. Częste pułapki to nieaktualny cache po zapisach, brak unieważniania przy zmianach schematu oraz oczekiwanie absolutnej spójności. Monitoruj współczynnik trafień w cache (cache hit ratio) i metryki usunięć (eviction metrics) w CloudWatch, a także skaluj typy węzłów lub shardy klastra, gdy pamięć lub CPU stają się wąskim gardłem.

Szeregi czasowe z Timestream i wzorce replik do odczytu

Amazon Timestream jest usługą stworzoną specjalnie do obsługi szeregów czasowych: pozyskiwanie danych odbywa się za pomocą API WriteRecords z SDK z wykorzystaniem wsadowych wywołań WriteRecords, a zapytania wykonuje się za pomocą TimestreamQuery.query(sql). Projektuj schemat rekordów z wymiarami o niskiej kardynalności i używaj rekordów z wieloma miarami (multi-measure records), aby zredukować amplifikację zapisu. Konfiguruj reguły retencji dla warstwy pamięci (memory) i magnetycznej (magnetic) dla każdej tabeli, aby przechowywać najnowsze dane w trybie „hot” i tanio składować starsze dane; dostosowywanie retencji jest kluczowe, ponieważ rozmiar retencji w warstwie pamięci wpływa na koszty i wydajność zapytań. Do analityki używaj zapytań specyficznych dla szeregów czasowych (time_bin lub bin) i stosuj filtrowanie „push down” na wymiarach, aby zminimalizować ilość skanowanych danych. Integrując szeregi czasowe z relacyjnymi bazami danych, przenoś historyczne, niezmienne dane do Timestream, a „gorące” metadane serwuj z RDS/Aurora przy użyciu ElastiCache. Aby skalować odczyty z baz relacyjnych, dodaj repliki do odczytu (read replicas) i kieruj na nie ruch tylko do odczytu; w przypadku Aurory używaj punktów końcowych typu „reader” i sprawdzaj opóźnienie replikacji (CloudWatch ReplicaLag) przed przekierowaniem krytycznych odczytów. Częstym błędem deweloperów jest stosowanie wysokiej kardynalności w Timestream lub kluczy cache’u generowanych dla każdego żądania, co prowadzi do gwałtownego wzrostu zużycia pamięci masowej i szkodzi wydajności. Używaj przetwarzania wsadowego dla zapisów oraz asynchronicznych potoków pozyskiwania danych (Kinesis, Firehose), aby wygładzać skoki obciążenia i unikać throttlingu.

Problem praktyczny: Scenariusz użycia

Scenariusz: NovaShop prowadzi wieloregionową platformę e-commerce w AWS, używając Aurora MySQL dla zamówień w regionie us-east-1, API opartych na Lambda oraz globalnego katalogu klientów w DynamoDB. Deweloperzy korzystają z CI/CD na jednym koncie AWS i przechowują poświadczenia do bazy danych w Secrets Manager.

Wyzwanie: Podczas gwałtownych wzrostów sprzedaży funkcje Lambda wyczerpują połączenia z bazą danych, a katalog wymaga odczytów z mikrosekundowym opóźnieniem; deweloperzy muszą zachować bezpieczeństwo dzięki rotowanym poświadczeniom i minimalnej latencji przy odczycie produktów.

Zalecane podejście:

1. Utwórz RDS Proxy dla klastra Aurora za pomocą CreateDBProxy, połącz je z ARN sekretu w Secrets Manager i skonfiguruj uwierzytelnianie IAM; zaktualizuj funkcje Lambda, aby używały punktu końcowego proxy i pobierały poświadczenia za pomocą SecretsManager.getSecretValue().
2. Dla katalogu wdróż klaster Amazon DAX i zmień klienta DynamoDB na AmazonDaxClient({endpoints}), który opakowuje DynamoDB DocumentClient, aby zapewnić odczyty z mikrosekundowym opóźnieniem.
3. Włącz automatyczną rotację w Secrets Manager dla sekretu Aurory, używając szablonu Lambda do rotacji RDS (rotate-secret lub konfiguracja przez konsolę) i upewnij się, że rola IAM funkcji Lambda ma uprawnienia do wywołania secretsmanager:GetSecretValue.
4. Dodaj klaster ElastiCache for Redis (w trybie „cluster mode”) do buforowania sesji i zaimplementuj wzorzec cache-aside z wartościami TTL oraz blokadą odświeżania SETNX, aby zapobiec zjawisku „stampede”.

Uzasadnienie: Użycie RDS Proxy zapobiega burzom połączeń (connection storms) wynikającym ze skalowania Lambda, podczas gdy IAM/Secrets Manager chroni poświadczenia dzięki automatycznej rotacji; DAX zapewnia mikrosekundowe odczyty z DynamoDB, a ElastiCache obsługuje tymczasowe buforowanie sesji/odczytów, co jest zgodne z najlepszymi praktykami skalowania serverless i bezpieczeństwa.

← Pamięć masowa · Wszystkie domeny · Obsługa wiadomości →

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

Przeglądaj Amazon →