Strategie di architettura per la riparazione automatica e l'auto-conservazione

Si applica a questa raccomandazione della checklist di affidabilità del Framework Azure Well-Architected:

Questa guida descrive le raccomandazioni per la creazione di funzionalità di auto-conservazione e riparazione automatica nell'architettura dell'applicazione per ottimizzare l'affidabilità.

Le funzionalità di conservazione automatica aggiungono resilienza al carico di lavoro. Riducono la probabilità di un'interruzione completa e consentono al carico di lavoro di funzionare normalmente, o in uno stato danneggiato, quando si verificano errori. Le funzionalità di riparazione automatica aiutano a ridurre al minimo i tempi di inattività, integrando il rilevamento dei guasti e le azioni correttive automatiche per rispondere ai guasti.

Definizioni

Progettare per la ridondanza

Una delle strategie più efficaci per proteggere il carico di lavoro da malfunzionamenti consiste nel creare ridondanza in tutti i relativi componenti ed evitare singoli punti di errore. La possibilità di eseguire il failover dei componenti o dell'intero carico di lavoro sulle risorse ridondanti offre un modo efficiente per gestire la maggior parte degli errori nel sistema.

Creare ridondanza a livelli diversi, prendere in considerazione componenti dell'infrastruttura ridondanti, ad esempio calcolo, rete e archiviazione, e prendere in considerazione la distribuzione di più istanze della soluzione. A seconda dei requisiti aziendali, è possibile creare ridondanza all'interno di una singola area o in più aree. È anche possibile decidere se è necessaria una progettazione attiva-attiva o passiva attiva per soddisfare i requisiti di ripristino. Per altre informazioni, vedere Strategie di architettura per la progettazione di strategie di ridondanza e architettura per l'uso di zone e aree di disponibilità.

Progettazione per la conservazione automatica

Per progettare il carico di lavoro per la conservazione automatica, seguire i modelli di progettazione dell'architettura dell'infrastruttura e dell'applicazione per ottimizzare la resilienza del carico di lavoro. Per ridurre al minimo la probabilità di un'interruzione completa dell'applicazione, aumentare la resilienza della soluzione eliminando singoli punti di guasto e riducendo al minimo il raggio di esplosione degli errori. Gli approcci di progettazione in questo articolo offrono diverse opzioni per rafforzare la resilienza del carico di lavoro e soddisfare gli obiettivi di affidabilità definiti del carico di lavoro.

Linee guida e modelli di progettazione dell'infrastruttura

A livello di infrastruttura, una progettazione dell'architettura ridondante deve supportare i flussi critici, con risorse distribuite tra zone o aree di disponibilità. Implementare la scalabilità automatica quando possibile. La scalabilità automatica consente di proteggere il carico di lavoro da picchi imprevisti nell'attività, rafforzando ulteriormente l'infrastruttura.

Usare il modello Deployment Stamps o il modello Bulkhead per ridurre al minimo il raggio dell'esplosione quando si verificano problemi. Questi modelli consentono di mantenere disponibile il carico di lavoro se un singolo componente non è disponibile. Usare i modelli di progettazione delle applicazioni seguenti in combinazione con la strategia di scalabilità automatica.

• Modello di stampi di distribuzione: fornire, gestire e monitorare diversi gruppi di risorse per ospitare e gestire più carichi di lavoro o utenti. Ogni singola copia viene chiamata stamp o a volte un'unità di servizio, un'unità di scala o una cella.

• Modello a paratia: partizionare le istanze del servizio in gruppi diversi, noti come pool, in base ai requisiti del carico e disponibilità del consumer. Questa progettazione consente di isolare i guasti e di sostenere le funzionalità del servizio per alcuni utenti, anche durante un malfunzionamento.

Linee guida e modelli di progettazione delle applicazioni

Evitare di costruire applicazioni monolitiche nella progettazione del software. Usare servizi o microservizi ad accoppiamento libero che comunicano tra loro tramite standard ben definiti per ridurre il rischio di problemi estesi quando si verificano malfunzionamenti in un singolo componente. Ad esempio, è possibile standardizzare l'uso di un bus di servizio per gestire tutte le comunicazioni asincrone. La standardizzazione dei protocolli di comunicazione garantisce che la progettazione delle applicazioni sia coerente e semplificata, che rende il carico di lavoro più affidabile e più semplice da risolvere quando si verificano malfunzionamenti. Quando pratica, preferire la comunicazione asincrona tra i componenti rispetto alla comunicazione sincrona per ridurre al minimo i problemi di timeout.

Usare modelli comprovati del settore per sviluppare gli standard di progettazione e semplificare gli aspetti dell'architettura. I modelli di progettazione che consentono di supportare l'affidabilità sono disponibili nell'articolo Modelli di affidabilità .

Progettazione per l'auto-riparazione

Per progettare il carico di lavoro per l'autoriparazione, implementa il rilevamento dei guasti affinché le risposte automatiche siano attivate e i flussi critici si ripristinino con eleganza. Abilitare la registrazione per fornire informazioni operative sulla natura dell'errore e sull'esito positivo del ripristino. Gli approcci da adottare per ottenere l'auto-riparazione per un flusso critico dipendono dagli obiettivi di affidabilità definiti per tale flusso e dai componenti e dalle dipendenze del flusso.

Linee guida per la progettazione dell'infrastruttura

A livello di infrastruttura, i flussi critici dovrebbero essere supportati da una progettazione dell'architettura ridondante, con il failover automatizzato abilitato per i componenti che lo supportano. È possibile abilitare il failover automatico per i tipi di servizi seguenti:

• Risorse di calcolo: i set di scalabilità di macchine virtuali di Azure e la maggior parte dei servizi di calcolo PaaS (Platform as a Service) possono essere configurati per il failover automatico.

• Database: i database relazionali possono essere configurati per il failover automatico con soluzioni come cluster di failover SQL di Azure, gruppi di disponibilità AlwaysOn o funzionalità predefinite con servizi PaaS. I database NoSQL hanno funzionalità di clustering simili e funzionalità predefinite per i servizi PaaS.

• Archiviazione: utilizzare opzioni di archiviazione ridondanti con failover automatico.

Linee guida per la progettazione di applicazioni

Oltre a usare modelli di progettazione che supportano l'affidabilità, altre strategie che consentono di sviluppare meccanismi di riparazione automatica includono:

• Usare i checkpoint per le transazioni a esecuzione prolungata: i checkpoint possono fornire resilienza se un'operazione a esecuzione prolungata ha esito negativo. Quando l'operazione viene riavviata, ad esempio se viene gestita da un'altra macchina virtuale, può riprendere dall'ultimo checkpoint. Prendere in considerazione l'implementazione di un meccanismo che registra le informazioni sullo stato dell'attività a intervalli regolari. Salvare questo stato in una risorsa di archiviazione durevole accessibile da qualsiasi istanza del processo che esegue l'attività. Se il processo viene arrestato, il lavoro che stava eseguendo può essere ripreso dall'ultimo punto di controllo, utilizzando un'altra istanza. Sono disponibili librerie che forniscono questa funzionalità, ad esempio NServiceBus e MassTransit. Lo stato viene mantenuto in modo trasparente, con gli intervalli allineati all'elaborazione dei messaggi dalle code nel servizio bus di Azure.

• Implementare azioni di autoriparazione automatica: Usare azioni automatizzate attivate dalla soluzione di monitoraggio, attivate quando vengono rilevate modifiche allo stato di salute predeterminato.

  Ad esempio, se il monitoraggio rileva che un'app Web non risponde alle richieste, è possibile compilare l'automazione tramite uno script di PowerShell per riavviare il servizio app. A seconda del set di competenze del team e delle tecnologie di sviluppo preferite, usare un webhook o una funzione per creare azioni di automazione più complesse. Per un esempio di utilizzo di una funzione per rispondere alla limitazione del database, vedere l'architettura di riferimento dell'automazione cloud basata su eventi. L'uso di azioni automatizzate consente di recuperare rapidamente e ridurre al minimo la necessità di intervento umano.

  Usare modelli di auto-riparazione e funzionalità specifiche della tecnologia. Ad esempio, anziché elaborare ripetutamente un messaggio danneggiato in una coda, che potrebbe bloccare l'elaborazione futura dei messaggi, puoi progettare approcci correttivi come l'uso di una coda di lettere morte. È possibile automatizzare lo spostamento di messaggi problematici nella coda, ma la gestione degli elementi è in genere una valutazione manuale seguita da un passaggio di correzione specifico dello scenario.

Implementare una modalità di degrado graduale

Nonostante i meccanismi di auto-conservazione e riparazione automatica, è comunque possibile riscontrare situazioni in cui uno o più componenti non funzionano nella misura in cui non sono disponibili per un certo periodo di tempo. In questi casi, idealmente, il carico di lavoro può mantenere una funzionalità sufficiente per permettere all'azienda di continuare in uno stato degradato. Per assicurarsi che ciò sia possibile, progettate e implementate una modalità di degradazione controllata. Si tratta di un flusso di lavoro distinto abilitato in reazione ai componenti non riusciti. Le considerazioni relative alla progettazione e all'implementazione includono:

• Rilevamento degli errori e avvio automatico: I sistemi di monitoraggio e avviso devono rilevare componenti degradati e guasti, quindi usare questi segnali per creare un flusso di lavoro che determina quando attivare la modalità di degrado controllato sia necessaria. Il flusso di lavoro deve quindi reindirizzare automaticamente le chiamate da e verso i componenti interessati a componenti alternativi o altre azioni simili.
• Implementare un'esperienza utente degradata: Includere un meccanismo di notifica per gli utenti nella modalità di degradazione graduale per assicurarsi che sappiano quali funzionalità rimangono e cosa è cambiato. Questo in genere si riflette nei messaggi legati a diverse funzioni del carico di lavoro, ad esempio un popup quando si aggiungono elementi a un carrello.
• Creare percorsi alternativi per completare le funzioni essenziali del carico di lavoro: Riflettere sui flussi critici del carico di lavoro e determinare come gestire tali flussi quando i componenti di base non sono disponibili. Ad esempio, se un database è inattivo, l'applicazione potrebbe passare a una modalità di sola lettura usando i dati memorizzati nella cache. Per illustrare ulteriormente questo esempio, se un gateway di pagamento è inattivo, l'uso di dati memorizzati nella cache potrebbe consentire agli utenti di salvare il carrello e completare l'acquisto in un secondo momento.

Implementare meccanismi per la gestione degli errori temporanei

Gli errori temporanei, ad esempio i timeout di rete, sono un problema comune per i carichi di lavoro cloud, quindi la presenza di meccanismi per gestirli può ridurre al minimo i tempi di inattività e la risoluzione dei problemi durante il funzionamento del carico di lavoro nell'ambiente di produzione. Poiché la maggior parte delle operazioni che hanno esito negativo a causa di un errore temporaneo avrà esito positivo se è consentito tempo sufficiente prima di ritentare l'operazione, l'uso di un meccanismo di ripetizione dei tentativi è l'approccio più comune per gestire gli errori temporanei. Quando si progetta la strategia di ripetizione dei tentativi, considerare quanto segue:

Per una revisione completa delle raccomandazioni e delle considerazioni, vedere la guida alla progettazione degli errori temporanei .

Implementare processi in background

I processi in background sono un modo efficace per migliorare l'affidabilità di un sistema separando le attività dall'interfaccia utente. Implementare un'attività come processo in background se non richiede input o feedback dell'utente e se non influisce sulla velocità di risposta dell'interfaccia utente.

Esempi comuni di lavori in background sono:

• Processi a elevato utilizzo di CPU, ad esempio l'esecuzione di calcoli complessi o l'analisi di modelli strutturali.
• Processi con utilizzo intensivo di I/O, ad esempio l'esecuzione di più operazioni di archiviazione o l'indicizzazione di file di grandi dimensioni.
• Processi batch, ad esempio l'aggiornamento regolare dei dati o l'elaborazione di attività in un momento specifico.
• Flussi di lavoro a esecuzione prolungata, come il completamento di un ordine o la preparazione di servizi e sistemi.

Fare riferimento alla guida di progettazione dei processi in background per ottenere indicazioni dettagliate per effettuare una revisione completa delle raccomandazioni e considerazioni.

Facilitazione di Azure

La maggior parte dei servizi di Azure e degli SDK client include un meccanismo di ripetizione dei tentativi. Ma differiscono perché ogni servizio ha caratteristiche e requisiti diversi, quindi ogni meccanismo di ripetizione dei tentativi viene ottimizzato per un servizio specifico. Per altre informazioni, vedere Raccomandazioni per la gestione degli errori temporanei.

Usare i gruppi di azioni di Monitoraggio di Azure per le notifiche, ad esempio posta elettronica, voce o SMS e per attivare azioni automatizzate. Quando si riceve una notifica di errore, attivare un runbook di Automazione di Azure, Azure Event Hubs, una funzione di Azure, una Logic App di Azure o un webhook per eseguire un'azione di correzione automatica.

Example

Ad esempio, i casi d'uso di alcuni modelli, vedere il modello di app Web affidabile per .NET. Seguire questa procedura per distribuire un'implementazione di riferimento.

Collegamenti correlati

• Modelli di affidabilità
• Gestire gli errori temporanei
• Sviluppare processi in background
• Modelli di progettazione cloud
• Progettazione per la riparazione automatica

Elenco di controllo per l'affidabilità

Fare riferimento al set completo di raccomandazioni.