Práticas recomendadas do Memorystore para Valkey

Esta página fornece orientações sobre como usar o Memorystore for Valkey de maneira otimizada. Ela também aponta possíveis problemas a serem evitados.

Práticas recomendadas de gerenciamento de memória

Esta seção descreve estratégias para gerenciar a memória da instância para que o Memorystore for Valkey funcione com eficiência para seu aplicativo.

Conceitos de gerenciamento de memória

  • Uso da memória: a quantidade de memória que sua instância usa. Você tem uma capacidade de memória fixa. É possível usar métricas para monitorar a quantidade de memória que você está usando.

  • Política de remoção: o Memorystore for Valkey usa a política de remoção volatile-lru. É possível usar comandos do Valkey, como o comando EXPIRE, para definir remoções de chaves.

Monitorar o uso da memória de uma instância

Para monitorar o uso da memória de uma instância do Memorystore for Valkey, recomendamos que você consulte a métrica /instance/memory/maximum_utilization. Se o uso da memória da instância se aproximar de 80% e você espera que o uso de dados aumente, então escalonar verticalmente o tamanho da instância para abrir espaço para novos dados.

Se a instância tiver alto uso da memória, faça o seguinte para melhorar o desempenho:

Se você tiver problemas, entre em contato com Google Cloud o atendimento ao cliente.

Escalonar fragmentos no modo de cluster ativado

Ao escalonar o número de fragmentos em uma instância, recomendamos que você faça isso durante períodos de poucas gravações. O escalonamento durante períodos de alto uso pode colocar pressão de memória na instância devido à sobrecarga de memória causada pela replicação ou migração de slots.

Se o caso de uso do Valkey usar remoções de chaves, o escalonamento para um tamanho de instância menor poderá reduzir a proporção de ocorrências em cache. Nessa circunstância, no entanto, não é necessário se preocupar com a perda de dados, já que a remoção de chaves é esperada.

Para casos de uso do Valkey em que você não quer perder chaves, só é possível reduzir o escalonamento para uma instância menor que ainda tenha espaço suficiente para seus dados. A nova contagem de fragmentos de destino precisa permitir pelo menos 1,5 vezes a memória usada pelos dados. Em outras palavras, você precisa provisionar fragmentos suficientes para 1,5 vezes a quantidade de dados na instância. É possível usar a métrica /instance/memory/total_used_memory para conferir quantos dados estão armazenados na instância.

Práticas recomendadas de uso da CPU

Se ocorrer uma interrupção zonal inesperada, isso levará à redução dos recursos de CPU da instância devido à capacidade perdida dos nós na zona indisponível. Recomendamos o uso de instâncias de alta disponibilidade. O uso de várias réplicas por fragmento (em vez de uma réplica por fragmento) fornece recursos de CPU adicionais durante uma interrupção. É possível ter até cinco réplicas por fragmento.

Além disso, recomendamos gerenciar o uso da CPU do nó para que os nós tenham sobrecarga de CPU suficiente para lidar com o tráfego adicional da capacidade perdida se ocorrer uma interrupção zonal inesperada. Monitore o uso da CPU para instâncias principais e réplicas usando a métrica de segundos de CPU da linha de execução principal /instance/cpu/maximum_utilization.

Dependendo do número de réplicas provisionadas por nó, recomendamos os seguintes destinos de uso da CPU /instance/cpu/maximum_utilization:

  • Para instâncias com uma réplica por nó, defina um valor /instance/cpu/maximum_utilization de 0,5 segundo para a instância principal e 0,5 segundo para a réplica.
  • Para instâncias com duas réplicas por nó ou mais, defina um valor /instance/cpu/maximum_utilization de 0,9 segundo para a instância principal e 0,5 segundo para cada réplica.

Se os valores da métrica excederem essas recomendações, recomendamos aumentar o número de fragmentos na instância. Se você tiver menos de cinco réplicas para sua instância, também poderá escalonar verticalmente o número de réplicas, até um máximo de cinco.

Se a instância tiver alta utilização da CPU ou se os recursos dela ficarem esgotados (por exemplo, por ter muitas conexões), a instância poderá ter um comportamento inadequado e as métricas externas poderão estar ausentes.

Comandos do Valkey com uso intensivo de recursos

Recomendamos que você evite usar comandos do Valkey com uso intensivo de recursos. O uso desses comandos pode resultar nos seguintes problemas de desempenho:

  • Alta latência e tempos limite do cliente
  • Pressão de memória causada por comandos que aumentam o uso da memória
  • Perda de dados durante a replicação e sincronização de nós porque a linha de execução principal do Valkey está bloqueada
  • Verificações de integridade, observabilidade e replicação esgotadas

A tabela a seguir lista exemplos de comandos do Valkey com uso intensivo de recursos e oferece alternativas eficientes.

Categoria Comando com uso intensivo de recursos Alternativa eficiente em termos de recursos
Executar para todo o keyspace KEYS SCAN
Executar para um conjunto de chaves de comprimento variável LRANGE Limite o tamanho do intervalo usado para uma consulta.
ZRANGE Limite o tamanho do intervalo usado para uma consulta.
HGETALL HSCAN
SMEMBERS SSCAN
Bloquear a execução de um script EVAL Verifique se o script não é executado indefinidamente.
EVALSHA Verifique se o script não é executado indefinidamente.
Remover arquivos e links DELETE UNLINK
Publicar e assinar PUBLISH SPUBLISH
SUBSCRIBE SSUBSCRIBE

Práticas recomendadas do cliente Valkey

Evitar sobrecarga de conexão no Valkey

Para mitigar o impacto causado por um influxo repentino de conexões, recomendamos o seguinte:

  • Determine o tamanho do pool de conexões do cliente que é melhor para você. Um bom tamanho inicial para cada cliente é uma conexão por nó do Valkey. Em seguida, faça um benchmark para conferir se mais conexões ajudam sem saturar a contagem máxima de conexões permitida.

  • Quando o cliente se desconecta do servidor porque o servidor atinge o tempo limite, tente novamente com espera exponencial com jitter. Isso ajuda a evitar que vários clientes sobrecarreguem o servidor simultaneamente.

Detectar e processar conexões sem resposta

Recomendamos configurar o aplicativo cliente para detectar conexões sem resposta ao Memorystore for Valkey. Quando uma conexão sem resposta é detectada, o cliente precisa redefini-la. Para criar um aplicativo resiliente, recomendamos as seguintes configurações do cliente:

  • Configurar parâmetros de sinal de atividade do TCP: defina os parâmetros TCP keepalive time, TCP keepalive interval e TCP keepalive probes para que os clientes detectem e descartem conexões sem resposta de maneira proativa, mesmo quando as conexões estiverem inativas. Por exemplo, se você definir o parâmetro TCP keepalive time como 30 segundos, TCP keepalive interval como 10 segundos e TCP keepalive probes como 3, os clientes vão redefinir as conexões inativas sem resposta em um minuto.
  • Configurar tempos limite de usuário TCP: defina esse tempo limite nos clientes para redefinir conexões que têm solicitações pendentes e param de responder. Por exemplo, se você definir o tempo limite como 15 segundos, os clientes vão redefinir as conexões sem resposta que têm solicitações pendentes após 15 segundos.

Para instâncias com o modo de cluster ativado

Seu aplicativo precisa usar um cliente Valkey com reconhecimento de cluster ao se conectar a uma instância do Memorystore for Valkey com o modo de cluster ativado. Para exemplos de clientes com reconhecimento de cluster e configurações de amostra, consulte Exemplos de código da biblioteca de cliente. O cliente precisa manter um mapa de slots de hash para os nós correspondentes na instância para enviar solicitações aos nós corretos. Isso evita a sobrecarga de desempenho causada por redirecionamentos.

Mapeamento do cliente

Os clientes precisam receber uma lista completa de slots e os nós mapeados nas seguintes situações:

  • Quando o cliente é inicializado, ele precisa preencher o slot inicial para o mapeamento de nós.

  • Quando um redirecionamento MOVED é recebido do servidor, como na situação de um failover em que todos os slots atendidos pelo nó principal anterior são assumidos pela réplica, ou quando os slots estão sendo movidos da instância principal de origem para o nó principal de destino.

  • Quando um erro CLUSTERDOWN é recebido do servidor ou as conexões com um servidor específico atingem o tempo limite de maneira persistente.

  • Quando um erro READONLY é recebido do servidor. Isso pode acontecer quando uma instância principal é rebaixada para uma réplica.

  • Além disso, os clientes precisam atualizar periodicamente a topologia para manter os clientes aquecidos para quaisquer mudanças e aprender sobre mudanças que podem não resultar em redirecionamentos ou erros do servidor, como quando novos nós de réplica são adicionados. Observe que todas as conexões obsoletas também precisam ser fechadas como parte da atualização da topologia para reduzir a necessidade de processar conexões com falha durante o tempo de execução do comando.

Descoberta de clientes

A descoberta de clientes geralmente é feita emitindo um comando SLOTS, NODES ou CLUSTER SHARDS para o servidor Valkey. Recomendamos o uso do comando CLUSTER SHARDS. CLUSTER SHARDS substitui o comando SLOTS (descontinuado), fornecendo uma representação mais eficiente e extensível da instância.

O tamanho da resposta para os comandos de descoberta de clientes pode variar com base no tamanho e na topologia da instância. Instâncias maiores com mais nós produzem uma resposta maior. Como resultado, é importante garantir que o número de clientes que fazem a descoberta da topologia de nós não cresça sem limites.

Essas atualizações de topologia de nós são caras no servidor Valkey, mas também são importantes para a disponibilidade do aplicativo. Portanto, é importante garantir que cada cliente faça uma única solicitação de descoberta a qualquer momento (e armazene o resultado em cache na memória) e que o número de clientes que fazem as solicitações seja limitado para evitar a sobrecarga do servidor.

Por exemplo, quando o aplicativo cliente é iniciado ou perde a conexão com o servidor e precisa realizar a descoberta de nós, um erro comum é que o cliente aplicativo faz várias solicitações de reconexão e descoberta sem adicionar espera exponencial na nova tentativa. Isso pode tornar o servidor Valkey sem resposta por um período prolongado, causando uma utilização muito alta da CPU.

Usar um endpoint de descoberta para descoberta de nós

Use o endpoint de descoberta do Memorystore for Valkey para realizar a descoberta de nós. O endpoint de descoberta tem alta disponibilidade e é balanceado por carga em todos os nós da instância. Além disso, o endpoint de descoberta tenta rotear as solicitações de descoberta de nós para nós com a visualização de topologia mais atualizada.

Para instâncias com o modo de cluster desativado

Ao se conectar a uma instância com o modo de cluster desativado, seu aplicativo precisa se conectar ao endpoint principal para gravar na instância e recuperar as gravações mais recentes. Seu aplicativo também pode se conectar ao endpoint do leitor para ler réplicas e isolar o tráfego do nó principal.

Se você usar a estratégia de criar antes de destruir ao realizar a manutenção na instância, poderá receber a seguinte mensagem de erro:

READONLY You can't write against a read only replica.

Para resolver esse problema, interrompa a conexão com a instância. Em seguida, recrie a conexão.

Práticas recomendadas de persistência

Esta seção explica as práticas recomendadas de persistência.

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

Para melhores resultados de backup da instância com snapshots do RDB ou adição de réplicas à instância, use as seguintes práticas recomendadas:

Gerenciamento de memória

Os snapshots do RDB usam um fork de processo e um mecanismo de "cópia na gravação" para tirar um snapshot dos dados do nó. Dependendo do padrão de gravações nos nós, a memória usada dos nós aumenta à medida que as páginas tocadas pelas gravações são copiadas. O consumo de memória pode ser até o dobro do tamanho dos dados no nó.

Para garantir que os nós tenham memória suficiente para concluir o snapshot, mantenha ou defina maxmemory em 80% da capacidade do nó para que 20% sejam reservados para a sobrecarga. Essa sobrecarga de memória, além de monitorar snapshots, ajuda a gerenciar sua carga de trabalho para ter snapshots bem-sucedidos. Além disso, ao adicionar réplicas, diminua o tráfego de gravação o máximo possível. Para mais informações, consulte Monitorar o uso da memória de uma instância.

Snapshots obsoletos

A recuperação de nós de um snapshot obsoleto pode causar problemas de desempenho no aplicativo, pois ele tenta reconciliar uma quantidade significativa de chaves obsoletas ou outras mudanças no banco de dados, como uma mudança de esquema. Se você estiver preocupado com a recuperação de um snapshot obsoleto, poderá desativar o recurso de persistência do RDB. Depois de reativar a persistência, um snapshot será feito no próximo intervalo de snapshot programado.

Impacto no desempenho de snapshots do RDB

Dependendo do padrão de carga de trabalho, os snapshots do RDB podem afetar o desempenho da instância e aumentar a latência dos aplicativos. É possível minimizar o impacto no desempenho dos snapshots do RDB programando a execução deles durante períodos de baixo tráfego de instância, se você estiver confortável com snapshots menos frequentes.

Por exemplo, se a instância tiver pouco tráfego das 1h às 4h, defina o horário de início como 3h e o intervalo como 24 horas.

Se o sistema tiver uma carga constante e exigir snapshots frequentes, recomendamos que você avalie cuidadosamente o impacto no desempenho e considere os benefícios de usar snapshots do RDB para a carga de trabalho.

Adicionar uma réplica

A adição de uma réplica requer um snapshot do RDB. Para mais informações sobre snapshots do RDB, consulte Gerenciamento de memória.

Quando usar uma instância de zona única

Se você configurar uma instância para que ela não use réplicas, recomendamos que você use uma instância de zona única. Geralmente, estes são os motivos:

Custo e desempenho

Se minimizar o custo e ter desempenho máximo para seus clientes localizados na mesma região forem seus principais motivadores, recomendamos que você escolha uma instância de zona única.

Minimizar o impacto da interrupção

Ao escolher uma instância de zona única, é menos provável que as interrupções zonais afetem sua instância. Ao colocar todos os nós em uma única zona, a chance de uma interrupção zonal afetar seu servidor cai de 100% para 33%. Há uma chance de 33% de que a zona em que sua instância está localizada fique inativa, em vez de uma chance de 100% de que os nós, que estão localizados na zona indisponível, sejam afetados.

Recuperação rápida

Se ocorrer uma interrupção zonal para uma instância de zona única, o Memorystore for Valkey vai simplificar a recuperação dos seus dados. É possível provisionar uma nova instância em uma zona funcional rapidamente e redirecionar o aplicativo para operações minimamente interrompidas.

Ativar o Transport Layer Security (TLS)

Esta seção explica os benefícios de segurança e as implicações de desempenho do uso do Transport Layer Security (TLS), além de recomendações para a ativação dele.

Benefícios de segurança

Ao usar o TLS, você tem os seguintes benefícios de segurança:

  • Autenticação do Identity and Access Management (IAM): o TLS usa esse tipo de autenticação para proteger contra ataques de spoofing de servidor, como ataques man-in-the-middle.
  • Criptografia em trânsito: Google Clouda criptografia integrada do protege o tráfego na rede do Google em um nível de infraestrutura. No entanto, isso envolve confiar nas pilhas de host e de rede do Google. Embora essa criptografia seja transparente e ativada por padrão, ela não é de ponta a ponta. Por outro lado, o TLS usa criptografia em trânsito na camada de aplicativo. Essa criptografia de ponta a ponta oferece mais controle sobre suas chaves e processos de criptografia.
  • Proteção de token de autenticação: Se você usar a autenticação do IAM, a ativação do TLS vai minimizar o risco de expor e vazar seus tokens de autenticação.

Implicações no desempenho

O TLS afeta o desempenho das seguintes maneiras:

  • Estabelecer conexões: Um cliente e um servidor que estabeleceram uma sessão TLS podem retomar a sessão sem repetir o processo de uso intensivo de recursos de estabelecer a conexão entre o cliente e o servidor. Ao ativar a retomada do TLS, você reduz a sobrecarga de estabelecer uma conexão entre o cliente e o servidor.

    Se você não estabelecer a retomada do TLS, o estabelecimento de conexões será de uso intensivo de recursos. Para conexões novas e atuais, muitas conexões entre o cliente e o servidor podem levar a tempos limite de conexão. Isso pode causar um efeito bola de neve porque o Memorystore for Valkey tenta restabelecer conexões com tempo limite, o que aumenta os recursos usados para estabelecer conexões.

  • Criptografar e descriptografar dados: a criptografia e a descriptografia de dados envolvem operações com uso intensivo de CPU que afetam o cliente e o servidor. Isso pode reduzir a capacidade da instância e aumentar a latência dela.

Recomendações

Ao considerar se deve ativar o TLS, recomendamos que você avalie suas políticas de segurança considerando os benefícios e desvantagens do TLS. Se você optar por ativar o TLS, tenha em mente as seguintes considerações:

  • A ativação da retomada do TLS atenua a sobrecarga para estabelecer conexões. Uma conexão entre o cliente e o servidor é necessária apenas para a conexão inicial. No entanto, uma expansão repentina do tamanho da instância do cliente pode resultar em uma breve interrupção causada pelo handshake completo inicial de cada novo host do cliente.
  • Embora algumas bibliotecas de cliente talvez não ofereçam controles integrados para ativar o TLS, é possível usar um código personalizado para integrar essa funcionalidade às instâncias.