Amazon SOA-C02: Database e caching — Guida allo studio

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Fa parte della AWS SysOps Administrator Associate SOA-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

I database e il caching sono responsabilità operative fondamentali per un amministratore SysOps: forniscono storage persistente, disponibilità e letture a bassa latenza per le applicazioni. Questo dominio copre l’esecuzione di database relazionali gestiti (RDS e Aurora), la scalabilità della capacità di lettura/scrittura, il comportamento di replica e failover e l’uso di ElastiCache per ridurre il carico sul DB. Una corretta configurazione di backup, gruppi di parametri, monitoraggio e pattern di invalidazione della cache previene la perdita di dati e riduce gli incidenti operativi.

Operazioni su RDS e Aurora, backup e Multi-AZ

RDS (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server) e Amazon Aurora (compatibile con MySQL e PostgreSQL) sono motori relazionali gestiti con semantiche operative diverse. Il Multi-AZ per RDS crea uno standby sincrono in un’altra AZ — gestito da AWS, con failover automatizzato in pochi minuti, nessuna promozione manuale e lo standby non è accessibile per le letture. Aurora separa gli endpoint di scrittura e di lettura: quello di scrittura è un endpoint di cluster supportato da un’istanza primaria, e Aurora utilizza uno storage distribuito che si replica automaticamente tra le AZ e tipicamente può eseguire il failover più rapidamente di RDS perché lo storage è condiviso.

Configurare backup e conservazione utilizzando:

Backup automatici: abilitarli con un periodo di conservazione (es. modify-db-instance –backup-retention-period 7). Questi forniscono il ripristino point-in-time (PITR) a qualsiasi secondo all’interno della finestra di conservazione per i motori supportati.
Snapshot manuali: create-db-snapshot (o create-db-cluster-snapshot per Aurora) per catturare uno snapshot da conservare; gli snapshot persistono finché non vengono eliminati.
Ripristino PITR: aws rds restore-db-instance-to-point-in-time per RDS, o restore-db-cluster-from-snapshot e poi creare le istanze per Aurora.

Criteri decisionali:

Usare Multi-AZ per alta disponibilità e failover automatizzato quando la disponibilità in scrittura è critica e le letture sullo standby non sono necessarie.
Usare Aurora (storage clusterizzato) quando si necessita di IOPS elevati, failover rapido e auto-scaling dello storage.
Usare le repliche di lettura (read replica) per la scalabilità in lettura e il disaster recovery cross-region (sono asincrone e possono essere promosse).

Esempi di CLI operativi:

Abilitare Multi-AZ: aws rds modify-db-instance –db-instance-identifier mydb –multi-az –apply-immediately
Creare snapshot automatico: aws rds create-db-snapshot –db-snapshot-identifier snap1 –db-instance-identifier mydb
Ripristinare PITR: aws rds restore-db-instance-to-point-in-time –source-db-instance-identifier mydb –target-db-instance-identifier mydb-restore –restore-time “YYYY-MM-DDTHH:MM:SSZ”

Repliche di lettura, failover e strategie di replica

Le repliche di lettura (read replica) sono copie asincrone (istanze di lettura RDS o Aurora) utilizzate principalmente per scalare il traffico di lettura ed eseguire l’offload del reporting. Comportano un ritardo di replica (monitorare la metrica ReplicaLag) e non sono adatte per una consistenza forte (strong consistency). Le repliche di lettura possono essere promosse a istanze DB standalone per supportare il disaster recovery.

Strategie e scelte di replica:

Sincrona (standby Multi-AZ di RDS) — garanzia di zero data drift, nessuna capacità di lettura sullo standby.
Repliche di lettura asincrone — scalano le letture, abilitano copie cross-region, rischio di ritardo della replica e potenziale perdita di dati in caso di failover.
Istanze di lettura Aurora — forniscono endpoint di lettura clusterizzati, failover a bassa latenza tramite re-routing degli endpoint e bilanciamento automatico degli endpoint di lettura.

Pattern operativi:

Creare una replica di lettura: aws rds create-db-instance-read-replica –db-instance-identifier read1 –source-db-instance-identifier primary
Promuovere una replica: aws rds promote-read-replica –db-instance-identifier read1
Monitorare: CloudWatch DatabaseConnections, ReplicaLag, ReadIOPS, WriteIOPS e Performance Insights per decidere quando aggiungere o rimuovere repliche.

Criteri decisionali:

Se si necessita di HA per le scritture, scegliere Multi-AZ. Se si necessita di throughput in lettura e offload per l’analisi, scegliere repliche di lettura o istanze di lettura Aurora.
Per il DR cross-region, creare repliche di lettura nella regione di destinazione e considerare la copia automatizzata di snapshot o DMS per la migrazione.

Caching con ElastiCache e invalidazione della cache

ElastiCache offre Redis e Memcached per ridurre il carico e la latenza del DB. Scegliere Redis quando si necessita di persistenza, replica, strutture dati e alta disponibilità con Multi-AZ e failover automatico. Scegliere Memcached per un caching orizzontale semplice dove lo sharding e le prestazioni multithread sono prioritarie.

Configurazioni e pattern chiave:

Creare un cluster Redis con repliche e Multi-AZ: aws elasticache create-replication-group –replication-group-id rg1 –replication-group-description “rg” –engine redis –num-cache-clusters 3 –automatic-failover-enabled
Usare la modalità cluster abilitata per Redis per scalare gli shard; Memcached richiede l’hashing lato client per lo sharding.
Politiche di eviction: volatile-lru, allkeys-lru, noeviction — da regolare in base alla preferenza di rimuovere solo le chiavi scadute o qualsiasi chiave quando la memoria è piena.
Monitorare CacheHits e CacheMisses per calcolare il cache hit ratio: hit_ratio = CacheHits / (CacheHits + CacheMisses). Puntare a un hit ratio elevato per ridurre le letture dal DB.

Strategie di invalidazione della cache:

Cache-aside: l’applicazione controlla prima la cache, in caso di miss legge dal DB e popola la cache; far scadere o eliminare esplicitamente la cache durante le scritture.
Write-through/write-behind: le scritture nella cache si propagano al DB; il write-behind raggruppa le scritture sul DB in batch (aggiunge complessità).
Time-to-live (TTL): impostare TTL conservativi per dati che possono diventare obsoleti; combinare con il versioning della cache o chiavi di invalidazione per modifiche allo schema o invalidazione di massa.
Usare il pub/sub di Redis o eventi Lambda per notificare le istanze dell’applicazione per un’invalidazione distribuita quando necessario.

Gruppi di parametri del database, scalabilità e monitoraggio

I gruppi di parametri controllano le impostazioni specifiche del motore (ad es., max_connections, innodb_buffer_pool_size). RDS utilizza i gruppi di parametri DB per le istanze e i gruppi di parametri del cluster DB per Aurora. Le modifiche ad alcuni parametri richiedono un riavvio (apply pending-reboot), altre vengono applicate immediatamente.

Pattern di gestione:

Creare e modificare un gruppo di parametri:

undefined

; poi

undefined

Scalare la classe dell’istanza:

undefined

(o durante la finestra di manutenzione per evitare un riavvio).

Autoscaling dello storage: abilitare per i tipi di motore supportati; Aurora scala automaticamente lo storage.

Segnali di monitoraggio e scalabilità:

Utilizzare CloudWatch (FreeableMemory, CPUUtilization, DatabaseConnections, WriteLatency, ReadLatency, DiskQueueDepth) e Performance Insights per SQL lenti e le attese principali (top waits).
Abilitare il Monitoraggio Avanzato (Enhanced Monitoring) e impostare la granularità (ad es., 1s per il troubleshooting).
Utilizzare RDS Proxy per gestire il connection pooling e ridurre le tempeste di connessioni (connection storms) per applicazioni serverless o ad alta concorrenza.

Procedure di backup/ripristino e considerazioni sulla migrazione

I backup e i ripristini devono essere espliciti e testati. I backup automatici forniscono il ripristino point-in-time (PITR) entro il periodo di retention; gli snapshot manuali vengono conservati fino alla loro eliminazione e possono essere copiati tra region e su chiavi KMS diverse. Essere espliciti riguardo alla region e al timestamp durante il ripristino.

Comandi di ripristino comuni:

Ripristino a un punto nel tempo (RDS):

undefined

Ripristino di uno snapshot (cross-region): prima copiare lo snapshot (copy-db-snapshot) nella region di destinazione, poi ripristinare.

Considerazioni sulla migrazione:

AWS DMS per migrazioni con downtime minimo (eterogenee/omogenee). DMS supporta la replica continua; assicurarsi che le impostazioni del motore di origine siano corrette (binlog abilitato per MySQL).
Migrazione logica (mysqldump, pg_dump) per esportazioni semplici; ripristino da snapshot fisico per dataset di grandi dimensioni.
Validare i set di caratteri, le differenze nei gruppi di parametri e le chiavi KMS per gli snapshot crittografati.

Errori Comuni e Criteri Decisionali

Ripristinare backup nella region o al momento sbagliato: verificare sempre –region e –restore-time prima del ripristino; utilizzare lo snapshot copiato nella region di destinazione e testare i ripristini in un ambiente di staging.
Presumere che le repliche di lettura (read replica) forniscano alta disponibilità: ricordare che le repliche sono asincrone; utilizzare Multi-AZ o Aurora per l’HA in scrittura e la replica sincrona.
Trascurare l’invalidazione della cache: progettare TTL, chiavi versionate o invalidazione basata su eventi; evitare di affidarsi unicamente a TTL brevi per la correttezza dei dati.
Non abilitare correttamente i backup automatici o la retention: impostare backup-retention-period >0 e validare il PITR con ripristini di prova; assicurarsi che le chiavi KMS siano disponibili nella region di destinazione per la copia dello snapshot.
Modificare i gruppi di parametri senza riavviare: controllare l’ApplyMethod; pianificare i riavvii nelle finestre di manutenzione per i parametri che lo richiedono, al fine di evitare downtime imprevisti.
Scalare senza gestire le connessioni: aumentare la classe dell’istanza senza usare RDS Proxy o il connection pooling potrebbe non risolvere le tempeste di connessioni; implementare il pooling per gestire molte connessioni di breve durata.

Problema Pratico: Scenario d’Uso

Acme Retail gestisce un’istanza primaria MySQL RDS con un traffico di lettura intenso e picchi occasionali dovuti all’analitica; riscontrano lag della replica (replica lag) durante l’ETL notturno e notano un elevato ricambio di connessioni (connection churn) che causa picchi di CPU.

Abilitare un gruppo aggiuntivo di repliche di lettura per l’analitica, isolato dai lettori dell’applicazione, e posizionarlo in una diversa AZ o region per il DR.
Configurare il monitoraggio della replica (metrica ReplicaLag) e aggiungere una logica di autoscaling per aggiungere lettori quando il lag o la ReadLatency superano le soglie.
Implementare RDS Proxy davanti all’applicazione per multiplexare le connessioni e ridurre il connection churn; ottimizzare max_connections nel gruppo di parametri in modo appropriato.
Spostare i job di analitica affinché utilizzino la replica per l’analitica e adottare una strategia di caching cache-aside tramite ElastiCache Redis con TTL appropriati per ridurre le query ripetute.
Testare le procedure di failover e ripristino: eseguire un ripristino PITR su un’istanza di staging e validare i passaggi di promozione della replica.

Questo approccio separa i carichi di lavoro di lettura, riduce la pressione delle connessioni sull’istanza primaria e utilizza la cache per diminuire il volume di letture dal DB. Segue le best practice di AWS combinando la scalabilità in lettura, il connection pooling e processi di backup/ripristino testati per mantenere la disponibilità e la resilienza operativa.

← Elaborazione e Auto Scaling · Tutti i domini · Serverless e integrazione di applicazioni →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →