Esta página oferece orientações sobre o uso ideal do Memorystore for Redis Cluster. Essa página também indica possíveis problemas que devem ser 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 Redis Cluster funcione com eficiência para seu aplicativo.
Conceitos de gerenciamento de memória
Carga de gravação : o volume e a velocidade com que você adiciona ou atualiza chaves no seu 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
volatile-lrupolítica de remoção. É possível usar comandos como o comando 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, o 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ê espera que o uso de dados aumente, escalonar verticalmente o tamanho do cluster para abrir espaço para novos dados.
Monitorar um cluster com uma carga de gravação alta
Confira a métrica /cluster/memory/maximum_utilization. Dependendo da gravidade da carga de gravação alta, o cluster pode apresentar problemas de desempenho nos seguintes limites:
Cargas de gravação muito altas podem apresentar problemas se
/cluster/memory/maximum_utilizationatingir 65% ou mais.Cargas de gravação moderadamente altas podem apresentar problemas se
/cluster/memory/maximum_utilizationatingir 85% ou mais.
Nesses cenários, aumente o tamanho do cluster para melhorar o desempenho.
Se você tiver problemas ou estiver preocupado com o fato de a instância ter uma carga de gravação alta, entre em contato com o Google Cloud Suporte.
Escalonar fragmentos
Ao escalonar o número de fragmentos em uma instância, faça isso durante períodos de baixa gravação. O escalonamento durante períodos de alta carga de gravação 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 Redis usar remoções de chaves, o escalonamento para um tamanho de cluster menor poderá reduzir a proporção de ocorrências em cache. Nessa circunstância, no entanto, 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, só é possível reduzir o cluster para um tamanho 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, provisione fragmentos suficientes para 1,5 vezes a quantidade de dados no cluster. É possível usar a métrica /cluster/memory/total_used_memory para conferir a quantidade de dados armazenados em
sua instância.
Práticas recomendadas de uso da CPU
Se ocorrer uma interrupção zonal inesperada, isso levará à redução dos recursos de CPU do cluster devido à perda de capacidade dos nós na zona indisponível. Recomendamos o uso de clusters de alta disponibilidade. O uso de várias réplicas por fragmento (em vez de uma réplica por fragmento) oferece 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 /cluster/cpu/maximum_utilization.
Dependendo do número de réplicas provisionadas por nó, recomendamos os seguintes destinos de uso da CPU /cluster/cpu/maximum_utilization:
- Para instâncias com uma réplica por nó, defina um valor
/cluster/cpu/maximum_utilizationde 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ó, defina um valor
/cluster/cpu/maximum_utilizationde 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 a instância, também poderá escalonar verticalmente o número de réplicas, até um máximo de cinco.
Comandos do Redis que consomem muitos recursos
Recomendamos evitar o uso de comandos do Redis que consomem muitos 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 que consomem muitos recursos e oferece alternativas eficientes.
| Categoria | Comando que consome muitos 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
O aplicativo precisa usar um cliente do Redis com reconhecimento de cluster ao se conectar a uma instância do Memorystore for Redis Cluster. 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 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 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 na nova fragmentação 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 tempos limite de forma persistente.Quando um erro
READONLYé recebido do servidor. Isso pode acontecer quando uma instância principal é rebaixada para 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 lidar com conexões com falha durante o tempo de 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 o uso do comando CLUSTER SHARDS. CLUSTER SHARDS substitui o comando CLUSTER SLOTS (descontinuado), fornecendo uma representação mais eficiente e extensível do cluster.
O tamanho da resposta para os comandos de descoberta de cliente de cluster pode variar com base no tamanho e na topologia do cluster. Clusters 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 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 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 do 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 tornar o servidor Redis sem resposta por um período prolongado, causando um uso muito alto 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 desconectar do servidor devido ao tempo limite, tente novamente 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 do cluster. O endpoint de descoberta tem alta disponibilidade e é balanceado por carga em todos os nós do cluster. Além disso, o endpoint de descoberta tenta encaminhar as solicitações de descoberta de cluster 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 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 fazer 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, reduza o tráfego de gravação o máximo possível. Consulte Monitorar um cluster com uma carga de gravação alta para saber mais.
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, desative o recurso de persistência do RDB. Depois de reativar a persistência, um snapshot será feito no próximo intervalo 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 para 3h e o intervalo para 24 horas.
Se o sistema tiver uma carga constante e exigir snapshots frequentes, 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 um cluster de zona única
Se você configurar um cluster para que ele não use réplicas, recomendamos que você use um cluster de zona única. Geralmente, estes são os motivos:
Custo e desempenho
Se a minimização do custo e o desempenho máximo para os clientes localizados na mesma região forem seus principais fatores, recomendamos que você escolha um cluster de zona única.
Minimizar o impacto da interrupção
Ao escolher um cluster de zona única, é menos provável que as interrupções zonais afetem o cluster. 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 o cluster está localizado fique inativa, em vez de uma chance de 100% de que os nós localizados na zona indisponível sejam afetados.
Recuperação rápida
Se ocorrer uma interrupção zonal para um cluster de zona única, o Memorystore for Redis Cluster vai simplificar a recuperação dos dados. É possível provisionar um novo cluster em uma zona funcional rapidamente e redirecionar o aplicativo para operações minimamente interrompidas.
Práticas recomendadas do Lettuce
Esta seção descreve as práticas recomendadas para usar o Lettuce para se conectar a uma instância do Memorystore for Redis 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 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 as chaves e os processos de criptografia.
- Proteção de token de autenticação: se você usar a autenticação do IAM, a ativação do TLS 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 intenso 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á um processo que consome 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 Redis Cluster 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 intenso de CPU que afetam o cliente e o servidor. Isso pode reduzir a capacidade do cluster e aumentar a latência dele.
Recomendações
Ao considerar se você quer 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 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 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 possam não oferecer controles integrados para ativar o TLS, é possível usar um código personalizado para integrar essa funcionalidade aos clusters.