Informazioni sulle pratiche di topologia cloud affidabile e resiliente

L'architettura di un'applicazione affidabile nel cloud è in genere diversa da un'architettura di applicazione tradizionale. Sebbene in passato potresti aver acquistato hardware ridondante di fascia alta per ridurre al minimo la possibilità che un'intera piattaforma applicativa non riesca, nel cloud è importante riconoscere in anticipo che si verificheranno errori. Invece di cercare di prevenire del tutto i guasti, l'obiettivo è quello di ridurre al minimo gli effetti di un singolo componente guasto (singolo punto di guasto o SPOF). Segui queste best practice per creare affidabilità in ogni fase del processo di progettazione.

Le applicazioni affidabili sono:

Resilienti e recuperati con grazia dagli errori e continuano a funzionare con tempi di inattività minimi e perdita di dati prima del recupero completo.
Altamente disponibile (HA) ed eseguito come progettato in buono stato senza tempi di inattività significativi.
Protetto da guasti della regione attraverso una buona progettazione di disaster recovery (DR).

Capire come questi elementi funzionano insieme e come influenzano i costi è essenziale per creare un'applicazione affidabile. Può aiutarti a determinare quanto tempo di inattività è accettabile, il costo potenziale per la tua azienda e quali funzioni sono necessarie durante un ripristino.

Architetto per l'affidabilità

Quando si crea un'applicazione cloud, utilizzare quanto segue per creare affidabilità.

Definire i requisiti.
Definisci i requisiti di disponibilità e ripristino in base ai carichi di lavoro che stai portando sulle esigenze cloud e aziendali.
Applicare le best practice architettoniche.
Segui pratiche comprovate, identifica i possibili punti di errore nell'architettura e determina in che modo l'applicazione risponderà agli errori.
Test con simulazioni e failover forzati.
Simula gli errori, attiva i failover forzati e verifica il rilevamento e il recupero da questi errori.
Distribuisci le applicazioni in modo coerente.
Rilascia alla produzione utilizzando processi affidabili e ripetibili e automatizza dove possibile.
Monitorare lo stato dell'applicazione.
Rileva gli errori, monitora gli indicatori dei potenziali errori e misura lo stato delle tue applicazioni.
Gestisci guasti e disastri.
Identifica quando si verifica un errore e determina come affrontarlo in base a strategie consolidate.

Definizione requisiti

Definisci i requisiti di disponibilità e ripristino in base ai carichi di lavoro che stai portando sulle esigenze cloud e aziendali.

Quando si identificano le esigenze aziendali e si abbina il piano di affidabilità, tenere presente quanto riportato di seguito.

Identificare i carichi di lavoro e i relativi requisiti
Un carico di lavoro è una funzionalità o un task distinti separati logicamente da altri carichi di lavoro, in termini di business logic e requisiti di storage dei dati. Ogni carico di lavoro ha requisiti diversi per disponibilità, scalabilità, coerenza dei dati e disaster recovery.
Determina i pattern d'uso
Il modo in cui viene utilizzata un'applicazione svolge un ruolo nei requisiti. Identifica le differenze nei requisiti durante i periodi critici e non critici. Ad esempio, un'elaborazione di fine mese per la gestione di un'applicazione non può avere esito negativo durante la fine del mese, ma potrebbe gestire l'errore in altri momenti. Per garantire il tempo di attività, è possibile aggiungere ulteriori componenti o ridondanza durante i periodi critici e rimuoverli quando non aggiungono più valore.
Identificare componenti e percorsi critici
Non tutti i componenti del sistema potrebbero essere importanti come altri. Ad esempio, è possibile disporre di un componente facoltativo che aggiunge valore incrementale, ma che il carico di lavoro possa essere eseguito senza, se necessario. Scopri dove si trovano questi componenti e, al contrario, dove si trovano le parti critiche del tuo carico di lavoro. Ciò contribuirà a definire le metriche di disponibilità e affidabilità e a pianificare le strategie di ripristino per dare priorità ai componenti di maggiore importanza.
Identificare le dipendenze esterne e l'effetto dell'errore a valle
Se il carico di lavoro dipende da servizi esterni, un errore in queste dipendenze può influire negativamente sulla disponibilità del carico di lavoro. Implementare metodi di disaccoppiamento dell'integrazione per isolare da guasti a valle.
Determina i requisiti di disponibilità dei carichi di lavoro
L'alta disponibilità (HA) è normalmente definita in termini di tempo di attività. Una destinazione HA del 99%, ad esempio, significa che una determinata risorsa può non essere disponibile per 3,65 giorni all'anno. Oracle Cloud Infrastructure (OCI) è progettato per offrirti un ambiente ad alta disponibilità. OCI pubblica un Service Level Agreement (SLA) per ciascuno dei suoi servizi che descrive gli impegni di Oracle in termini di uptime e connettività a tali servizi e dovresti esaminarli per vedere come soddisfano i tuoi requisiti. Alcuni servizi su OCI hanno alti livelli di HA built-in, in particolare i servizi gestiti da Oracle come il database autonomo. Per garantire che un'architettura dell'applicazione soddisfi i requisiti aziendali, definisci gli SLA di destinazione per ogni carico di lavoro, incluse le dipendenze esterne. Tenere conto del costo e della complessità del rispetto dei requisiti di disponibilità, oltre alle dipendenze delle applicazioni.
Stabilisci i tuoi parametri di ripristino: RTO (Recovery Time Objective) e RPO (Recovery Point Objective)
RTO è il periodo di tempo massimo accettabile in cui un'applicazione può non essere disponibile dopo un incidente irreversibile.

RPO è la durata massima della perdita di dati accettabile durante un disastro.

Per ricavare questi valori, effettua una valutazione del rischio e assicurati di comprendere il costo e il rischio di tempi di inattività o perdita di dati nella tua organizzazione.

I backup incrementali per lo storage forniscono sicurezza contro la perdita di dati tramite punti di recupero. Il periodo compreso tra ogni backup limita la quantità massima di dati persi dopo il ripristino da un backup.

Ad esempio, considera di utilizzare uno dei criteri di backup predefiniti di Oracle per lo storage dei volumi a blocchi OCI: Bronzo, Argento e Oro. Ogni criterio di backup comprende pianificazioni con una frequenza di backup incrementale impostata, ad esempio mensile, settimanale o giornaliero, e un periodo di conservazione definito.
Definire un disastro
Avere piani e requisiti di disaster recovery ben documentati è importante, ma la natura caotica di un tale evento può creare confusione. Scopri cosa costituisce un disastro per la tua azienda, identifica i ruoli chiave che saranno necessari durante un disastro e stabilisci un piano di comunicazione ben definito per avviare una risposta al disastro.
Considera costi
Da un punto di vista di FinOps, considerare le implicazioni dei costi di diverse strategie di affidabilità. Questo ti aiuta a fare scelte informate sui tuoi requisiti di disponibilità e recupero.

Applicare le best practice per l'architettura

Durante la progettazione dell'architettura, concentrati sulle procedure di implementazione che soddisfano i requisiti aziendali, identifica i punti di errore e minimizza l'ambito dei guasti.

Tenere conto delle procedure consigliate illustrate di seguito.

Determinare dove si possono verificare errori
Analizzare l'architettura per identificare i tipi di errori che potrebbero verificarsi nell'applicazione, i potenziali effetti di ciascuna e le possibili strategie di ripristino.
Determina il livello di ridondanza richiesto in base ai requisiti HA e DR
Il livello di ridondanza richiesto per ogni carico di lavoro dipende dalle esigenze e dai fattori aziendali nel costo complessivo dell'applicazione.
Design per la scalabilità
Un'applicazione cloud deve essere in grado di ridimensionarsi per adeguarsi alle modifiche all'uso. Inizia con componenti discreti e progetta l'applicazione per rispondere automaticamente alle modifiche di caricamento quando possibile. Tieni a mente i limiti di scalabilità durante la progettazione in modo da poter espanderti facilmente in futuro.
Utilizzare il bilanciamento del carico per distribuire le richieste
Il bilanciamento del carico distribuisce le richieste dell'applicazione a istanze di servizio in buono stato rimuovendo dalla rotazione le istanze in cattivo stato. L'esternalizzazione delle informazioni sullo stato renderà il ridimensionamento del backend trasparente per l'utente finale. Se lo stato viene tracciato nella sessione, potrebbe essere necessaria la persistenza.
Costruisci i requisiti di disponibilità e resilienza nella tua progettazione
La resilienza è la capacità di un sistema di recuperare dagli errori e continuare a funzionare. La disponibilità è la proporzione di tempo in cui il sistema è funzionale e funzionante. Implementa le best practice per l'alta disponibilità, ad esempio evitando singoli punti di errore e scomponendo i carichi di lavoro in base all'obiettivo a livello di servizio. Utilizza le funzioni standard del tuo livello di dati, come la continuità delle applicazioni e le transazioni asincrone per garantire disponibilità e resilienza.
Implementazione DR
Progetta la tua soluzione per soddisfare i requisiti RTO e RPO identificati. Assicurati di poter portare online tutti i componenti della tua soluzione DR all'interno del tuo RTO. Proteggi i tuoi dati in modo da poter incontrare il tuo RPO. È fondamentale archiviare, eseguire il backup e replicare i dati.
- Backup dei dati
  Anche con un ambiente DR completamente replicato, i backup regolari sono ancora fondamentali. Esegui regolarmente il backup e la convalida dei dati e assicurati che nessun singolo account utente abbia accesso ai dati di produzione e di backup.
- Scegliere i metodi di replica per i dati dell'applicazione
  I dati dell'applicazione vengono memorizzati in vari data store e potrebbero avere requisiti di disponibilità diversi. Valutare i metodi e le posizioni di replica per ogni tipo di data store per assicurarsi che soddisfino i requisiti HA e RPO.
- Comprendi le implicazioni del fallimento ed è un effetto sulla disponibilità ai disastri
  È necessario creare un'istanza di un'altra area per la replica per soddisfare i requisiti dei carichi di lavoro? Dovrai preoccuparti della coerenza dei dati in caso di failback?
- Documentare e testare i processi di failover e failback
  Documentare chiaramente le istruzioni per eseguire il failover in un nuovo data store e testarle regolarmente per assicurarsi che siano accurate e facili da seguire.
- Assicurati che il tuo piano di recupero dei dati soddisfi il tuo RTO
  Assicurati che la tua strategia di backup e replica preveda tempi di recupero dei dati che soddisfino il tuo RTO e il tuo RPO. Tenere conto di tutti i tipi di dati utilizzati dall'applicazione, inclusi dati di riferimento, file e database.

Test periodico con simulazioni e failover forzati

I test di affidabilità richiedono la misurazione delle prestazioni del carico di lavoro end-to-end in condizioni di errore che si verificano solo in modo intermittente.

Eseguire test per individuare scenari di errore comuni attivando errori effettivi o simulandoli
Utilizzare il test di iniezione dei guasti per testare scenari comuni (comprese combinazioni di guasti) e tempi di ripristino.
Identificare gli errori che si verificano solo sotto carico
Eseguire il test del carico di picco, utilizzando dati di produzione o dati sintetici il più vicino possibile ai dati di produzione, per vedere come si comporta l'applicazione in condizioni reali.
Esegui drill-down disaster recovery
Avere un piano di disaster recovery in atto e testarlo periodicamente per assicurarsi che funzioni.
Esegui test di failover e failback
Assicurarsi che i servizi dipendenti dell'applicazione eseguano il failover e il failover nell'ordine corretto.
Eseguire i test di simulazione
Testare scenari reali può evidenziare problemi che devono essere affrontati. Gli scenari devono essere controllabili e non dirompenti per l'azienda. Informa la gestione dei piani di test di simulazione.
Sonde di stato dei test
Configura le sonde di integrità per i load balancer e i manager del traffico per controllare i componenti critici del sistema. Testarli per assicurarsi che rispondano in modo appropriato.
Sistemi di monitoraggio dei test
Assicurati che i sistemi di monitoraggio segnalino in modo affidabile informazioni critiche e dati accurati per identificare potenziali errori.
Includi servizi di terze parti in scenari di test
Testare i possibili punti di errore dovuti a interruzioni del servizio di terze parti, oltre al recupero.
Impara dai problemi riscontrati durante i test
Se i test rivelano problemi o lacune, assicurati che vengano identificati e risolti aggiungendo ulteriore monitoraggio o adeguando i processi operativi.

Distribuisci le applicazioni in modo coerente

La distribuzione include il provisioning dei servizi e delle risorse di Oracle Cloud Infrastructure (OCI), la distribuzione del codice dell'applicazione e l'applicazione delle impostazioni di configurazione. Un aggiornamento può comportare tutte e tre le attività o un sottoinsieme di esse.

Automatizza il processo di implementazione delle applicazioni
Automatizza il maggior numero possibile di processi. Se possibile, le implementazioni manuali nella produzione dovrebbero essere eliminate, anche se ciò potrebbe essere accettabile in ambienti inferiori per promuovere velocità e flessibilità.
Sfrutta l'automazione per testare il codice prima della distribuzione
I test per individuare bug, vulnerabilità della sicurezza, funzionalità, prestazioni e integrazioni sono fondamentali per ridurre al minimo i problemi rilevati dagli utenti finali. Gli errori di test dovrebbero impedire il rilascio del codice nella produzione.
Progetta il tuo processo di rilascio per massimizzare la disponibilità
Se il processo di rilascio richiede la disconnessione dei servizi durante la distribuzione, l'applicazione non sarà disponibile finché non torneranno in linea. Sfrutta le funzionalità di staging e produzione della piattaforma. Se possibile, rilasciare nuove distribuzioni in un subset di utenti da monitorare per individuare eventuali errori nelle prime ore.
Disporre di un piano di rollback per la distribuzione
Progettare un processo di rollback per tornare a un'ultima versione valida nota e ridurre al minimo i tempi di inattività in caso di mancata distribuzione. L'automazione del rollback alla distribuzione non riuscita può impedire tempi di inattività non necessari.
Registra e verifica le distribuzioni
Se si utilizzano tecniche di distribuzione nell'area intermedia, in produzione sono in esecuzione più versioni dell'applicazione. Implementa una solida strategia di registrazione per acquisire il maggior numero possibile di informazioni specifiche della versione.
Documenta il processo di rilascio dell'applicazione
Definisci e documenta chiaramente il tuo processo di rilascio e assicurati che sia disponibile per l'intero team operativo.

