# REL10-BP04 Usar arquiteturas de anteparo para limitar o escopo de impacto
Assim como os anteparos de um navio, esse padrão garante que uma falha seja contida em um pequeno subconjunto de solicitações ou clientes para que o número de solicitações prejudicadas seja limitado e a maioria possa continuar sem erros. Geralmente, os anteparos de dados são chamados de partições, enquanto os anteparos de serviços são conhecidos como células.
Em uma *arquitetura baseada em células*, cada célula é uma instância completa e independente do serviço e tem um tamanho máximo fixo. À medida que a carga aumenta, as cargas de trabalho também aumenta por meio da adição de células. Uma chave de partição é usada no tráfego de entrada para determinar qual célula processará a solicitação. Qualquer falha é contida na única célula em que ela ocorre. Assim, o número de solicitações prejudicadas é limitado, e as outras células continuam sem erros. É importante identificar a chave de partição adequada para minimizar as interações entre células e evitar a necessidade de envolver serviços de mapeamento complexos em cada solicitação. Os serviços que exigem mapeamento complexo acabam apenas transferindo o problema para os serviços de mapeamento, enquanto os serviços que exigem interações entre células criam dependências entre células (e, assim, reduzem as melhorias de disponibilidade esperadas desse processo).
![\[Diagrama mostrando arquitetura baseada em células\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/cell-based-architecture.png)
Em sua publicação no blog da AWS, Colm MacCarthaigh explica como o Amazon Route 53 usa o conceito de [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/) para isolar as solicitações do cliente em fragmentos. Neste caso, um fragmento consiste em duas ou mais células. Com base na chave de partição, o tráfego de um cliente (ou recursos, ou o que você deseja isolar) é roteado para o fragmento atribuído. No caso de oito células com duas células por fragmento e clientes divididos entre os quatro fragmentos, 25% dos clientes terão impacto no caso de um problema.
![\[Diagrama mostrando serviço dividido em fragmentos tradicionais\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/service-divided-into-traditional-shards.png)
Com a fragmentação aleatória, você cria fragmentos virtuais de duas células cada e atribui seus clientes a um desses fragmentos virtuais. Quando ocorre um problema, você ainda pode perder um quarto de todo o serviço, mas a maneira como clientes ou recursos são atribuídos significa que o escopo do impacto com fragmentação aleatória é consideravelmente menor que 25%. Com oito células, há 28 combinações exclusivas de duas células, o que significa que há 28 possíveis fragmentos embaralhados (fragmentos virtuais). Se você tiver centenas ou milhares de clientes e atribuir cada cliente a um fragmento embaralhado, o escopo do impacto devido a um problema será apenas 1/28. Isso é sete vezes melhor do que a fragmentação normal.
![\[Diagrama mostrando serviço dividido em fragmentos aleatórios.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/service-divided-into-shuffle-shards.png)
Um fragmento pode ser usado para servidores, filas ou outros recursos, além de células.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Use arquiteturas de anteparo. Assim como os anteparos de um navio, esse padrão garante que uma falha seja contida em um pequeno subconjunto de solicitações ou usuários de modo que o número de solicitações prejudicadas seja limitado, e a maioria possa continuar sem erros. Geralmente, os anteparos de dados são chamados de partições, enquanto os anteparos de serviços são conhecidos como células.
+ [Laboratório do Well-Architected: isolamento de falhas com fragmentação aleatória](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
+ [Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
+ [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)](https://youtu.be/swQbA4zub20)
+ Avalie a arquitetura baseada em células da workload. Em uma arquitetura baseada em células, cada célula é uma instância completa e independente do serviço e tem um tamanho máximo fixo. À medida que a carga aumenta, as cargas de trabalho também aumenta por meio da adição de células. Uma chave de partição é usada no tráfego de entrada para determinar qual célula processará a solicitação. Qualquer falha é contida na única célula em que ela ocorre. Assim, o número de solicitações prejudicadas é limitado, e as outras células continuam sem erros. É importante identificar a chave de partição adequada para minimizar as interações entre células e evitar a necessidade de envolver serviços de mapeamento complexos em cada solicitação. Os serviços que exigem mapeamento complexo acabam apenas transferindo o problema para os serviços de mapeamento, enquanto os serviços que exigem interações entre células reduzem a autonomia das células (e, assim, as melhorias de disponibilidade esperadas desse processo).
+ Em sua publicação no blog da AWS, Colm MacCarthaigh explica como o Amazon Route 53 usa o conceito de fragmentação aleatória para isolar as solicitações do cliente em fragmentos.
+ [Fragmentação aleatória: isolamento de falhas massivo e mágico](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
## Recursos
**Documentos relacionados:**
+ [Fragmentação aleatória: isolamento de falhas massivo e mágico](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
+ [A Amazon Builders’ Library: isolamento de workload usando a fragmentação aleatória](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
**Vídeos relacionados:**
+ [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)](https://youtu.be/swQbA4zub20)
+ [Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
**Exemplos relacionados:**
+ [Laboratório do Well-Architected: isolamento de falhas com fragmentação aleatória](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)