# REL10-BP04 Utilizzo di architetture a paratie per limitare la portata dell'impatto
Come per le paratie su una nave, questo modello garantisce il contenimento di un guasto in un piccolo sottoinsieme di richieste o clienti, in modo che il numero di richieste danneggiate sia limitato e si possa comunque continuare senza errori. Le paratie per i dati sono spesso chiamate partizioni, mentre le paratie per i servizi sono note come celle.
In una *architettura basata su celle*, ogni cella è un'istanza completa e indipendente del servizio e ha una dimensione massima fissa. Con l'aumentare del carico, i carichi di lavoro aumentano aggiungendo più celle. Una chiave di partizione viene utilizzata sul traffico in entrata per determinare quale cella elaborerà la richiesta. Qualsiasi guasto è contenuto nella singola cella in cui si verifica, in modo che il numero di richieste danneggiate sia limitato man mano che le altre celle continuano senza errori. È importante identificare la chiave di partizione corretta per ridurre al minimo le interazioni tra celle ed evitare la necessità di coinvolgere servizi di mappatura complessi in ogni richiesta. I servizi che richiedono una mappatura complessa finiscono semplicemente per spostare il problema ai servizi di mappatura, là dove i servizi che richiedono interazioni cross-cell creano dipendenze tra celle (e questo riduce i miglioramenti della disponibilità che ne deriverebbero).
![\[Diagramma che mostra un'architettura basata su celle\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/cell-based-architecture.png)
In un post del suo blog AWS, Colm MacCarthaigh spiega in che modo Amazon Route 53 utilizza il concetto di [https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/) per isolare le richieste dei clienti negli shard. Uno shard in questo caso è costituito da due o più celle. In base alla chiave di partizione, il traffico da un cliente (o risorse o qualsiasi altra cosa desideri isolare) viene instradato allo shard assegnato. Nel caso di otto celle con due celle per shard e clienti divisi tra i quattro shard, il 25% dei clienti riscontrerebbe un impatto in caso di problema.
![\[Diagramma che mostra un servizio suddiviso in partizioni tradizionali\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/service-divided-into-traditional-shards.png)
Con lo sharding casuale, puoi creare shard virtuali di due celle ciascuno e assegnare i clienti a uno di questi shard virtuali. Quando si verifica un problema, puoi comunque perdere un quarto dell'intero servizio, ma il modo in cui vengono assegnati i clienti o le risorse significa che l'ambito dell'impatto con lo sharding casuale è notevolmente inferiore al 25%. Con otto celle, ci sono 28 combinazioni univoche di due celle, il che significa che ci sono 28 possibili shard casuali (shard virtuali). Se disponi di centinaia o migliaia di clienti e assegni ogni cliente a uno shard casuale, l'impatto causato da un problema è di solo 1/28. Questo è sette volte superiore rispetto allo sharding normale.
![\[Diagramma che mostra un servizio suddiviso in partizioni casuali.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/service-divided-into-shuffle-shards.png)
Uno shard può essere utilizzato per server, code o altre risorse in aggiunta alle celle.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Utilizzo di architetture paratie Come per le paratie su una nave, questo modello garantisce il contenimento di un guasto in un piccolo sottoinsieme di richieste/utenti, in modo che il numero di richieste danneggiate sia limitato e si possa comunque continuare senza errori. Le paratie per i dati sono spesso chiamate partizioni, mentre le paratie per i servizi sono note come celle.
+ [Well-Architected lab: Fault isolation with shuffle sharding](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
+ [Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Introduzione alla libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
+ [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (Come AWS riduce al minimo il raggio di esplosione dei guasti) (ARC338)](https://youtu.be/swQbA4zub20)
+ Valutazione dell'architettura basata su celle per il carico di lavoro In un'architettura basata su celle, ogni cella è un'istanza completa e indipendente del servizio e ha una dimensione massima fissa. Con l'aumentare del carico, i carichi di lavoro aumentano aggiungendo più celle. Una chiave di partizione viene utilizzata sul traffico in entrata per determinare quale cella elaborerà la richiesta. Qualsiasi guasto è contenuto nella singola cella in cui si verifica, in modo che il numero di richieste danneggiate sia limitato man mano che le altre celle continuano senza errori. È importante identificare la chiave di partizione corretta per ridurre al minimo le interazioni tra celle ed evitare la necessità di coinvolgere servizi di mappatura complessi in ogni richiesta. I servizi che richiedono una mappatura complessa finiscono semplicemente per spostare il problema ai servizi di mappatura, mentre i servizi che richiedono interazioni tra celle riducono l'autonomia delle celle (e quindi i presunti miglioramenti della disponibilità che ne deriverebbero).
+ Nel suo post del blog AWS, Colm MacCarthaigh spiega in che modo Amazon Route 53 utilizza il concetto di partizione casuale per isolare le richieste dei clienti nelle partizioni
+ [Shuffle Sharding: Massive and Magical Fault Isolation](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
## Risorse
**Documenti correlati:**
+ [Shuffle Sharding: Massive and Magical Fault Isolation](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
+ [The Amazon Builders' Library: Isolamento del carico di lavoro utilizzando lo sharding casuale](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
**Video correlati:**
+ [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (Come AWS riduce al minimo il raggio di esplosione dei guasti) (ARC338)](https://youtu.be/swQbA4zub20)
+ [Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Introduzione alla libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
**Esempi correlati:**
+ [Well-Architected lab: Fault isolation with shuffle sharding](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)