Solução de problemas de instâncias gerenciadas do Lambda - AWS Lambda
Problemas de controle de utilização e escalabilidadeProblemas de simultaneidadeProblemas de performanceProblemas do provedor de capacidadeProblemas de monitoramento e observabilidadeObter ajuda adicionalPróximas etapas

Solução de problemas de instâncias gerenciadas do Lambda

Problemas de controle de utilização e escalabilidade

Altas taxas de erro durante o aumento de escala na vertical

Problema: você enfrenta erros de controle de utilização (HTTP 429) quando o tráfego aumenta rapidamente.

Causa: as instâncias gerenciadas do Lambda escalam de forma assíncrona com base na utilização de recursos da CPU e na saturação da multissimultaneidade. Se seu tráfego mais do que dobrar em 5 minutos, será possível ver controles de utilização quando o Lambda aumentar a escala verticalmente das instâncias e ambientes de execução para atender à demanda.

Solução:

  • Ajuste a utilização de recursos de destino: se sua workload tiver padrões de tráfego previsíveis, defina uma menor utilização dos recursos de destino para manter espaço adicional para picos de tráfego.

  • Capacidade de pré-aquecimento: para aumentos planejados de tráfego, aumente gradualmente o tráfego por um longo período para permitir que a escalabilidade acompanhe o ritmo.

  • Monitore as métricas de escalabilidade: acompanhe as métricas de erro de controle de utilização para compreender o motivo dos problemas de controle de utilização e escalabilidade de capacidade.

  • Revise a configuração da função: certifique-se de que suas configurações de memória de função e vCPU suportem execuções multissimultâneas. Aumente a memória funcional ou a alocação de vCPUs, se necessário.

Redução lenta da escala na vertical

Problema: as instâncias demoram muito para reduzir a escala verticalmente depois que o tráfego diminui.

Causa: as instâncias gerenciadas do Lambda reduzem a escala verticalmente de forma gradual para manter a disponibilidade e para evitar mudanças rápidas de capacidade que possam afetar a performance.

Solução:

Esse comportamento é esperado. O Lambda reduz a escala verticalmente das instâncias de forma conservadora para garantir a estabilidade. Monitore suas métricas do CloudWatch para acompanhar o número de instâncias em execução.

Problemas de simultaneidade

Ambientes de execução com baixa simultaneidade sofrem controles de utilização

Problema: suas funções sofrem controle de utilização apesar de terem capacidade disponível.

Causa: os ambientes de execução com simultaneidade máxima muito baixa podem ter dificuldade em escalar de forma eficaz. As instâncias gerenciadas do Lambda são projetadas para aplicações multissimultâneas.

Solução:

  • Aumente a simultaneidade: se suas invocações de função usarem muito pouca CPU, aumente a configuração de simultaneidade máxima até 64 por vCPU.

  • Otimize o código da função: revise seu código de função para reduzir o consumo de CPU por invocação, permitindo maior simultaneidade.

  • Ajuste a memória a vCPU da função: certifique-se de que sua função tenha recursos suficientes para lidar com várias invocações simultâneas.

Problemas de segurança de thread (runtime de Java)

Problema: sua função de Java produz resultados incorretos ou passa por condições de corrida sob carga.

Causa: vários threads executam o método manipulador simultaneamente, e o estado compartilhado não é seguro para threads.

Solução:

  • Use AtomicInteger ou AtomicLong para contadores em vez de tipos primitivos

  • Substitua HashMap por ConcurrentHashMap

  • Use Collections.synchronizedList() para encapsular ArrayList

  • Use ThreadLocal para o estado específico da solicitação

  • Acesse os IDs de rastreamento a partir do objeto de contexto do Lambda, não de variáveis de ambiente

Para obter orientação detalhada, consulte a documentação do runtime de Java para instâncias gerenciadas do Lambda.

Problemas de isolamento de estado (runtime de Node.js)

Problema: sua função de Node.js retorna dados de diferentes solicitações ou sofre corrupção de dados.

Causa: as variáveis globais são compartilhadas entre invocações simultâneas no mesmo thread de operador. Quando as operações assíncronas geram controle, outras invocações podem modificar o estado compartilhado.

Solução:

  • Instale e use @aws/lambda-invoke-store para todos os estados específicos da solicitação

  • Substitua as variáveis globais por InvokeStore.set() e InvokeStore.get()

  • Use nomes de arquivo exclusivos em /tmp com IDs de solicitação

  • Acesse os IDs de rastreamento usando InvokeStore.getXRayTraceId() em vez de variáveis de ambiente

Para obter orientação detalhada, consulte a documentação do runtime de Node.js para instâncias gerenciadas do Lambda.

Conflitos de arquivos (runtime de Python)

Problema: sua função de Python lê dados incorretos dos arquivos em /tmp.

Causa: vários processos compartilham o diretório /tmp. Gravações simultâneas no mesmo arquivo podem causar corrupção de dados.

Solução:

  • Use nomes de arquivo exclusivos com IDs de solicitação: /tmp/request_{context.request_id}.txt

  • Use o bloqueio de arquivos com fcntl.flock() para arquivos compartilhados

  • Limpe arquivos temporários com os.remove() após o uso

Para obter orientação detalhada, consulte a documentação do runtime de Python para instâncias gerenciadas do Lambda.

Problemas de performance

Alta utilização de memória

Problema: suas funções apresentam alta utilização de memória ou erros de memória insuficiente.

Causa: cada solicitação simultânea em Python é executada em um processo separado com seu próprio espaço de memória. O uso total de memória é igual à memória por processo multiplicada pelos processos simultâneos.

Solução:

  • Monitore a métrica MemoryUtilization no CloudWatch

  • Reduza a configuração MaxConcurrency se o uso da memória se aproximar do limite de memória da função

  • Aumente a alocação de memória da função para suportar maior simultaneidade

  • Otimize o uso da memória carregando dados sob demanda em vez de durante a inicialização

Performance inconsistente

Problema: a performance da função varia significativamente entre as invocações.

Causa: o Lambda pode selecionar diferentes tipos de instância com base na disponibilidade, ou as funções podem estar sendo executadas em instâncias com disponibilidade variável de recursos.

Solução:

  • Especifique os tipos de instância permitidos: se você tiver requisitos de performance específicos, configure os tipos de instância permitidos em seu provedor de capacidade para limitar os tipos de instância que o Lambda pode selecionar.

  • Monitore as métricas em nível de instância: acompanhe CPUUtilization e MemoryUtilization no nível do provedor de capacidade para identificar restrições de recursos.

  • Analise as métricas de capacidade: verifique vCPUAvailable e MemoryAvailable para garantir que recursos suficientes estejam disponíveis em suas instâncias.

Problemas do provedor de capacidade

A versão da função falha ao se tornar ATIVA

Problema: sua versão da função permanece em um estado pendente após a publicação.

Causa: o Lambda está executando instâncias gerenciadas e iniciando ambientes de execução. Esse processo leva tempo, especialmente para a primeira versão da função em um novo provedor de capacidade.

Solução:

Aguarde até que o Lambda conclua o processo de inicialização. O Lambda executa três instâncias por padrão para resiliência de AZ e inicia três ambientes de execução antes de marcar a versão da sua função como ATIVA. Isso normalmente demora vários minutos.

Não é possível excluir o provedor de capacidade

Problema: você recebe um erro ao tentar excluir um provedor de capacidade.

Causa: não é possível excluir um provedor de capacidade que tenha versões de função anexadas a ele.

Solução:

  1. Identifique todas as versões de funções usando o provedor de capacidade com a API ListFunctionVersionsByCapacityProvider.

  2. Exclua ou atualize essas versões de funções para remover a associação do provedor de capacidade.

  3. Tente excluir novamente o provedor de capacidade.

Mensagens de erro genéricas durante a publicação da função

Problema: você encontra mensagens de erro genéricas, como “Ocorreu um erro interno durante a publicação” ao publicar as funções.

Solução:

  • Verifique as permissões do IAM: certifique-se de ter a permissão lambda:PassCapacityProvider para o provedor de capacidade que está tentando usar.

  • Verifique a configuração do provedor de capacidade: confirme se seu provedor de capacidade está no estado ATIVO usando a API GetCapacityProvider.

  • Revise a configuração da VPC: certifique-se de que as sub-redes e os grupos de segurança especificados em seu provedor de capacidade estejam configurados e acessíveis corretamente.

  • Verifique os logs do AWS CloudTrail: revise os logs do CloudTrail para obter informações detalhadas de erro sobre a operação que falhou.

Problemas de monitoramento e observabilidade

Métricas ausentes do CloudWatch

Problema: você não vê as métricas esperadas no CloudWatch para seu provedor de capacidade ou funções.

Causa: as métricas são publicadas em intervalos de 5 minutos. Novos provedores de capacidade ou funções podem não ter métricas disponíveis imediatamente.

Solução:

Aguarde pelo menos de 5 a 10 minutos após publicar uma versão de função antes de esperar que as métricas apareçam no CloudWatch. Verifique se você está vendo o namespace (AWS/Lambda) e as dimensões (CapacityProviderName, FunctionName ou InstanceType) corretos.

Não é possível localizar os logs do CloudWatch

Problema: sua função é executada com êxito, mas você não consegue encontrar os logs no CloudWatch Logs.

Causa: as instâncias gerenciadas do Lambda são executadas em sua VPC e exigem conectividade de rede para enviar logs para o CloudWatch Logs. Sem a configuração adequada de conectividade da VPC, suas funções não podem alcançar o endpoint do serviço CloudWatch Logs.

Solução:

Configure a conectividade da VPC para permitir que suas funções enviem logs para o CloudWatch Logs. Você tem três opções:

Opção 1: endpoint da VPC para o CloudWatch Logs (recomendado para produção)

  1. Abra o console da Amazon VPC, em console.aws.amazon.com/vpc/.

  2. No painel de navegação, escolha Endpoints.

  3. Escolha Criar endpoint.

  4. Em Categoria do serviço, escolha Serviços do AWS.

  5. Em Nome do serviço, selecione com.amazonaws.region.logs (substitua region por sua região da AWS).

  6. Em VPC, selecione a VPC usada pelo seu provedor de capacidade.

  7. Em Sub-redes, selecione as sub-redes nas quais deseja criar as interfaces de rede de endpoint. Para obter alta disponibilidade, selecione sub-redes em várias zonas de disponibilidade.

  8. Em Grupos de segurança, selecione os grupos de segurança que permitem tráfego de HTTPS de entrada (porta 443) no grupo de segurança da sua função.

  9. Habilite DNS privado para o endpoint

  10. Escolha Criar endpoint.

Opção 2: sub-rede pública com gateway da Internet

Se o seu provedor de capacidade usa sub-redes públicas, certifique-se de que:

  1. Um gateway da Internet esteja conectado à VPC.

  2. A tabela de rotas encaminhe o tráfego para 0.0.0.0/0 ao gateway da Internet

  3. Os grupos de segurança permitam tráfego de HTTPS de saída na porta 443

Opção 3: sub-rede privada com gateway de NAT

Se o seu provedor de capacidade usa sub-redes privadas, certifique-se de que:

  1. Exista um gateway de NAT em uma sub-rede pública

  2. A tabela de rotas da sub-rede privada encaminhe o tráfego para 0.0.0.0/0 ao gateway de NAT

  3. A tabela de rotas da sub-rede pública encaminhe o tráfego para 0.0.0.0/0 a um gateway da Internet

  4. Os grupos de segurança permitam tráfego de HTTPS de saída na porta 443

Para obter orientações detalhadas sobre as opções de conectividade de VPC, consulte Conectividade de VPC para instâncias gerenciadas do Lambda.

Dificuldade em correlacionar logs de solicitações simultâneas

Problema: os logs de solicitações diferentes são intercalados, dificultando o rastreamento de solicitações individuais.

Causa: a intercalação de logs é esperada, e é o comportamento padrão em sistemas multissimultâneos.

Solução:

  • Use registro em log estruturado com formato JSON: inclua o ID da solicitação em todas as instruções de log

  • Java: use Log4j com ThreadContext para incluir automaticamente o ID da solicitação

  • Node.js: Use console.log() com formatação JSON e inclua InvokeStore.getRequestId()

  • Python: use o módulo de registro em log padrão com formatação JSON e inclua context.request_id

Para obter orientação detalhada, consulte as páginas de documentação específicas do runtime.

Obter ajuda adicional

Se você continuar enfrentando problemas depois de tentar essas soluções:

  1. Analise as métricas do CloudWatch: verifique as métricas do provedor de capacidade e do ambiente de execução para identificar restrições de recursos ou problemas de escalabilidade.

  2. Verifique os logs do AWS CloudTrail: revise os logs do CloudTrail para obter informações detalhadas sobre chamadas de API e erros.

  3. Entre em contato com o suporte da AWS: se você não conseguir resolver o problema, entre em contato com o suporte da AWS com detalhes sobre a configuração do seu provedor de capacidade, a configuração da função e as mensagens de erro específicas que você está encontrando.

Próximas etapas