Raccomandazioni per la riparazione automatica e l'auto-conservazione

  • Articolo

Si applica a questa raccomandazione per l'affidabilità di Azure Well-Architected Framework:

RE:07 Rafforzare la resilienza e la recuperabilità del carico di lavoro implementando misure di auto-conservazione e riparazione automatica. Creare funzionalità nella soluzione usando modelli di affidabilità basati sull'infrastruttura e modelli di progettazione basati su software per gestire gli errori dei componenti e gli errori temporanei. Creare funzionalità nel sistema per rilevare gli errori dei componenti della soluzione e avviare automaticamente un'azione correttiva mentre il carico di lavoro continua a funzionare con funzionalità complete o ridotte.

Guide correlate:Erroritemporanei deiprocessi | in background

Questa guida descrive le raccomandazioni per la creazione di funzionalità di riparazione automatica e di auto-conservazione 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 operare in uno stato danneggiato mentre i componenti non riusciti vengono ripristinati. Le funzionalità di riparazione automatica consentono di evitare tempi di inattività creando nel rilevamento degli errori e azioni correttive automatiche per rispondere a diversi tipi di errore.

Questa guida descrive i modelli di progettazione che si concentrano sull'auto-conservazione e sulla riparazione automatica. Incorporarli nel carico di lavoro per rafforzare la resilienza e la recuperabilità. Se non implementi modelli, le tue app sono a rischio di errori quando si verificano problemi inevitabili.

Definizioni

Termine Definizione
Riparazione automatica Possibilità del carico di lavoro di risolvere automaticamente i problemi ripristinando i componenti interessati e, se necessario, eseguendo il failover nell'infrastruttura ridondante.
Conservazione automatica Capacità del carico di lavoro di essere resiliente ai potenziali problemi.

Strategie di progettazione chiave

Linee guida per l'auto-conservazione

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 errore 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 di disponibilità o aree. 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 bulkhead per ridurre al minimo il raggio dell'esplosione in caso di 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 stamp di distribuzione: effettuare il provisioning, la gestione e il monitoraggio di un gruppo vario di risorse per ospitare e gestire più carichi di lavoro o tenant. Ogni singola copia è denominata stamp o talvolta un'unità di servizio, un'unità di scala o una cella.

  • Modello bulkhead: partizionare le istanze del servizio in gruppi diversi, noti come pool, in base ai requisiti di carico e disponibilità del consumer. Questa progettazione consente di isolare gli errori e di sostenere le funzionalità del servizio per alcuni consumer, anche in caso di errore.

Linee guida e modelli di progettazione delle applicazioni

