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á.
Etapas comuns de solução de problemas e melhores práticas com ElastiCache
Os tópicos a seguir fornecem dicas de solução de problemas para erros e problemas que você pode encontrar ao usar ElastiCache. Se encontrar um problema que não esteja listado aqui, você poderá usar o botão de feedback desta página para relatá-lo.
Para obter mais orientações sobre solução de problemas e respostas a perguntas comuns de suporte, acesse a Central de Conhecimento da AWS
Tópicos
Problemas de conexão
Se você não conseguir se conectar ao ElastiCache cache, considere uma das seguintes opções:
Usando o TLS: se você estiver com uma conexão interrompida ao tentar se conectar ao seu ElastiCache endpoint, talvez não esteja usando o TLS no seu cliente. Se você estiver usando o ElastiCache Serverless, a criptografia em trânsito estará sempre ativada. Certifique-se de que seu cliente esteja usando o TLS para se conectar ao cache. Saiba mais sobre como se conectar a um cache habilitado para TLS.
VPC: ElastiCache os caches só podem ser acessados de dentro de uma VPC. Certifique-se de que a EC2 instância a partir da qual você está acessando o cache e o ElastiCache cache sejam criados na mesma VPC. Como alternativa, você deve ativar o emparelhamento de VPC entre a VPC em que sua instância EC2 reside e a VPC em que você está criando seu cache.
Grupos de segurança: ElastiCache usa grupos de segurança para controlar o acesso ao seu cache. Considere o seguinte:
Certifique-se de que o grupo de segurança usado pelo seu ElastiCache cache permita acesso de entrada a ele a partir da sua EC2 instância. Veja aqui para saber como configurar corretamente as regras de entrada em seu grupo de segurança.
Certifique-se de que o grupo de segurança usado pelo ElastiCache cache permita o acesso às portas do cache (6379 e 6380 para servidores sem servidor e 6379, por padrão, para projetos próprios). ElastiCache usa essas portas para aceitar comandos Valkey ou Redis OSS. Saiba mais sobre como configurar o acesso à porta aqui.
Se a conexão continuar sendo difícil, consulte Problemas de conexão persistentes para outras etapas.
Erros do cliente Valkey ou Redis OSS
ElastiCache O Serverless só pode ser acessado usando clientes que oferecem suporte ao protocolo de modo de cluster Valkey ou Redis OSS. Clusters autoprojetados podem ser acessados de clientes em qualquer um dos modos, dependendo da configuração do cluster.
Se você estiver enfrentando erros no seu cliente, considere o seguinte:
Modo de cluster: se você estiver enfrentando erros de CROSSLOT ou erros com o comando SELECT
, talvez esteja tentando acessar um cache habilitado para o modo de cluster com um cliente Valkey ou Redis OSS que não suporta o protocolo Cluster. ElastiCache O Serverless só oferece suporte a clientes que oferecem suporte ao protocolo de cluster Valkey ou Redis OSS. Se você quiser usar o Valkey ou Redis OSS no “Modo de cluster desabilitado” (CMD), será necessário criar seu próprio cluster. Erros de CROSSLOT: Se você estiver enfrentando o erro
ERR CROSSLOT Keys in request don't hash to the same slot, talvez esteja tentando acessar chaves que não pertencem ao mesmo slot em um cache do modo de cluster. Como lembrete, o ElastiCache Serverless sempre opera no Modo Cluster. Operações com várias chaves, transações ou scripts Lua envolvendo várias chaves são permitidos somente se todas as chaves envolvidas estiverem no mesmo slot de hash.
Para obter mais práticas recomendadas sobre a configuração de clientes Valkey ou Redis OSS, consulte esta postagem no blog
Solução de problemas de alta latência no Serverless ElastiCache
Se sua carga de trabalho parecer estar com alta latência, você pode analisar as SuccessfulWriteRequestLatency métricas CloudWatch SuccessfulReadRequestLatency e para verificar se a latência está relacionada ao Serverless. ElastiCache Essas métricas medem a latência interna ao ElastiCache Serverless - a latência do lado do cliente e os tempos de viagem da rede entre seu cliente e o endpoint ElastiCache Serverless não estão incluídos.
Solução de problemas de latência do lado do cliente
Se você notar uma latência elevada no lado do cliente, mas nenhum aumento correspondente nas CloudWatch SuccessfulReadRequestLatency SuccessfulWriteRequestLatency métricas que medem a latência do lado do servidor, considere o seguinte:
Verifique se o grupo de segurança permite acesso às portas 6379 e 6380: o ElastiCache Serverless usa a porta 6379 para o endpoint primário e a porta 6380 para o endpoint do leitor. Alguns clientes estabelecem conectividade com as duas portas para cada nova conexão, mesmo que seu aplicativo não esteja usando o recurso Ler da réplica. Se o grupo de segurança não permitir acesso de entrada às duas portas, o estabelecimento da conexão poderá levar mais tempo. Saiba mais sobre como configurar o acesso à porta aqui.
Solução de problemas de latência do lado do servidor
Alguma variabilidade e picos ocasionais não devem ser motivo de preocupação. No entanto, se a Average estatística mostrar um aumento acentuado e persistir, você deve verificar o Personal Health Dashboard AWS Health Dashboard e o Personal Health Dashboard para obter mais informações. Se necessário, considere abrir um caso de suporte com Suporte.
Considere as seguintes práticas recomendadas e estratégias para reduzir a latência:
Habilitar leitura da réplica: se seu aplicativo permitir essa opção, recomendamos habilitar o recurso “Ler da réplica” em seu cliente Valkey ou Redis OSS para escalar as leituras e obter menor latência. Quando ativado, o ElastiCache Serverless tenta rotear suas solicitações de leitura para nós de cache de réplica que estão na mesma zona de disponibilidade (AZ) do seu cliente, evitando assim a latência de rede entre AZ. Observe que, ao ativar o recurso Ler da réplica em seu cliente, seu aplicativo aceitará uma eventual consistência nos dados. Seu aplicativo talvez receba dados mais antigos por algum tempo se você tentar ler depois de gravar em uma chave.
Certifique-se de que seu aplicativo seja implantado da AZs mesma forma que seu cache: você pode observar uma maior latência do lado do cliente se seu aplicativo não for implantado da AZs mesma forma que seu cache. Ao criar um cache sem servidor, você pode fornecer as sub-redes de onde seu aplicativo acessará o cache, e o Serverless ElastiCache cria VPC Endpoints nessas sub-redes. Certifique-se de que seu aplicativo seja implantado no mesmo AZs. Caso contrário, seu aplicativo poderá sofrer um salto entre AZ ao acessar o cache, resultando em maior latência do lado do cliente.
Conexões de reutilização: as solicitações ElastiCache sem servidor são feitas por meio de uma conexão TCP habilitada para TLS usando o protocolo RESP. Iniciar a conexão (incluindo a autenticação da conexão, se configurada) leva tempo, então a latência da primeira solicitação é maior que o normal. Solicitações em uma conexão já inicializada oferecem ElastiCache baixa latência consistente. Por esse motivo, você deve considerar o uso do pool de conexões ou a reutilização das conexões OSS Valkey ou Redis existentes.
Velocidade de escalonamento: o ElastiCache Serverless é escalado automaticamente à medida que sua taxa de solicitações aumenta. Um grande aumento repentino na taxa de solicitações, mais rápido do que a velocidade na qual o ElastiCache Serverless é escalado, pode resultar em latência elevada por algum tempo. ElastiCache Normalmente, o Serverless pode aumentar rapidamente a taxa de solicitações suportadas, levando de 10 a 12 minutos para dobrar a taxa de solicitações.
Inspecione comandos de longa execução: alguns comandos do Valkey ou do Redis OSS, incluindo scripts Lua ou comandos em grandes estruturas de dados, podem ser executados por muito tempo. Para identificar esses comandos, ElastiCache publica métricas de nível de comando. Com o ElastiCache Serverless, você pode usar as
BasedECPUsmétricas.Solicitações limitadas: quando as solicitações são limitadas no ElastiCache Serverless, você pode experimentar um aumento na latência do lado do cliente em seu aplicativo. Quando as solicitações são limitadas no ElastiCache Serverless, você deve ver um aumento na métrica Serverless. ThrottledRequests ElastiCache Consulte a seção abaixo para solucionar problemas em solicitações com controle de utilização.
Distribuição uniforme de chaves e solicitações: no ElastiCache Valkey e no Redis OSS, uma distribuição desigual de chaves ou solicitações por slot pode resultar em um hot slot que pode resultar em latência elevada. ElastiCache O Serverless suporta até 30.000 ECPUs /segundo (90.000 ECPUs /segundo ao usar Read from Replica) em um único slot, em uma carga de trabalho que executa comandos SET/GET simples. Recomendamos avaliar a distribuição da chave e da solicitação em todos os slots e garantir uma distribuição uniforme se a taxa de solicitação exceder esse limite.
Solução de problemas de limitação no Serverless ElastiCache
Em arquiteturas orientadas a serviços e sistemas distribuídos, a limitação da taxa na qual as chamadas de API são processadas por vários componentes do serviço é chamada de controle de utilização. Isso suaviza os picos, controla as incompatibilidades na produtividade dos componentes e permite recuperações mais previsíveis quando há um evento operacional inesperado. ElastiCache O Serverless foi projetado para esses tipos de arquiteturas, e a maioria dos clientes Valkey ou Redis OSS tem novas tentativas incorporadas para solicitações limitadas. Algum grau de controle de utilização não é necessariamente um problema para a aplicação, mas o controle de utilização persistente de uma parte sensível à latência do fluxo de trabalho de dados pode afetar negativamente a experiência do usuário e reduzir a eficiência geral do sistema.
Quando as solicitações são limitadas no ElastiCache Serverless, você deve ver um aumento na métrica Serverless. ThrottledRequests ElastiCache Se você está percebendo um grande número de solicitações com controle de utilização, considere o seguinte:
Velocidade de escalabilidade: o ElastiCache Serverless é escalado automaticamente à medida que você ingere mais dados ou aumenta sua taxa de solicitações. Se seu aplicativo for dimensionado mais rápido do que a velocidade com que o Serverless é escalado, suas solicitações podem ser limitadas, enquanto o ElastiCache Serverless é escalado para acomodar sua carga de trabalho. ElastiCache ElastiCache Normalmente, a tecnologia sem servidor pode aumentar o tamanho do armazenamento rapidamente, levando de 10 a 12 minutos para dobrar o tamanho do armazenamento em seu cache.
Distribuição uniforme de chaves e solicitações: no ElastiCache Valkey e no Redis OSS, uma distribuição desigual de chaves ou solicitações por slot pode resultar em um hot slot. Um hot slot pode resultar na limitação de solicitações, se a taxa de solicitação para um único slot exceder 30.000 por ECPUs segundo e estiver em uma carga de trabalho de execução simples. SET/GET commands. Similarly, with ElastiCache for Memcached, a hot key can result in throttling of requests if the request rate exceeds 30,000 ECPUs/second
Ler da réplica: se sua aplicação permitir, considere usar o recurso “Ler da réplica”. A maioria dos clientes Valkey ou Redis OSS pode ser configurada para “escalar leituras” para direcionar as leituras para os nós de réplica. Esse recurso permite que você escale o tráfego de leitura. Além disso, o ElastiCache Serverless encaminha automaticamente a leitura das solicitações de réplica para os nós na mesma zona de disponibilidade do seu aplicativo, resultando em menor latência. Quando a opção Ler da réplica está ativada, você pode atingir até 90.000 por ECPUs segundo em um único slot, para cargas de trabalho com comandos SET/GET simples.
Related Topics
