REL10-BP04 Utilizzo di architetture a scomparti per limitare la portata dell'impatto - Principio di base dell'affidabilità
Guida all'implementazioneRisorse

REL10-BP04 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 usa più istanze isolate di un carico di lavoro, in cui ogni istanza è 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: con un'architettura basata su celle, molti tipi comuni di errore sono limitati alla cella stessa, per un ulteriore isolamento degli errori. Queste limitazioni possono fornire resilienza a determinati tipi di errore altrimenti difficili da contenere, tra cui implementazioni del codice non riuscite o richieste compromesse o che attivano una modalità di errore specifica, note anche come richieste poison pill.

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: la scelta della chiave di partizione impone alcune considerazioni speciali.

    • 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. Alcuni esempi: ID cliente oppure ID risorsa.

    • 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 un'unica 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: è un componente condiviso tra celle e di conseguenza non può seguire la stessa strategia di compartimentazione applicata alle 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 spiegato da Colm MacCárthaigh in Reliability, constant work, and a good cup of coffee, progettazioni semplici e modelli di lavoro costanti producono sistemi affidabili e riducono l'antifragilità.

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

    • La dimensione massima deve essere 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 Esecuzione di un test di carico sul 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 e multi-regione: è consigliabile utilizzare più livelli di resilienza a tipi di errore diversi.

    • 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 informazioni, consulta REL10-BP02 Selezione delle posizioni appropriate per la tua implementazione multiposizione.

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

Livello di rischio associato alla mancata adozione di questa best practice: elevato

Risorse

Best practice correlate:

Documenti correlati:

Video correlati:

Esempi correlati: