Práticas recomendadas do Memorystore for Redis Cluster

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

Observação: para ver exemplos de configuração de cliente do cluster Redis, consulte Exemplos de código da biblioteca de cliente.

Práticas recomendadas de gerenciamento de memória

Esta seção descreve estratégias para gerenciar a memória dos clusters para que o Memorystore para Redis Cluster funcione de maneira eficiente nos seus aplicativos cliente.

Conceitos de gerenciamento de memória

• Gravação de carga: o volume e a velocidade com que você adiciona ou atualiza chaves no cluster do Redis. A carga de gravação pode variar de normal a muito alta, dependendo do caso de uso do Redis e dos padrões de uso do aplicativo.

• Política de remoção: o Memorystore for Redis Cluster usa a política de remoção volatile-lru. Você pode usar comandos como EXPIRE para definir remoções de chaves.

Monitorar um cluster com uma carga de gravação normal

Confira a métrica /cluster/memory/maximum_utilization. Se /cluster/memory/maximum_utilization estiver em 100% ou menos, seu cluster do Redis terá um bom desempenho quando você usar uma carga de gravação normal.

No entanto, se o uso da memória se aproximar de 100% e você esperar que o uso de dados aumente, escalonar verticalmente o tamanho do cluster para abrir espaço para novos dados.

Monitorar um cluster com uma alta carga de gravação

Confira a métrica /cluster/memory/maximum_utilization. Dependendo da gravidade da sua alta carga de gravação, o cluster pode ter problemas de desempenho nos seguintes limites:

• Cargas de gravação muito altas podem ter problemas se /cluster/memory/maximum_utilization atingir 65% ou mais.

• Cargas de gravação moderadamente altas podem ter problemas se /cluster/memory/maximum_utilization atingir 85% ou mais.

Nesses cenários, aumente o tamanho do cluster para melhorar a performance.

Se você tiver problemas ou achar que seu cluster tem uma carga de gravação alta, entre em contato com o suporte doGoogle Cloud .

Escalonar fragmentos

Ao escalonar o número de fragmentos em um cluster, faça isso durante períodos de pouca gravação. O escalonamento durante períodos de alta carga de gravação pode colocar pressão de memória no cluster devido à sobrecarga de memória causada pela replicação ou migração de slots.

Se o caso de uso do Redis usar remoções de chaves, o escalonamento para um tamanho de cluster menor poderá reduzir a proporção de ocorrência em cache. Nesse caso, não é preciso se preocupar com a perda de dados, já que a remoção de chaves é esperada.

Para casos de uso do Redis em que você não quer perder chaves, faça o escalonamento reduzindo para um cluster 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 vezes a quantidade de dados no cluster. Use a métrica /cluster/memory/total_used_memory para saber a quantidade de dados armazenados no cluster.

Práticas recomendadas para uso da CPU

Se ocorrer uma interrupção zonal inesperada, isso vai reduzir os recursos de CPU do cluster devido à perda de capacidade dos nós na zona indisponível. Recomendamos usar clusters de alta disponibilidade. Usar várias réplicas por fragmento (em vez de uma réplica por fragmento) fornece recursos extras de CPU 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 ele tenha sobrecarga suficiente para lidar com o tráfego adicional da capacidade perdida se ocorrer uma interrupção zonal inesperada. Monitore o uso da CPU para primários e réplicas usando a métrica Segundos de CPU da linha de execução principal /cluster/cpu/maximum_utilization.

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

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

Se os valores da métrica excederem essas recomendações, aumente o número de fragmentos no cluster. Se você tiver menos de cinco réplicas para o cluster, também poderá escalonar verticalmente o número de réplicas, até um máximo de cinco.

Se o cluster tiver alta utilização da CPU ou os recursos dele se esgotarem (por exemplo, por ter muitas conexões), o cluster poderá apresentar um comportamento inadequado e as métricas externas poderão estar ausentes.

Comandos do Redis com uso intensivo de recursos

Recomendamos evitar o uso de comandos do Redis que exigem muitos recursos. O uso desses comandos pode resultar nos seguintes problemas de desempenho:

• Alta latência e tempos limite do cliente
• Pressão na 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 insuficientes

A tabela a seguir lista exemplos de comandos do Redis que consomem muitos recursos e oferece alternativas eficientes.

Dica: além de serem pesados para os recursos, à medida que o tamanho total dos dados aumenta, o custo de usar esses comandos também aumenta.

Para saber 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ê conhece os comandos que causam problemas de latência. Para determinar alternativas eficientes em termos de recursos para esses comandos, consulte a tabela a seguir.

Categoria	Comando que usa muitos recursos	Alternativa eficiente em 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 em uma consulta.
	ZRANGE	Limite o tamanho do intervalo usado em 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 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 utilização de memória
• Escalonamento para uso da CPU
• Escalonamento para reduzir pontos de acesso

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

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

Escalonamento da utilização de memória

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

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

• A utilização média de memória do cluster excede o limite sugerido de 70%.
• A utilização máxima da memória excede 80% e a utilização média excede 50%.

Se o cluster atender a uma das seguintes condições, considere acionar uma operação de redução de escalonamento:

• A utilização média de memória do cluster cai abaixo do limite sugerido de 50%.
• A utilização máxima da memória cai abaixo de 60% e a utilização média cai abaixo de 40%.

Escalonamento do uso da CPU

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

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

• O uso médio da CPU do cluster excede o limite sugerido de 70%.
• A utilização máxima da CPU excede 80% e a utilização média excede 50%.

Se o cluster atender a uma das seguintes condições, considere acionar uma operação de redução de escalonamento:

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

Escalonamento para reduzir pontos de acesso

O Memorystore para Redis Cluster oferece 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ó do cluster mais carregado, enquanto o valor médio representa a carga de todo o cluster. Se o valor máximo for significativamente maior que o valor médio, isso indica que um nó específico está carregado de forma desproporcional (um ponto de acesso). Para resolver esse problema, recomendamos escalonar horizontalmente seu cluster. Para mais informações, consulte Escalonar a capacidade da instância.

Quando você observa uma divergência significativa entre as variações média e máxima, é possível executar os comandos INFO memory e INFO cpu nos nós do cluster para coletar dados em tempo real diretamente do cluster. Para mais informações sobre como usar esses comandos, consulte INFO na documentação do Redis.

Práticas recomendadas para clientes Redis

Seu aplicativo precisa usar um cliente do Redis compatível com cluster ao se conectar a um cluster. Para exemplos de clientes compatíveis com clusters 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 no cluster para enviar solicitações aos nós certos e evitar a sobrecarga de desempenho causada por redirecionamentos de cluster.

Mapeamento de clientes

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

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

• Quando um redirecionamento MOVED é recebido do servidor, como em uma situação de failover em que todos os slots atendidos pelo nó primário anterior são assumidos pela réplica ou em um refragmentação em que os slots estão sendo movidos do primário de origem para o nó primário de destino.

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

• Quando um erro READONLY é recebido do servidor. Isso pode acontecer quando um primário é rebaixado para réplica.

• Além disso, os clientes precisam atualizar periodicamente a topologia para manter os clientes preparados para mudanças 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. As conexões desatualizadas também precisam 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 de clientes geralmente é feita emitindo um comando CLUSTER SLOT, CLUSTER NODE ou CLUSTER SHARDS para o servidor Redis. Recomendamos usar o comando CLUSTER SHARDS. CLUSTER SHARDS substitui o comando CLUSTER SLOTS (descontinuado) ao fornecer uma representação mais eficiente e extensível do cluster.

O tamanho da resposta para os comandos de descoberta de clientes do cluster pode variar com base no tamanho e na topologia do cluster. Clusters maiores com mais nós geram uma resposta maior. Por isso, é importante garantir que o número de clientes que fazem a descoberta da topologia do cluster não cresça sem limites.

Essas atualizações de topologia são caras no servidor Redis, 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 em cache o resultado na memória) e que o número de clientes que fazem as solicitações seja limitado para evitar sobrecarga no servidor.

Por exemplo, quando o aplicativo cliente é iniciado ou perde a conexão com o servidor e precisa realizar a descoberta de cluster, 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 deixar o servidor Redis sem resposta por um longo período, causando uma utilização muito alta da CPU.

Evitar sobrecarga de descoberta no Redis

Para reduzir o impacto causado por um fluxo repentino de solicitações de conexão e descoberta, 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 a um tempo limite, tente de novo com espera exponencial com jitter. Isso ajuda a evitar que vários clientes sobrecarreguem o servidor ao mesmo tempo.

• Use o endpoint de descoberta do Memorystore for Redis Cluster para realizar a descoberta de clusters. O endpoint de descoberta tem alta disponibilidade e balanceamento de carga em todos os nós do cluster. Além disso, o endpoint de descoberta tenta rotear as solicitações de descoberta de cluster para nós com a visualização de topologia mais atualizada.

Detectar e processar conexões que não respondem

Recomendamos configurar o aplicativo cliente para detectar conexões sem resposta com o cluster do 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 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 proativamente conexões sem resposta, mesmo quando elas 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 ociosas sem resposta em um minuto.
• Configure tempos limite de usuário TCP: defina esse tempo limite nos clientes para redefinir conexões com 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.

Práticas recomendadas de persistência

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

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

Para ter os melhores resultados ao fazer backup do cluster com snapshots de RDB ou adicionar réplicas a ele, 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 criar um snapshot dos dados do nó. Dependendo do padrão de gravações nos nós, a memória usada deles aumenta à medida que as páginas afetadas 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 sobrecarga. Essa sobrecarga de memória, além de monitorar snapshots, ajuda você a gerenciar sua 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. Consulte Monitorar um cluster com uma alta carga de gravação para saber mais.

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

Para resolver esse problema, reduza o uso da memória do cluster de uma das seguintes maneiras:

• Reduza o consumo de memória do cluster para menos de 80% da memória máxima permitida do nó.
• Escalone o tipo de nó do cluster para que ele tenha mais memória.

Depois que o uso da memória do cluster ficar 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 programado.

Impacto no desempenho dos snapshots do RDB

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

Por exemplo, se o tráfego do cluster for baixo 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, avalie com cuidado o impacto na performance e pondere os benefícios de usar snapshots do 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 RDB, consulte Gerenciamento de memória.

Quando usar um cluster de zona única

Se você configurar um cluster para não usar réplicas, recomendamos usar um cluster de zona única. Geralmente, estes são os motivos:

Custo e performance

Se o principal objetivo for minimizar o custo e ter o melhor desempenho para os clientes localizados na mesma região, recomendamos escolher um cluster de zona única.

Minimizar o impacto de uma interrupção

Quando você escolhe um cluster de zona única, é menos provável que interrupções zonais afetem seu cluster. 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 o cluster está localizado 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 do serviço zonal em um cluster de zona única, o Memorystore para Redis Cluster simplifica a recuperação dos seus dados. É possível provisionar um novo cluster em uma zona funcional rapidamente e redirecionar o aplicativo para operações com interrupção mínima.

Práticas recomendadas para o Lettuce

Nesta seção, descrevemos as práticas recomendadas para usar o Lettuce para se conectar a um cluster.

Atualizar valores de parâmetro

Ao usar o Lettuce, mude o parâmetro validateClusterNodeMembership para false. Caso contrário, quando a topologia mudar, você poderá receber erros unknownPartition.

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 de interceptação.
• Criptografia em trânsito: a criptografia integrada doGoogle Cloudprotege o tráfego na rede do Google em nível de infraestrutura. No entanto, isso envolve confiar no host e nas pilhas 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ê usa a autenticação do IAM, ativar o TLS minimiza 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 intenso de recursos para estabelecer a conexão entre eles. 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 será intensivo em recursos. Para conexões novas e atuais, muitas conexões entre o cliente e o servidor podem causar tempos limite de conexão. Isso pode causar um efeito bola de neve porque o Memorystore para Redis Cluster tenta restabelecer conexões com tempo esgotado, 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 exigem muito da CPU e afetam o cliente e o servidor. Isso pode reduzir a capacidade e aumentar a latência do cluster.

Recomendações

Ao considerar se deve ativar o TLS, recomendamos que você avalie suas políticas de segurança e os benefícios e desvantagens do TLS. Se você ativar o TLS, considere o seguinte:

• A ativação da retomada do TLS reduz a sobrecarga do estabelecimento de 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 do cluster 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 código personalizado para integrar essa funcionalidade aos clusters.