Scegli la disponibilità tra zone e regioni

Parti dall’operazione dell’utente

L’alta disponibilità (HA) mira a mantenere utilizzabile un servizio nonostante i guasti dei componenti. Definisci cosa significhi utilizzabile prima di scegliere l’architettura. Una pagina di prenotazione che si carica mentre tutte le richieste di prenotazione falliscono non è un servizio di prenotazione disponibile.

Fissa un obiettivo di livello di servizio (SLO) per l’operazione importante. Definisci quali richieste contano, cosa significa successo e il periodo di misurazione. Lo SLA di un servizio cloud descrive l’impegno di quel fornitore. Non dimostra la disponibilità misurata della tua applicazione.

A titolo illustrativo, una disponibilità temporale del 99,9% consente 43,2 minuti di indisponibilità in un mese di 30 giorni. Uno SLO basato sulle richieste ha un denominatore diverso. Nessuna delle due misure indica quanti dati puoi perdere o garantisce una durata massima per una singola interruzione.

Comprendi i confini di guasto

Una AWS Availability Zone (AZ) è una collocazione infrastrutturale isolata all’interno di una Region. Una Region contiene più AZ. Un’architettura multi-region distribuisce i componenti del carico di lavoro tra Region diverse. Altri fornitori hanno confini e comportamenti propri: esamina il servizio scelto.

Sono possibilità progettuali, non garanzie di disponibilità. Un’etichetta non dimostra che ogni componente necessario usi il confine previsto.

Segui l’intero percorso della richiesta

Considera un servizio fittizio di prenotazione. Le repliche web funzionano in due AZ. Entrambe usano un database e un gateway in uscita nella AZ A. Il gateway serve a chiamare il fornitore dei pagamenti.

Se la AZ A si guasta, la replica web nella AZ B può restare sana mentre la prenotazione continua a fallire. Il team deve valutare database, percorso di rete, provider di identità, dipendenza dai pagamenti e instradamento. Esamina la modalità effettiva del database gestito: replica, failover e comportamento delle letture variano per prodotto e configurazione.

Verifica anche la capacità. Le risorse superstiti devono gestire il carico richiesto. Un progetto che conta sulla creazione di capacità durante un incidente dipende da quote, risorse disponibili e operazioni del control plane.

Esegui un’esercitazione controllata con confini definiti, condizioni di arresto e un responsabile. Verifica una prenotazione completa, inclusa la riconciliazione del pagamento. Registra richieste fallite e tempo necessario a ripristinare un funzionamento utile.

Decidi se un’altra Region risolve il problema

Operare in più Region aggiunge trasferimento dati, risorse duplicate, coordinamento dei deployment e lavoro operativo. Active/passive mantiene un ambiente pronto a ricevere traffico. Active/active serve traffico da più di un ambiente. La prontezza richiesta e il comportamento dei dati sono diversi.

Per il servizio di prenotazione, le scritture simultanee pongono una domanda: due Region possono vendere lo stesso posto? Definisci quale componente decide una prenotazione e cosa accade durante l’interruzione della replica. «Replicare il database» non è una risposta completa.

Verifica collocazioni ammesse dei dati, chiavi di cifratura, certificati, DNS, segreti e servizi esterni. Un guasto comune dell’identità o un rilascio difettoso può colpire più Region. Più località non eliminano ogni causa comune.

Collega disponibilità e recupero

L’HA gestisce guasti specifici durante il funzionamento. Il disaster recovery ripristina un servizio utilizzabile e i suoi dati dopo un evento che lo interrompe. Un servizio multi-region ha comunque bisogno di un piano di recupero per eliminazioni o dati corrotti.

Documenta gli scenari di guasto scelti e quelli che l’azienda accetta. Mantieni allineati test e definizioni infrastrutturali mentre l’applicazione cambia. Prosegui con RTO, RPO e disaster recovery.