Progettazione per la resilienza
 Il carico di lavoro deve continuare a operare con funzionalità complete o ridotte. |
|---|
L'utente deve aspettarsi malfunzionamenti dei componenti, interruzioni della piattaforma, riduzioni delle prestazioni e altri guasti. È necessario creare resilienza nel sistema in modo che sia a tolleranza di errore e possa ridursi normalmente.
Scenario di esempio
Contoso Air è una compagnia aerea commerciale con un reparto di sviluppo interno. L'applicazione line-of-business principale è una soluzione di prenotazione che consente ai clienti di prenotare i voli direttamente con Contoso Air. L'app è incorporata in Azure e utilizza il Servizio app di Azure, Cosmos DB, Funzioni di Azure, App per la logica di Azure e bus di servizio di Azure.
Determinare i rischi di errore
Identificare i potenziali punti di errore nel sistema, in particolare per i componenti critici, e determinare l'effetto sui flussi utente e di sistema.
Analizzare il caso di errore, il raggio di esplosione e l'intensità dell'errore per ogni potenziale punto di guasto. I casi di errore e la loro intensità possono variare da scenari a impatto relativamente basso, ad esempio la perdita temporanea di un processo back-end, arrivando a interruzioni a scalabilità completa causate da emergenze. L'esecuzione di questa analisi consente di determinare la progettazione delle funzionalità di gestione degli errori a livello di componente.
Sfida di Contoso
- L'applicazione line-of-business offre molte funzioni chiave, che vanno dal marketing al commercio. Il flusso utente di acquisto del ticket è stato identificato come quello più critico. Il team del carico di lavoro ha stabilito che devono essere implementate maggiori misure di affidabilità per garantire che il flusso sia ottimizzato per la resilienza.
- Il team ha a disposizione del tempo per apportare miglioramenti come il disaccoppiamento dei componenti e la riprogettazione dei flussi, ma vuole assicurarsi di impiegare tale tempo per concentrarsi sui miglioramenti di maggior valore.
Applicazione dell'approccio e risultati
- Il team identifica il gateway di pagamento esterno come punto di errore potenziale. Il gateway è a disponibilità elevata, ma è possibile che gli utenti riscontrano errori temporanei occasionali, causati da problemi di rete o da picchi di richieste estremamente elevate. Il gateway potrebbe rifiutare alcune richieste quando è sovraccaricato dall'invio di più richieste simultanee.
- Il team determina che gli utenti devono inviare di nuovo le richieste quando il gateway rifiuta le richieste iniziali, causando un'esperienza utente negativa.
Implementare meccanismi di autoconservazione
Creare capacità di autoconservazione utilizzando correttamente i modelli di progettazione e modularizzando il progetto per isolare gli errori.
Creando funzionalità di autoconservazione nel sistema, sarà possibile evitare che un problema influisca sui componenti downstream. Il sistema sarà in grado di attenuare errori temporanei e permanenti, colli di bottiglia delle prestazioni e altri problemi che potrebbero influire sull'affidabilità. Sarà anche possibile anche ridurre al minimo il raggio dell'esplosione.
Sfida di Contoso
- Il team vuole limitare al massimo il rischio di errori temporanei che causano il rifiuto delle richieste degli utenti da parte del gateway di pagamento. A causa della natura temporanea di alcune delle condizioni di errore, è probabile che la stessa richiesta abbia esito positivo, se viene inviata di nuovo.
Applicazione dell'approccio e risultati
- Il team sviluppa la logica personalizzata nel flusso per ritentare la transazione dopo un breve ritardo, quando viene rilevato un errore che può essere ripetuto.
- La progettazione della soluzione verrà modificata per incorporare il modello di ripetizione dei tentativi, aumentando leggermente il tempo di attesa tra i tentativi fino a quando la richiesta non viene elaborata correttamente o viene raggiunto il numero massimo di errori.
- Il team decide anche di separare le funzionalità di interazione dell'utente e di elaborazione dei pagamenti back-end di questo flusso, ricorrendo a un approccio basato su eventi con il bus di servizio di Azure. Quando si verificano errori irreversibili durante l'elaborazione del messaggio (dopo il numero massimo di tentativi), il processore back-end abbandona l'elaborazione della richiesta, lasciando il messaggio nella coda in modo che possa essere rielaborato in un secondo momento.
Creare una ridondanza e una resilienza complete
Creare ridondanza nei livelli e resilienza in vari livelli applicazione.
Puntare alla ridondanza nelle utilità fisiche e nella replica immediata dei dati. Mirare anche alla ridondanza nel livello funzionale che copre servizi, operazioni e personale. La ridondanza consente di ridurre al minimo i singoli punti di guasto. Ad esempio, se si verifica un'interruzione che interessa uno o più componenti, una zona di disponibilità o un'intera area, una distribuzione ridondante (attiva-attiva o attiva-passiva) consente di soddisfare gli obiettivi di tempo di attività.
L'aggiunta di intermediari impedisce la dipendenza diretta tra i componenti, migliorando il buffering. Entrambi questi vantaggi rafforzano la resilienza del sistema.
Sfida di Contoso
- L'implementazione di tentativi e di disaccoppiamento delle chiamate del gateway di pagamento dall'interfaccia utente tramite il bus di servizio ha aumentato notevolmente l'affidabilità di questo flusso, ma gli stakeholder aziendali continuano a preoccuparsi della perdita di dati che potrebbe verificarsi a causa di un errore irreversibile nell'area primaria.
Applicazione dell'approccio e risultati
- Il team decide di eseguire l'aggiornamento al livello premium del bus di servizio. In questo modo, possono sfruttare le funzionalità di supporto delle zone di disponibilità di tale livello. Con questa funzionalità, più copie dei dati vengono archiviate in tre strutture separate fisicamente (zone di disponibilità) e il servizio dispone di riserve di capacità sufficienti per gestire immediatamente la perdita irreversibile e completa di un data center.
- Inoltre, il team configura il ripristino di emergenza geografico del bus di servizio di Azure per replicare continuamente i dati in un'area secondaria, che verrà usata nel caso improbabile di un guasto completo dell'area primaria.