Como minimizo o tempo de inatividade quando meu ElastiCache para Redis está sendo escalado?

Resolução

Para minimizar o tempo de inatividade, considere o seguinte:

• Para minimizar o impacto da sincronização, evite escalar sob workloads elevadas. Se o cluster estiver sob workload elevada e a escalabilidade estiver demorando muito, reduza as solicitações recebidas para o Redis para evitar falhas de sincronização. Durante o processo de escalabilidade, a sincronização (gravação em segundo plano, bifurcada ou sem bifurcação) pode ser acionada. A sincronização é uma operação com alto consumo de computação e consome memória extra. Verifique a métrica SaveInProgress no Amazon CloudWatch para ver quando a sincronização aconteceu. Lembre-se de que essa métrica coleta dados a cada minuto. Por causa disso, a métrica pode não capturar a sincronização que terminou há menos de um minuto. Para obter mais informações sobre workload de monitoramento, consulte Práticas recomendadas de monitoramento com o Amazon ElastiCache para Redis usando o Amazon CloudWatch.
• Dependendo do tipo de escalabilidade, pode haver uma nova união de nó, um nó pode ser removido de um cluster ou o IP de um nó pode mudar durante a escalabilidade. O Amazon ElastiCache para Redis fornece diferentes tipos de endpoints de conexão para conexão com o cluster. A escolha do tipo de endpoint de conexão depende dos requisitos da aplicação. É uma prática recomendada testar a escalabilidade em um ambiente não destinado à produção para identificar problemas inesperados causados pela configuração incorreta do lado do cliente ao conectar o cluster do Redis.
• Se o cliente se conectar a uma nova réplica que está no andamento da sincronização, o erro LOADING: Redis is loading the dataset in memory (CARREGANDO: o Redis está carregando o conjunto de dados na memória) será exibido. Configure o cliente do Redis ou o código da aplicação para tentar a consulta novamente em outra réplica ou envie uma consulta para o nó primário. O tempo necessário para carregar o conjunto de dados depende do tamanho dos dados e da performance do nó. Teste em seu ambiente de teste para determinar se isso será um problema.
• Você pode configurar o cluster para escalar automaticamente, em vez de escalar manualmente. A escalabilidade automática evita problemas de performance causados por aumentos repentinos na workload recebida. Para obter mais informações, consulte Clusters do ElastiCache para Redis com Auto Scaling.

Visão geral sobre o tempo de inatividade da ação de escalabilidade

Há quatro ações de escalabilidade:

• Reduzir a escala horizontalmente.
• Aumentar a escala horizontalmente.
• Alterar os tipos de nós.
• Alterar o número de grupos de nós. Isso só é compatível com clusters do Redis (modo de cluster desabilitado).

Para obter mais informações, consulte Escalabilidade de clusters do ElastiCache para Redis.

Normalmente, o tempo de inatividade de escalabilidade pode levar alguns segundos no máximo, dependendo da ação de escalabilidade e da configuração do cluster. Veja a seguir explicações sobre o tempo de inatividade para cada tipo de cluster e ação de escalabilidade:

Clusters do Redis (modo de cluster desativado)

Reduzir a escala horizontalmente: remove um nó de réplica dos clusters. Você pode fazer isso para reduzir custos. Lembre-se de que reduzir a escala horizontalmente também diminui a durabilidade dos dados. Se as suas aplicações usarem apenas um endpoint primário para se conectar ao cluster, a remoção dos nós de réplica não causará nenhum tempo de inatividade. Isso ocorre porque o endpoint primário aponta para o nó primário.

No entanto, se suas aplicações usarem endpoints de leitor ou endpoints individuais para se conectar a esse nó de réplica, a conexão original com o nó de réplica removido será interrompida e a aplicação deverá estabelecer uma nova conexão TCP com outros nós de réplica. A aplicação também precisa executar a pesquisa de DNS novamente para evitar a conexão com o nó de réplica removido. A propagação de DNS dos endpoints do leitor pode causar alguns segundos de tempo de inatividade se o cliente estiver usando endpoints de leitor.

Aumentar a escala horizontalmente: adiciona um nó de réplica a um cluster existente. O nó primário é sincronizado com os novos nós. Para evitar o tempo de inatividade durante a sincronização, avalie a possibilidade de aumentar a escala horizontalmente durante as horas em que a workload é mínima.

Alterar tipos de nós: essa ação faz com que novos nós do tipo especificado sejam criados. O nó primário antigo é sincronizado com o novo nó primário, que sincroniza com os novos nós de réplica. Durante esse processo de escalabilidade, certifique-se de que:

• A workload não seja tão elevada a ponto de causar falha na sincronização.
• O IP dos novos nós pode não ser o mesmo dos nós antigos. Talvez sua aplicação precise realizar a pesquisa de DNS no endpoint primário ou no endpoint do leitor novamente e estabelecer novas conexões com o novo nó. Demora alguns segundos para a propagação do DNS, portanto, pode haver alguma interrupção no seu serviço antes que o cliente alcance o novo nó.
  Nas versões 5.0.5 ou superiores do Redis, a interrupção é minimizada. O cliente do Redis tenta novamente a solicitação para um novo nó se a solicitação falhar devido ao encerramento do nó antigo. É uma prática recomendada atualizar para a nova versão do Redis para se beneficiar das otimizações no serviço ElastiCache.

Clusters do Redis (modo de cluster ativado)

Reduzir a escala horizontalmente: significa remover um fragmento de um cluster. Antes que o fragmento seja removido, os dados nesse fragmento serão migrados para outros nós. Esse processo é chamado de “refragmentação”. A refragmentação causa uma workload extra no cluster, e o cliente deve oferecer suporte ao cluster do Redis. Para obter informações sobre como minimizar o tempo de inatividade durante a redução da escala na horizontal, consulte Práticas recomendadas: redimensionamento de clusters on-line.

Para minimizar o problema de performance devido redução excessiva da escala horizontalmente, considere escalar gradualmente. Por exemplo, se o objetivo for reduzir a escala horizontalmente de 12 para 6 fragmentos, faça primeiro de 12 para 9 fragmentos. Após reduzir a escala horizontalmente pela primeira vez, verifique a performance do cluster durante o horário de pico e, em seguida, faça uma redução adicional.

Aumentar a escala horizontalmente: adiciona um fragmento a um cluster. Os dados em outros fragmentos são migrados para o novo fragmento. Esse processo é chamado de “refragmentação”. A refragmentação causa uma workload extra no cluster, e o cliente deve oferecer suporte ao cluster do Redis. Para obter informações sobre como minimizar o tempo de inatividade durante o aumento da escala na horizontal, consulte Práticas recomendadas: redimensionamento de clusters on-line.

Alterar tipos de nós: durante essa ação, para cada fragmento, o nó primário antigo é sincronizado com o novo nó primário. Em seguida, os novos nós primários são sincronizados com os novos nós de réplica. Durante esse processo de escalabilidade, certifique-se de que:

• A workload não seja tão elevada a ponto de causar falha na sincronização.
• O IP dos novos nós pode não ser o mesmo dos nós antigos. Para determinar o endereço IP, sua aplicação pode usar o comando cluster nodes ou cluster slots para obter informações atualizadas sobre a topologia do cluster. A maioria dos clientes Redis que oferecem suporte a clusters do Redis pode atualizar a topologia do cluster. No entanto, talvez seja necessário configurar o cliente Redis para fazer isso. Para obter informações sobre como configurar seu cliente Redis, consulte a documentação do seu tipo de cliente específico.

Alterar o número de grupos de nós: essa ação altera o número de nós de réplica em cada fragmento. Quando o número de nós de réplica aumenta, novos nós de réplica ingressam no cluster e o nó primário é sincronizado com o novo nó. Portanto, verifique a performance dos nós primários antes de adicionar nós de réplica adicionais. Quando o número de nós de réplica diminui e se o cliente precisa ler de um nó de réplica removido, ele deve enviar a solicitação para um dos novos nós de réplica. O cliente também deve atualizar a topologia do cluster para evitar que outras solicitações sejam enviadas para o nó removido.

---

Informações relacionadas

Replicação: Redis (modo de cluster desativado) versus Redis (modo de cluster ativado)

Etapa 4: conectar-se ao nó do cluster - Encontre os endpoints do nó

Escalabilidade de clusters do ElastiCache para Redis

Garantir que você tenha memória suficiente para criar um snapshot do Redis