REL 4: Come si progettano 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 impediscono gli errori e migliorano il tempo medio tra errori (MTBF).

Risorse

AWS re:Invent 2019: Moving to event-driven architectures (SVS308)
AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes loose coupling, constant work, static stability)
AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)
What Is Amazon EventBridge?
What Is Amazon Simple Queue Service?
Amazon EC2: Ensuring Idempotency
The Amazon Builders' Library: Challenges with distributed systems

Best practice:

• 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.

• 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à.

• 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.

• Esecuzione di un lavoro costante: I sistemi possono fallire quando si verificano modifiche rapide e di grandi dimensioni nel carico. Ad esempio, un sistema di controllo dello stato che monitora lo stato 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.

Piano di miglioramento

Identificazione del tipo di sistema distribuito necessario

Identificazione del 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: 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.

Implementazione di dipendenze "loosely coupled"

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 (SVS308)
What Is Amazon EventBridge?
What Is Amazon Simple Queue Service?

• 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 (MAD205)
• 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 (API304)

Rendere tutte le risposte idempotenti

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.

• 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

Esecuzione di un lavoro costante

Esecuzione di un lavoro costante: I sistemi possono fallire quando si verificano modifiche rapide e di grandi dimensioni nel carico
AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes constant work)

• Progettare carichi di lavoro in modo che le dimensioni del payload rimangano costanti indipendentemente dal numero di successi o errori.
  • 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 ai client. Il sistema di controllo dello stato dovrebbe invece 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. Ecco in che modo il piano di controllo è progettato per i controlli dello stato di Amazon Route 53.