View a markdown version of this page

REL11-BP02 Failover para recursos íntegros - AWS Well-Architected Framework
Orientação para implementação Recursos

REL11-BP02 Failover para recursos íntegros

Se ocorrer uma falha no recurso, os recursos íntegros deverão continuar atendendo às solicitações. Para falhas de localização (como zona de disponibilidade ou Região da AWS), garanta que você tenha sistemas implementados para realizar failover para recursos íntegros em locais sem problemas.

Ao projetar um serviço, distribua a carga entre recursos, zonas de disponibilidade ou regiões. Portanto, a falha ou a deficiência de um recurso individual podem ser atenuadas transferindo o tráfego para os recursos íntegros restantes. Pense em como os serviços são descobertos e encaminhados em caso de falha.

Projete seus serviços pensando na recuperação de falhas. Na AWS, projetamos os serviços para minimizar o tempo para recuperação de falhas e o impacto sobre os dados. Nossos serviços usam principalmente datastores que reconhecem solicitações apenas após serem armazenadas de modo durável entre várias réplicas em uma região. Eles são criados para usar isolamento com base em células e usar o isolamento de falhas fornecido por zonas de disponibilidade. Usamos automação amplamente em nossos procedimentos operacionais. Também otimizamos nossa funcionalidade de substituir e reiniciar para a recuperação rápida de interrupções.

Os padrões e os designs que permitem o failover variam para cada serviço de plataforma da AWS. Muitos serviços gerenciados nativos da AWS são nativamente várias zonas de disponibilidade (como o Lambda ou o API Gateway). Outros serviços da AWS (como EC2 e EKS) exigem designs específicos de práticas recomendadas para oferecer compatibilidade com o failover de recursos ou armazenamento de dados entre AZs.

O monitoramento deve ser configurado para conferir se o recurso de failover está íntegro, acompanhar o andamento do failover dos recursos e monitorar a recuperação do processo empresarial.

Resultado desejado: Os sistemas são capazes de usar novos recursos de forma automática ou manual para se recuperarem da degradação.

Antipadrões comuns:

  • Planejar o fracasso não faz parte da fase de planejamento e design.

  • O RTO e o RPO não são estabelecidos.

  • Monitoramento insuficiente para detectar falhas nos recursos.

  • Isolamento adequado dos domínios de falha.

  • O failover multirregional não é considerado.

  • A detecção de falhas é sensível ou agressiva demais ao decidir realizar o failover.

  • Não testar nem validar o design de failover.

  • Executar a automação de autorreparação sem notificar que a reparação era necessária.

  • Falta de um período de amortecimento a fim de evitar falhas muito precoces.

Benefícios de estabelecer esta prática recomendada: Você pode criar sistemas mais resilientes que mantenham a confiabilidade em caso de falhas, degradando-se normalmente e se recuperando com rapidez.

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

Orientação para implementação

Os serviços da AWS, como o Elastic Load Balancing e o Amazon EC2 Auto Scaling, ajudam a distribuir a carga entre recursos e zonas de disponibilidade. Portanto, a falha de um recurso individual (como uma instância do EC2) ou o comprometimento de uma zona de disponibilidade podem ser atenuados desviando o tráfego para os recursos íntegros restantes.

Para workloads multirregionais, os projetos são mais complicados. Por exemplo, réplicas de leitura entre regiões permitem que você implante os dados em várias Regiões da AWS. No entanto, o failover ainda é necessário para promover a réplica de leitura como primária e direcionar seu tráfego para o novo endpoint. O Amazon Route 53, o Route 53, o ARC, o CloudFront e o AWS Global Accelerator podem ajudar a direcionar o tráfego entre Regiões da AWS.

Serviços da AWS, como Amazon S3, Lambda, API Gateway, Amazon SQS, Amazon SNS, Amazon SES, Amazon Pinpoint, Amazon ECR, AWS Certificate Manager, EventBridge ou Amazon DynamoDB, são implantados automaticamente em várias zonas de disponibilidade pela AWS. Em caso de falha, esses serviços da AWS direcionam automaticamente o tráfego para locais íntegros. Os dados são armazenados de forma redundante em várias zonas de disponibilidade e permanecem disponíveis.

Para o Amazon RDS, o Amazon Aurora, o Amazon Redshift, o Amazon EKS ou o Amazon ECS, Multi-AZ é uma opção de configuração. A AWS poderá direcionar o tráfego para a instância íntegra se o failover for iniciado. Essa ação de failover pode ser realizada pela AWS ou conforme exigido pelo cliente.

Para instâncias do Amazon EC2, o Amazon Redshift, tarefas do Amazon ECS ou pods do Amazon EKS, você escolhe em quais zonas de disponibilidade implantar. Para alguns designs, o Elastic Load Balancing fornece a solução para detectar instâncias em zonas não íntegras e direcionar o tráfego para as zonas íntegras. O Elastic Load Balancing também pode rotear o tráfego para componentes em seu datacenter on-premises.

Para o failover de tráfego em várias regiões, o redirecionamento pode utilizar o Amazon Route 53, o ARC, o AWS Global Accelerator, o Route 53 Private DNS for VPCs ou o CloudFront para oferecer uma maneira de definir domínios da Internet e atribuir políticas de roteamento, incluindo verificações de integridade, para rotear o tráfego para regiões íntegras. O AWS Global Accelerator fornece endereços IP estáticos que atuam como um ponto de entrada fixo para sua aplicação e, depois, são roteados para os endpoints nas Regiões da AWS de sua escolha, usando a rede global da AWS em vez da Internet com o objetivo de melhorar o desempenho e a confiabilidade.

Etapas da implementação

  • Crie designs de failover para todas as aplicações e serviços apropriados. Isole cada componente da arquitetura e crie designs de failover que atendam ao RTO e ao RPO de cada componente.

  • Configure ambientes inferiores (como desenvolvimento ou teste) com todos os serviços necessários para ter um plano de failover. Implemente as soluções usando a infraestrutura como código (IaC) para garantir a repetibilidade.

  • Configure um local de recuperação, como uma segunda região, para implementar e testar os designs de failover. Se necessário, os recursos para testes podem ser configurados temporariamente para limitar os custos adicionais.

  • Determine quais planos de failover são automatizados pela AWS, quais podem ser automatizados por um processo de DevOps e quais podem ser manuais. Documente e avalie o RTO e o RPO de cada serviço.

  • Crie um manual de failover e inclua todas as etapas para realizar o failover de cada recurso, aplicação e serviço.

  • Crie um manual de failback e inclua todas as etapas de failback (com tempo) de cada recurso, aplicação e serviço.

  • Crie um plano para iniciar e ensaiar o manual. Use simulações e testes de caos para testar a automação e as etapas do manual.

  • Para danos na localização (como zona de disponibilidade ou Região da AWS), garanta que você tenha sistemas implementados para realizar failover para recursos íntegros em locais sem problemas. Confira a cota, os níveis de ajuste de escala automático e os recursos em execução antes do teste de failover.

Recursos

Práticas recomendadas relacionadas ao Well-Architected:

Documentos relacionados:

Exemplos relacionados: