# Architettura del carico di lavoro
**Topics**
+ [REL 3 In che modo progetti l'architettura del servizio di carico di lavoro?](w2aac19b9b7b5.md)
+ [REL 4 In che modo progetti le interazioni in un sistema distribuito per evitare errori?](w2aac19b9b7b7.md)
+ [REL 5 In che modo progetti le interazioni in un sistema distribuito per mitigare o affrontare gli errori?](w2aac19b9b7b9.md)
# REL 3 In che modo progetti l'architettura del servizio di carico di lavoro?
Creazione di carichi di lavoro altamente scalabili e affidabili utilizzando un'architettura orientata ai servizi (SOA) o un'architettura di microservizi. L'architettura orientata ai servizi (SOA) è la pratica di rendere i componenti software riutilizzabili tramite interfacce di servizio. L'architettura dei microservizi va oltre, per rendere i componenti più piccoli e semplici.
**Topics**
+ [REL03-BP01 Scelta del tipo di segmentazione del carico di lavoro](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Creazione di servizi focalizzati su domini e funzionalità aziendali specifici](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Fornitura di contratti di servizio per API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Scelta del tipo di segmentazione del carico di lavoro
La segmentazione del carico di lavoro è importante quando vengono determinati i requisiti di resilienza dell'applicazione. L'architettura monolitica deve essere evitata se possibile. Valuta invece con particolare attenzione quali componenti dell'applicazione possono essere suddivisi in microservizi. A seconda dei requisiti dell'applicazione, ciò potrebbe risultare in una combinazione di architettura orientata ai servizi (SOA) e microservizi, laddove possibile. I carichi di lavoro stateless sono maggiormente idonei a essere implementati come microservizi.
**Risultato desiderato:** i carichi di lavoro devono essere supportabili, scalabili e devono essere caratterizzati dalla minore interdipendenza possibile.
Quando scegli come segmentare il carico di lavoro, trova il giusto compromesso tra i vantaggi e le complessità. Ciò che è giusto per un nuovo prodotto al primo lancio è diverso dai requisiti di un carico di lavoro creato per ridimensionare le risorse. Durante la rifattorizzazione (riprogettazione) di un monolito, dovrai considerare la capacità dell'applicazione di supportare la suddivisione in servizi stateless. La suddivisione dei servizi in elementi più piccoli consente a team ristretti e ben definiti di svilupparli e gestirli. Tuttavia, servizi di piccole dimensioni possono introdurre complessità, che includono un eventuale aumento della latenza, un debug più complesso e un maggiore carico operativo.
**Anti-pattern comuni:**
+ Il [microservizio *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) rappresenta una situazione in cui i componenti atomici diventano così interdipendenti che un errore verificatosi in un componente genera un errore molto più grande, rendendo i componenti rigidi e fragili se considerati come monolito.
**Vantaggi dell'adozione di questa best practice:**
+ Segmenti più specifici comportano maggiore agilità, flessibilità organizzativa e scalabilità.
+ Riduzione dell'impatto derivante dall'interruzione dei servizi.
+ I componenti dell'applicazione possono avere requisiti di disponibilità diversi, che a loro volta possono essere supportati da una segmentazione più atomica.
+ Responsabilità ben definite per i team che supportano il carico di lavoro.
**Livello di rischio associato se questa best practice non fosse adottata:** alto
## Guida all'implementazione
Scegli il tipo di architettura in base al tipo di segmentazione del carico di lavoro. Scegli una SOA o un'architettura di microservizi (o, in alcuni rari casi, un'architettura monolitica). Anche se scegli di iniziare con un'architettura monolitica, devi assicurarti che sia modulare e possa evolvere in SOA o microservizi man mano che il prodotto si dimensiona con l'adozione da parte degli utenti. La SOA e i microservizi offrono rispettivamente una segmentazione più piccola, preferita come architettura moderna scalabile e affidabile, ma ci sono compromessi da considerare soprattutto quando si distribuisce un'architettura di microservizi.
Uno dei principali compromessi è che ora disponi di un'architettura di calcolo distribuita che può rendere più difficile il raggiungimento dei requisiti di latenza degli utenti ed è presente un'ulteriore complessità nel debug e nel tracciamento delle interazioni degli utenti. Puoi utilizzare AWS X-Ray per risolvere questo problema. Un altro effetto da considerare è l'aumento della complessità operativa man mano che aumenta il numero di applicazioni che gestisci, che richiede la distribuzione di più componenti di indipendenza.
![\[Diagramma che illustra il confronto tra architettura monolitica, orientata ai servizi e di microservizi\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)
## Passaggi dell'implementazione
+ Determina l'architettura più appropriata per rifattorizzare (riprogettare) o creare l'applicazione. SOA e microservizi offrono segmentazione rispettivamente di dimensioni minori, preferita in quanto architettura moderna, scalabile e affidabile. SOA può essere un buon compromesso per ottenere una segmentazione di dimensioni minori, evitando al contempo alcune delle complessità dei microservizi. Per ulteriori dettagli, consulta [I compromessi dei microservizi](https://martinfowler.com/articles/microservice-trade-offs.html).
+ Se il carico di lavoro è adatto e la tua organizzazione può supportarla, è consigliabile utilizzare un'architettura di microservizi per ottenere la massima agilità e affidabilità. Per ulteriori dettagli, consulta [Implementing Microservices on AWS (Implementazione di microservizi in AWS).](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Considera l'ipotesi di attenerti al modello [*Strangler* Fig](https://martinfowler.com/bliki/StranglerFigApplication.html) per eseguire la rifattorizzazione (riprogettazione) di un monolito in componenti più piccoli. Ciò comporta la graduale sostituzione di componenti specifici dell'applicazione con nuove applicazioni e nuovi servizi. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) funge da punto di partenza per la rifattorizzazione incrementale. Per ulteriori dettagli, consulta [Seamlessly migrate on-premises legacy workloads using a strangler pattern (Migrazione senza problemi di carichi di lavoro legacy on-premise mediante un modello Strangler)](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ L'implementazione di microservizi può richiedere un meccanismo di individuazione dei servizi per consentire ai servizi distribuiti di comunicare tra loro. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) può essere utilizzato con architetture orientate ai servizi per offrire rilevamento e accesso affidabili ai servizi. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) può inoltre essere utilizzato per il rilevamento dinamico dei servizi basato su DNS.
+ In caso di migrazione da un monolito a una SOA, [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) può aiutare a colmare il divario come bus del servizio durante la riprogettazione delle applicazioni legacy nel cloud.
+ Per i monoliti esistenti con un unico database condiviso, scegli come riorganizzare i dati in segmenti più piccoli. Questa riorganizzazione può avvenire per unità aziendale, schema di accesso o struttura dei dati. A questo punto del processo di rifattorizzazione (riprogettazione), deve orientare la scelta verso un database di tipo relazionale o non relazionale (NoSQL). Per ulteriori dettagli, consulta [From SQL to NoSQL (Da SQL a NoSQL)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**Livello di impegno per il piano di implementazione:** alto
## Risorse
**Best practice correlate:**
+ [REL03-BP02 Creazione di servizi focalizzati su domini e funzionalità aziendali specifici](rel_service_architecture_business_domains.md)
**Documenti correlati:**
+ [Amazon API Gateway: configurazione di una REST API mediante OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Cosa si intende per architettura orientata ai servizi?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Bounded Context (un modello centrale in Domain-Driven Design)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [I compromessi dei microservizi](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservizi: una definizione di questo nuovo termine di architettura](https://www.martinfowler.com/articles/microservices.html)
+ [Implementazione di microservizi in AWS](https://aws.amazon.com/microservices/)
+ [What is AWS App Mesh? (Che cos'è AWS App Mesh?)](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**Esempi correlati:**
+ [Iterative App Modernization Workshop (Workshop sulla modernizzazione delle applicazioni interattive)](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**Video correlati:**
+ [Delivering Excellence with Microservices on AWS (Implementazione dell'eccellenza con i microservizi in AWS)](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Creazione di servizi focalizzati su domini e funzionalità aziendali specifici
L'architettura orientata ai servizi (SOA) crea servizi con funzioni ben delineate definite dalle esigenze aziendali. I microservizi utilizzano modelli di dominio e contesto delimitato per restringere ulteriormente questa operazione, in modo che ogni servizio esegua una sola operazione. Focalizzarsi su funzionalità specifiche consente di differenziare i requisiti di affidabilità dei diversi servizi e mirare agli investimenti in modo più specifico. Un problema aziendale conciso e l'associazione di un piccolo team a ciascun servizio facilitano il dimensionamento dell'organizzazione.
Nella progettazione di un'architettura di microservizi, è utile impiegare Domain-Driven Design (DDD) per modellare il problema aziendale utilizzando le entità. Ad esempio, per il sito Web Amazon.com, le entità possono includere pacchetti, consegna, pianificazione, prezzo, sconto e valuta. Quindi il modello viene ulteriormente suddiviso in modelli più piccoli utilizzando il [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html), dove le entità che condividono caratteristiche e attributi simili vengono raggruppate insieme. Pertanto, utilizzando il pacchetto di esempio di Amazon.com, la consegna e la pianificazione sarebbero parte del contesto di spedizione, mentre il prezzo, lo sconto e la valuta fanno parte del contesto dei prezzi. Con il modello diviso in contesti, emerge un modello su come delimitare i microservizi.
![\[Modello di come delimitare i microservizi\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/building-services.png)
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Progetta il carico di lavoro in base ai domini aziendali e alle loro rispettive funzionalità. Focalizzarsi su funzionalità specifiche consente di differenziare i requisiti di affidabilità dei diversi servizi e mirare agli investimenti in modo più specifico. Un problema aziendale conciso e l'associazione di un piccolo team a ciascun servizio facilitano il dimensionamento dell'organizzazione.
+ Esegui l'analisi di dominio per mappare una progettazione basata sul dominio (DDD, domain-driven design) per il carico di lavoro. In seguito, puoi scegliere un tipo di architettura per soddisfare le esigenze del carico di lavoro.
+ [How to break a Monolith into Microservices (Come trasformare un monolite in microservizi)](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Getting Started with DDD when Surrounded by Legacy Systems (Iniziare con il DDD quando si è circondati da sistemi legacy)](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Eric Evans "Domain-Driven Design: Tackling Complexity in the Heart of Software"](https://www.amazon.com/gp/product/0321125215)
+ [Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Suddividi i tuoi servizi in componenti più piccoli possibile. Con l'architettura di microservizi, puoi dividere il tuo carico di lavoro in componenti dotati della funzionalità minima per consentire agilità e ridimensionamento dell'organizzazione.
+ Definisci l'API per il carico di lavoro e i suoi obiettivi di progettazione, limiti e qualsiasi altra considerazione per l'uso.
+ Definizione dell'API.
+ La definizione dell'API deve consentire la crescita e parametri aggiuntivi.
+ Definizione delle disponibilità progettate.
+ La tua API può avere più obiettivi di progettazione per funzioni differenti.
+ Definizione di limiti
+ Esegui test per definire i limiti delle tue capacità di carico di lavoro.
## Risorse
**Documenti correlati:**
+ [Amazon API Gateway: configurazione di una REST API mediante OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Bounded Context (un modello centrale in Domain-Driven Design)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Eric Evans "Domain-Driven Design: Tackling Complexity in the Heart of Software"](https://www.amazon.com/gp/product/0321125215)
+ [Getting Started with DDD when Surrounded by Legacy Systems (Iniziare con il DDD quando si è circondati da sistemi legacy)](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [How to break a Monolith into Microservices (Come trasformare un monolite in microservizi)](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [I compromessi dei microservizi](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservizi: una definizione di questo nuovo termine di architettura](https://www.martinfowler.com/articles/microservices.html)
+ [Implementazione di microservizi in AWS](https://aws.amazon.com/microservices/)
# REL03-BP03 Fornitura di contratti di servizio per API
I contratti di servizio sono accordi documentati tra i team sull'integrazione dei servizi e includono una definizione API leggibile dal computer, limiti di velocità e aspettative di prestazioni. Una strategia di controllo delle versioni consente ai clienti di continuare a utilizzare l'API esistente e migrare le applicazioni all'API più recente quando sono pronte. La distribuzione può avvenire in qualsiasi momento, purché il contratto non venga violato. Il team del fornitore di servizi può utilizzare lo stack tecnologico scelto per soddisfare il contratto API. Analogamente, l'utente del servizio può utilizzare la propria tecnologia.
I microservizi portano il concetto dell'architettura orientata ai servizi (SOA) al punto della creazione di servizi che hanno una serie minima di funzionalità. Ogni servizio pubblica un'API e obiettivi di progettazione, limiti e altre considerazioni per l'utilizzo del servizio. Questo stabilisce un *contratto* con le applicazioni di chiamata. Questo comporta tre vantaggi principali:
+ Il servizio ha un problema aziendale circoscritto da risolvere e un piccolo team proprietario del problema aziendale. Questo consente un miglior ridimensionamento organizzativo.
+ Ciascun team può effettuare un'implementazione in qualsiasi momento purché questa soddisfi i rispettivi requisiti "contrattuali" e dell'API.
+ Il team può utilizzare qualsiasi stack tecnologico a condizione che soddisfi le proprie API e altri requisiti di "contratto".
Amazon API Gateway è un servizio completamente gestito che semplifica agli sviluppatori la creazione, la pubblicazione, la manutenzione, il monitoraggio e la protezione delle API su qualsiasi scala. Gestisce tutte le attività coinvolte nell'accettazione e nell'elaborazione di fino a centinaia di migliaia di chiamate API simultanee, tra cui la gestione del traffico, il controllo delle autorizzazioni e degli accessi, il monitoraggio e la gestione delle versioni delle API. Utilizzando OpenAPI Specification (OAS), precedentemente noto come Swagger Specification, è possibile definire il contratto API e importarlo in API Gateway. Con API Gateway, puoi eseguire la versione e la distribuzione delle API.
**Livello di rischio associato se questa best practice non fosse adottata:** Bassa
## Guida all'implementazione
+ Fornisci contratti di servizio per API: i contratti di servizio sono accordi documentati tra i team sull'integrazione dei servizi e includono una definizione di API leggibile meccanicamente, limiti di velocità e aspettative di prestazioni.
+ [Amazon API Gateway: configurazione di una REST API mediante OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ Una strategia di controllo delle versioni consente ai client di continuare a utilizzare l'API esistente e migrare le applicazioni all'API più recente quando sono pronte.
+ Amazon API Gateway è un servizio completamente gestito che semplifica agli sviluppatori la creazione delle API su qualsiasi scala. Utilizzando OpenAPI Specification (OAS), precedentemente noto come Swagger Specification, puoi definire il contratto API e importarlo in API Gateway. Con API Gateway, puoi eseguire la versione e la distribuzione delle API.
## Risorse
**Documenti correlati:**
+ [Amazon API Gateway: configurazione di una REST API mediante OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Bounded Context (un modello centrale in Domain-Driven Design)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [I compromessi dei microservizi](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservizi: una definizione di questo nuovo termine di architettura](https://www.martinfowler.com/articles/microservices.html)
+ [Implementazione di microservizi in AWS](https://aws.amazon.com/microservices/)
# REL 4 In che modo progetti le interazioni in un sistema distribuito per evitare 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 in 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 prevengono gli errori e migliorano il tempo medio tra errori (MTBF).
**Topics**
+ [REL04-BP01 Identificazione del tipo di sistema distribuito necessario](rel_prevent_interaction_failure_identify.md)
+ [REL04-BP02 Implementazione di dipendenze "loosely coupled"](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL04-BP03 Esecuzione di un lavoro costante](rel_prevent_interaction_failure_constant_work.md)
+ [REL04-BP04 Rendere tutte le risposte idempotenti](rel_prevent_interaction_failure_idempotent.md)
# REL04-BP01 Identificazione del tipo di sistema distribuito necessario
I sistemi distribuiti hard real-time richiedono risposte che devono essere fornite in modo sincrono e rapido, mentre i sistemi soft real-time hanno una finestra temporale più generosa di minuti o più per la risposta. I sistemi offline gestiscono le risposte tramite elaborazione in batch o asincrona. I sistemi distribuiti hard real-time hanno i requisiti di affidabilità più severi.
Le difficoltà maggiori [con i sistemi distribuiti](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) riguardano i sistemi distribuiti hard real-time, noti anche come servizi di richiesta/risposta. La difficoltà sta nel fatto che le richieste arrivino in modo imprevedibile e le risposte debbano essere fornite rapidamente (ad esempio, il cliente è attivamente in attesa della risposta). Alcuni esempi includono server Web front-end, pipeline degli ordini, transazioni con carte di credito, ogni API AWS e telefonia.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Identifica il tipo di sistema distribuito necessario. Le sfide nell'ambito dei sistemi distribuiti includevano la latenza, il dimensionamento, la comprensione delle API di rete, i dati di marshalling e non-marshalling e la complessità di algoritmi come Paxos. Man mano che i sistemi diventano più grandi e più distribuiti, quelli che erano casi teorici limite diventano eventi regolari.
+ [The Amazon Builders' Library: Difficoltà dei sistemi distribuiti](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ I sistemi distribuiti hard real-time richiedono risposte da fornire in modo sincrono e rapido.
+ I sistemi soft real-time hanno una finestra temporale più generosa di minuti o più per la risposta.
+ I sistemi offline gestiscono le risposte tramite elaborazione in batch o asincrona.
+ I sistemi distribuiti hard real-time hanno i requisiti di affidabilità più severi.
## Risorse
**Documenti correlati:**
+ [Amazon EC2: Ensuring Idempotency (EC2: garantire l'idempotenza)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [The Amazon Builders' Library: Difficoltà dei sistemi distribuiti](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [The Amazon Builders' Library: Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Che cos'è Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**Video correlati:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (AWS New York Summit 2019: Introduzione alle architetture guidate dagli eventi e ad Amazon EventBridge) (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small (Chiudere i cicli e aprire le menti: come prendere il controllo dei sistemi, grandi e piccoli) (sono inclusi accoppiamento debole, lavoro costante e stabilità statica) (ARC337)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (Passare alle architetture basate sugli eventi) (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP02 Implementazione di dipendenze "loosely coupled"
Le dipendenze come sistemi di accodamento, sistemi di streaming, flussi di lavoro e sistemi di bilanciamento del carico sono "loosely coupled" (con accoppiamento debole). L'accoppiamento debole aiuta a isolare il comportamento di un componente dagli altri componenti che dipendono da esso, aumentando la resilienza e l'agilità.
Se i cambiamenti apportati a un componente forzano la modifica anche di altri componenti basati sullo stesso, allora si parla di *"tightly* coupling" (accoppiamento stretto). *Il "loose* coupling" (accoppiamento debole) interrompe questa dipendenza, in modo che i componenti dipendenti debbano conoscere solo l'interfaccia con versione e pubblicata. L'implementazione di un accoppiamento debole tra dipendenze isola un errore all'interno di una dipendenza affinché non influenzi l'altra.
L'accoppiamento debole consente di aggiungere liberamente ulteriore codice o caratteristiche a un componente, riducendo al minimo i rischi per i componenti che dipendono da esso. Inoltre, la scalabilità è migliorata in quanto è possibile aumentare orizzontalmente o persino modificare l'implementazione sottostante della dipendenza.
Per migliorare ulteriormente la resilienza tramite accoppiamento debole, rendi le interazioni dei componenti asincrone laddove possibile. Questo modello è idoneo a qualsiasi interazione che non richieda una risposta immediata e laddove la conferma della registrazione di una richiesta sia sufficiente. Include un componente che genera eventi e un altro che li utilizza. I due componenti non si integrano tramite un'interazione diretta point-to-point, ma in genere attraverso un livello di archiviazione intermedio durevole, come una coda SQS o una piattaforma di dati in streaming come Amazon Kinesis o AWS Step Functions.
![\[Diagramma che mostra le dipendenze come i sistemi di accodamento e i load balancer sono "loosely coupled"\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/loosely-coupled-dependencies.png)
Le code Amazon SQS ed Elastic Load Balancer sono solo due modi per aggiungere un livello intermedio per l'accoppiamento debole. Le architetture basate su eventi possono anche essere create in Cloud AWS utilizzando Amazon EventBridge, che può astrarre i client (produttori di eventi) dai servizi a cui fanno affidamento (consumatori di eventi). Amazon Simple Notification Service (Amazon SNS) è una soluzione efficace quando hai bisogno di messaggistica da-molti-a-molti, dalla velocità di trasmissione effettiva elevata e basata su push. Utilizzando gli argomenti di Amazon SNS, i sistemi di pubblicazione possono inviare messaggi a un numero elevato di endpoint sottoscrittori per l'elaborazione parallela.
Mentre le code offrono diversi vantaggi, nella maggior parte dei sistemi hard real-time, le richieste più vecchie di una soglia temporale (spesso secondi) dovrebbero essere considerate obsolete (il client ha abbandonato e non è più in attesa di una risposta) e non elaborate. In questo modo, è possibile elaborare invece le richieste più recenti (e probabilmente ancora valide).
**Anti-pattern comuni:**
+ Distribuzione di un singleton come parte di un carico di lavoro.
+ Invocazione diretta di API tra livelli di carico di lavoro senza funzionalità di failover o elaborazione asincrona della richiesta.
**Vantaggi dell'adozione di questa best practice:** L'accoppiamento debole aiuta a isolare il comportamento di un componente dagli altri componenti che dipendono da esso, aumentando la resilienza e l'agilità. L'errore in un componente è isolato dagli altri.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Implementazione di dipendenze "loosely coupled". Le dipendenze come sistemi di accodamento, sistemi di streaming, flussi di lavoro e sistemi di bilanciamento del carico sono "loosely coupled" (con accoppiamento debole). L'accoppiamento debole aiuta a isolare il comportamento di un componente dagli altri componenti che dipendono da esso, aumentando la resilienza e l'agilità.
+ [AWS re:Invent 2019: Moving to event-driven architectures (Passare alle architetture basate sugli eventi) (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Che cos'è Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ Amazon EventBridge consente di creare architetture basate su eventi caratterizzate da accoppiamento e distribuzione deboli.
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (AWS New York Summit 2019: Introduzione alle architetture guidate dagli eventi e ad Amazon EventBridge) (MAD205)](https://youtu.be/tvELVa9D9qU)
+ Se i cambiamenti apportati a un componente forzano la modifica anche di altri componenti che si basano su esso, allora sono strettamente accoppiati. L'accoppiamento debole interrompe questa dipendenza, in modo che i componenti dipendenti debbano conoscere solo l'interfaccia con versione e pubblicata.
+ Rendere le interazioni dei componenti asincrone, laddove possibile. Questo modello è idoneo a qualsiasi interazione che non richieda una risposta immediata e laddove la conferma della registrazione di una richiesta sia sufficiente.
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (Applicazioni scalabili serverless basate sugli eventi con l'utilizzo di Amazon SQS e Lambda) (API304)](https://youtu.be/2rikdPIFc_Q)
## Risorse
**Documenti correlati:**
+ [AWS re:Invent 2019: Moving to event-driven architectures (Passare alle architetture basate sugli eventi) (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon EC2: Ensuring Idempotency (EC2: garantire l'idempotenza)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [The Amazon Builders' Library: Difficoltà dei sistemi distribuiti](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [The Amazon Builders' Library: Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Che cos'è Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**Video correlati:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (AWS New York Summit 2019: Introduzione alle architetture guidate dagli eventi e ad Amazon EventBridge) (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small (Chiudere i cicli e aprire le menti: come prendere il controllo dei sistemi, grandi e piccoli) (sono inclusi accoppiamento debole, lavoro costante e stabilità statica) (ARC337)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (Passare alle architetture basate sugli eventi) (SVS308)](https://youtu.be/h46IquqjF3E)
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (Applicazioni scalabili serverless basate sugli eventi con l'utilizzo di Amazon SQS e Lambda) (API304)](https://youtu.be/2rikdPIFc_Q)
# REL04-BP03 Esecuzione di un lavoro costante
I sistemi possono fallire quando si verificano modifiche rapide e di grandi dimensioni nel carico. Ad esempio, se il carico di lavoro effettua un controllo dell'integrità di migliaia di server deve inviare ogni volta lo stesso payload delle dimensioni (uno snapshot completo dello stato corrente). Indipendentemente dal fatto che non ci siano server guasti, o che lo siano tutti, il sistema di controllo dello stato esegue un lavoro costante con modifiche rapide e di piccole dimensioni.
Ad esempio, se il sistema di controllo dello stato monitora 100.000 server, il carico su di esso è nominale al di sotto del tasso di errore normalmente basso del server. Tuttavia, se un evento importante rendesse la metà di questi server non integra, il sistema di controllo dello stato sarebbe sovraccarico nel tentativo di aggiornare i sistemi di notifica e comunicare lo stato con i client. Pertanto, il sistema di controllo dello stato dovrebbe ogni volta inviare lo snapshot completo dello stato corrente. 100.000 stati di integrità del server, ciascuno rappresentato da un bit, sarebbero solo un payload di 12,5 KB. Indipendentemente dal fatto che non ci siano server guasti, o che lo siano tutti, il sistema di controllo dello stato esegue un lavoro costante e le modifiche rapide e di grandi dimensioni non rappresentano una minaccia per la stabilità del sistema. Questo è in realtà il modo in cui Amazon Route 53 gestisce i controlli dell'integrità degli endpoint (come gli indirizzi IP) per stabilire come gli utenti finali vengono instradati verso di loro.
**Livello di rischio associato se questa best practice non fosse adottata:** Bassa
## Guida all'implementazione
+ Esegui un lavoro costante in modo che i sistemi non falliscano quando si verificano cambiamenti rapidi e significativi nel carico.
+ Implementazione di dipendenze "loosely coupled". Le dipendenze come sistemi di accodamento, sistemi di streaming, flussi di lavoro e sistemi di bilanciamento del carico sono "loosely coupled" (con accoppiamento debole). L'accoppiamento debole aiuta a isolare il comportamento di un componente dagli altri componenti che dipendono da esso, aumentando la resilienza e l'agilità.
+ [The Amazon Builders' Library: Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small (Chiudere i cicli e aprire le menti: come prendere il controllo dei sistemi, grandi e piccoli), include lavoro costante (ARC337)](https://youtu.be/O8xLxNje30M?t=2482)
+ Per l'esempio di un sistema di controllo dell'integrità che monitora 100.000 server, progetta i carichi di lavoro in modo che le dimensioni dei payload rimangano costanti indipendentemente dal numero di successi o di fallimenti.
## Risorse
**Documenti correlati:**
+ [Amazon EC2: garantire l'idempotenza](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [The Amazon Builders' Library: Difficoltà dei sistemi distribuiti](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [The Amazon Builders' Library: Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Video correlati:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (Introduzione alle architetture guidate dagli eventi e ad Amazon EventBridge) (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small (Chiudere i cicli e aprire le menti: come prendere il controllo dei sistemi, grandi e piccoli), include lavoro costante (ARC337)](https://youtu.be/O8xLxNje30M?t=2482)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small (Chiudere i cicli e aprire le menti: come prendere il controllo dei sistemi, grandi e piccoli), sono inclusi accoppiamento debole, lavoro costante e stabilità statica (ARC337)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: passare alle architetture basate sugli eventi (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP04 Rendere tutte le risposte idempotenti
Un servizio idempotente promette il completamento di ogni richiesta esattamente una volta, in modo tale che effettuare più richieste identiche abbia lo stesso effetto di effettuare una singola richiesta. Un servizio idempotente semplifica ad un client l'implementazione di nuovi tentativi senza temere che una richiesta venga elaborata erroneamente più volte. Per eseguire questa operazione, i client possono inviare richieste API con un token di idempotenza: viene utilizzato lo stesso token ogni volta che si ripete la richiesta. Un'API del servizio idempotente utilizza il token per restituire una risposta identica a quella restituita la prima volta che la richiesta è stata completata.
In un sistema distribuito, è facile eseguire un'operazione al massimo una volta (il client effettua una sola richiesta) o almeno una volta (la richiesta continua finché il client non ottiene la conferma dell'esito positivo). Tuttavia, è difficile garantire che un'operazione sia idempotente, il che significa che viene eseguita *esattamente* una volta, in modo tale che effettuare più richieste identiche abbia lo stesso effetto di effettuare una singola richiesta. Utilizzando i token di idempotenza nelle API, i servizi possono ricevere una richiesta di mutazione una o più volte senza creare record duplicati o effetti collaterali.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Rendi tutte le risposte idempotenti. Un servizio idempotente promette il completamento di ogni richiesta esattamente una volta, in modo tale che effettuare più richieste identiche abbia lo stesso effetto di effettuare una singola richiesta.
+ I client possono inviare richieste API con un token di idempotenza: viene utilizzato lo stesso token ogni volta che si ripete la richiesta. Un'API del servizio idempotente utilizza il token per restituire una risposta identica a quella restituita la prima volta che la richiesta è stata completata.
+ [Amazon EC2: Ensuring Idempotency (EC2: garantire l'idempotenza)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
## Risorse
**Documenti correlati:**
+ [Amazon EC2: Ensuring Idempotency (EC2: garantire l'idempotenza)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [The Amazon Builders' Library: Difficoltà dei sistemi distribuiti](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [The Amazon Builders' Library: Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Video correlati:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (AWS New York Summit 2019: Introduzione alle architetture guidate dagli eventi e ad Amazon EventBridge) (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small (Chiudere i cicli e aprire le menti: come prendere il controllo dei sistemi, grandi e piccoli) (sono inclusi accoppiamento debole, lavoro costante e stabilità statica) (ARC337)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (Passare alle architetture basate sugli eventi) (SVS308)](https://youtu.be/h46IquqjF3E)
# 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