Condividi tramite

Raccomandazioni per la riparazione automatica e l'auto-conservazione

  • Articolo

Si applica a questa raccomandazione per l'affidabilità del framework ben progettato di Azure:

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: Errori temporanei dei processi | in background

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

Questa guida descrive i modelli di progettazione incentrati sull'auto-conservazione e la riparazione automatica. Incorporarli nel carico di lavoro per rafforzare la resilienza e la recuperabilità. Se non si implementano modelli, le app sono a rischio di errore 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.
Autoconservazione Capacità del carico di lavoro di essere resiliente contro 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 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 stamp di distribuzione: effettuare il provisioning, gestire e monitorare un gruppo di risorse diverso per ospitare e gestire più carichi di lavoro o tenant. Ogni singola copia viene chiamata stamp o a volte un'unità di servizio, un'unità di scala o una cella.

  • Modello di intestazione bulk: 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 durante un errore.

Linee guida e modelli di progettazione delle applicazioni

Evitare di compilare 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 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, in modo da rendere il carico di lavoro più affidabile e più semplice da risolvere quando si verificano malfunzionamenti. Quando pratico, 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 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 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 di 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 controllo attestazioni: suddividere un messaggio di grandi dimensioni in un controllo attestazioni 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 proteggendo il bus di messaggi e impedendo al client di essere sovraccaricati o rallentati.

  • 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, ottimizzando la velocità effettiva, migliorando la scalabilità e la disponibilità e bilanciando 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 i client e l'applicazione o il servizio. Il broker convalida e purifica 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 facilitare carichi pesanti 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 il consumo di risorse usate da un'istanza di un'applicazione, da un singolo tenant o da 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 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, ad esempio il completamento di un ordine o il provisioning di servizi e sistemi.

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

Linee guida 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: è possibile configurare azure set di scalabilità di macchine virtuali e la maggior parte dei servizi di calcolo PaaS (Platform as a Service) 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: 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, si rischia di 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 usa un'operazione coerente finale costituita da una serie di passaggi, implementare il modello 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, la visualizzazione delle raccomandazioni sui prodotti è probabilmente meno critica rispetto all'elaborazione degli ordini. Una riduzione delle prestazioni normale può includere anche operazioni di failover automatico. Quando un database esegue 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 dei leader: quando è necessario coordinare un'attività, usare le elezioni dei leader per selezionare un coordinatore in modo che un coordinatore non sia un singolo punto di guasto. In caso di errore, ne viene selezionato un altro. Invece di implementare un algoritmo di elezione leader da zero, prendere in considerazione 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. 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 checkpoint usando un'altra istanza. Sono disponibili 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 riparazione automatica

Un altro approccio alla riparazione automatica è l'uso di azioni automatizzate attivate dalla soluzione di monitoraggio quando vengono rilevate modifiche dello stato di integrità 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 uso di una funzione per rispondere alla limitazione della 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.

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 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 ai requisiti aziendali e del carico di lavoro 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 per l'affidabilità

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo per l'affidabilità