Pilar de ElastiCache eficiência de desempenho da lente Amazon Well-Architected - Amazon ElastiCache (RedisOSS)
PE 1: Como você monitora o desempenho do seu ElastiCache cluster Amazon?PE 2: Como você está distribuindo o trabalho entre os nós ElastiCache do cluster?EP 3: Para workloads de armazenamento em cache, como você monitora e relata a eficácia e a performance do cache? EP 4: Como sua workload otimiza o uso de recursos e conexões de rede?EP 5: Como você gerencia a exclusão e/ou remoção de chaves?PE 6: Como você modela e interage com os dados ElastiCache? PE 7: Como você registra comandos de execução lenta no seu ElastiCache cluster da Amazon?PE8: Como o Auto Scaling ajuda a aumentar o desempenho do ElastiCache cluster?

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Pilar de ElastiCache eficiência de desempenho da lente Amazon Well-Architected

O pilar Eficiência de performance enfoca o uso eficiente dos recursos de TI e computação. Os principais tópicos incluem a seleção dos tipos e tamanhos certos de recursos com base nos requisitos da workload, o monitoramento da performance e a tomada de decisões informadas para manter a eficiência à medida que as necessidades dos negócios evoluem.

PE 1: Como você monitora o desempenho do seu ElastiCache cluster Amazon?

Introdução: ao entender as métricas de monitoramento existentes, você pode identificar a utilização atual. O monitoramento adequado pode ajudar a identificar possíveis gargalos que afetam a performance de um cluster.

Benefício: a compreensão das métricas associadas ao seu cluster pode ajudar a orientar técnicas de otimização que podem levar à redução da latência e ao aumento do throughput.

  • [Obrigatório] Teste de referência da performance usando um subconjunto da workload.

    • Você deve monitorar a performance da workload real usando mecanismos, como testes de carga.

    • Monitore as CloudWatch métricas durante a execução desses testes para obter uma compreensão das métricas disponíveis e estabelecer uma linha de base de desempenho.

  • [Melhor] Para cargas de trabalho ElastiCache (RedisOSS), renomeie comandos computacionalmente caros, como, por exemploKEYS, para limitar a capacidade dos usuários de executar comandos de bloqueio em clusters de produção.

    • ElastiCache As cargas de trabalho (RedisOSS) que executam o mecanismo 6.x podem aproveitar o controle de acesso baseado em funções para restringir determinados comandos. O acesso aos comandos pode ser controlado criando usuários e grupos de usuários com o AWS console ou CLI associando os grupos de usuários a um cluster ElastiCache (RedisOSS). No Redis OSS 6, quando RBAC ativado, podemos usar “- @dangerous" e ele não permitirá comandos caros comoKEYS,, MONITORSORT, etc. para esse usuário.

    • Para a versão 5.x do mecanismo, renomeie os comandos usando o rename-commands parâmetro no grupo de parâmetros do cluster ElastiCache (RedisOSS).

  • [Melhor] Analise consultas lentas e procure técnicas de otimização.

    • Para cargas de trabalho ElastiCache (RedisOSS), saiba mais sobre suas consultas analisando o Slow Log. Por exemplo, você pode usar o comando redis-cli slowlog get 10 para mostrar os últimos 10 comandos que excederam o limite de latência (10 segundos por padrão).

    • Certas consultas podem ser realizadas com mais eficiência usando estruturas de dados complexas ElastiCache (RedisOSS). Como exemplo, para pesquisas de intervalo de estilo numérico, uma aplicação pode implementar índices numéricos simples com conjuntos ordenados. O gerenciamento desses índices pode reduzir as verificações realizadas no conjunto de dados e retornar dados com maior eficiência de performance.

    • Para cargas de trabalho ElastiCache (RedisOSS), redis-benchmark fornece uma interface simples para testar o desempenho de diferentes comandos usando entradas definidas pelo usuário, como número de clientes e tamanho dos dados.

    • Como o Memcached só oferece suporte a comandos simples em nível de chave, considere criar chaves adicionais como índices para evitar a iteração no espaço de chaves a fim de atender às consultas do cliente.

  • [Recursos]:

PE 2: Como você está distribuindo o trabalho entre os nós ElastiCache do cluster?

Introdução em nível de pergunta: A forma como seu aplicativo se conecta aos ElastiCache nós da Amazon pode afetar o desempenho e a escalabilidade do cluster.

