Amazon DVA-C02: Database e Caching (RDS, Aurora, ElastiCache, Timestream, Proxy) — Guida allo studio
Fa parte della AWS Developer Associate DVA-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.
RDS e Aurora: progettazione, scalabilità e crittografia
La progettazione di database relazionali su RDS o Aurora inizia con la valutazione dei compromessi del carico di lavoro tra un’istanza RDS provisioned a nodo singolo e lo storage distribuito di Aurora. Scegli Aurora quando hai bisogno di elevata scalabilità in lettura e failover rapido: le repliche Aurora condividono il volume del cluster, quindi la promozione è veloce, mentre le repliche di lettura (read replica) di RDS MySQL/Postgres utilizzano una replica asincrona basata su binlog e possono presentare ritardi (lag). Per scalare le letture, aggiungi repliche di lettura e indirizza il traffico di lettura dell’applicazione verso di esse; usa gli endpoint di lettura (reader endpoint) in Aurora per bilanciare automaticamente il carico tra le repliche. Per le scritture, sono importanti la scalabilità verticale (classe di istanza) e un’attenta progettazione dello schema e degli indici. Abilita sempre la crittografia at-rest con una KMS CMK al momento della creazione: abilitare la crittografia in un secondo momento richiede uno snapshot e un ripristino in una nuova istanza crittografata; questa è una trappola comune. Per la protezione in-transit, imponi connessioni TLS/SSL (RDS fornisce i CA bundle). Per le credenziali, preferisci AWS Secrets Manager con rotazione automatica utilizzando il template Lambda predefinito per la rotazione di RDS; recupera programmaticamente i segreti con SecretsManager.getSecretValue() negli SDK. Considera l’autenticazione IAM DB per eliminare le password statiche: genera un token tramite RDS.Signer (SDK) o rds.generate-db-auth-token, quindi connettiti con un token di breve durata. Strumenta utilizzando Performance Insights, Enhanced Monitoring e CloudWatch; usa i log delle query lente (slow query log) e EXPLAIN per individuare gli hotspot.
Connection pooling, RDS Proxy e pattern serverless
Le funzioni serverless e le applicazioni con un numero elevato di connessioni esauriscono comunemente i limiti di connessione del DB. Il pattern più semplice in Node.js consiste nel posizionare un pool mysql2/promise nello scope globale della Lambda e riutilizzarlo tra le invocazioni, ma questo non risolve il problema della scalabilità con un’elevata concorrenza. RDS Proxy è la risposta gestita: crea il proxy con create_db_proxy, associalo ai segreti di Secrets Manager e alle istanze RDS/Aurora di destinazione, e usa l’endpoint del proxy dalla tua applicazione. RDS Proxy gestisce il multiplexing delle connessioni, l’integrazione con l’autenticazione IAM e il failover. Per Aurora Serverless o quando preferisci chiamate di tipo HTTP, usa la RDS Data API: rdsdataservice.executeStatement({resourceArn, secretArn, sql, database}) consente alle Lambda di eseguire SQL senza connessioni TCP persistenti. Un errore comune è mescolare la Data API con i cluster provisioned: la Data API è pensata per i cluster serverless e ha semantiche di latenza e transazione diverse. Tieni inoltre presente che RDS Proxy introduce un timeout del pool di connessioni e un max_connections; ottimizza il timeout del client inattivo (idle client timeout) e il prestito di connessioni (connection borrowing) per i picchi di esecuzione delle Lambda. Usa SecretsManager.getSecretValue() per le credenziali e ruotale con rotateSecret o abilita la rotazione automatica nella console/SDK.
Strategie di caching: ElastiCache, DAX e progettazione della cache
La scelta della strategia di caching dipende dal data store e dai pattern di accesso. Per DynamoDB, DAX offre una latenza di lettura nell’ordine dei microsecondi e un’integrazione trasparente con l’SDK tramite AmazonDaxClient, che funge da wrapper per DynamoDB.DocumentClient; è ideale per carichi di lavoro con molte letture (read-heavy) e a consistenza finale (eventually consistent). Per il caching di dati relazionali o di valori chiave-valore arbitrari, usa ElastiCache Redis per strutture dati avanzate, persistenza (snapshot AOF/RDB), replica e sharding in modalità cluster, oppure Memcached per un caching semplice e scalabile orizzontalmente. Implementa il pattern cache-aside per le letture e write-through/write-behind solo quando è accettabile in termini di consistenza e complessità. La progettazione delle chiavi è fondamentale: usa prefissi per applicazione e versione, imposta TTL ragionevoli ed evita la cardinalità illimitata. Gestisci le cache stampede con pattern di lock-and-refresh (SETNX o Redlock) o con un aggiornamento probabilistico anticipato del TTL. Configura Redis con multi-AZ e failover automatico; crea gruppi di replica (replication group) con failover automatico e snapshot tramite CreateReplicationGroup. Le trappole comuni includono dati obsoleti (stale) nella cache dopo le scritture, la mancata invalidazione in seguito a modifiche dello schema e l’aspettarsi una consistenza assoluta. Monitora il cache hit ratio e le metriche di eviction in CloudWatch e scala i tipi di nodo o gli shard del cluster quando la memoria o la CPU diventano un collo di bottiglia.
Serie temporali con Timestream e pattern di read-replica
Amazon Timestream è progettato specificamente per le serie temporali: l’ingestione avviene tramite l’API WriteRecords dell’SDK con chiamate WriteRecords in batch, e le query con TimestreamQuery.query(sql). Progetta lo schema dei record con dimensioni a bassa cardinalità e utilizza record multi-misura per ridurre l’amplificazione in scrittura (write amplification). Configura regole di retention per la memoria e per lo storage magnetico per ogni tabella, in modo da mantenere i dati recenti “hot” (ad accesso rapido) e archiviare a basso costo i dati più vecchi; la regolazione della retention è fondamentale perché la dimensione del tier di memoria influisce sui costi e sulle prestazioni delle query. Per l’analisi, utilizza query specifiche per serie temporali (time_bin o bin) ed effettua il push down dei filtri sulle dimensioni per minimizzare i dati scansionati. Quando si integrano serie temporali con database relazionali, sposta i dati storici immutabili su Timestream e servi i metadati “hot” da RDS/Aurora con ElastiCache. Per la scalabilità in lettura sui database relazionali, aggiungi read replica e instrada il traffico di sola lettura; per Aurora, utilizza i reader endpoint ed esamina il ritardo della replica (CloudWatch ReplicaLag) prima di instradare letture critiche. Un errore comune per gli sviluppatori (gotcha) è l’alta cardinalità in Timestream o nelle chiavi di caching prodotte per ogni richiesta, il che fa lievitare lo storage e peggiora le prestazioni. Utilizza il batching per le scritture e pipeline di ingestione asincrone (Kinesis, Firehose) per gestire i picchi di traffico ed evitare il throttling.
Problema Pratico: Scenario d’Uso
Scenario: NovaShop gestisce una piattaforma di e-commerce multi-regionale in AWS, utilizzando Aurora MySQL per gli ordini in us-east-1, con API basate su Lambda e un catalogo clienti globale in DynamoDB. Gli sviluppatori utilizzano CI/CD in un unico account AWS e archiviano le credenziali del DB in Secrets Manager.
Sfida: Durante i picchi di vendite, le funzioni Lambda esauriscono le connessioni al database e il catalogo richiede letture nell’ordine dei microsecondi; gli sviluppatori devono preservare la sicurezza con credenziali ruotate e garantire una latenza minima per la lettura dei prodotti.
Approccio Raccomandato:
- Creare un RDS Proxy per il cluster Aurora utilizzando CreateDBProxy, collegare l’ARN del segreto di Secrets Manager e configurare l’autenticazione IAM; aggiornare Lambda per utilizzare l’endpoint del proxy e SecretsManager.getSecretValue() per le credenziali.
- Per il catalogo, distribuire un cluster Amazon DAX e passare dal client DynamoDB a AmazonDaxClient({endpoints}), che funge da wrapper per il DynamoDB DocumentClient per letture nell’ordine dei microsecondi.
- Abilitare la rotazione automatica di Secrets Manager per il segreto di Aurora utilizzando il template Lambda di rotazione per RDS (rotate-secret o configurazione tramite console) e assicurarsi che il ruolo IAM di Lambda possa chiamare secretsmanager:GetSecretValue.
- Aggiungere un cluster ElastiCache for Redis (in modalità cluster) per il caching delle sessioni e implementare il pattern cache-aside con TTL e un lock di aggiornamento (SETNX) per prevenire le cache stampede.
Motivazione: L’uso di RDS Proxy previene le tempeste di connessioni (connection storm) dovute alla scalabilità di Lambda, mentre IAM/Secrets Manager protegge le credenziali con rotazione automatizzata; DAX fornisce letture da DynamoDB nell’ordine dei microsecondi ed ElastiCache gestisce il caching transitorio di sessioni/letture, allineandosi con le best practice di scalabilità e sicurezza serverless.
← Archiviazione · Tutti i domini · Messaggistica →
Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Supera l'esame →