Práticas recomendadas para o Memorystore for Valkey

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

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

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

Conceitos de gestão de memória

• Utilização de memória: a quantidade de memória que a sua instância usa. Tem uma capacidade de memória fixa. Pode usar métricas para monitorizar a quantidade de memória que está a usar.

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

Monitorize a utilização de memória de uma instância

Para monitorizar a utilização de memória de uma instância do Memorystore for Valkey, recomendamos que veja a métrica /instance/memory/maximum_utilization. Se a utilização de memória da instância se aproximar dos 80% e esperar que a utilização de dados aumente, aumente a dimensão da instância para criar espaço para novos dados.

Se a instância tiver uma utilização elevada de memória, faça o seguinte para melhorar o desempenho:

• Aumente o tamanho da instância.
• Diminua o maxmemory parâmetro de configuração.

Se tiver problemas, contacte o Google Cloud apoio ao cliente.

Dimensione os fragmentos no modo de cluster ativado

Quando aumenta o número de fragmentos numa instância, recomendamos que o faça durante períodos de poucas gravações. O dimensionamento durante períodos de utilização elevada pode exercer pressão sobre a memória da sua 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 Valkey usar remoções de chaves, a escalabilidade para um tamanho de instância 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 da chave é esperada.

Para exemplos de utilização do Valkey em que não quer perder chaves, deve reduzir a escala apenas para uma instância mais pequena 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 na sua instância. Pode usar a métrica /instance/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 a sua instância devido à capacidade perdida dos nós na zona indisponível. Recomendamos a utilização de instâncias 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 primários e réplicas através da métrica Segundos de CPU da thread principal/instance/cpu/maximum_utilization.

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

• Para instâncias com 1 réplica por nó, deve segmentar um valor de /instance/cpu/maximum_utilization de 0,5 segundos para a réplica principal e a réplica.
• Para instâncias com 2 réplicas por nó, deve segmentar um valor /instance/cpu/maximum_utilization de 0,9 segundos para a principal e 0,5 segundos para as réplicas.

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 do Valkey com utilização intensiva de recursos

Recomendamos vivamente que evite usar comandos do Valkey que consomem muitos 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 Valkey está bloqueada
• Verificações de funcionamento, observabilidade e replicação com recursos insuficientes

A tabela seguinte apresenta exemplos de comandos Valkey que consomem muitos recursos e oferece alternativas que consomem poucos 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 para o cliente Valkey

Evite a sobrecarga de ligações no Valkey

Para mitigar o impacto causado por um afluxo súbito de ligações, recomendamos o seguinte:

• Determine o tamanho do conjunto de ligações de cliente mais adequado para si. Um bom tamanho inicial para cada cliente é uma ligação por nó do Valkey. Em seguida, pode realizar testes de referência para ver se mais ligações ajudam sem saturar o número máximo permitido de ligações.

• Quando o cliente se desliga do servidor porque o servidor excede o tempo limite, tente novamente com um recuo exponencial com variação aleatória. Isto ajuda a evitar que vários clientes sobrecarreguem o servidor em simultâneo.

Para instâncias com o modo de cluster ativado

A sua aplicação tem de usar um cliente Valkey com reconhecimento de clusters quando se liga a uma instância do Memorystore for Valkey com o modo de cluster ativado. Para ver exemplos de clientes com reconhecimento de clusters e configurações de exemplo, consulte os exemplos de código da biblioteca de cliente. O seu cliente tem de manter um mapa de espaços de hash para os nós correspondentes na instância para enviar pedidos para os nós corretos. Isto evita a sobrecarga de desempenho causada por redirecionamentos.

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 SLOTS, NODES ou CLUSTER SHARDS para o servidor Valkey. Recomendamos que use o comando CLUSTER SHARDS. CLUSTER SHARDS substitui o comando SLOTS (descontinuado), oferecendo uma representação mais eficiente e extensível da instância.

O tamanho da resposta para os comandos de deteção de clientes pode variar com base no tamanho e na topologia da instância. As instâncias 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 nós não aumenta sem limites.

Estas atualizações da topologia dos nós são dispendiosas no servidor Valkey, 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 nós, um erro comum é a aplicação cliente fazer vários pedidos de nova ligação e deteção sem adicionar uma retirada exponencial na nova tentativa. Isto pode tornar o servidor Valkey não responsivo durante um período prolongado, o que provoca uma utilização muito elevada da CPU.

Use um ponto final de deteção para a deteção de nós

Use o ponto final de deteção do Memorystore for Valkey para realizar a deteção de nós. O ponto final de descoberta está altamente disponível e tem equilíbrio de carga em todos os nós na instância. Além disso, o ponto final de deteção tenta encaminhar os pedidos de deteção de nós para nós com a vista de topologia mais atualizada.

Para instâncias com o modo de cluster desativado

Quando se liga a uma instância com o modo de cluster desativado, a sua aplicação tem de se ligar ao ponto final principal para escrever na instância e aceder às escritas mais recentes. A sua aplicação também pode ligar-se ao ponto final do leitor para ler a partir de réplicas e isolar o tráfego do nó principal.

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. Para mais informações, consulte o artigo Monitorize a utilização de memória de uma instância.

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

Para resolver este problema, reduza a utilização de memória da instância de uma das seguintes formas:

• Diminua a utilização da memória gerada pela instância para menos de 80% da memória máxima permitida do nó.
• Dimensione o tipo de nó para a sua instância de modo a ter mais memória.

Depois de a utilização de memória da instância 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.