# REL 5 In che modo progetti le interazioni in un sistema distribuito per mitigare o affrontare gli errori?
I sistemi distribuiti si basano sulle reti di comunicazione per interconnettere i componenti (ad esempio server o servizi). Il carico di lavoro deve funzionare in modo affidabile nonostante la perdita o la latenza dei dati su queste reti. I componenti del sistema distribuito devono funzionare in modo da non influire negativamente su altri componenti o sul carico di lavoro. Queste best practice consentono ai carichi di lavoro di affrontare stress o guasti, recuperare più rapidamente e mitigare l'impatto di tali problemi. Il risultato è un miglioramento del tempo medio di ripristino (MTTR).
**Topics**
+ [REL05-BP01 Implementazione del degrado elegante per trasformare le dipendenze forti applicabili in dipendenze deboli](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 Richieste di limitazione (della larghezza di banda della rete)](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Controllo e limitazione delle chiamate di ripetizione](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Errore rapido e limitazione delle code](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Impostazione dei timeout dei client](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 Rendere i servizi stateless laddove possibile](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 Implementazione di leve di emergenza](rel_mitigate_interaction_failure_emergency_levers.md)
# REL05-BP01 Implementazione del degrado elegante per trasformare le dipendenze forti applicabili in dipendenze deboli
Quando le dipendenze di un componente non sono integre, il componente stesso può comunque funzionare, anche se in modo degradato. Ad esempio, quando una chiamata di dipendenza non riesce, utilizza invece una risposta statica predeterminata.
Considera un servizio B chiamato dal servizio A che a sua volta chiama il servizio C.
![\[Diagramma che mostra l'errore del servizio C quando viene chiamato dal servizio B. Il servizio B restituisce una risposta degradata al servizio A\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/graceful-degradation.png)
Quando il servizio B chiama il servizio C, ha ricevuto da quest'ultimo un errore o un timeout. Il servizio B, senza una risposta dal servizio C (e dai dati che contiene) restituisce invece ciò che può. Questo può essere l'ultimo valore buono memorizzato nella cache oppure il servizio B può sostituire una risposta statica predeterminata a ciò che avrebbe ricevuto dal servizio C. Può quindi restituire una risposta degradata all'intermediario, il servizio A. Senza questa risposta statica, l'errore nel servizio C si propagherebbe attraverso il servizio B fino al servizio A, causando una perdita di disponibilità.
Secondo il fattore moltiplicativo nell'equazione di disponibilità per le dipendenze forti (consulta [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122)), qualsiasi calo della disponibilità di C influisce notevolmente sulla disponibilità effettiva di B. Restituendo il servizio di risposta statica B mitiga l'errore in C e, sebbene degradato, rende la disponibilità del servizio C simile alla disponibilità del 100% (presupponendo che restituisca in modo affidabile la risposta statica in condizioni di errore). La risposta statica è una semplice alternativa alla restituzione di un errore e non è un tentativo di ricalcolare la risposta utilizzando metodi diversi. Tali tentativi a livello di un meccanismo completamente diverso che cercano di ottenere lo stesso risultato sono chiamati comportamento di fallback e sono un anti-modello da evitare.
Un altro esempio di degrado elegante è il *modello dell'interruttore*. Le strategie di ripetizione devono essere utilizzate quando l'errore è transitorio. Quando non è il caso e l'operazione potrebbe non riuscire, il modello dell'interruttore impedisce al client di eseguire una richiesta che potrebbe non riuscire. Quando le richieste vengono elaborate normalmente, l'interruttore viene chiuso e le richieste scorrono. Quando il sistema remoto inizia a restituire errori o presenta una latenza elevata, l'interruttore si apre e la dipendenza viene ignorata o i risultati vengono sostituiti con risposte ottenute più semplicemente, ma meno complete (che potrebbero essere semplicemente una cache di risposta). Periodicamente, il sistema tenta di chiamare la dipendenza per determinare se è stata ripristinata. In questo caso, l'interruttore viene chiuso.
![\[Diagramma che mostra l'interruttore in stato aperto e chiuso.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/circuit-breaker.png)
Oltre agli stati chiusi e aperti mostrati nel diagramma, dopo un periodo di tempo configurabile nello stato aperto, l'interruttore può passare allo stato semiaperto. In questo stato, tenta periodicamente di chiamare il servizio a una velocità molto inferiore rispetto al normale. Questa indagine viene utilizzata per controllare lo stato del servizio. Dopo un certo numero di successi nello stato semiaperto, l'interruttore passa allo stato chiuso e le normali richieste riprendono.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Implementa il degrado elegante per trasformare le dipendenze forti applicabili in dipendenze deboli. Quando le dipendenze di un componente non sono integre, il componente stesso può comunque funzionare, anche se in modo degradato. Ad esempio, quando una chiamata di dipendenza non riesce, utilizza invece una risposta statica predeterminata.
+ Restituendo una risposta statica, il carico di lavoro mitiga gli errori che si verificano nelle sue dipendenze.
+ [Corso Well-Architected: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
+ Rileva quando è probabile che l'operazione di ripetizione non vada a buon fine e impedisci al client di effettuare chiamate non riuscite con il modello dell'interruttore.
+ [CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html)
## Risorse
**Documenti correlati:**
+ [Amazon API Gateway: throttling delle richieste API per migliorare le prestazioni](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [CircuitBreaker (riepilogo dal libro Circuit Breaker da "Release It\$1")](https://martinfowler.com/bliki/CircuitBreaker.html)
+ [Ripetizione dei tentativi in caso di errore e backoff esponenziale in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Michael Nygard "Release It\$1 Design and Deploy Production-Ready Software"](https://pragprog.com/titles/mnee2/release-it-second-edition/)
+ [The Amazon Builders' Library: Evitare il fallback nei sistemi distribuiti](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [The Amazon Builders' Library: Evitare insormontabili backlog di code](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [The Amazon Builders' Library: Sfide e strategie del caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [The Amazon Builders' Library: Timeout, nuovi tentativi e backoff con jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Video correlati:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Presentazione della libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
**Esempi correlati:**
+ [Corso Well-Architected: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL05-BP02 Richieste di limitazione (della larghezza di banda della rete)
La richiesta di limitazione (della larghezza di banda della rete) è un modello di mitigazione per rispondere a un aumento imprevisto della domanda. Alcune richieste vengono soddisfatte, ma quelle che superano un limite definito vengono rifiutate e restituiscono un messaggio che indica che sono state sottoposte a throttling. L'aspettativa per i client è che si ritirino e abbandonino la richiesta o riprovino a una velocità più lenta.
I servizi devono essere progettati per gestire una capacità nota di richieste che ogni nodo o cella può elaborare. Questa capacità può essere stabilita mediante test di carico. È quindi necessario tenere traccia del tasso di arrivo delle richieste e se il tasso di arrivo temporaneo supera questo limite, la risposta appropriata è segnalare che la richiesta è stata limitata. Ciò consente all'utente di riprovare, potenzialmente su un nodo o una cella differente che potrebbe avere capacità disponibile. Amazon API Gateway fornisce metodi per la limitazione (della larghezza di banda della rete) delle richieste. Amazon SQS e Amazon Kinesis possono eseguire il buffer delle richieste, livellare il tasso di richiesta e alleggerire la necessità di limitazione (della larghezza di banda della rete) per le richieste che possono essere gestite in modo asincrono.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Richieste di limitazione (della larghezza di banda della rete). Si tratta di un modello di mitigazione per rispondere a un aumento imprevisto della domanda. Alcune richieste vengono soddisfatte, ma quelle che superano un limite definito vengono rifiutate e restituiscono un messaggio che indica che sono state sottoposte a throttling. L'aspettativa per i client è che si ritirino e abbandonino la richiesta o riprovino a una velocità più lenta.
+ Utilizzo di Amazon API Gateway
+ [throttling delle richieste API per migliorare il throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
## Risorse
**Documenti correlati:**
+ [Amazon API Gateway: throttling delle richieste API per migliorare le prestazioni](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Ripetizione dei tentativi in caso di errore e backoff esponenziale in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [The Amazon Builders' Library: Evitare il fallback nei sistemi distribuiti](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [The Amazon Builders' Library: Evitare insormontabili backlog di code](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [The Amazon Builders' Library: Timeout, nuovi tentativi e backoff con jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [throttling delle richieste API per migliorare il throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
**Video correlati:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Presentazione della libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP03 Controllo e limitazione delle chiamate di ripetizione
Utilizza il backoff esponenziale per eseguire nuovi tentativi dopo intervalli progressivamente più lunghi. Introduci il jitter per randomizzare gli intervalli di ripetizione e limitare il numero massimo di tentativi.
I componenti tipici di un sistema software distribuito includono server, sistemi di bilanciamento del carico, database e server DNS. Durante il funzionamento, e sempre soggetti ad anomalie, uno qualsiasi tra questi componenti può iniziare a generare errori. La tecnica predefinita per gestire gli errori consiste nell'implementare nuovi tentativi lato client. Questa tecnica aumenta l'affidabilità e la disponibilità dell'applicazione. Tuttavia, su vasta scala, e se i client tentano di riprovare l'operazione fallita non appena si verifica un errore, la rete può diventare rapidamente satura di richieste nuove e riproposte, ognuna delle quali compete per la larghezza di banda della rete. Ciò può causare una *tempesta di ripetizione dei tentativi,* che ridurrà la disponibilità del servizio. Questo modello potrebbe continuare finché non si verifica un errore completo del sistema.
Per evitare tali scenari, è necessario utilizzare gli algoritmi di backoff come il *backoff esponenziale* comune. Gli algoritmi di backoff esponenziale riducono gradualmente la velocità con cui vengono eseguiti i nuovi tentativi, evitando così la congestione della rete.
Molti SDK e librerie software, inclusi quelli di AWS, implementano una versione di questi algoritmi. Tuttavia, **non dare mai per scontato che esista un algoritmo di backoff: esegui sempre test e verificane la presenza.**
Il backoff semplice da solo non è sufficiente perché nei sistemi distribuiti tutti i client possono eseguire simultaneamente il backoff, creando cluster di chiamate ripetute. Nel suo post del blog [Exponential Backoff and Jitter (Jitter e backoff esponenziale) ](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-italics%0djitter/), spiega come modificare la funzione wait() nel backoff esponenziale per evitare cluster di chiamate riproposte. La soluzione consiste nell'aggiungere *jitter* nella funzione wait(). Per evitare di eseguire nuovi tentativi per troppo tempo, le implementazioni dovrebbero limitare il backoff a un valore massimo.
Infine, è importante configurare un *numero massimo di tentativi* o di tempo trascorso, dopo il quale i nuovi tentativi semplicemente falliranno. Gli SDK AWS lo implementano per impostazione predefinita e può essere configurato. Per i servizi di livello inferiore, un limite massimo di tentativi di risposta pari a zero o a uno può limitare il rischio ed essere comunque efficace in quanto i tentativi di risposta sono delegati ai servizi di livello superiore.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Controlla e limita le chiamate riproposte. Utilizza il backoff esponenziale per eseguire nuovi tentativi dopo intervalli progressivamente più lunghi. Introduci il jitter per randomizzare gli intervalli di ripetizione e limitare il numero massimo di tentativi.
+ [Ripetizione dei tentativi in caso di errore e backoff esponenziale in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ Gli SDK di Amazon implementano i nuovi tentativi e il backoff esponenziale per impostazione predefinita. Potrai implementare una logica similare nel tuo livello di dipendenze quando effettui chiamate ai tuoi servizi dipendenti. Potrai decidere quali sono i timeout e quando cessare i tentativi in base al tuo caso d'uso.
## Risorse
**Documenti correlati:**
+ [Amazon API Gateway: throttling delle richieste API per migliorare le prestazioni ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Ripetizione dei tentativi in caso di errore e backoff esponenziale in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [The Amazon Builders' Library: Evitare il fallback nei sistemi distribuiti](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [The Amazon Builders' Library: Evitare insormontabili backlog di code](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [The Amazon Builders' Library: Sfide e strategie del caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [The Amazon Builders' Library: Timeout, nuovi tentativi e backoff con jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Video correlati:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Presentazione della libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP04 Errore rapido e limitazione delle code
Se il carico di lavoro non è in grado di rispondere correttamente a una richiesta, restituisce rapidamente un errore. Ciò consente il rilascio delle risorse associate a una richiesta e permette al servizio di recuperare se le risorse sono in esaurimento. Se il carico di lavoro è in grado di rispondere correttamente, ma la frequenza delle richieste è troppo elevata, utilizza una coda per eseguire il buffer delle richieste. Tuttavia, non consentire code lunghe che possono comportare l'elaborazione di richieste obsolete a cui il client ha già rinunciato.
Questa best practice si applica al lato server, o ricevitore, della richiesta.
Tieni presente che le code possono essere create a più livelli di un sistema e possono compromettere notevolmente la possibilità di recuperare rapidamente quando le richieste obsolete (che non necessitano più di una risposta) vengono elaborate prima di richieste più recenti. Fai attenzione ai luoghi in cui sono presenti code. Spesso si nascondono nei flussi di lavoro o nel lavoro registrato in un database.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Errore rapido e limitazione delle code. Se il carico di lavoro non è in grado di rispondere correttamente a una richiesta, restituisce rapidamente un errore. Ciò consente il rilascio delle risorse associate a una richiesta e permette al servizio di recuperare se le risorse sono in esaurimento. Se il carico di lavoro è in grado di rispondere correttamente, ma la frequenza delle richieste è troppo elevata, utilizza una coda per eseguire il buffer delle richieste. Tuttavia, non consentire code lunghe che possono comportare l'elaborazione di richieste obsolete a cui il client ha già rinunciato.
+ Implementazione d'errore rapido quando il servizio è eccessivamente sollecitato.it
+ [Errore rapido](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ Limita le code in un sistema basato su code, quando l'elaborazione si interrompe ma i messaggi continuano ad arrivare, il debito di messaggi può accumularsi in un backlog di grandi dimensioni, determinando un aumento del tempo di elaborazione. Il lavoro potrebbe essere completato troppo tardi perché i risultati siano utili, provocando essenzialmente il danneggiamento della disponibilità che l'accodamento doveva evitare.
+ [The Amazon Builders' Library: Evitare insormontabili backlog di code](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
## Risorse
**Documenti correlati:**
+ [Ripetizione dei tentativi in caso di errore e backoff esponenziale in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Errore rapido](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [The Amazon Builders' Library: Evitare il fallback nei sistemi distribuiti](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [The Amazon Builders' Library: Evitare insormontabili backlog di code](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [The Amazon Builders' Library: Sfide e strategie del caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [The Amazon Builders' Library: Timeout, nuovi tentativi e backoff con jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Video correlati:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Presentazione della libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP05 Impostazione dei timeout dei client
Imposta i timeout in modo appropriato, verificali sistematicamente e non fare affidamento sui valori predefiniti poiché sono generalmente troppo alti.
Questa best practice si applica al lato client, o al mittente, della richiesta.
Imposta sia un timeout di connessione che un timeout di richiesta su qualsiasi chiamata remota e, generalmente, su qualsiasi chiamata tra i processi. Molti framework offrono funzionalità di timeout integrate, ma fai attenzione perché molti hanno valori predefiniti infiniti o troppo alti. Un valore troppo elevato riduce l'utilità del timeout perché le risorse continuano a essere consumate mentre il client attende che si verifichi il timeout. Un valore troppo basso può generare un aumento del traffico sul back-end e una maggiore latenza perché vengono ritentate troppe richieste. In alcuni casi, questo può portare a interruzioni complete perché tutte le richieste vengono ritentate.
Per ulteriori informazioni su come Amazon utilizza timeout, nuovi tentativi e backoff con jitter, consulta la [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card).
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Imposta sia un timeout di connessione che un timeout di richiesta su qualsiasi chiamata remota e, generalmente, su qualsiasi chiamata tra i processi. Molti framework offrono funzionalità di timeout integrate, ma fai attenzione perché molti hanno valori predefiniti infiniti o troppo alti. Un valore troppo elevato riduce l'utilità del timeout perché le risorse continuano a essere consumate mentre il client attende che si verifichi il timeout. Un valore troppo basso può generare un aumento del traffico sul back-end e una maggiore latenza perché vengono ritentate troppe richieste. In alcuni casi, questo può portare a interruzioni complete perché tutte le richieste vengono ritentate.
+ [AWS SDK: Retries and Timeouts (SDK AWS: nuovi tentativi e timeout)](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
## Risorse
**Documenti correlati:**
+ [AWS SDK: Retries and Timeouts (SDK AWS: nuovi tentativi e timeout)](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Amazon API Gateway: throttling delle richieste API per migliorare le prestazioni](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Ripetizione dei tentativi in caso di errore e backoff esponenziale in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [The Amazon Builders' Library: Timeout, nuovi tentativi e backoff con jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Video correlati:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Presentazione della libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP06 Rendere i servizi stateless laddove possibile
I servizi non devono richiedere lo stato oppure devono eseguire l'offload dello stato in modo tale che, tra diverse richieste client, non vi sia alcuna dipendenza dai dati archiviati localmente su disco o in memoria. In questo modo i server possono essere sostituiti a piacimento senza compromettere la disponibilità. Amazon ElastiCache o Amazon DynamoDB sono ottime destinazioni per lo stato di offload.
![\[In questa applicazione Web stateless, viene eseguito l'offload dello stato della sessione in Amazon ElastiCache.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/stateless-webapp.png)
Quando gli utenti o i servizi interagiscono con un'applicazione, spesso eseguono una serie di interazioni che formano una sessione. Una sessione è un dato univoco per gli utenti che persistono tra le richieste mentre utilizzano l'applicazione. Un'applicazione stateless è un'applicazione che non richiede la conoscenza delle interazioni precedenti e non memorizza le informazioni sulla sessione.
Una volta progettata per essere stateless, puoi utilizzare servizi di elaborazione serverless, come AWS Lambda o AWS Fargate.
Oltre alla sostituzione del server, un altro vantaggio delle applicazioni stateless è che possono ricalibrare orizzontalmente perché qualsiasi risorsa di calcolo disponibile (ad esempio istanze EC2 e funzioni AWS Lambda) può soddisfare ogni richiesta.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Trasforma le applicazioni in stateless. Applicazioni stateless consentono un dimensionamento orizzontale e sono tolleranti al guasto di un singolo nodo.
+ Eliminazione dello stato che potrebbe effettivamente essere memorizzato nei parametri di richiesta.
+ Dopo aver esaminato se lo stato è necessario, sposta qualsiasi tracciamento dello stato in una cache multizona resiliente o in un archivio di dati come Amazon ElastiCache, Amazon RDS, Amazon DynamoDB o una soluzione di dati distribuiti di terze parti. Memorizza uno stato impossibile da spostare in datastore resilienti.
+ Alcuni dati (come i cookie) possono passare nei titoli o nei parametri di query.
+ Effettua il refactoring per rimuovere uno stato che può essere passato velocemente nelle richieste.
+ È possibile che alcuni dati non siano effettivamente necessari per richiesta e possano essere recuperati on demand.
+ Rimuovi i dati recuperabili in modo asincrono.
+ Scegli un datastore che soddisfi i requisiti per uno stato necessario.
+ Valuta l'utilizzo di un database NoSQL per dati non relazionali.
## Risorse
**Documenti correlati:**
+ [The Amazon Builders' Library: Evitare il fallback nei sistemi distribuiti](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [The Amazon Builders' Library: Evitare insormontabili backlog di code](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [The Amazon Builders' Library: Sfide e strategie del caching](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
# REL05-BP07 Implementazione di leve di emergenza
Le leve di emergenza sono processi rapidi che possono mitigare l'impatto sulla disponibilità sul carico di lavoro.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Implementa leve di emergenza. Si tratta di processi rapidi che possono mitigare l'impatto della disponibilità sul carico di lavoro. Possono essere utilizzati in assenza di una causa principale. Una leva di emergenza ideale riduce a zero il carico cognitivo dei resolver fornendo criteri di attivazione e disattivazione completamente deterministici. Le leve sono spesso manuali, ma possono anche essere automatizzate
+ Esempi di leve includono
+ Bloccare tutto il traffico dei robot
+ Servire pagine statiche anziché dinamiche
+ Ridurre la frequenza delle chiamate a una dipendenza
+ Limitare le chiamate dalle dipendenze
+ Suggerimenti per l'implementazione e l'utilizzo di leve di emergenza
+ Quando le leve sono attivate, fai di meno, non di più
+ Rendi le cose semplici, evita comportamenti bimodali
+ Testare periodicamente le leve
+ Di seguito sono elencati alcuni esempi di operazioni che NON rappresentano leve di emergenza
+ Aggiunta di capacità
+ Chiamare i proprietari dei servizi dei client che dipendono dal tuo servizio e chiedere loro di ridurre le chiamate
+ Apportare una modifica al codice e rilasciarlo