Blog
Nel contesto di applicazioni distribuite su piattaforme cloud o, più in generale, in un qualsiasi contesto che preveda una comunicazione tra molteplici servizi, uno degli aspetti fondamentali di un sistema è la capacità di tollerare errori transienti. Un errore si definisce transiente se si verifica per un breve periodo di tempo come, ad esempio, la perdita momentanea di connessione o timeout della stessa. Un sistema resiliente rispetto ad errori transienti di comunicazione risulterà più stabile ed efficiente.
Errori transienti di comunicazione sono generalmente comuni su architetture cloud oriented, per questo motivo è buona pratica prevedere una logica di retry che sia trasparente ai client per mascherare gli errori e minimizzarne l’impatto sull'applicazione.
I principali pattern di gestione degli errori sono i seguenti:
Cancel: Nel caso in cui l’errore riscontrato non sia di natura transiente o probabilmente verrebbe riscontrato nuovamente anche con successivi tentativi (ad esempio l’accesso ad una risorsa che restituisce uno Status Code 404), l’applicazione annullerà immediatamente l’operazione e riporterà l’eccezione.
Retry: Nel caso in cui l’errore riscontrato sia non comune o raro (ad esempio l’instabilità nella trasmissione dei pacchetti), l’applicazione invierà immediatamente un secondo tentativo poiché è improbabile che venga riscontrato nuovamente lo stesso errore.
Retry after delay: Nel caso in cui l’errore riscontrato sia di natura transiente, generato da situazioni temporanee che probabilmente ritorneranno a regime automaticamente (ad esempio la momentanea perdita di pacchetti), verrà schedulato un numero finito di retry intervallati da delay lineari o esponenziali.
Qualsiasi strategia si scelga per rendere un sistema resiliente agli errori transienti è necessario valutare attentamente il trade-off tra il tempo di attesa delle richieste e la probabilità di restituire l’errore ai client. Tale scelta è sicuramente legata alla tipologia dei servizi esposti ed al contesto applicativo. Per applicazioni definite non critiche è generalmente preferibile utilizzare una logica fail-fast per non impattare eccessivamente sul throughput dell’applicazione. Al contrario, per applicazioni batch, è preferibile aumentare il numero di retry e minimizzare gli errori.
Valutare una corretta politica di retry non significa solo incrementare la stabilità del sistema ma permette soprattutto di evitare effetti collaterali. Politiche di retry eccessivamente aggressive possono infatti degradare ulteriormente le prestazioni di un sistema già in sovraccarico.
RESTSchemaRetry è una libreria .NET Standard che implementa una semplice strategia di retry per chiamate a servizi REST. La versione attuale utilizza i pattern Retry after delay e Cancel per gestire gli eventuali errori transienti di comunicazione. La libreria analizza lo status code delle operazioni REST per decidere se effettuare nuovamente la chiamata oppure restituire direttamente l’errore.
Di seguito alcuni esempi di funzionamento:
In questo caso l'errore riscontrato ha status code 500 (Internal Server Error), verrà quindi considerato un errore transiente e si applicherà un pattern Retry after delay mascherando i successivi tentativi.
In questo caso l'errore riscontrato ha status code 404 (Not Found) e non verrà considerato un errore transiente poiché è improbabile che successivi tentativi ottengano risultati differenti, di conseguenza l'errore verrà riportato direttamente al chiamante.
La libreria è disponibile su GitHub sotto licenza MIT.
Risorse:
https://docs.microsoft.com/en-us/azure/architecture/patterns/retry
https://docs.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker
Francesco Del Re - engineering87