REL10-BP03 Utilizzo di architetture a scomparti per limitare la portata dell'impatto - Pilastro dell'affidabilità

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

REL10-BP03 Utilizzo di architetture a scomparti per limitare la portata dell'impatto

Implementa architetture a scomparti (note anche come architetture basate su celle) per limitare l'effetto di un guasto all'interno di un carico di lavoro a un numero ridotto di componenti.

Risultato desiderato: un'architettura basata su celle utilizza più istanze isolate di un carico di lavoro, ciascuna delle quali è nota come cella. Ogni cella è indipendente, non condivide lo stato con altre celle e gestisce un sottoinsieme delle richieste complessive del carico di lavoro. Questo approccio riduce il possibile impatto di un errore, ad esempio un aggiornamento software non valido, a una singola cella e alle richieste elaborate. Se un carico di lavoro usa 10 celle per gestire 100 richieste e si verifica un errore, il 90% delle richieste complessive non sarà interessato dall'errore.

Anti-pattern comuni:

  • Aumento illimitato delle celle.

  • Applicazione di aggiornamenti o implementazioni del codice in tutte le celle contemporaneamente.

  • Condivisione dello stato dei componenti tra celle (con l'eccezione del livello di instradamento).

  • Aggiunta di logica di business o instradamento complessa al livello di instradamento.

  • Le interazioni tra celle non sono ridotte al minimo.

Vantaggi dell'adozione di questa best practice: limitazione alla cella stessa di molti tipi comuni di errori, a garanzia di un ulteriore isolamento dei guasti, grazie alle architetture basate su celle. Questi limiti relativi agli errori possono garantire resilienza in caso di determinati tipi di errori, altrimenti difficili da contenere, come implementazioni di codice non riuscite o richieste danneggiate o che richiamano una modalità di errore specifica (nota anche come richieste poison pill).

Livello di rischio associato se questa best practice non fosse adottata: elevato

Guida all'implementazione

Su una nave gli scomparti permettono di limitare la falla di uno scafo a una sola sezione dello scafo. In sistemi complessi, questo modello viene spesso replicato per consentire l'isolamento degli errori. Le limitazioni per l'isolamento degli errori riducono l'effetto di un errore all'interno di un carico di lavoro a un numero limitato di componenti. I componenti al di fuori della barriera non subiscono gli effetti del guasto. Utilizzando più barriere per l'isolamento dei guasti, puoi limitare l'impatto sul carico di lavoro. In AWS i clienti possono usare più zone di disponibilità e regioni per fornire l'isolamento degli errori, ma questo concetto può essere esteso anche all'architettura del carico di lavoro.

Il carico di lavoro complessivo viene partizionato in celle tramite una chiave di partizione. Questa chiave deve essere allineata alla granularità del servizio o al modo naturale in cui il carico di lavoro del servizio può essere suddiviso con interazioni minime tra celle. Esempi di chiavi di partizione sono un ID cliente, un ID risorsa o qualsiasi altro parametro facilmente accessibile nella maggior parte delle chiamate API. Un livello di instradamento alle celle distribuisce le richieste a singole celle in base alla chiave di partizione e presenta un unico endpoint ai client.

Diagramma che mostra un'architettura basata su celle

Figura 11: architettura basata su celle

Passaggi dell'implementazione

Nel progettare un'architettura basata su celle, devi tenere conto di diversi aspetti della progettazione:

  1. Chiave di partizione: presta particolare attenzione alla scelta della chiave di partizione.

    • Questa deve essere allineata alla granularità del servizio o al modo naturale in cui il carico di lavoro del servizio può essere suddiviso con interazioni minime tra celle. Alcuni esempi sono customer ID o resource ID.

    • La chiave di partizione deve essere disponibile in tutte le richieste, direttamente o in modo da poter essere facilmente dedotta in modo deterministico da altri parametri.

  2. Mappatura persistente delle celle: i servizi a monte devono interagire solo con una singola cella per l'intero ciclo di vita delle risorse correlate.

    • A seconda del carico di lavoro, può essere necessaria una strategia di migrazione delle celle per la migrazione dei dati da una cella a un'altra. Un possibile scenario in cui è necessaria la migrazione delle celle è quando una risorsa o un utente specifico nel carico di lavoro diventa troppo grande e richiede una cella dedicata.

    • Le celle non devono condividere lo stato o i componenti.

    • Di conseguenza, l'interazione tra celle deve essere evitata o mantenuta al minimo, in quanto le interazioni creano dipendenze tra le celle e riducono quindi i vantaggi forniti dall'isolamento degli errori.

  3. Livello di instradamento: il livello di instradamento è un componente condiviso tra celle, pertanto non può basarsi sulla stessa strategia di compartimentazione delle celle.

    • È consigliabile che il livello di instradamento distribuisca richieste a singole celle usando un algoritmo di mappatura delle partizioni efficiente in termini di risorse di calcolo, ad esempio combinando funzioni hash crittografiche e aritmetica modulare per mappare le chiavi di partizione alle celle.

    • Per evitare l'impatto su più celle, il livello di instradamento deve restare il più semplice e orizzontalmente scalabile possibile, evitando logica di business complessa in questo livello. Questo approccio offre il vantaggio aggiuntivo di semplificare la comprensione del suo comportamento previsto in ogni momento, permettendo test esaustivi. Come illustrato da Colm MacCárthaigh in Reliability, constant work, and a good cup of coffee, progettazioni semplici e schemi di lavoro costanti si traducono in sistemi affidabili e nella riduzione dell'antifragilità.

  4. Dimensione delle celle: le celle devono avere una dimensione massima che non deve essere superata

    • La dimensione massima va identificata attraverso l'esecuzione di test completi, fino a raggiungere i punti di rottura e definire i margini operativi. Per ulteriori informazioni su come implementare procedure di test, consulta REL07-BP04 Load Testa il tuo carico di lavoro.

    • L'aumento del carico di lavoro complessivo deve essere gestito tramite l'aggiunta di celle, in modo da poterlo dimensionare in base al crescere della domanda.

  5. Strategie multi-AZ o multi-regione: si consiglia di utilizzare più livelli di resilienza per proteggersi da diversi domini di errore.

    • Per la resilienza, devi utilizzare un approccio che costruisca livelli di difesa. Un livello protegge dalle interruzioni minime e più comuni attraverso la creazione di un'architettura a disponibilità elevata tramite più zone di disponibilità. Un altro livello di difesa è destinato a proteggere da eventi rari come disastri naturali diffusi e interruzioni a livello regionale. Questo secondo livello implica l'architettura dell'applicazione in modo che si estenda su più Regioni AWS. L'implementazione di una strategia multi-regione per il tuo carico di lavoro aiuta a proteggerlo da disastri naturali diffusi che colpiscono un'ampia regione geografica di un paese o da guasti tecnici di portata regionale. Tieni presente che l'implementazione di un'architettura multi-regione può essere molto complessa e di solito non è necessaria per la maggior parte dei carichi di lavoro. Per ulteriori dettagli, consulta REL10-BP01 Implementazione del carico di lavoro in diversi luoghi.

  6. Implementazione del codice: è preferibile una strategia di implementazione del codice scaglionata rispetto all'implementazione simultanea di modifiche al codice in tutte le celle.

Risorse

Best practice correlate:

Documenti correlati:

Video correlati:

Esempi correlati: