# 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)