REL11-BP03 Automatizar a reparação em todas as camadas - Pilar Confiabilidade
Orientação para implementação Recursos

REL11-BP03 Automatizar a reparação em todas as camadas

Após a detecção de uma falha, use recursos automatizados para executar ações de correção. As degradações podem ser corrigidas automaticamente por meio de mecanismos internos de serviço ou exigir que os recursos sejam reiniciados ou removidos por meio de ações de remediação.

Para aplicações autogerenciadas e reparação entre regiões, os projetos de recuperação e os processos de recuperação automatizados podem ser extraídos de práticas recomendadas existentes.

A capacidade de reiniciar ou remover um recurso é uma ferramenta importante para corrigir falhas. Uma prática recomendada é deixar os serviços sem estado sempre que possível. Isso evita a perda de dados ou a disponibilidade na reinicialização do recurso. Na nuvem, você pode (e geralmente deve) substituir todo o recurso (por exemplo, uma instância de computação ou função sem servidor) como parte da reinicialização. A reinicialização em si é uma maneira simples e confiável de se recuperar de falhas. Muitos tipos diferentes de falhas ocorrem em cargas de trabalho. As falhas podem ocorrer em hardware, software, comunicações e operações.

Reiniciar ou tentar novamente também se aplica às solicitações de rede. Aplique a mesma abordagem de recuperação tanto a um tempo limite de rede quanto a uma falha de dependência em que a dependência retorna um erro. Ambos os eventos têm um efeito similar sobre o sistema, assim, em vez de tentar tornar qualquer um dos eventos um caso especial, aplique uma estratégia similar de nova tentativa limitada com recuo e variação exponenciais. A capacidade de reiniciar é um mecanismo de recuperação presente na computação orientada para a recuperação e arquiteturas de cluster de alta disponibilidade.

Resultado desejado: Ações automatizadas são executadas para corrigir a detecção de uma falha.

Antipadrões comuns:

  • Provisionamento de recursos sem dimensionamento automático.

  • Implantação de aplicações em instâncias ou contêineres individualmente.

  • Implantação de aplicações que não podem ser implantadas em vários locais sem usar a recuperação automática.

  • Reparação manual de aplicações que não são reparadas por meio do ajuste de escala automático e recuperação automática.

  • Sem automação para failover nos bancos de dados.

  • Não há métodos automatizados para redirecionar o tráfego para novos endpoints.

  • Sem replicação de armazenamento.

Benefícios de estabelecer esta prática recomendada: A reparação automatizada pode reduzir seu tempo médio de recuperação e melhorar sua disponibilidade.

Nível de risco exposto se esta prática recomendada não for estabelecida: alto

Orientação para implementação

Os designs para Amazon EKS ou outros serviços do Kubernetes devem incluir conjuntos mínimos e máximos de réplicas ou com estado e tamanho mínimo do cluster e do grupo de nós. Esses mecanismos fornecem uma quantidade mínima de recursos de processamento continuamente disponíveis e, ao mesmo tempo, remediam automaticamente quaisquer falhas usando o ambiente de gerenciamento do Kubernetes.

Os padrões de design que são acessados por meio de um balanceador de carga usando clusters de computação devem utilizar grupos Auto Scaling. O Elastic Load Balancing (ELB) distribui automaticamente o tráfego de entrada da aplicação entre vários destinos e dispositivos virtuais em uma ou mais Zonas de Disponibilidade (AZs).

Designs baseados em computação em cluster que não usam balanceamento de carga devem ter seu tamanho projetado para a perda de pelo menos um nó. Isso permitirá que o serviço se mantenha funcionando em uma capacidade potencialmente reduzida enquanto recupera um novo nó. Entre os exemplos de serviço estão Mongo, DynamoDB Accelerator, Amazon Redshift, Amazon EMR, Cassandra, Kafka, MSK-EC2, Couchbase, ELK e Amazon OpenSearch Service. Muitos desses serviços podem ser projetados com recursos adicionais de recuperação automática. Algumas tecnologias de cluster devem gerar um alerta sobre a perda de um nó, acionando um fluxo de trabalho automático ou manual para recriar um novo nó. Esse fluxo de trabalho pode ser automatizado usando o AWS Systems Manager para corrigir problemas rapidamente.

É possível usar o Amazon EventBridge para monitorar e filtrar eventos, como alarmes do CloudWatch ou alterações no estado de outros serviços da AWS. Com base nas informações do evento, ele pode então invocar AWS Lambda, Systems Manager Automation ou outros destinos para executar uma lógica de remediação personalizada na workload. O Amazon EC2 Auto Scaling pode ser configurado para verificar a integridade da instância EC2. Se a instância estiver em qualquer estado que não seja em execução, ou se o status do sistema for prejudicado, o Amazon EC2 Auto Scaling considerará que essa instância não é íntegra e executará uma instância de substituição. Para substituições em grande escala (como a perda de uma Zona de Disponibilidade inteira), a estabilidade estática é preferida para alta disponibilidade.

Etapas da implementação

  • Use grupos do Auto Scaling para implantar camadas em uma workload. O Auto Scaling pode executar a autorreparação em aplicações sem estado e adicionar e remover capacidade.

  • Para instâncias computacionais mencionadas anteriormente, use balanceamento de carga e escolha o tipo apropriado de balanceador de carga.

  • Considere a recuperação para Amazon RDS. Com instâncias em espera, configure para failover automático para a instância em espera. Para a réplica de leitura do Amazon RDS, é necessário um fluxo de trabalho automatizado para tornar uma réplica de leitura primária.

  • Implemente recuperação automática em instâncias do EC2 que têm aplicações implantadas que não podem estar em vários locais e podem tolerar a reinicialização em caso de falhas. É possível usar a recuperação automática para substituir o hardware com falha e reiniciar a instância quando a aplicação não puder ser implantada em vários locais. Os metadados da instância e os endereços IP associados são mantidos, bem como os volumes do EBS e pontos de montagem no Amazon Elastic File System ou sistemas de arquivos para Lustre e Windows. Com o uso do AWS OpsWorks, é possível configurar a autorreparação das instâncias do EC2 no nível da camada.

  • Implemente a recuperação automatizada usando o AWS Step Functions e o AWS Lambda quando não for possível usar o ajuste de escala automático ou a recuperação automática, ou quando a recuperação automática falhar. Quando não for possível usar o ajuste de escala automático e a recuperação automática ou quando a recuperação automática falhar, você poderá automatizar a reparação usando o AWS Step Functions e o AWS Lambda.

  • O Amazon EventBridge pode ser usado para monitorar e filtrar eventos como alarmes do CloudWatch ou mudanças de estado em outros serviços da AWS. Com base nas informações do evento, ele pode invocar o AWS Lambda (ou outros destinos) para executar a lógica de correção personalizada na workload.

Recursos

Práticas recomendadas relacionadas:

Documentos relacionados:

Vídeos relacionados:

Exemplos relacionados:

Ferramentas relacionadas: