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 conselhos sobre solução de problemas e respostas a perguntas comuns de suporte, visite o Centro de AWS Conhecimento
Tópicos
Problemas de conectividade
Se você não conseguir se conectar ao ElastiCache cache, considere uma das seguintes opções:
UsandoTLS: Se você estiver com uma conexão interrompida ao tentar se conectar ao seu ElastiCache endpoint, talvez não esteja usando TLS em 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 TLS para se conectar ao cache. Saiba mais sobre como se conectar a um cache TLS habilitado.
VPC: ElastiCache os caches são acessíveis somente de dentro de a. VPC Certifique-se de que a EC2 instância a partir da qual você está acessando o ElastiCache cache e o cache sejam criados na mesmaVPC. Como alternativa, você deve ativar o VPCpeering entre o VPC local em que sua EC2 instância reside e o VPC local 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 RedisOSS. Saiba mais sobre como configurar o acesso à porta aqui.
Se a conexão continuar difícil, Problemas persistentes de conexão consulte 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 RedisOSS. Clusters autoprojetados podem ser acessados de clientes em qualquer um dos modos, dependendo da configuração do cluster.
Se você estiver enfrentando erros em seu cliente, considere o seguinte:
Modo de cluster: se você estiver enfrentando CROSSLOT erros ou erros com o SELECT
comando, talvez esteja tentando acessar um cache habilitado para o modo de cluster com um OSS cliente Valkey ou Redis que não suporta o protocolo Cluster. ElastiCache O Serverless oferece suporte apenas a clientes que oferecem suporte ao protocolo de cluster Valkey ou RedisOSS. Se você quiser usar Valkey ou Redis OSS em “Modo de cluster desativado” (CMD), deverá criar seu próprio cluster. CROSSLOTerros: Se você estiver enfrentando o
ERR CROSSLOT Keys in request don't hash to the same sloterro, talvez esteja tentando acessar chaves que não pertencem ao mesmo slot em um cache do modo 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.
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 seu 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 AWS Support.
Considere as seguintes melhores práticas e estratégias para reduzir a latência:
Ativar leitura da réplica: se seu aplicativo permitir, recomendamos ativar o recurso “Ler da réplica” em seu OSS cliente Valkey ou Redis 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 ativar o recurso Ler da réplica em seu cliente significa que seu aplicativo aceita uma eventual consistência nos dados. Seu aplicativo pode receber 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 ElastiCache Serverless cria endpoints nessas sub-redes. VPC Certifique-se de que seu aplicativo seja implantado no mesmoAZs. Caso contrário, seu aplicativo poderá incorrer em 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 TCP conexão TLS habilitada 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 do que a normal. Solicitações em uma conexão já inicializada oferecem ElastiCache baixa latência consistente. Por esse motivo, você deve considerar usar o pool de conexões ou reutilizar as conexões Valkey ou Redis existentes. OSS
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 RedisOSS, 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 com solicitações limitadas.
Distribuição uniforme de chaves e solicitações: ElastiCache com o Valkey e o RedisOSS, 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/simples. SET GET 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, limitar a taxa na qual as API chamadas são processadas por vários componentes do serviço é chamado de limitaçã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 OSS clientes Valkey ou Redis 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 limitadas, 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: ElastiCache com o Valkey ou o RedisOSS, 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ções em um único slot exceder 30.000 por ECPUs segundo, em uma carga de trabalho que executa comandos/simples. SET GET
Leia da réplica: se seu aplicativo permitir, considere usar o recurso “Ler da réplica”. A maioria dos OSS clientes Valkey ou Redis 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 ECPUs /segundo em um único slot, para cargas de trabalho com comandos/simples. SET GET
Related Topics
