Práticas recomendadas para mudanças de zona no ARC

Verifique se você planejou e pré-escalou ou pode escalar automaticamente a capacidade suficiente para acomodar a carga extra imposta às zonas de disponibilidade ao iniciar uma mudança de zona. Com uma arquitetura orientada à recuperação, uma recomendação típica é pré-escalar a capacidade computacional para incluir espaço suficiente para atender ao pico de tráfego quando uma de suas (normalmente) três réplicas estiver off-line.

Quando você inicia uma mudança de zona para um recurso compatível e o tráfego é desviado de uma AZ, a capacidade que sua aplicação estava usando para atender às solicitações é removida. Você deve garantir que tenha planejado uma transferência de tráfego para fora de uma AZ e possa continuar atendendo às solicitações restantes AZs.

Quando o Controlador de Recuperação de Aplicações (ARC) da Amazon desvia o tráfego de uma deficiência, por exemplo, usando a mudança de zona ou a mudança automática de zona, o mecanismo que o ARC usa para mover o tráfego da sua aplicação é uma atualização de DNS. Uma atualização de DNS faz com que todas as novas conexões sejam direcionadas para fora do local comprometido.

No entanto, os clientes com conexões abertas preexistentes podem continuar fazendo solicitações com base no local comprometido até que os clientes se reconectem. Para garantir uma recuperação rápida, recomendamos que você limite a quantidade de tempo que os clientes permanecem conectados aos seus endpoints.

Teste regularmente a remoção do tráfego das zonas de disponibilidade para seu aplicativo iniciando mudanças de zona. Planeje e execute mudanças de zona iniciais, preferencialmente em ambientes de teste e produção, como parte dos testes regulares de failover para recuperar seus aplicativos em caso de desastre. Testes regulares são uma parte essencial para garantir que você esteja pronto e tenha a confiança necessária para mitigar problemas quando ocorrer um evento operacional.

As mudanças de zona funcionam marcando um recurso, ou seja, uma réplica de aplicativo, como não íntegro em uma zona de disponibilidade. Isso significa que é fundamental garantir que os recursos nas aplicações geralmente estejam íntegros e recebam tráfego ativamente nas zonas de disponibilidade de uma região. Recomendamos que você tenha painéis para monitorar isso, incluindo, por exemplo, métricas do ELB para alvos não íntegros e bytes processados por zona de disponibilidade.

Considere monitorar a integridade de seus recursos em uma segunda região adjacente. A vantagem dessa abordagem é que ela pode ser mais representativa da experiência de seus usuários finais, além de reduzir o risco de sua aplicação e seu monitoramento serem afetados pelo mesmo desastre ao mesmo tempo.

Para iniciar uma mudança de zona quando você precisa recuperar um aplicativo rapidamente, com poucas dependências, recomendamos usar a API AWS Command Line Interface ou com ações de mudança de zona, com credenciais pré-armazenadas, se possível. Você também pode iniciar mudanças zonais no Console de gerenciamento da AWS, para facilitar o uso. Mas quando uma recuperação rápida e confiável é essencial, as operações do plano de dados são a melhor escolha. Para mais informações, consulte Guia de referência da API de mudança de zona.

Uma mudança de zona afasta o tráfego de uma zona de disponibilidade temporariamente para mitigar uma deficiência. Você deve restaurar o recurso para manutenção do aplicativo assim que tiver tomado medidas para corrigir um problema. Isso garante que seu aplicativo geral seja restaurado ao estado original, totalmente redundante e resiliente.