Monitora stato applicazione

Implementa le best practice per il monitoraggio e gli avvisi nell'applicazione in modo da poter rilevare gli errori e avvisare un operatore di risolverli.

Implementare il trace intorno alle chiamate di servizio
I dati sulle prestazioni di base possono aiutare a fornire dati sulle tendenze che possono essere utilizzati per identificare in modo proattivo i problemi relativi alle prestazioni prima che influiscano sugli utenti.
Implementare sonde sanitarie
Eseguili regolarmente dall'esterno dell'applicazione per identificare il deterioramento dello stato e delle prestazioni dell'applicazione. Queste sonde dovrebbero essere più di semplici test di pagina statici, dovrebbero riflettere lo stato olistico dell'applicazione.
Controlla flussi di lavoro con tempi di esecuzione lunghi
Individuare i problemi in anticipo può ridurre al minimo la necessità di eseguire il rollback dell'intero flusso di lavoro o di eseguire più transazioni di compensazione.
Mantenere i log di sistema, applicazione e audit
Utilizza un servizio di log centralizzato per memorizzare i log.
Impostare un sistema di allarme rapido
Identificare gli indicatori prestazioni chiave (KPI) dello stato di integrità di un'applicazione, ad esempio le eccezioni transitorie e la latenza delle chiamate remote, nonché impostare i valori di soglia appropriati per ciascuna di esse. Inviare un avviso alle operazioni quando viene raggiunto il valore di soglia.
Addestrare più operatori per monitorare l'applicazione ed eseguire passaggi di ripristino manuale
Assicurarsi che sia sempre attivo almeno un operatore qualificato.

Gestisci errori e disastri

Crea un piano di ripristino e assicurati che copra il ripristino dei dati, le interruzioni della rete, gli errori dei servizi dipendenti e le interruzioni del servizio a livello di area. Considera le tue VM, lo storage, i database e altri servizi OCI nella tua strategia di ripristino.

Pianifica per la gestione degli incidenti
Definisci ruoli e responsabilità chiari per la gestione degli incidenti in modo da garantire l'esecuzione dei servizi o ripristinarli il più rapidamente possibile.
Documentare e testare il piano di disaster recovery
Scrivere un piano di disaster recovery che rifletta l'impatto aziendale degli errori delle applicazioni. Automatizza il più possibile il processo di ripristino e documenta eventuali passaggi manuali. Testare regolarmente il processo di disaster recovery per convalidare e migliorare il piano.
Comprendere i ruoli chiave necessari per il coordinamento DR
Assicurati che le attività di DR siano ben coordinate e che le applicazioni abbiano la priorità in base al valore aziendale.
Preparazione per errore applicazione
Preparati a una serie di errori, inclusi quelli gestiti automaticamente, quelli che riducono le funzionalità e quelli che rendono l'applicazione non disponibile. L'applicazione dovrebbe informare gli utenti di problemi temporanei.
Recupero da danneggiamento dei dati
Se si verifica un errore in un data store, verificare la presenza di incoerenze dei dati quando l'area di memorizzazione diventa nuovamente disponibile, soprattutto se i dati sono stati replicati. Ripristina i dati danneggiati da un backup.
Ripristino da un'interruzione di rete
È possibile utilizzare i dati inseriti nella cache per eseguirli localmente con funzionalità di applicazione ridotte. In caso contrario, considera i tempi di inattività dell'applicazione o il failover in un'altra area. Memorizzare i dati in una posizione alternativa finché la connettività non viene ripristinata.
Recupero da un errore di servizio dipendente
Determinare le funzionalità ancora disponibili e le modalità di risposta dell'applicazione.
Ripristina da un'interruzione del servizio a livello regionale
Le interruzioni del servizio a livello regionale sono rare, ma dovresti avere una strategia per affrontarle, soprattutto per le applicazioni critiche. Potresti essere in grado di ridistribuire l'applicazione in un'altra area o ridistribuire il traffico.
Impara dai test DR e migliora i processi
Assicurati che tutti i problemi riscontrati durante il test DR vengano acquisiti e che i piani per risolverli vengano risolti in test o failover futuri.