Benefício: o uso adequado dos nós disponíveis no cluster garantirá que o trabalho seja distribuído entre os recursos disponíveis. As técnicas a seguir também ajudam a evitar recursos ociosos.

  • [Obrigatório] Faça com que os clientes se conectem ao ElastiCache endpoint adequado.

    • ElastiCache (RedisOSS) implementa endpoints diferentes com base no modo de cluster em uso. Para o modo de cluster ativado, ElastiCache fornecerá um endpoint de configuração. Para o modo de cluster desativado, ElastiCache fornece um endpoint primário, normalmente usado para gravações, e um endpoint de leitura para balancear leituras entre réplicas. A implementação correta desses endpoints resultará em melhor performance e operações de escalabilidade mais fáceis. Evite conectar-se a endpoints de nós individuais, a menos que haja um requisito específico que justifique isso.

    • Para clusters Memcached de vários nós, ElastiCache fornece um endpoint de configuração que permite a descoberta automática. É recomendável usar um algoritmo de hash para distribuir o trabalho uniformemente entre os nós de cache. Muitas bibliotecas de clientes do Memcached implementam hash consistente. Verifique a documentação da biblioteca que você está usando para ver se ela oferece suporte para hashing consistente e como implementá-lo. Você pode encontrar mais informações sobre a implementação desses atributos aqui.

  • [Melhor] Aproveite as vantagens do modo de cluster ElastiCache (RedisOSS) ativado para melhorar a escalabilidade.

    • ElastiCache Os clusters (RedisOSS) (modo de cluster ativado) oferecem suporte a operações de escalabilidade on-line (entrada/saída e cima/redução) para ajudar a distribuir dados dinamicamente entre fragmentos. O uso do endpoint de configuração vai garantir que os clientes com reconhecimento de cluster possam se ajustar às mudanças na topologia do cluster.

    • Você também pode reequilibrar o cluster movendo os hashslots entre os fragmentos disponíveis no seu cluster ElastiCache (RedisOSS) (modo de cluster ativado). Isso ajuda a distribuir o trabalho de modo mais eficiente entre os fragmentos disponíveis.

  • [Melhor] Implemente uma estratégia para identificar e corrigir chaves “hot” na workload.

    • Considere o impacto das estruturas de OSS dados multidimensionais do Redis, como listas, fluxos, conjuntos etc. Essas estruturas de dados são armazenadas em OSS chaves Redis únicas, que residem em um único nó. Uma chave multidimensional muito grande tem o potencial de utilizar mais capacidade de rede e memória do que outros tipos de dados e pode provocar um uso desproporcional desse nó. Se possível, projete sua workload para distribuir o acesso aos dados entre várias chaves distintas.

    • As chaves “hot” na workload podem afetar a performance do nó em uso. Para cargas de trabalho ElastiCache (RedisOSS), você pode detectar teclas de atalho usando redis-cli --hotkeys se uma política de LFU memória máxima estiver em vigor.

    • Considere replicar chaves “hot” entre vários nós para distribuir o acesso a eles de forma mais uniforme. Essa abordagem exige que o cliente grave em vários nós primários (o OSS nó Redis em si não fornecerá essa funcionalidade) e mantenha uma lista de nomes de chave para leitura, além do nome da chave original.

    • EElastiCache(RedisOSS) a versão 6 oferece suporte ao cache do lado do cliente assistido pelo servidor. Isso permite que os aplicativos aguardem alterações em uma chave antes de fazer chamadas de rede de volta paraElastiCache.

  • [Recursos]:

EP 3: Para workloads de armazenamento em cache, como você monitora e relata a eficácia e a performance do cache?

Introdução em nível de pergunta: O armazenamento em cache é uma carga de trabalho comum ElastiCache e é importante que você entenda como gerenciar a eficácia e o desempenho do cache.

