Solucionar problemas de mapeamento de origens de eventos no Lambda

Problemas no Lambda relacionados a um mapeamento de origem de evento podem ser mais complexos, pois envolvem depuração em vários serviços. Além disso, o comportamento da origem do evento pode ser diferente com base na origem do evento exata utilizada. Esta seção lista problemas comuns que envolvem mapeamentos de origens de eventos e fornece orientação sobre como identificá-los e solucioná-los.

Identificação e gerenciamento do controle de utilização

No Lambda, o controle de utilização ocorre quando você atinge o limite de concorrência da sua função ou conta. Considere o exemplo abaixo, em que uma função do Lambda lê mensagens de uma fila do Amazon SQS. Essa função do Lambda simula invocações de 30 segundos e tem um tamanho de lote de 1. Isso significa que ela processa apenas 1 mensagem a cada 30 segundos:

const doWork = (ms) => new Promise(resolve => setTimeout(resolve, ms))

exports.handler = async (event) => {
    await doWork(30000)

}

Com um tempo de invocação tão longo, as mensagens começam a chegar na fila com mais rapidez do que são processadas. Se a simultaneidade não reservada da sua conta for 100, o Lambda escalará até 100 execuções simultâneas e, em seguida, ocorrerá o controle de utilização. Você pode conferir esse padrão nas métricas do CloudWatch para a função:

As métricas do CloudWatch para a função não mostram erros, mas o gráfico Execuções simultâneas mostra que a simultaneidade máxima de 100 foi atingida. Como resultado, o gráfico Controle de utilização mostra o controle de utilização em vigor.

Você pode detectar o controle de utilização com alarmes do CloudWatch e configurando um alarme sempre que a métrica de controle de utilização de uma função for maior que 0. Depois de identificar o problema de controle de utilização, você tem algumas opções de resolução:

Erros na função de processamento

Se a função de processamento gerar erros, o Lambda retornará as mensagens para a fila do SQS. O Lambda impede que sua função seja escalada para evitar erros em grande escala. As métricas a seguir do SQS no CloudWatch indicam um problema com o processamento de filas:

Em particular, tanto a idade da mensagem mais antiga quanto o número de mensagens visíveis estão aumentando, enquanto nenhuma mensagem é excluída. A fila continua crescendo, mas as mensagens não estão sendo processadas. As métricas do CloudWatch para a função do Lambda de processamento também indicam que há um problema:

A métrica Contagem de erros é diferente de zero e está aumentando, enquanto o valor de Execuções simultâneas reduziu e o controle de utilização foi interrompido. Isso mostra que o Lambda parou de escalar sua função devido a erros. Os logs do CloudWatch da função fornecem detalhes do tipo de erro.

Você pode resolver esse problema identificando a função que está causando o erro e, em seguida, localizando e resolvendo o erro. Depois que você corrigir o erro e implantar o novo código da função, as métricas do CloudWatch deverão mostrar a recuperação do processamento:

Aqui, o valor da métrica Contagem de erros cai para zero e o valor da métrica Taxa de sucesso retorna a 100%. O Lambda começa a escalar a função novamente, conforme mostrado no gráfico Execuções simultâneas.

Identificação e tratamento de contrapressão

Se um produtor de eventos gerar consistentemente mensagens para uma fila do SQS mais rápido do que uma função do Lambda é capaz de processá-las, ocorre uma contrapressão. Nesse caso, o monitoramento do SQS deve mostrar a idade da mensagem mais antiga crescendo linearmente, juntamente com o número aproximado de mensagens visíveis. Você pode detectar contrapressão nas filas usando os alarmes do CloudWatch.

As etapas para resolver a contrapressão dependem da sua workload. Se o objetivo principal for aumentar a capacidade de processamento e o throughput por meio da função do Lambda, existem algumas opções: