REL 10: Como usar o isolamento de falhas para proteger sua carga de trabalho?

Os limites isolados de falhas restringem o efeito de uma falha em uma carga de trabalho a um número controlado de componentes. A falha não afeta os componentes fora do limite. Ao usar vários limites isolados de falhas, você pode restringir o impacto sobre sua carga de trabalho.

Recursos

AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)
Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)
AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)
AWS re:Invent 2019: Innovation and operation of the AWS global network infrastructure (NET339)
What is AWS Outposts?
Global Tables: Multi-Region Replication with DynamoDB
AWS Local Zones FAQ
AWS Global Infrastructure
The Amazon Builders' Library: Workload isolation using shuffle-sharding

Melhores práticas:

• Implante a carga de trabalho em vários locais: Distribua os dados e os recursos da carga de trabalho por várias zonas de disponibilidade ou, quando necessário, por regiões da AWS. A diversidade dos locais pode variar conforme a necessidade.

• Automatize a recuperação de componentes restritos a um único local: Se os componentes da carga de trabalho só puderem ser executados em uma única zona de disponibilidade ou datacenter no local, você deverá implementar capacidade suficiente para fazer uma recompilação completa da carga de trabalho em conformidade com os objetivos de recuperação definidos.

• 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 ou fragmentos, enquanto os anteparos de serviços são conhecidos como células.

Plano de melhoria

Implante a carga de trabalho em vários locais

Use várias zonas de disponibilidade e regiões da AWS: Distribua os dados e os recursos da carga de trabalho por várias zonas de disponibilidade ou, quando necessário, por regiões da AWS. A diversidade dos locais pode variar conforme a necessidade.

• Os serviços regionais são inerentemente implantados nas zonas de disponibilidade.
  • Isso inclui o Amazon S3, o Amazon DynamoDB e o AWS Lambda (quando não estão conectados a uma VPC)
• Implante suas cargas de trabalho baseadas em contêiner, instância e função em várias zonas de disponibilidade. Use datastores multizona, incluindo caches: Use os recursos do Auto Scaling do EC2, o posicionamento de tarefas do ECS e a configuração de função do AWS Lambda durante a execução em sua VPC e nos clusters do ElastiCache.
  • Use sub-redes que estão em zonas de disponibilidade separadas ao implantar grupos de Auto Scaling.
    Example: Distributing instances across Availability Zones
    Amazon ECS task placement strategies
    Configuring an AWS Lambda function to access resources in an Amazon VPC
    Choosing Regions and Availability Zones
  • Use sub-redes que estão em zonas de disponibilidade separadas ao implantar grupos de Auto Scaling.
    Example: Distributing instances across Availability Zones
  • Use os parâmetros de posicionamento de tarefas do ECS, com a especificação de grupos de sub-rede de banco de dados.
    Amazon ECS task placement strategies
  • Use as sub-redes em várias zonas de disponibilidade ao configurar uma função para executar na sua VPC.
    Configuring an AWS Lambda function to access resources in an Amazon VPC
  • Use várias zonas de disponibilidade com os clusters do ElastiCache.
    Choosing Regions and Availability Zones

Se sua carga de trabalho precisar ser implantada em várias regiões, escolha uma estratégia multirregional: A maioria das necessidades de confiabilidade pode ser atendida em uma única região da AWS por meio de uma estratégia multizona de disponibilidade. Use uma estratégia multirregional quando necessário para atender às suas necessidades de negócio.
AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)

• O backup para outra região da AWS pode servir como mais uma camada para garantir que os dados estejam disponíveis quando necessário.
• Algumas cargas de trabalho têm requisitos normativos que exigem o uso de uma estratégia multirregional

Avalie a carga de trabalho do AWS Outposts: Se a carga de trabalho exigir baixa latência do datacenter no local ou tiver requisitos de processamento de dados locais. Em seguida, use o AWS Outposts para executar a infraestrutura e os serviços da AWS no local
What is AWS Outposts?

Determine se as zonas locais da AWS ajudam você a fornecer serviços aos usuários: Se você tiver requisitos de baixa latência, veja se as zonas locais da AWS estão próximas dos seus usuários. Se estiverem, use-as para implantar as cargas de trabalho mais perto desses usuários
AWS Local Zones FAQ

Automatize a recuperação de componentes restritos a um único local

Implementar a autorreparação: Quando possível, use a escalabilidade automática para implantar instâncias ou contêineres. Quando não for possível, use a recuperação automática de instâncias do EC2 ou implemente a automação de autorreparação com base nos eventos de ciclo de vida do contêiner do Amazon EC2 ou do ECS.

• Use os grupos de Auto Scaling para instâncias e cargas de trabalho de contêiner que não têm requisitos de endereço IP de instância única, endereço IP privado, endereço IP elástico e metadados de instância.
  What Is EC2 Auto Scaling?
  Service automatic scaling
  • É possível usar os dados do usuário da configuração de execução para implementar uma automação capaz de fazer a autorreparação da maioria das cargas de trabalho.
• Use a recuperação automática de instâncias do EC2 para cargas de trabalho que exigem um endereço do ID de instância única, endereço IP privado, endereço IP elástico e metadados de instância.
  Recover your instance.
  • A recuperação automática enviará alertas de status de recuperação para um tópico do SNS quando a falha na instância for detectada.
• Use os eventos de ciclo de vida da instância do EC2 ou os eventos do ECS para automatizar a autorreparação quando a escalabilidade automática ou a recuperação do EC2 não puder ser usada.
  EC2 Auto Scaling lifecycle hooks
  Amazon ECS events
  • Use os eventos para invocar a automação que reparará seu componente de acordo com a lógica do processo necessária.

Use a recuperação automática de instâncias do EC2 para cargas de trabalho que exigem um endereço do ID de instância única, endereço IP privado, endereço IP elástico e metadados de instância.
Recover your instance.

• A recuperação automática enviará alertas de status de recuperação para um tópico do SNS quando a falha na instância for detectada.

Use os eventos de ciclo de vida da instância do EC2 ou os eventos do ECS para automatizar a autorreparação quando a escalabilidade automática ou a recuperação do EC2 não puder ser usada.
EC2 Auto Scaling lifecycle hooks
Amazon ECS events

• Use os eventos para invocar a automação que reparará seu componente de acordo com a lógica do processo necessária.

Use arquiteturas de anteparo

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 ou fragmentos, enquanto os anteparos de serviços são conhecidos como células
Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)
AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)

Avalie a arquitetura baseada em células da carga de trabalho: 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 independência 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 dos clientes em fragmentos
  Shuffle Sharding: Massive and Magical Fault Isolation