Práticas recomendadas do Memorystore para Valkey

Esta página fornece orientações sobre como usar o Memorystore for Valkey de maneira ideal. Esta página também indica possíveis problemas que devem ser evitados.

Práticas recomendadas de gerenciamento de memória

Nesta seção, descrevemos estratégias para gerenciar a memória da instância para que o Memorystore for Valkey funcione de maneira eficiente no seu aplicativo.

Conceitos de gerenciamento de memória

• Uso da memória: a quantidade de memória que a instância usa. Você tem uma capacidade de memória fixa. Use as 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 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 para Valkey, recomendamos que você confira a métrica /instance/memory/maximum_utilization. Se o uso da memória da instância se aproximar de 80% e você esperar que o uso de dados aumente, aumente 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:

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

Se tiver problemas, entre em contato com o atendimento ao cliente doGoogle Cloud .

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 uma instância menor pode reduzir a proporção de ocorrência em cache. Nesse caso, no entanto, você não precisa 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, reduza a escala vertical 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 vez a memória usada pelos dados. Em outras palavras, provisione fragmentos suficientes para 1,5 vez a quantidade de dados na instância. Use a métrica /instance/memory/total_used_memory para ver quantos dados estão armazenados na sua instância.

Práticas recomendadas para uso da CPU

Se ocorrer uma interrupção inesperada na zona, isso vai reduzir os recursos de CPU da instância devido à perda de capacidade 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 extra da capacidade perdida se houver uma interrupção inesperada na zona. Monitore o uso da CPU para primárias e réplicas usando a métrica Segundos de CPU da linha de execução principal /instance/cpu/maximum_utilization.

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

• Para instâncias com uma réplica por nó, defina um valor de /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 ou mais réplicas por nó, use um valor de /instance/cpu/maximum_utilization de 0,9 segundo para a primária 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 na 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 de CPU ou se os recursos dela forem esgotados (por exemplo, por ter muitas conexões), ela poderá se comportar de maneira inadequada e as métricas externas poderão estar ausentes.

Comandos do Valkey que consomem muitos recursos

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

• Latência alta 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 sem recursos

A tabela a seguir lista exemplos de comandos do Valkey que consomem muitos recursos e oferece alternativas que são eficientes em termos de recursos.

Dica: além de consumir muitos recursos, o custo de usar esses comandos aumenta conforme o tamanho total dos dados aumenta.

Para descobrir quais comandos de longa duração você usa, use SLOWLOG. Essa ferramenta fornece uma lista de comandos que levam mais tempo para serem executados. Como resultado, você sabe quais comandos causam problemas de latência. Para determinar alternativas eficientes em termos de recursos para esses comandos, consulte a tabela a seguir.

Categoria	Comando que consome muitos recursos	Alternativa com uso eficiente 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 para limites de escalonamento

Os cenários de limite de escalonamento se enquadram nas seguintes categorias:

• Escalonamento para uso da memória
• Escalonamento para uso da CPU
• Escalonamento para reduzir pontos de acesso

Se a carga de trabalho depende da remoção de chaves, o Google não recomenda a redução da escala vertical para uso da CPU ou uso da memória. Nessas cargas de trabalho, o uso da memória costuma atingir a capacidade máxima antes que as remoções ocorram automaticamente. Os picos de memória resultantes bloqueiam as operações de redução de escala vertical.

As seções a seguir detalham cenários comuns e limites de métricas que podem justificar o escalonamento.

Escalonamento de uso da memória

Para determinar quando escalonar com base no uso da memória, monitore as métricas /instance/memory/average_utilization e /instance/memory/maximum_utilization. Para mais informações sobre essas métricas, consulte Métricas de monitoramento compatíveis.

Se a instância atender a uma das seguintes condições, considere acionar uma operação de escalonamento horizontal:

• O uso médio da memória da instância excede o limite sugerido de 70%.
• O uso máximo da memória excede 80% e o uso médio da memória excede 50%.

Se a instância atender a uma das seguintes condições, considere acionar uma operação de redução de escala vertical:

• O uso médio da memória da instância cai abaixo do limite sugerido de 50%.
• O uso máximo da memória cai para menos de 60%, e o uso médio da memória cai para menos de 40%.

Escalonamento de uso da CPU

Para determinar quando escalonar com base no uso da CPU, monitore as métricas /instance/cpu/average_utilization e /instance/cpu/maximum_utilization.

Se a instância atender a uma das seguintes condições, considere acionar uma operação de escalonamento horizontal:

• A utilização média da CPU da instância excede o limite sugerido de 70%.
• A utilização máxima da CPU excede 80% e a utilização média da CPU excede 50%.

Se a instância atender a uma das seguintes condições, considere acionar uma operação de redução de escala vertical:

• A utilização média da CPU da instância cai abaixo do limite sugerido de 50%.
• A utilização máxima da CPU cai abaixo de 60% e a utilização média da CPU cai abaixo de 40%.

Escalonamento para reduzir pontos de acesso

O Memorystore para Valkey fornece variações médias e máximas da mesma métrica, que podem ser usadas para identificar pontos de acesso para essa família de métricas. O valor máximo representa o nó da instância que está mais carregado, enquanto o valor médio representa a carga de toda a instância. Se o valor máximo for significativamente maior que o valor médio, isso indica que um nó específico está carregado de maneira desproporcional (um ponto de acesso). Para resolver esse problema, recomendamos que você escalonar horizontalmente sua instância. Para mais informações, consulte Escalonar a capacidade da instância.

Quando você observar uma divergência significativa entre as variações média e máxima, execute os comandos INFO memory e INFO cpu nos nós da instância para coletar dados em tempo real diretamente dela. Para mais informações sobre como usar esses comandos, consulte INFO na documentação do Valkey.

Práticas recomendadas para clientes do Valkey

Evitar sobrecarga de conexão no Valkey

Para reduzir 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 comparativo de mercado para ver se mais conexões ajudam sem saturar a contagem máxima de conexões permitida.

• Quando o cliente se desconectar do servidor devido ao tempo limite do servidor, tente novamente com espera exponencial com instabilidade. Isso ajuda a evitar que vários clientes sobrecarreguem o servidor ao mesmo tempo.

Detectar e processar conexões que não respondem

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

• Configure os 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 que não respondem de maneira proativa, mesmo quando as conexões estão 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 que não respondem em um minuto.
• Configurar tempos limite do usuário TCP: defina esse tempo limite nos clientes para redefinir conexões que têm solicitações pendentes e parar de responder. Por exemplo, se você definir o tempo limite como 15 segundos, os clientes vão redefinir as conexões que não respondem e 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 do Valkey que reconheça clusters ao se conectar a uma instância do Memorystore for Valkey com o modo de cluster ativado. Para exemplos de clientes que reconhecem clusters e exemplos de configurações, 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 de clientes

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 mapeamento inicial de slots para nós.

• Quando um redirecionamento MOVED é recebido do servidor, como em uma situação de failover em que todos os slots atendidos pelo nó principal anterior são assumidos pela réplica, ou em uma nova fragmentação em que os slots são movidos do nó 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 forma 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 se manterem preparados para qualquer mudança e saber sobre alterações que podem não resultar em redirecionamentos ou erros do servidor, como quando novos nós de réplica são adicionados. Todas as conexões inativas também precisam ser fechadas como parte da atualização da topologia para reduzir a necessidade de lidar com conexões com falha durante o ambiente 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) ao fornecer uma representação mais eficiente e extensível da instância.

O tamanho da resposta para os comandos de descoberta do cliente pode variar com base no tamanho e na topologia da instância. Instâncias maiores com mais nós produzem uma resposta maior. Por isso, é 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ã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 em um determinado momento (e armazene em cache o resultado 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 é o aplicativo cliente fazer várias solicitações de reconexão e descoberta sem adicionar espera exponencial na nova tentativa. Isso pode fazer com que o servidor Valkey pare de responder por um longo período, causando uma utilização muito alta da CPU.

Usar um endpoint de descoberta para descobrir nós

Use o endpoint de descoberta do Memorystore for Valkey para realizar a descoberta de nós. O endpoint de descoberta é altamente disponível e tem balanceamento de carga em todos os nós da instância. Além disso, o endpoint de descoberta tenta encaminhar 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

Quando o aplicativo se conecta a uma instância com o modo de cluster desativado, ele 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 as réplicas e isolar o tráfego do nó principal.

Como as instâncias com o modo de cluster desativado têm apenas um fragmento, elas não usam uma topologia na memória. Portanto, a atualização da topologia não é aplicável.

Durante failovers e eventos de manutenção, as conexões com a instância são interrompidas. Para garantir que o aplicativo se reconecte após esses eventos, implemente um mecanismo de nova tentativa com espera exponencial.

É possível usar a estratégia de criar antes de destruir ao realizar manutenção na instância. Para mais informações sobre essa estratégia, consulte Estratégia de ciclo de vida de criação antes da destruição.

Se você usar essa estratégia, 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

Nesta seção, explicamos as práticas recomendadas para persistência.

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

Para ter os melhores resultados ao fazer backup da instância com snapshots de RDB ou adicionar réplicas à instância, use as seguintes práticas recomendadas:

Gerenciamento de memória

Os snapshots do RDB usam uma bifurcação de processo e um mecanismo de cópia em gravação para criar 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% seja reservado para sobrecarga. Essa sobrecarga de memória, além de monitorar snapshots, ajuda a gerenciar a carga de trabalho para ter snapshots bem-sucedidos. Além disso, ao adicionar réplicas, reduza 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.

Observação: se você adicionar uma réplica a uma instância que usa mais de 80% da memória máxima da instância, a operação vai falhar e você vai receber uma mensagem de erro.

Para resolver esse problema, reduza o uso da memória da instância de uma das seguintes maneiras:

• Reduza o consumo de memória da instância para menos de 80% da memória máxima permitida do nó.
• Dimensione o tipo de nó da instância para que ela tenha mais memória.

Depois que o uso da memória da instância estiver abaixo do limite de 80%, adicione a réplica novamente.

Snapshots desatualizados

A recuperação de nós de um snapshot desatualizado pode causar problemas de desempenho no aplicativo, já que ele tenta reconciliar uma quantidade significativa de chaves desatualizadas 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 desatualizado, desative o recurso de persistência do RDB. Depois que você reativar a persistência, um snapshot será criado no próximo intervalo de snapshot programado.

Impacto no desempenho dos 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-os para serem executados durante períodos de baixo tráfego de instâncias, se você não se importar com snapshots menos frequentes.

Por exemplo, se a instância tiver pouco tráfego entre 1h e 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 de RDB para a carga de trabalho.

Adicionar uma réplica

Para adicionar uma réplica, é necessário um snapshot do RDB. Para mais informações sobre snapshots de 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 usar uma instância de zona única. Geralmente, estes são os motivos:

Custo e desempenho

Se os principais fatores forem minimizar o custo e ter o melhor desempenho para os clientes localizados na mesma região, recomendamos que você escolha uma instância de zona única.

Minimizar o impacto da interrupção

Quando você escolhe uma instância de zona única, as falhas zonais têm menos probabilidade de afetar sua instância. Ao colocar todos os nós em uma única zona, a chance de uma interrupção zonal afetar o 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 em uma instância de zona única, o Memorystore for Valkey simplifica a recuperação dos dados. É possível provisionar uma nova instância em uma zona em funcionamento rapidamente e redirecionar o aplicativo para operações com o mínimo de interrupção.

Práticas recomendadas para planejamento de capacidade

Para garantir que você possa provisionar recursos e criar arquiteturas resilientes, recomendamos as seguintes práticas recomendadas de planejamento de capacidade:

• Implante em vários locais: se não for possível criar uma instância na zona preferida devido a restrições temporárias de recursos, tente criar a instância em uma zona diferente na mesma região ou em uma região diferente.
• Usar o acesso entre regiões: configure seus clientes para acessar as instâncias localizadas em regiões diferentes. Se você precisar provisionar uma instância em uma região diferente devido a restrições de recursos locais, seus clientes poderão se conectar à instância.
• Usar a replicação entre regiões: para promover uma instância secundária em uma região alternativa para uma instância principal de leitura ou gravação para recuperação de desastres, realize uma troca.

Ativar o Transport Layer Security (TLS)

Nesta seção, explicamos 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 de person-in-the-middle.
• Criptografia em trânsito: a criptografia integrada doGoogle Cloudprotege 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 do aplicativo. Essa criptografia de ponta a ponta oferece mais controle sobre as chaves e os processos de criptografia.
• Proteção de token de autenticação: se você usa a autenticação do IAM, ativar o TLS minimiza o risco de exposição e vazamento dos 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 retomá-la sem repetir o processo de estabelecimento da conexão entre eles, que consome muitos recursos. Ao ativar a retomada de 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 consumirá muitos 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 as conexões que expiraram, o que aumenta os recursos usados para estabelecer conexões.

• Criptografar e descriptografar dados: a criptografia e a descriptografia de dados envolvem operações que consomem muita CPU e 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 e considere os benefícios e as desvantagens do TLS. Se você optar por ativar o TLS, considere o seguinte:

• Ativar a retomada do TLS reduz 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 não ofereçam controles integrados para ativar o TLS, é possível usar um código personalizado para integrar essa funcionalidade às instâncias.