Nesta página, fornecemos orientações sobre como usar o Memorystore para Valkey da melhor forma. Essa página também indica possíveis problemas que devem ser evitados.
Práticas recomendadas para o gerenciamento de memória
Esta seção descreve estratégias para gerenciar a memória da instância para que o Memorystore para Valkey funcione de maneira eficiente no seu aplicativo.
Conceitos de gerenciamento de memória
Carga de gravação: o volume e a velocidade com que você adiciona ou atualiza chaves na sua instância da Valkey. A carga de gravação pode variar de normal a muito alta, dependendo do caso de uso e dos padrões de uso do aplicativo da Valkey.
Política de remoção: o Memorystore para Valkey usa a política de remoção
volatile-lru. É possível usar comandos Valkey, como EXPIRE, para definir remoções de chaves.
monitorar uma instância que tem uma carga de gravação normal;
Confira a métrica /instance/cpu/maximum_utilization. Se /instance/cpu/maximum_utilization for
a 100% ou menos, sua instância Valkey apresenta um bom desempenho quando você usa uma carga de gravação normal.
No entanto, se o uso de memória se aproximar de 100% e você esperar que o uso de dados aumente, escalone o tamanho da instância para abrir espaço para novos dados.
Monitorar uma instância que tem uma alta carga de gravação
Confira a métrica /instance/memory/maximum_utilization. Dependendo da gravidade da carga de gravação alta, a instância pode ter problemas de desempenho nos seguintes limites:
Cargas de gravação muito altas podem ter problemas se
/instance/memory/maximum_utilizationchegar a 65% ou mais.Cargas de gravação moderadamente altas podem apresentar problemas se
/instance/memory/maximum_utilizationatingir 85% ou mais.
Nesses cenários, aumente o tamanho da instância para melhorar a performance.
Se você tiver problemas ou achar que a instância tem uma alta carga de gravação, entre em contato com Suporte do Google Cloud.
Como escalonar fragmentos
Ao aumentar o número de fragmentos em uma instância, faça isso durante períodos de poucas gravações. O escalonamento durante períodos de alta carga de gravação pode sobrecarregar a memória da instância devido à sobrecarga causada pela replicação ou migração de slots.
Se o caso de uso da Valkey usar remoções de chaves, o escalonamento para um tamanho de instância menor pode reduzir a proporção de ocorrência em cache. No entanto, nessa circunstância, você não precisa se preocupar em perder dados, já que a eliminação de chaves é esperada.
Para casos de uso da chave Valkey em que você não quer perder chaves, é necessário reduzir o tamanho para uma instância menor que ainda tenha espaço suficiente para os dados. A nova contagem de fragmentos de destino precisa permitir pelo menos 1,5 vezes a memória usada pelos dados. Em outras palavras, provisioneie divisões suficientes para 1,5 vezes a quantidade de dados que está na sua instância. Use a métrica /instance/memory/total_used_memory para saber a quantidade de dados armazenados na sua instância.
Práticas recomendadas de uso da CPU
Se ocorrer uma interrupção zonal inesperada, isso vai reduzir os recursos de CPU da sua instância devido à perda de capacidade dos nós na zona indisponível. Recomendamos o uso de instâncias altamente disponíveis. O uso de duas réplicas por fragmento (em vez de uma réplica por fragmento) fornece recursos de CPU adicionais durante uma interrupção. 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 devido à perda de capacidade caso ocorra uma falha temporária de zona inesperada. 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 de quantas réplicas você provisiona por nó, recomendamos os seguintes destinos 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_utilizationde 0,5 segundo para o primário e a réplica. - Para instâncias com duas réplicas por nó, segmente um valor de
/instance/cpu/maximum_utilizationde 0,9 segundo para a instância principal e de 0,5 segundo para as réplicas.
Se os valores da métrica excederem essas recomendações, recomendamos aumentar o número de fragmentos ou réplicas na sua instância.
Comandos Valkey de alto uso da CPU
Evite comandos Valkey que sejam caros para executar por vários motivos. Esta seção apresenta exemplos de motivos pelos quais alguns comandos são caros, mas essa lista não é exaustiva.
Comandos que operam em todo o espaço de chaves
- KEYS
Comandos que operam em um conjunto de chaves de comprimento variável
- LRANGE
- ZRANGE
- HGETALL
Comandos que bloqueiam a execução de um script
- AVALIAÇÃO
- EVALSHA
Riscos do uso de comandos caros
- Latência alta e tempo limite do cliente.
- Pressão de memória causada por comandos que aumentam o uso de memória.
- Perda de dados durante a replicação e sincronização de nós devido ao bloqueio da linha de execução principal do Valkey.
- Verificações de integridade, observabilidade e replicação com falta de recursos.
Práticas recomendadas para clientes do Valkey
O aplicativo precisa usar um cliente Valkey compatível com cluster ao se conectar a uma instância do Memorystore para Valkey. Para conferir exemplos de clientes com reconhecimento de cluster e exemplos de configurações, consulte Exemplos de código da biblioteca de cliente. Seu cliente precisa manter um mapa de slots de hash para os nós correspondentes na instância para enviar solicitações aos nós certos e evitar a sobrecarga de desempenho causada pelos 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 deve preencher o slot inicial para nós mapeamento.
Quando um redirecionamento
MOVEDé recebido do servidor, como na situação de um failover quando todos os slots exibidos pelo antigo nó principal são acessados pela réplica ou pela refragmentação quando os slots estão sendo movidos da origem primário para o nó primário de destino.Quando um erro
CLUSTERDOWNé recebido do servidor, ou as conexões com um servidor específico encontram tempos limite persistentes.Quando um erro
READONLYé recebido do servidor. Isso pode acontecer quando uma instância é rebaixado a réplica.Além disso, os clientes precisam atualizar periodicamente a topologia para manter os clientes preparados para qualquer mudança e saber sobre mudanças que não resultem em redirecionamentos / erros do servidor, como quando novos nós de réplica são adicionados. Observe que conexões desatualizadas também devem ser fechadas como parte da atualização da topologia para reduzir a necessidade de lidar com conexões com falha durante a execução do comando.
Descoberta de clientes
A descoberta do cliente geralmente é feita emitindo um comando SLOTS, NODES ou CLUSTER SHARDS para o servidor do 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 cliente pode variar com base no tamanho da instância e na topologia. 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 do nó não aumente ilimitado.
Essas atualizações da 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 a qualquer momento (e armazene 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 do servidor e precisa executar a descoberta de nós, um erro comum é que o aplicativo cliente faz várias solicitações de reconexão e descoberta sem adicionar espera exponencial na nova tentativa. Isso pode fazer com que o servidor Valkey não responda por um período prolongado, causando uma utilização muito alta da CPU.
Evitar sobrecarga de descoberta no Valkey
Para reduzir o impacto causado por uma entrada repentina de solicitações de conexão e detecção, recomendamos o seguinte:
Implemente um pool de conexões de cliente com um tamanho finito e pequeno para limitar o número de conexões de entrada simultâneas do aplicativo cliente.
Quando o cliente se desconecta do servidor devido ao tempo limite, tente novamente com com espera exponencial com instabilidade. Isso ajuda a evitar que vários clientes sobrecarreguem o servidor ao mesmo tempo.
Use o endpoint de descoberta do Memorystore para 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 encaminhar as solicitações de descoberta de nó para nós com a visualização de topologia mais atualizada.
Práticas recomendadas de persistência
Esta seção explica as práticas recomendadas para persistência.
Persistência do RDB
Para melhores resultados ao fazer backup da sua instância com snapshots de RDB, use as seguintes práticas recomendadas:
Gerenciamento de memória
Os snapshots do RDB usam bifurcação de processo e "copy-on-write" para capturar 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. Na pior das hipóteses, o consumo de memória pode ser 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ó. Assim, 20% serão reservados para sobrecarga. Consulte Monitorar uma instância que tem uma carga de gravação alta para saber mais. Essa sobrecarga de memória, além dos snapshots do Monitoring, ajuda você a gerenciar a carga de trabalho para ter snapshots bem-sucedidos.
Snapshots desatualizados
A recuperação de nós de um snapshot desatualizado pode causar problemas de desempenho no seu aplicativo, já que ele tenta reconciliar uma quantidade significativa de chaves desatualizadas ou outras alterações 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á capturado 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. Para minimizar o impacto no desempenho dos snapshots do RDB, programe-os para serem executados durante períodos de baixo tráfego da instância, caso você se sinta confortável 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 tem uma carga constante e exige snapshots frequentes, avalie cuidadosamente o impacto no desempenho e pondere os benefícios de usar snapshots do RDB para a carga de trabalho.
Escolha uma instância de zona única se ela não usar réplicas
Ao configurar uma instância sem réplicas, recomendamos uma arquitetura de zona única para melhorar a confiabilidade. Veja a seguir os motivos:
Minimizar o impacto da interrupção
Interrupções 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 do serviço zonal diminuir de 100% a 33%. Isso ocorre porque há uma chance de 33% de que a zona em que sua instância está localizada seja interrompida, em vez de uma chance de 100% de que os nós localizados na zona indisponível sejam afetados.
Recuperação rápida
No caso de uma interrupção do serviço zonal, a recuperação é simplificada. Você pode responder rapidamente provisionar uma nova instância em uma zona de funcionamento e redirecionar para operações com interrupções mínimas.