Probe di integrità e degradazione controllata

Le probe di integrità sono il meccanismo con cui i bilanciatori del carico e i traffic manager rilevano se un'istanza backend è in grado di gestire le richieste. Senza probe di integrità, un bilanciatore del carico potrebbe continuare a inviare traffico a un server guasto o che non risponde, causando errori visibili agli utenti. Probe di integrità configurate correttamente consentono il reindirizzamento automatico del traffico lontano dalle istanze non integre entro pochi secondi dal guasto.

Azure Load Balancer supporta due tipi di probe di integrità:

• Probe TCP — verifica se il backend può accettare una connessione TCP su una porta specificata. È semplice, ma non verifica la logica dell'applicazione.
• Probe HTTP/HTTPS — invia una richiesta GET a un percorso specificato e si aspetta una risposta 200 OK. È più precisa perché testa direttamente l'endpoint dell'applicazione.

Un backend viene contrassegnato come non integro se la probe non riesce per un numero configurabile di tentativi consecutivi.

Un endpoint di integrità ben progettato (/health) fa più che restituire 200 OK: verifica che le dipendenze critiche dell'applicazione siano raggiungibili. Un controllo di integrità completo potrebbe verificare la connettività al database, alla cache e alle API downstream. Se una dipendenza non è disponibile, l'endpoint restituisce un codice di stato 5xx, segnalando al bilanciatore del carico di rimuovere l'istanza dalla rotazione.

Azure Traffic Manager utilizza probe di integrità anche a livello regionale. Invia periodicamente richieste GET HTTP o HTTPS all'URL dell'endpoint configurato in ogni area geografica. Se un endpoint non risponde entro la finestra di timeout per un determinato numero di intervalli consecutivi, Traffic Manager lo contrassegna come degradato e interrompe l'instradamento delle query DNS verso di esso, reindirizzando gli utenti verso un'area geografica integra.

Azure Application Gateway offre funzionalità di probe di integrità più avanzate rispetto al Load Balancer standard. Supporta probe personalizzate che specificano l'host header, l'intervallo di codici di stato previsto (ad esempio, 200-399) e una stringa da confrontare nel corpo della risposta. Application Gateway supporta anche il routing per percorso, consentendo a diversi pool backend di avere configurazioni di probe di integrità differenti per percorsi URL diversi.

La degradazione controllata è la capacità di un'applicazione di continuare a fornire funzionalità parziali quando una o più dipendenze hanno un problema. Invece di arrestarsi completamente, l'applicazione rileva l'indisponibilità di un servizio non critico e passa a uno stato degradato, ma ancora utile. Ad esempio, se un servizio di raccomandazione non è disponibile, un sito di e-commerce potrebbe mostrare suggerimenti generici invece di interrompere l'intera pagina del prodotto.

Il pattern circuit breaker impedisce a un'applicazione di chiamare ripetutamente un servizio downstream che presenta errori. Quando un servizio inizia a non funzionare, il circuit breaker si apre e restituisce immediatamente un errore o una risposta di fallback senza effettuare la chiamata di rete. Dopo un periodo di attesa, passa allo stato half-open e consente una richiesta di prova. Se la richiesta ha esito positivo, il circuito si chiude e riprende il normale funzionamento.

Per i guasti transitori (brevi interruzioni della rete, sovraccarico temporaneo del servizio), è appropriata una strategia di retry con exponential backoff. L'applicazione ripete la chiamata non riuscita dopo un intervallo, raddoppiando il ritardo a ogni tentativo fino a un massimo. L'aggiunta di un jitter (una variazione casuale) al ritardo impedisce che tutti i tentativi di nuovo invio si sincronizzino e sovraccarichino un servizio in fase di ripristino.

Il pattern bulkhead isola le diverse parti di un'applicazione in pool di risorse separati, in modo che un guasto in un'area non consumi tutte le risorse e non arresti l'intero sistema. Il nome deriva dalle paratie delle navi, che impediscono a un compartimento allagato di far affondare l'intera imbarcazione. In Azure, ciò può significare usare pool di thread separati o piani App Service separati per servizi diversi, così da contenere i guasti.

Una tecnica comune di riduzione graduale delle funzionalità consiste nel fornire dati memorizzati nella cache o obsoleti quando un'origine dati in tempo reale non è disponibile. Ad esempio, una pagina del catalogo prodotti potrebbe fornire i prezzi memorizzati il giorno precedente in Azure Cache for Redis, invece di visualizzare un errore se il database è temporaneamente irraggiungibile. Gli utenti riscontrano un inconveniente limitato (prezzi leggermente obsoleti) anziché un'interruzione completa.

La riduzione graduale delle funzionalità deve essere visibile e misurata. Usi Application Insights per monitorare, come metriche personalizzate, la frequenza delle aperture del circuit breaker, delle risposte di fallback e dei tentativi di nuovo invio. Configuri alert quando queste metriche superano determinate soglie, così il team reperibile viene informato che l'applicazione è in uno stato degradato, anche se l'esperienza dell'utente appare accettabile.

Verifichi la Sua comprensione dei concetti di Microsoft Azure Fundamentals (AZ-900) trattati in questa lezione.

In questa lezione ha appreso che le health probe consentono ai bilanciatori del carico di rilevare i backend non funzionanti e reindirizzare automaticamente il traffico; la riduzione graduale delle funzionalità mantiene le applicazioni parzialmente operative quando le dipendenze non funzionano; e pattern come circuit breaker, retry con backoff e bulkhead implementano la resilienza a livello applicativo. Prossimamente esamineremo i concetti di disaster recovery, definendo RTO, RPO e livelli di ripristino.