Práticas recomendadas do Memorystore para Redis

Nesta página, você encontra orientação sobre o uso ideal do Memorystore para Redis. Essa página também indica possíveis problemas que devem ser evitados.

Para ver uma lista de cenários de solução de problemas, consulte Solução de problemas.

Exportação de RDB

Ao exportar um backup do RDB, siga estas orientações:

Operações com uso intensivo de recursos

Para instâncias do Redis de nível Padrão, as seguintes operações usam memória extra durante a operação:

O upgrade, o escalonamento e o failover manual de versões usam memória extra (para instâncias do nível Padrão) devido à replicação. Essas operações seguem o processo de replicação descrito em Comportamento de upgrade da instância do nível Padrão.

As operações de importação e exportação exigem memória extra devido ao processo Redis interrompido e ao gerenciamento de dados de cópia em gravação associados a essas operações.

Para diminuir as desvantagens das operações que usam muitos recursos, é necessário:

Operações e cenários que exigem uma nova tentativa de conexão

As operações e os cenários a seguir interrompem a conexão de rede entre sua rede e a instância do Redis:

Essas operações modificam a instância, exigindo uma interrupção de conexão temporária. A lógica de nova tentativa precisa estar em espera exponencial antes da execução dessas operações para que o aplicativo se reconecte automaticamente e continue funcionando normalmente.

Manutenção de rotina

As instâncias do Memorystore para Redis passam por manutenção periodicamente. Para mais detalhes, consulte a política de manutenção do Memorystore para Redis maintenance policy.

Implemente as práticas recomendadas a seguir para se preparar para manutenção de rotina:

Gerenciamento de memória

O gerenciamento de memória pode ser um desafio devido à conhecida fragmentação de memória que ocorre com o Redis de código aberto. Recomendamos que você reduza a configuração maxmemory da instância para se manter sobrecarregado no caso de alta pressão da memória.

A melhor maneira de monitorar a pressão sobre a memória na instância do Memorystore é usar a métrica de proporção de uso da memória do sistema. Para obter um guia detalhado sobre como gerenciar a memória do Memorystore para Redis, consulte Práticas recomendadas para o gerenciamento de memória.

Como gerenciar conexões inativas

Com o tempo, é possível que o número de conexões com sua instância do Memorystore aumente se as conexões não estiverem sendo encerradas corretamente. Isso pode ter implicações negativas no desempenho, especialmente se você estiver usando criptografia em trânsito, que impõe limites máximos de conexões com base no seu nível de capacidade. Para atenuar esse problema, recomendamos o uso do timeout parâmetro de configuração do Redis que permite definir o número de segundos antes que as conexões de clientes inativas sejam encerradas automaticamente.

Nomes de recursos da transparência no acesso

Dados sensíveis não podem ser armazenados em nomes de recursos do Memorystore para Redis. Por nomes de recursos, queremos dizer nomes de instâncias do Memorystore para Redis e metadados de instâncias, como tags. Não há garantia de que os dados armazenados em nomes de recursos sejam protegidos pela Google Cloud transparência no acesso, e podem entrar em conflito com os requisitos de conformidade da transparência no acesso da sua organização.

Conector de acesso VPC sem servidor necessário em alguns ambientes sem servidor

Alguns ambientes sem servidor exigem um conector de acesso VPC sem servidor para se conectar ao Memorystore para Redis. Se quiser se conectar usando um desses ambientes, configure o conector de acesso VPC sem servidor para seu projeto.

Rede

Recomendamos usar o acesso a serviços particulares modo de conexão. O Memorystore para Redis usa dois modos de conexão: acesso particular a serviços e peering direto. O modo de conexão do acesso a serviços particulares simplifica o gerenciamento de intervalos de IP e permite o uso da VPC compartilhada, se quiser.

Depois de criar uma instância, não é possível alterar o modo de conexão.

Para mais detalhes, consulte Rede.

Monitoramento e alertas

Recomendamos o uso de monitoramento e alertas, porque eles fornecem indicadores-chave sobre o uso da memória da sua instância do Redis. Elas também fornecem insights sobre a eficiência da sua instância do Redis na resposta às solicitações de cache recebidas.

É necessário configurar os seguintes alertas padrão:

Práticas recomendadas para uso da CPU

O uso inadequado de comandos Redis com custo maior leva a alta latência, falta de resposta ou problemas de conectividade. As instâncias do nível Padrão oferecem alta disponibilidade durante a recuperação de desastres e dependem da replicação assíncrona entre os nós principal e de réplica. Se um dos nós tiver um processamento de comando caro que bloqueie a linha de execução principal do Redis, a replicação poderá ser afetada. Se o problema persistir e ocorrer uma interrupção de local, os dados mais recentes gravados no local da interrupção poderão não estar disponíveis no outro local.

Recomendamos o uso do Cloud Monitoring para definir alertas para a métrica de segundos de CPU da linha de execução principal (redis.googleapis.com/stats/cpu_utilization_main_thread) para garantir que o uso da CPU não exceda 0,8 segundos para o nó principal ou 0,5 segundos para cada nó de réplica, quando a réplica for designada como uma réplica de leitura.

Se a instância do Redis exceder os valores recomendados, recomendamos que você dimensione a instância para um nível de capacidade maior ou siga as instruções de solução de problemas para evitar operações com uso intensivo de CPU.

Se a instância tiver alto uso da CPU ou 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 com uso intensivo de recursos

Recomendamos que você evite usar comandos do Redis 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 Redis está bloqueada
  • Verificações de integridade, observabilidade e replicação esgotadas

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

Categoria Comando com uso intensivo de recursos Alternativa eficiente
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 DEL UNLINK
Publicar e inscrever-se PUBLISH SPUBLISH
SUBSCRIBE SSUBSCRIBE

Práticas recomendadas para clientes do Redis

Esta seção fornece orientações sobre o uso ideal do cliente do Redis.

Detectar e processar conexões sem resposta

Recomendamos configurar o aplicativo cliente para detectar conexões sem resposta ao Memorystore para Redis. 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 parar 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.