Melhores práticas para mudanças zonais em 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 único recurso de balanceador de carga, por exemplo, a capacidade de uma zona de disponibilidade é temporariamente removida de trás do balanceador de carga. Dependendo das mudanças de zona que você inicia e de como seus balanceadores de carga estão configurados, você deve se certificar de ter planejado cuidadosamente o gerenciamento do aumento de carga nas demais zonas de disponibilidade.

Quando o Amazon Application Recovery Controller (ARC) afasta o tráfego de uma deficiência, por exemplo, usando a mudança zonal ou a mudança automática zonal, o mecanismo ARC usado para mover o tráfego do seu aplicativo é uma atualização. DNS Uma DNS atualização faz com que todas as novas conexões sejam direcionadas para fora do local danificado.

No entanto, clientes com conexões abertas preexistentes podem continuar fazendo solicitações no local danificado 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.

Se você usar um Application Load Balancer, poderá usar a keepalive opção para configurar por quanto tempo as conexões continuarão. Para obter mais informações, consulte a duração HTTP do keepalive do cliente no Guia do usuário do Application Load Balancer.

Por padrão, os Application Load Balancers definem o valor da duração HTTP do keepalive do cliente como 3.600 segundos ou 1 hora. Sugerimos que você reduza o valor para estar alinhado com a meta de tempo de recuperação do aplicativo, por exemplo, 300 segundos. Ao escolher o tempo de duração HTTP do keepalive de um cliente, considere que esse valor é uma troca entre se reconectar com mais frequência em geral, o que pode afetar a latência, e afastar mais rapidamente todos os clientes de uma AZ ou região com problemas.

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 destinos nos balanceadores de carga de seus aplicativos 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 Elastic Load Balancing para alvos não íntegros bytesProcessed e 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. Ela também reduz o risco de seu aplicativo e seu monitoramento serem afetados pelo mesmo desastre ao mesmo tempo ("destino compartilhado").

Para iniciar uma mudança de zona quando você precisa recuperar um aplicativo rapidamente, com poucas dependências, recomendamos usar as ações de mudança de zona AWS Command Line Interface ou API com credenciais pré-armazenadas, se possível. Você também pode iniciar mudanças zonais no AWS Management Console, 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 obter mais informações, consulte o Guia de API referência de mudança zonal.

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.