Pilar Eficiência de performance da Lente do Well-Architected para o Amazon ElastiCache - Amazon ElastiCache
EP 1: Como você monitora a performance de um cluster do Amazon ElastiCache?EP 2: Como você está distribuindo o trabalho entre os nós do cluster do ElastiCache?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?EP 6: Como você modela e interage com os dados no ElastiCache? EP 7: Como você registra comandos lentos em log no seu cluster do Amazon ElastiCache?EP 8: Como o ajuste de escala automático ajuda a aumentar a performance do cluster do ElastiCache?

Pilar Eficiência de performance da Lente do Well-Architected para o Amazon ElastiCache

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.

EP 1: Como você monitora a performance de um cluster do Amazon ElastiCache?

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 métricas do CloudWatch enquanto executa esses testes para compreender as métricas disponíveis e estabelecer uma referência de performance.

  • [Ideal] Para workloads do ElastiCache para Valkey e Redis OSS, renomeie os comandos caros do ponto de vista computacional, como KEYS, para limitar a capacidade dos usuários de executar comandos de bloqueio em clusters de produção.

    • As workloads do ElastiCache que executam o mecanismo 6.x para Redis OSS podem aproveitar o controle de acesso baseado em perfil para restringir determinados comandos. O acesso aos comandos pode ser controlado por meio da criação de usuários e grupos de usuários com o Console da AWS ou a CLI, e associando os grupos de usuários a um cluster. No Redis OSS 6, quando o RBAC está habilitado, podemos usar “-@dangerous” para não permitir que determinado usuário execute comandos caros, como KEYS, MONITOR, SORT etc.

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

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

    • Para workloads do ElastiCache para Valkey e Redis OSS, saiba mais sobre suas consultas analisando o log lento. Por exemplo, você pode usar o comando valkey-cli slowlog get 10 para mostrar os últimos 10 comandos que excederam o limite de latência (10 milissegundos por padrão).

    • Certas consultas podem ser realizadas com mais eficiência usando estruturas de dados complexas do ElastiCache para Valkey e Redis OSS. 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 workloads do ElastiCache para Valkey e Redis OSS, redis-benchmark fornece uma interface simples para testar a performance 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]:

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

Introdução: a forma como sua aplicação se conecta aos nós do Amazon ElastiCache pode afetar a performance 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 endpoint adequado do ElastiCache.

    • O ElastiCache para Valkey e Redis OSS implementa diferentes endpoints com base no modo cluster em uso. Com o modo de cluster habilitado, o ElastiCache fornecerá um endpoint de configuração. Com o modo de cluster desabilitado, o ElastiCache fornece um endpoint primário, normalmente usado para gravações, e um endpoint de leitor para balancear as leituras entre as 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 de vários nós do Memcached, o ElastiCache fornece um endpoint de configuração que habilita 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 os clusters habilitados para o modo de cluster do ElastiCache para Valkey e Redis OSS para melhorar a escalabilidade.

    • Os clusters do ElastiCache para Valkey e Redis OSS (com modo de cluster habilitado) oferecem suporte a operações de escalabilidade on-line (aumento/redução da escala horizontal e verticalmente) para ajudar a distribuir os dados dinamicamente entre os 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 rebalancear o cluster movendo hashslots entre os fragmentos disponíveis no cluster do ElastiCache para Valkey e Redis OSS (com o modo de cluster habilitado). 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 dados multidimensionais do Valkey ou Redis OSS, como listas, fluxos, conjuntos etc. Essas estruturas de dados são armazenadas em chaves ú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 workloads do ElastiCache para Valkey e Redis OSS, você poderá detectar chaves “hot” usando valkey-cli --hotkeys se uma política LFU de 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 próprio nó do Valkey ou Redis OSS não fornecerá essa funcionalidade) e mantenha uma lista de nomes de chaves para leitura, além do nome da chave original.

    • O mecanismo do ElastiCache 7.2 para Valkey e posteriores e o ElastiCache versão 6 para Redis OSS e posteriores oferecem suporte ao armazenamento em cache do lado do cliente assistido pelo servidor. Isso permite que as aplicações aguardem alterações em uma chave antes de fazerem chamadas de rede de volta para o ElastiCache.

  • [Recursos]:

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

Introdução: o armazenamento em cache é uma workload comum no ElastiCache e é importante que você entenda como gerenciar a eficácia e a performance do seu 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 a performance do cache da aplicação em conjunto com os valores de latência e utilização da CPU para entender se você precisa fazer ajustes no tempo de vida ou em outros componentes da aplicação. O ElastiCache fornece um conjunto de métricas do CloudWatch para latências agregadas para cada estrutura de dados. Essas métricas de latência são calculadas usando a estatística commandstats do comando INFO e não incluem o tempo de rede e E/S. É apenas o tempo consumido pelo ElastiCache 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: vários clientes de aplicações oferecem suporte ao ElastiCache para Valkey, Memcached e Redis OSS, 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 ao seu cluster do ElastiCache.

    • 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 das conexões no Amazon CloudWatch usando CurrConnections e NewConnections.

    • 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: as workloads têm requisitos e comportamentos esperados diferentes quando um nó de cluster está se aproximando dos limites de consumo de memória. O ElastiCache 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 maxmemory-policy no grupo de parâmetros de cluster.

    • A política padrão volatile-lru libera memória ao remover chaves com um prazo de validade definido (valor de TTL). As políticas menos usadas (LFU) e menos usadas recentemente (LRU) removem as chaves com base no uso.

    • Para workloads do Memcached, existe uma política LRU padrão que controla as remoções em cada nó. O número de remoções em seu cluster do Amazon ElastiCache pode ser monitorado usando a métrica Evictions no 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 workloads do ElastiCache para Valkey e Redis OSS, ao remover explicitamente as chaves do cluster, UNLINK funciona como DEL: 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 workloads do ElastiCache versão 6.x para Redis OSS, o comportamento do comando DEL pode ser modificado no grupo de parâmetros usando o parâmetro lazyfree-lazy-user-del.

  • [Recursos]:

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

Introdução: o ElastiCache depende muito da aplicação das estruturas de dados e do modelo de dados usados, mas também precisa considerar o datastore subjacente (se houver). Entenda as estruturas de dados disponíveis e garanta que você esteja usando as estruturas de dados mais adequadas às suas necessidades.

Benefício: a modelagem de dados no ElastiCache tem várias camadas, incluindo caso de uso de aplicação, tipos de dados e relacionamentos entre elementos de dados. Além disso, cada tipo de dado e comando tem suas próprias assinaturas de performance 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]:

  • [Ideal] Os comandos do ElastiCache para Valkey e Redis OSS têm uma complexidade temporal 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 projeto de thread único do ElastiCache para Valkey e Redis OSS, um grande volume de operações de alta complexidade temporal resultará em menor desempenho e em possíveis tempos esgotados da operação.

    [Recursos]:

  • [Ideal] Use APIs para obter visibilidade da GUI no modelo de dados em seu cluster.

    [Recursos]:

EP 7: Como você registra comandos lentos em log no seu cluster do Amazon ElastiCache?

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 performance ruim, bem como comandos que impedem a performance ideal do mecanismo. O ElastiCache também tem a capacidade de encaminhar essas informações ao Amazon CloudWatch ou ao 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] ElastiCache executando um mecanismo versão 7.2 ou mais recente, ou executando um mecanismo Redis OSS versão 6.0 ou mais recente, grupo de parâmetros configurado corretamente e registro em log SLOWLOG habilitado no cluster.

    • Os parâmetros necessários só estarão disponíveis quando a compatibilidade da versão do mecanismo estiver definida como Valkey 7.2 e posterior, ou Redis OSS versão 6.0 ou posterior.

    • O registro em log SLOWLOG ocorre quando o tempo de execução de um comando pelo servidor é maior 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.

  • [Ideal] Aproveite os recursos do CloudWatch ou do Kinesis Data Firehose.

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

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

    • Determine qual formato atende melhor às suas necessidades, JSON ou texto simples.

    • Forneça permissões do IAM 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 mecanismo Valkey ou Redis OSS antes de ser registrado em log como um comando lento. 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 lentos são capturados na memória do Valkey ou Redis OSS por vez. 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 de valkey-cli por meio do comando SLOWLOG, considere aumentar esse valor. Isso permite que mais comandos permaneçam na memória do Valkey ou Redis OSS.

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

  • [Recursos]:

EP 8: Como o ajuste de escala automático ajuda a aumentar a performance do cluster do ElastiCache?

Introdução: ao implementar o atributo de ajuste de escala automático do Valkey ou Redis OSS, seus componentes do ElastiCache podem se ajustar ao longo do 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: a compreensão e o planejamento dos picos na workload podem garantir melhor performance do cache e a continuidade dos negócios. O ajuste de escala automático do ElastiCache monitora continuamente a utilização da CPU/memória para garantir que seu cluster esteja operando nos níveis de performance desejados.

  • [Obrigatório] Ao iniciar um cluster do ElastiCache para Valkey ou Redis OSS:

    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 métricas correspondentes do CloudWatch para utilização do cluster ao longo de 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]: