Capacity planning: dimensionare compute e storage

Il capacity planning parte dai workload metric osservati (CPU, memoria, IOPS, throughput di rete, dimensione del working set) e li proietta sui requisiti futuri, includendo picchi stagionali e crescita del dataset. Per il compute si sceglie il machine type: shape con più vCPU/RAM aumentano il throughput e riducono la contesa ma alzano il costo; sottodimensionare porta a throttling e latenza, sovradimensionare spreca budget. Per lo storage, su Cloud SQL l’SSD offre bassa latenza e IOPS elevati per carichi OLTP, mentre l’HDD costa meno ma è indicato solo per dataset grandi ad accesso sequenziale e poco sensibili alla latenza. Ricorda che IOPS e throughput spesso scalano con la dimensione del disco e con il numero di vCPU: aumentare lo storage può essere una leva di performance, non solo di capacità. Distingui scale up (macchina più grande, tipico dei relazionali monolitici come Cloud SQL/AlloyDB) da scale out (aggiungere nodi, nativo in Spanner e Bigtable). Prevedi headroom e valuta lo storage auto-growth per non esaurire lo spazio.

Zonale, regionale, multi-region: i trade-off di HA

L’high availability riguarda la continuità del servizio davanti al guasto di un componente. Un deployment zonale vive in una singola zona: nessuna protezione se la zona cade. Cloud SQL in configurazione HA è regionale: mantiene una failover replica (standby) in un’altra zona della stessa region con replica sincrona; se la zona primaria fallisce avviene il failover automatico verso lo standby, proteggendo da un guasto zonale ma non da un guasto regionale. Per requisiti superiori, Spanner in configurazione multi-region distribuisce i dati su più region con SLA fino al 99,999% e strong/external consistency, tollerando la perdita di un’intera region: è la scelta per scala orizzontale globale e disponibilità estrema. Attenzione: le read replica di Cloud SQL servono a scalare le letture e possono stare anche cross-region, ma non sono un meccanismo di failover automatico dello scrittore e vanno promosse manualmente.

Disaster recovery: backup, PITR e replica cross-region

Il disaster recovery riguarda il ripristino dopo un evento distruttivo (perdita di region, corruzione dati, errore umano) ed è governato da RTO (tempo di ripristino) e RPO (perdita dati tollerata). Gli strumenti chiave su Cloud SQL sono i backup automatici e il point-in-time recovery (PITR), che sfrutta i binary log (MySQL) o il WAL (PostgreSQL) per riportarsi a un istante preciso: è la difesa contro corruzione logica ed errori applicativi. Per la resilienza geografica si aggiunge una read replica cross-region, promuovibile se la region primaria diventa irraggiungibile: riduce l’RTO regionale ma richiede intervento. È fondamentale non confondere HA e DR: la failover replica dà continuità (HA) ma condivide la region; backup/PITR/replica cross-region danno ripristino (DR). Un RPO prossimo a zero richiede replica sincrona o architetture come Spanner; RPO/RTO più rilassati si coprono con backup e replica asincrona.

Maintenance window e notifiche

La manutenzione gestita (patch di engine e sistema) può comportare un breve riavvio. Si definisce una maintenance window in una fascia a basso traffico e si configurano le notifiche di manutenzione per anticipare gli aggiornamenti; su applicazioni critiche si può inoltre controllare l’ordine e le finestre in cui la manutenzione è consentita. In una configurazione Cloud SQL HA l’impatto del riavvio è mitigato dal failover, ma la finestra va comunque allineata al livello di disponibilità richiesto: SLA più stringenti impongono finestre più strette e un piano di comunicazione verso gli stakeholder.

Trappole tipiche d’esame

  • Sopravvivere alla perdita di un’intera region con 99,999% → soluzione: Spanner multi-region; Cloud SQL HA è solo regionale e non copre un guasto di region.
  • “Alta disponibilità” su Cloud SQL → soluzione: failover replica sincrona in altra zona (HA regionale), non una read replica: la read replica scala le letture, non fa failover automatico dello scrittore.
  • Recupero da cancellazione o corruzione dati di ieri → soluzione: PITR via binary log/WAL, non il failover: l’HA replica anche l’errore logico.
  • Ridurre l’RTO per un disastro regionale su Cloud SQL → soluzione: read replica cross-region da promuovere; è DR e richiede promozione manuale, non è automatica.
  • Picco di letture che satura il primario → soluzione: read replica (scale out delle letture), eventualmente Memorystore come cache; non basta aumentare lo storage.
  • Manutenzione che non deve impattare l’orario di punta → soluzione: maintenance window in fascia bassa più notifiche; su HA il failover riduce ma non azzera l’interruzione.