Práticas recomendadas para o Memorystore for Redis Cluster

Esta página fornece orientações sobre a utilização ideal do Memorystore for Redis Cluster. Esta página também indica potenciais problemas a evitar.

Nota: para ver exemplos de configuração de cliente do cluster Redis, consulte os exemplos de código da biblioteca cliente.

Práticas recomendadas de gestão de memória

Esta secção descreve estratégias para gerir a memória da instância, para que o Memorystore for Redis Cluster funcione de forma eficiente para a sua aplicação.

Conceitos de gestão de memória

• Carga de escrita: o volume e a velocidade a que adiciona ou atualiza chaves no seu cluster Redis. A sua carga de gravação pode variar de normal a muito elevada, consoante o seu exemplo de utilização do Redis e os padrões de utilização da aplicação.

• Política de despejo: o Memorystore for Redis Cluster usa a volatile-lru política de despejo. Pode usar comandos como o comando EXPIRE para definir despejos para chaves.

Monitorize um cluster que tenha uma carga de escrita normal

Veja a métrica /cluster/memory/maximum_utilization. Se /cluster/memory/maximum_utilization estiver a 100% ou menos, o cluster do Redis tem um bom desempenho quando usa uma carga de gravação normal.

No entanto, se a utilização de memória se aproximar dos 100% e esperar que a utilização de dados aumente, deve aumentar a dimensão do cluster para criar espaço para novos dados.

Monitorize um cluster com uma carga de escrita elevada

Veja a métrica /cluster/memory/maximum_utilization. Consoante a gravidade da sua carga de gravação elevada, o cluster pode ter problemas de desempenho nos seguintes limites:

• As cargas de escrita muito elevadas podem ter problemas se o /cluster/memory/maximum_utilization atingir 65% ou mais.

• As cargas de escrita moderadamente elevadas podem ter problemas se o valor de /cluster/memory/maximum_utilization atingir 85% ou mais.

Nestes cenários, deve aumentar o tamanho do cluster para melhorar o desempenho.

Se tiver problemas ou estiver preocupado com o facto de a sua instância ter uma carga de gravação elevada, contacte o Google Cloud apoio técnico.

Dimensionar fragmentos

Quando dimensiona o número de fragmentos numa instância, deve fazê-lo durante períodos de poucas gravações. O escalamento durante períodos de carga de escrita elevada pode exercer pressão sobre a memória da instância devido à sobrecarga de memória causada pela replicação ou pela migração de slots.

Se o seu exemplo de utilização do Redis usar despejos de chaves, o dimensionamento para um tamanho de cluster mais pequeno pode reduzir a taxa de acertos da cache. No entanto, nesta circunstância, não tem de se preocupar com a perda de dados, uma vez que a remoção de chaves é esperada.

Para exemplos de utilização do Redis em que não quer perder chaves, só deve reduzir a escala para um cluster mais pequeno que ainda tenha espaço suficiente para os seus dados. A nova quantidade de fragmentos de destino deve permitir, pelo menos, 1,5 vezes a memória usada pelos dados. Por outras palavras, deve aprovisionar fragmentos suficientes para 1,5 vezes a quantidade de dados atualmente no seu cluster. Pode usar a métrica /cluster/memory/total_used_memory para ver a quantidade de dados armazenados na sua instância.

Práticas recomendadas de utilização da CPU

Se ocorrer uma indisponibilidade zonal inesperada, isto leva a uma redução dos recursos de CPU para o seu cluster devido à capacidade perdida dos nós na zona indisponível. Recomendamos a utilização de clusters altamente disponíveis. A utilização de duas réplicas por fragmento (em vez de uma réplica por fragmento) fornece recursos adicionais da CPU durante uma indisponibilidade. Além disso, recomendamos que faça a gestão da utilização da CPU dos nós para que estes tenham capacidade de processamento da CPU suficiente para processar tráfego adicional da capacidade perdida se ocorrer uma indisponibilidade zonal inesperada. Deve monitorizar a utilização da CPU para as instâncias principais e as réplicas através da métrica /cluster/cpu/maximum_utilization.

Consoante o número de réplicas que aprovisiona por nó, recomendamos os seguintes /cluster/cpu/maximum_utilizationobjetivos de utilização da CPU:

• Para instâncias com uma réplica por nó, segmentar um valor de 0,5 segundos para a principal e 0,5 segundos para a réplica, quando a réplica é designada como uma réplica de leitura./cluster/cpu/maximum_utilization
• Para instâncias com duas réplicas por nó, segmente um /cluster/cpu/maximum_utilization valor de 0,8 segundos para a principal e 0,5 segundos para cada réplica.

Se os valores da métrica excederem estas recomendações, recomendamos que aumente o número de fragmentos ou réplicas na sua instância.

Comandos Redis que consomem muitos recursos

Recomendamos vivamente que evite usar comandos Redis que sejam intensivos em recursos. A utilização destes comandos pode resultar nos seguintes problemas de desempenho:

• Latência elevada e limites de tempo do cliente
• Pressão de memória causada por comandos que aumentam a utilização de memória
• Perda de dados durante a replicação e a sincronização de nós porque a thread principal do Redis está bloqueada
• Verificações de funcionamento, observabilidade e replicação com recursos insuficientes

A tabela seguinte apresenta exemplos de comandos Redis que consomem muitos recursos e oferece alternativas eficientes em termos de recursos.

Sugestão: além de consumirem muitos recursos, à medida que o tamanho total dos dados aumenta, também aumenta o custo de utilização destes comandos.

Para saber que comandos de execução prolongada usa, use SLOWLOG. Esta ferramenta fornece uma lista de comandos cuja execução demora mais tempo. Como resultado, sabe que comandos causam problemas de latência. Para determinar alternativas eficientes em termos de recursos para estes comandos, consulte a tabela seguinte.

Categoria	Comando com utilização intensiva de recursos	Alternativa eficiente em termos de recursos
Executar para todo o espaço de chaves	KEYS	SCAN
Apresentar para um conjunto de chaves de comprimento variável	LRANGE	Limite o tamanho do intervalo que usa para uma consulta.
	ZRANGE	Limite o tamanho do intervalo que usa para uma consulta.
	HGETALL	HSCAN
	SMEMBERS	SSCAN
Bloqueie a execução de um script	EVAL	Certifique-se de que o script não é executado indefinidamente.
	EVALSHA	Certifique-se de que o script não é executado indefinidamente.
Remova ficheiros e links	DELETE	UNLINK
Publicar e subscrever	PUBLISH	SPUBLISH
	SUBSCRIBE	SSUBSCRIBE

Práticas recomendadas do cliente Redis

A sua aplicação tem de usar um cliente Redis compatível com clusters quando se liga a uma instância do Memorystore for Redis Cluster. Para ver exemplos de clientes com reconhecimento de clusters e configurações de amostra, consulte os exemplos de código da biblioteca de cliente. O seu cliente tem de manter um mapa de espaços com hash para os nós correspondentes no cluster, de modo a enviar pedidos para os nós certos e evitar a sobrecarga de desempenho causada pelos redirecionamentos do cluster.

Mapeamento de clientes

Os clientes têm de obter uma lista completa de espaços e dos nós mapeados nas seguintes situações:

• Quando o cliente é inicializado, tem de preencher o espaço inicial para o mapeamento de nós.

• Quando é recebido um redirecionamento MOVED do servidor, como na situação de uma comutação por falha quando todos os espaços servidos pelo antigo nó principal são assumidos pela réplica ou uma nova divisão quando os espaços estão a ser movidos do principal de origem para o nó principal de destino.

• Quando é recebido um erro CLUSTERDOWN do servidor ou as ligações a um determinado servidor expiram de forma persistente.

• Quando é recebido um erro READONLY do servidor. Isto pode acontecer quando um servidor principal é rebaixado a réplica.

• Além disso, os clientes devem atualizar periodicamente a topologia para manter os clientes preparados para quaisquer alterações e saber mais sobre as alterações que podem não resultar em redirecionamentos/erros do servidor, como quando são adicionados novos nós de réplica. Tenha em atenção que as ligações desatualizadas também devem ser fechadas como parte da atualização da topologia para reduzir a necessidade de processar ligações com falhas durante a execução do comando.

Deteção de clientes

Normalmente, a deteção de clientes é feita através da emissão de um comando CLUSTER SLOT, CLUSTER NODE ou CLUSTER SHARDS para o servidor Redis. Recomendamos que use o comando CLUSTER SHARDS. CLUSTER SHARDS substitui o comando CLUSTER SLOTS (descontinuado), oferecendo uma representação mais eficiente e extensível do cluster.

O tamanho da resposta para os comandos de deteção de clientes do cluster pode variar com base no tamanho e na topologia do cluster. Os clusters maiores com mais nós produzem uma resposta maior. Como tal, é importante garantir que o número de clientes que fazem a deteção da topologia de cluster não aumenta sem limites.

Estas atualizações da topologia são dispendiosas no servidor Redis, mas também são importantes para a disponibilidade da aplicação. Por conseguinte, é importante garantir que cada cliente faz um único pedido de deteção em qualquer momento (e armazena o resultado na memória) e que o número de clientes que fazem os pedidos se mantém limitado para evitar sobrecarregar o servidor.

Por exemplo, quando a aplicação cliente é iniciada ou perde a ligação ao servidor e tem de realizar a deteção de clusters, um erro comum é a aplicação cliente fazer vários pedidos de nova ligação e deteção sem adicionar o recuo exponencial na nova tentativa. Isto pode tornar o servidor Redis não responsivo durante um período prolongado, o que provoca uma utilização da CPU muito elevada.

Evite a sobrecarga de deteção no Redis

Para mitigar o impacto causado por um afluxo súbito de pedidos de ligação e descoberta, recomendamos o seguinte:

• Implemente um conjunto de ligações de cliente com um tamanho finito e pequeno para limitar o número de ligações recebidas simultâneas da aplicação cliente.

• Quando o cliente se desliga do servidor devido ao limite de tempo, tente novamente com recuo exponencial com variação. Isto ajuda a evitar que vários clientes sobrecarreguem o servidor ao mesmo tempo.

• Use o ponto final de deteção do Memorystore for Redis Cluster para realizar a deteção do cluster. O ponto final de descoberta está altamente disponível e tem balanceamento de carga em todos os nós no cluster. Além disso, o ponto final de deteção tenta encaminhar os pedidos de deteção de clusters para nós com a vista de topologia mais atualizada.

Práticas recomendadas de persistência

Esta secção explica as práticas recomendadas para a persistência.

Persistência RDB e adição de réplicas

Para obter os melhores resultados da cópia de segurança da sua instância com instantâneos RDB ou adicionar réplicas à sua instância, use as seguintes práticas recomendadas:

Gestão de memória

Os instantâneos RDB usam um processo de ramificação e um mecanismo de "copy-on-write" para tirar um instantâneo dos dados do nó. Consoante o padrão de gravações nos nós, a memória usada dos nós aumenta à medida que as páginas afetadas pelas gravações são copiadas. A pegada de memória pode ser até o dobro do tamanho dos dados no nó.

Para garantir que os nós têm memória suficiente para concluir a captura instantânea, mantenha ou defina maxmemory como 80% da capacidade do nó, para que 20% seja reservado para custos gerais. Esta sobrecarga de memória, além de monitorizar as capturas instantâneas, ajuda a gerir a sua carga de trabalho para ter capturas instantâneas bem-sucedidas. Além disso, quando adiciona réplicas, reduza o tráfego de escrita o máximo possível. Consulte o artigo Monitorize um cluster com uma carga de escrita elevada para saber mais.

Nota: se adicionar uma réplica a um cluster que use mais de 80% da memória máxima do cluster, a operação falha e recebe uma mensagem de erro.

Para resolver este problema, reduza a utilização de memória do cluster de uma das seguintes formas:

• Diminua a utilização da memória gerada pelo cluster para menos de 80% da memória máxima permitida do nó.
• Aumente a escala do tipo de nó para o cluster de modo a ter mais memória.

Depois de a utilização de memória do cluster estar abaixo do limite de 80%, adicione novamente a réplica.

Instantâneos desatualizados

A recuperação de nós a partir de um instantâneo desatualizado pode causar problemas de desempenho para a sua aplicação, uma vez que tenta conciliar uma quantidade significativa de chaves desatualizadas ou outras alterações à sua base de dados, como uma alteração do esquema. Se tiver preocupações sobre a recuperação a partir de uma imagem instantânea desatualizada, pode desativar a funcionalidade de persistência RDB. Assim que reativar a persistência, é tirado um instantâneo no intervalo de instantâneos agendado seguinte.

Impacto no desempenho dos resumos RDB

Consoante o padrão da carga de trabalho, as cópias instantâneas RDB podem afetar o desempenho da instância e aumentar a latência das suas aplicações. Pode minimizar o impacto no desempenho das capturas instantâneas da RDB agendando a respetiva execução durante períodos de tráfego de instâncias baixo, se não se importar de ter capturas instantâneas menos frequentes.

Por exemplo, se a sua instância tiver pouco tráfego entre as 01:00 e as 04:00, pode definir a hora de início para as 03:00 e o intervalo para 24 horas.

Se o seu sistema tiver uma carga constante e exigir resumos frequentes, deve avaliar cuidadosamente o impacto no desempenho e ponderar as vantagens de usar resumos RDB para a carga de trabalho.

Adicione uma réplica

A adição de uma réplica requer um instantâneo RDB. Para mais informações sobre as cópias instantâneas RDB, consulte o artigo Gestão de memória.

Escolha uma instância de zona única se a sua instância não usar réplicas

Ao configurar uma instância sem réplicas, recomendamos uma arquitetura de zona única para melhorar a fiabilidade. Veja o motivo:

Minimize o impacto das interrupções

As falhas de energia zonais têm menor probabilidade de afetar a sua instância. Ao colocar todos os nós numa única zona, a probabilidade de uma indisponibilidade zonal afetar o seu servidor diminui de 100% para 33%. Isto deve-se ao facto de existir uma probabilidade de 33% de a zona onde a sua instância está localizada ficar indisponível, em oposição a uma probabilidade de 100% de os nós localizados na zona indisponível serem afetados.

Recuperação rápida

Se ocorrer uma indisponibilidade zonal, a recuperação é simplificada. Pode responder aprovisionando rapidamente uma nova instância numa zona em funcionamento e redirecionando a sua aplicação para operações com interrupções mínimas.

Práticas recomendadas do Lettuce

Esta secção descreve as práticas recomendadas para usar o Lettuce para estabelecer ligação a uma instância do Memorystore for Redis Cluster.

Atualize os valores dos parâmetros

Quando usar o Lettuce, altere o parâmetro validateClusterNodeMembership para false. Caso contrário, quando a topologia muda, podem ocorrer unknownPartition erros.