Evitare di creare applicazioni monolitiche nella progettazione dell'applicazione. 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 a 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, in modo da rendere 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, ad esempio i messaggi non recapitabili. I modelli di progettazione seguenti consentono di organizzare il carico di lavoro e definire le comunicazioni tra i componenti in modo da soddisfare al meglio i requisiti aziendali.

  • Modello Ambassador: separare la logica di business dal codice di rete e dalla logica di resilienza. Creare servizi helper che inviano richieste di rete per conto di un servizio consumer o di un'applicazione. È possibile usare questo modello per implementare meccanismi di ripetizione dei tentativi o interruzione del circuito.

  • Modello di Request-Reply asincrono: separare l'elaborazione back-end da un host front-end se l'elaborazione back-end deve essere asincrona, ma il front-end richiede una risposta chiara.

  • Modello Cache-Aside: caricare i dati su richiesta da un archivio dati in una cache. Questo modello può migliorare le prestazioni e mantenere la coerenza tra i dati contenuti nella cache e i dati presenti nell'archivio dati sottostante.

  • Modello interruttore: usare interruttori per determinare in modo proattivo se consentire a un'operazione di procedere o restituire un'eccezione in base al numero di errori recenti.

  • Modello di verifica attestazione: suddividere un messaggio di grandi dimensioni in un controllo attestazione e un payload. Inviare il controllo dell'attestazione alla piattaforma di messaggistica e archiviare il payload in un servizio esterno. Questo modello consente l'elaborazione di messaggi di grandi dimensioni durante la protezione del bus di messaggi e il mantenimento del sovraccarico o del rallentamento del client.

  • Modello Consumer concorrenti: consente a più consumer simultanei di elaborare i messaggi ricevuti nello stesso canale di messaggistica. Un sistema può elaborare più messaggi contemporaneamente, che ottimizza la velocità effettiva, migliora la scalabilità e la disponibilità e bilancia il carico di lavoro.

  • Configurare i timeout delle richieste: configurare i timeout delle richieste per le chiamate a servizi o database. I timeout di connessione del database sono in genere impostati su 30 secondi.

  • Modello Gatekeeper: proteggere applicazioni e servizi usando un'istanza host dedicata per brokerare le richieste tra client e l'applicazione o il servizio. Il broker convalida e sanifica le richieste e può fornire un ulteriore livello di sicurezza per limitare la superficie di attacco del sistema.

  • Modello di livellamento del carico basato su coda: separare le attività dal servizio nella soluzione usando una coda tra di esse in modo che possano essere eseguite in modo asincrono. Usare una coda come buffer tra un'attività e un servizio che richiama per semplificare carichi intermittenti intermittenti che possono causare un errore del servizio o il timeout dell'attività. Questo modello consente di ridurre al minimo l'effetto dei picchi di disponibilità e velocità di risposta per l'attività e il servizio.

  • Modello di limitazione: controllare l'utilizzo delle risorse usate da un'istanza di un'applicazione, un singolo tenant o un intero servizio. Questo modello consente al sistema di continuare a funzionare e soddisfare i contratti di servizio , anche quando un aumento della domanda pone un carico estremo sulle risorse.

  • Modello di gestione degli errori temporanei e modello di ripetizione dei tentativi: implementare una strategia per gestire gli errori temporanei per fornire resilienza nel carico di lavoro. Gli errori temporanei sono occorrenze normali e previste negli ambienti cloud. Le cause tipiche degli errori temporanei includono la perdita momentanea della connettività di rete, una connessione al database eliminata o un timeout quando un servizio è occupato. Per altre informazioni sullo sviluppo di una strategia di ripetizione dei tentativi, vedere la guida alla gestione degli errori temporanei in questa serie.

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 processi in background sono:

  • Processi a elevato utilizzo di CPU, ad esempio l'esecuzione di calcoli complessi o l'analisi di modelli strutturali.
  • Processi a elevato utilizzo 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, ad esempio il completamento di un ordine o il provisioning di servizi e sistemi.

Per altre informazioni, vedere Raccomandazioni per i processi in background.

Indicazioni per la riparazione automatica

Per progettare il carico di lavoro per la riparazione automatica, implementare il rilevamento degli errori in modo che le risposte automatiche vengano attivate e i flussi critici vengano ripristinati normalmente. Abilitare la registrazione per fornire informazioni operative sulla natura dell'errore e sull'esito positivo del ripristino. Gli approcci da adottare per ottenere la riparazione automatica per un flusso critico dipendono dalle destinazioni di affidabilità definite 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 devono essere supportati da una progettazione dell'architettura ridondante con failover automatizzato abilitato per i componenti che lo supportano. È possibile abilitare il failover automatico per i tipi di servizi seguenti:

  • Risorse di calcolo: azure set di scalabilità di macchine virtuali 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 Azure SQL cluster di failover, gruppi di disponibilità Always On o funzionalità predefinite con i servizi PaaS. I database NoSQL hanno funzionalità di clustering simili e funzionalità predefinite per i servizi PaaS.

  • Archiviazione: usare le opzioni di archiviazione ridondanti con failover automatico.

Linee guida e modelli di progettazione delle applicazioni

  • Blocca gli attori malintenzionati: se si limita un client, non significa che il client agisce in modo dannoso. Potrebbe significare che il client ha superato la quota del servizio. Tuttavia, se un client supera costantemente la quota o si comporta in modo non corretto, è possibile bloccarli. Definire un processo fuori banda per consentire a un client di richiedere lo sblocco.

  • Modello di interruttore: se un errore persiste dopo l'avvio del meccanismo di ripetizione dei tentativi, è possibile rischiare errori a catena risultanti da un backlog crescente di chiamate. Un interruttore progettato per funzionare con il meccanismo di ripetizione dei tentativi limita il rischio di errori a catena impedendo all'app di tentare ripetutamente di eseguire un'operazione che potrebbe non riuscire.

  • Modello di transazione di compensazione: se si utilizza un'operazione coerente finale costituita da una serie di passaggi, implementare il modello di transazione di compensazione. Se uno o più passaggi hanno esito negativo, è possibile usare questo modello per annullare il lavoro eseguito dai passaggi.

  • Degradare normalmente: a volte non è possibile risolvere un problema, ma è possibile fornire funzionalità ridotte. Si consideri un'applicazione in cui viene visualizzato un catalogo di libri. Nel caso in cui l'applicazione non possa recuperare l'immagine di anteprima di una copertina, si potrebbe visualizzare un'immagine segnaposto. Interi sottosistemi possono non essere critici per l'applicazione. Ad esempio, per un sito Web di e-commerce, che mostra le raccomandazioni sul prodotto è probabilmente meno critico rispetto all'elaborazione degli ordini. La riduzione della tolleranza può includere anche operazioni di failover automatico. Quando un database viene eseguito automaticamente il failover in una replica a causa di un problema con l'istanza primaria, le prestazioni vengono ridotte per un breve periodo di tempo.

  • Modello di elezione leader: quando è necessario coordinare un'attività, usare le elezioni leader per selezionare un coordinatore in modo che un coordinatore non sia un singolo punto di errore. In caso di errore, ne viene selezionato un altro. Anziché implementare un algoritmo di elezione leader da zero, considerare una soluzione off-the-shelf, ad esempio ZooKeeper.

  • Modelli di test: includere test dei modelli implementati come parte delle procedure di test standard.

  • 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 prelevata da un'altra macchina virtuale, può riprendere dall'ultimo checkpoint. È consigliabile implementare un meccanismo che registra le informazioni sullo stato sull'attività a intervalli regolari. Salvare questo stato nell'archiviazione durevole a cui è possibile accedere da qualsiasi istanza del processo che esegue l'attività. Se il processo viene arrestato, il lavoro eseguito può essere ripreso dall'ultimo checkpoint usando un'altra istanza. Esistono librerie che forniscono questa funzionalità, ad esempio NServiceBus e MassTransit. Vengono mantenuti in modo trasparente, in cui gli intervalli sono allineati all'elaborazione dei messaggi dalle code in bus di servizio di Azure.

Azioni di auto-guarigione automatizzate

Un altro approccio alla guarigione automatica è l'uso di azioni automatizzate attivate dalla soluzione di monitoraggio quando vengono rilevate modifiche dello stato di integrità pre-determinate. Ad esempio, se il monitoraggio rileva che un'app Web non risponde alle richieste, è possibile creare 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. Vedere l'architettura di riferimento per l'automazione cloud basata su eventi per un esempio di uso di una funzione per rispondere alla limitazione del database. L'uso di azioni automatizzate consente di recuperare rapidamente e ridurre al minimo la necessità di intervento umano.

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 è ottimizzato per un servizio specifico. Per altre informazioni, vedere Raccomandazioni per la gestione degli errori temporanei.

Usare 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 un errore, attivare un runbook Automazione di Azure, Hub eventi di Azure, una funzione di Azure, un'app per la logica o un webhook per eseguire un'azione di correzione automatica.

Considerazioni

Acquisire familiarità con le considerazioni per ogni modello. Assicurarsi che il modello sia adatto per il carico di lavoro e i requisiti aziendali prima dell'implementazione.

Esempio

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.

Elenco di controllo affidabilità

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo affidabilità