Benefício: sua aplicação pode mostrar sinais de performance lenta. Sua capacidade de usar métricas específicas de cache para informar sua decisão sobre como aumentar a performance da aplicação é essencial para sua workload de cache.

  • [Obrigatório] Meça e acompanhe a taxa de acertos de cache ao longo do tempo. A eficiência do seu cache é determinada pela “taxa de acertos de cache”. A taxa de acertos de cache é definida pelo total de acertos de chave dividido pelo total de acertos e erros. Quanto mais próxima de 1 for a taxa, mais eficaz será o cache. Uma taxa de acertos de cache baixa é decorrente do volume de erros de cache. Os erros de cache ocorrem quando a chave solicitada não é encontrada no cache. Uma chave não está no cache porque ela foi removida ou excluída, expirou ou nunca existiu. Entenda por que as chaves não estão no cache e desenvolva estratégias apropriadas para incluí-las no cache.

    [Recursos]:

  • [Obrigatório] Meça e colete o desempenho do cache do aplicativo em conjunto com os valores de latência e CPU utilização para entender se você precisa fazer ajustes no seu time-to-live ou em outros componentes do aplicativo. ElastiCache fornece um conjunto de CloudWatch métricas para latências agregadas para cada estrutura de dados. Essas métricas de latência são calculadas usando a estatística commandstats do INFO comando ElastiCache (RedisOSS) e não incluem a rede e o tempo de E/S. Esse é apenas o tempo consumido pelo ElastiCache (RedisOSS) para processar as operações.

    [Recursos]:

  • [Ideal] Escolha a estratégia de cache certa para suas necessidades. Uma taxa de acertos de cache baixa é decorrente do volume de erros de cache. Se sua workload foi projetada para ter um baixo volume de erros de cache (como comunicação em tempo real), é melhor realizar análises de suas estratégias de armazenamento em cache e aplicar as resoluções mais apropriadas para sua workload, como instrumentação de consulta para medir a memória e a performance. As estratégias implementadas para preencher e manter seu cache dependem de quais dados seus clientes precisam armazenar em cache e dos padrões de acesso a esses dados. Por exemplo, é improvável que você use a mesma estratégia para recomendações personalizadas em uma aplicação de streaming e para notícias em alta.

    [Recursos]:

EP 4: Como sua workload otimiza o uso de recursos e conexões de rede?

Introdução em nível de pergunta: ElastiCache (RedisOSS) e ElastiCache (Memcached) são compatíveis com muitos clientes de aplicativos, e as implementações podem variar. Você precisa entender o gerenciamento de redes e conexões em vigor para analisar o impacto potencial na performance.

Benefício: o uso eficiente dos recursos de rede pode melhorar a eficiência da performance do seu cluster. As recomendações a seguir podem reduzir as demandas de rede e melhorar a latência e o throughput do cluster.

  • [Obrigatório] Gerencie proativamente as conexões com seu ElastiCache cluster.

    • O agrupamento de conexões na aplicação reduz a sobrecarga criada no cluster devido à abertura e ao encerramento de conexões. Monitore o comportamento da conexão na Amazon CloudWatch usando CurrConnections NewConnections e.

    • Evite a fuga de conexões ao encerrar adequadamente as conexões de clientes, quando apropriado. As estratégias de gerenciamento de conexões incluem o encerramento adequado das conexões que não estão em uso e a definição de tempo limite para conexões.

    • Para workloads do Memcached, há uma quantidade configurável de memória reservada para lidar com conexões chamada memcached_connections_overhead.

  • [Melhor] Compacte objetos grandes para reduzir a memória e melhorar o throughput da rede.

    • A compactação de dados pode reduzir a quantidade necessária de throughput de rede (Gbps), mas aumenta a quantidade de trabalho na aplicação para compactar e descompactar dados.

    • A compactação também reduz a quantidade de memória consumida pelas chaves.

    • Com base nas necessidades da sua aplicação, considere as diferenças entre taxa de compressão e velocidade de compressão.

  • [Recursos]:

EP 5: Como você gerencia a exclusão e/ou remoção de chaves?

Introdução em nível de pergunta: as cargas de trabalho têm requisitos e comportamentos esperados diferentes quando um nó de cluster está se aproximando dos limites de consumo de memória. ElastiCache (RedisOSS) tem políticas diferentes para lidar com essas situações.

Benefício: o gerenciamento adequado da memória disponível e a compreensão das políticas de remoção vão ajudar a garantir o conhecimento do comportamento do cluster quando os limites de memória da instância forem excedidos.

  • [Obrigatório] Instrumente o acesso aos dados para avaliar qual política aplicar. Identifique uma política de memória máxima apropriada para controlar se e como as remoções são realizadas no cluster.

    • A remoção ocorre quando a memória máxima do cluster é consumida e há uma política em vigor para permitir a remoção. O comportamento do cluster nessa situação depende da política de remoção especificada. Essa política pode ser gerenciada usando o grupo de parâmetros do cluster maxmemory-policy no ElastiCache (RedisOSS).

    • A política padrão volatile-lru libera memória ao despejar chaves com um tempo de expiração (TTLvalor) definido. As políticas usadas com menos frequência (LFU) e usadas menos recentemente (LRU) removem as chaves com base no uso.

    • Para cargas de trabalho do Memcached, existe uma LRU política padrão que controla os despejos em cada nó. O número de despejos em seu ElastiCache cluster da Amazon pode ser monitorado usando a métrica de despejos na Amazon. CloudWatch

  • [Melhor] Padronize o comportamento de exclusão para controlar o impacto na performance de seu cluster e evitar gargalos de performance inesperados.

    • Para cargas de trabalho ElastiCache (RedisOSS), ao remover explicitamente as chaves do cluster, UNLINK é comoDEL: ele remove as chaves especificadas. No entanto, o comando executa a recuperação real da memória em um thread diferente, portanto não bloqueio, enquanto DEL bloqueia. A remoção real ocorrerá posteriormente de forma assíncrona.

    • Para cargas de trabalho ElastiCache (RedisOSS) 6.x, o comportamento do DEL comando pode ser modificado no grupo de parâmetros usando o parâmetro. lazyfree-lazy-user-del

  • [Recursos]:

PE 6: Como você modela e interage com os dados ElastiCache?

Introdução em nível de pergunta: ElastiCache depende muito do aplicativo das estruturas de dados e do modelo de dados usados, mas também precisa considerar o armazenamento de dados subjacente (se presente). Entenda as estruturas de dados ElastiCache (RedisOSS) disponíveis e garanta que você esteja usando as estruturas de dados mais adequadas às suas necessidades.

Benefício em nível de pergunta: a modelagem de dados ElastiCache tem várias camadas, incluindo casos de uso de aplicativos, tipos de dados e relacionamentos entre elementos de dados. Além disso, cada tipo de dados e comando ElastiCache (RedisOSS) tem suas próprias assinaturas de desempenho bem documentadas.

  • [Ideal] Uma das práticas recomendadas é reduzir a substituição não intencional de dados. Use uma convenção de nomenclatura que minimize a sobreposição de nomes de chave. A nomenclatura convencional de suas estruturas de dados usa um método hierárquico, como APPNAME:CONTEXT:ID e ORDER-APP:CUSTOMER:123.

    [Recursos]:

  • Os comandos [Best] ElastiCache (RedisOSS) têm uma complexidade de tempo definida pela notação Big O. Essa complexidade temporal de um comando é uma representação algorítmica/matemática de seu impacto. Ao introduzir um novo tipo de dado em sua aplicação, você precisa analisar cuidadosamente a complexidade temporal dos comandos relacionados. Os comandos com uma complexidade temporal de O(1) são constantes no tempo e não dependem do tamanho da entrada, enquanto os comandos com uma complexidade temporal de O(N) são lineares no tempo e estão sujeitos ao tamanho da entrada. Devido ao design de thread único do ElastiCache (RedisOSS), um grande volume de operações de alta complexidade de tempo resultará em menor desempenho e em possíveis tempos limite de operação.

    [Recursos]:

  • [Melhor] Use APIs para obter GUI visibilidade do modelo de dados em seu cluster.

    [Recursos]:

PE 7: Como você registra comandos de execução lenta no seu ElastiCache cluster da Amazon?

Introdução: benefícios do ajuste de performance por meio da captura, agregação e notificação de comandos de longa execução. Ao entender quanto tempo leva para que os comandos sejam executados, você pode determinar quais comandos resultam em baixo desempenho, bem como os comandos que impedem o desempenho ideal do mecanismo. ElastiCache (RedisOSS) também tem a capacidade de encaminhar essas informações para a Amazon CloudWatch ou o Amazon Kinesis Data Firehose.

Benefício: manter um log em um local permanente dedicado e fornecer eventos de notificação para comandos lentos podem ajudar na análise detalhada da performance e podem servir para acionar eventos automatizados.

  • [Obrigatório] Amazon ElastiCache (RedisOSS) executando a versão 6.0 do mecanismo ou mais recente, grupo de parâmetros configurado corretamente e SLOWLOG registro habilitado no cluster.

    • Os parâmetros necessários só estão disponíveis quando a compatibilidade da versão do mecanismo está definida para a OSS versão 6.0 ou superior do Redis.

    • SLOWLOGo registro ocorre quando o tempo de execução de um comando no servidor demora mais do que um valor especificado. O comportamento do cluster depende dos parâmetros do grupo de parâmetros associado, que são slowlog-log-slower-than e slowlog-max-len.

    • As alterações terão efeito imediatamente.

  • [Melhor] Aproveite nossos recursos do CloudWatch Kinesis Data Firehose.

    • Use os recursos de filtragem e alarme do CloudWatch CloudWatch Logs Insights e do Amazon Simple Notification Services para obter monitoramento de desempenho e notificação de eventos.

    • Use os recursos de streaming do Kinesis Data Firehose SLOWLOG para arquivar registros em armazenamento permanente ou para acionar o ajuste automático dos parâmetros do cluster.

    • Determine JSON se o TEXT formato simples atende melhor às suas necessidades.

    • Forneça IAM permissões para publicar no CloudWatch ou no Kinesis Data Firehose.

  • [Melhor] Configure slowlog-log-slower-than com um valor diferente do padrão.

    • Esse parâmetro determina por quanto tempo um comando pode ser executado no OSS mecanismo do Redis antes de ser registrado como um comando de execução lenta. O valor padrão é 10.000 microssegundos (10 milissegundos). O valor padrão pode ser muito alto para algumas workloads.

    • Determine um valor que seja mais adequado para sua workload com base nas necessidades da aplicação e nos resultados dos testes, mas lembre-se de que um valor muito baixo pode gerar dados em excesso.

  • [Melhor] Mantenha o valor padrão de slowlog-max-len.

    • Esse parâmetro determina o limite superior de quantos comandos de execução lenta são capturados na OSS memória do Redis a qualquer momento. O valor 0 desabilita a captura. Quanto maior o valor, mais entradas serão armazenadas na memória, reduzindo a chance de informações importantes serem removidas antes que possam ser revisadas. O valor padrão é 128.

    • O valor padrão é adequado para a maioria das workloads. Se houver necessidade de analisar dados em uma janela de tempo expandida a partir do redis-cli por meio do SLOWLOG comando, considere aumentar esse valor. Isso permite que mais comandos permaneçam na OSS memória do Redis.

      Se você estiver emitindo SLOWLOG os dados para o CloudWatch Logs ou para o Kinesis Data Firehose, os dados persistirão e poderão ser analisados fora do sistema, reduzindo ElastiCache a necessidade de armazenar um grande número de comandos de execução lenta na memória do Redis. OSS

  • [Recursos]:

PE8: Como o Auto Scaling ajuda a aumentar o desempenho do ElastiCache cluster?

Introdução em nível de pergunta: ao implementar o recurso de escalonamento OSS automático do Redis, ElastiCache seus componentes podem se ajustar com o tempo para aumentar ou diminuir automaticamente os fragmentos ou réplicas desejados. Isso pode ser feito implementando a política de rastreamento de metas ou de ajuste de escala programado.

Benefício em nível de pergunta: compreender e planejar os picos na carga de trabalho pode garantir um desempenho aprimorado do armazenamento em cache e a continuidade dos negócios. ElastiCache (RedisOSS) O Auto Scaling monitora continuamente CPU sua utilização de /Memória para garantir que seu cluster esteja operando nos níveis de desempenho desejados.

  • [Obrigatório] Ao iniciar um cluster para ElastiCache (RedisOSS):

    1. Verifique se o modo de cluster está habilitado.

    2. Verifique se a instância pertence a uma família de determinado tipo e tamanho compatíveis com o ajuste de escala automático.

    3. Verifique se o cluster não está sendo executado em datastores globais, Outposts ou zonas locais.

    [Recursos]:

  • [Ideal] Identifique se sua workload exige muita leitura ou gravação para definir a política de ajuste de escala. Para obter a melhor performance, use apenas uma métrica de rastreamento. É recomendável evitar várias políticas para cada dimensão, pois as políticas de ajuste de escala automático aumentam a escala horizontalmente quando a meta é atingida, mas só aumentam a escala verticalmente quando todas as políticas de rastreamento de metas estiverem prontas para aumentar a escala verticalmente.

    [Recursos]:

  • [Ideal] O monitoramento da performance ao longo do tempo pode ajudar você a detectar mudanças na workload que passariam despercebidas se monitoradas em momentos específicos. Você pode analisar as CloudWatch métricas correspondentes para a utilização do cluster em um período de quatro semanas para determinar o limite do valor-alvo. Se você ainda não tiver certeza de qual valor escolher, recomendamos começar com o valor mínimo de métrica predefinido compatível.

    [Recursos]:

  • [Melhor] Recomendamos testar sua aplicação com as workloads mínimas e máximas esperadas, para identificar o número exato de fragmentos/réplicas necessários para que o cluster desenvolva políticas de ajuste de escala e reduza os problemas de disponibilidade.

    [Recursos]: