Por que a métrica do Lambda IteratorAge está aumentando para meus Amazon DynamoDB Streams?

Data da última atualização: 12/09/2022

Ao consumir registros do meu stream do Amazon DynamoDB, vejo um pico na métrica do AWS Lambda IteratorAge. Por que a idade do iterador da minha função está aumentando e como posso resolver isso?

Breve descrição

A métrica do Lambda IteratorAge mede a latência entre quando um registro é adicionado a um stream do DynamoDB e quando a função processa esse registro. Quando o IteratorAge aumenta, isso significa que o Lambda não está processando com eficiência os registros gravados no stream do DynamoDB.

Estes são os principais motivos pelos quais o IteratorAge aumenta:

  • Erros de invocação
  • Ocorrência do acelerador
  • Baixo throughput do Lambda

Resolução

Erros de invocação

O Lambda foi projetado para processar lotes de registros em sequência e repetir erros. Portanto, se uma função retornar um erro toda vez que for invocada, o Lambda continuará tentando novamente. Ele faz isso até que os registros expirem ou excedam a idade máxima configurada no mapeamento da origem do evento. O período de retenção do stream do DynamoDB é 24. O Lambda continua tentando novamente por até um dia, até que o registro expire e, em seguida, passa para o próximo lote de registros.

Verifique a métrica de erros do Lambda para confirmar se um erro de invocação é a causa raiz do pico do IteratorAge. Em caso afirmativo, verifique os logs do Lambda para depurar o erro e modifique seu código. Certifique-se de incluir uma instrução try-catch em seu código ao lidar com o erro.

Há três parâmetros na configuração de mapeamento de origem de eventos que podem ajudá-lo a evitar picos de IteratorAge:

  • Tentativas de repetição o número máximo de vezes que o Lambda tenta novamente quando a função retorna um erro.
  • Idade máxima de registro: a idade máxima de um registro que o Lambda envia para sua função. Isso ajuda você a descartar registros que são muito antigos.
  • Dividir lote em caso de erro: quando a função retornar um erro, divida o lote em dois antes de tentar novamente. Tentar novamente com lotes menores isola registros ruins e soluciona problemas de tempo limite. Observação: dividir um lote não conta para a cota de novas tentativas.

Para reter eventos descartados, configure o mapeamento da origem do evento para enviar detalhes sobre lotes com falha para uma fila do Amazon Simple Queue Service (Amazon SQS). Ou configure o mapeamento de origem uniforme para enviar detalhes para um tópico do Amazon Simple Notification Service (Amazon SNS). Para fazer isso, use o parâmetro On-failure destination.

Ocorrências de aceleração

Como os registros de eventos são lidos sequencialmente, as funções do Lambda não podem progredir para o próximo registro se a chamada atual for limitada.

Ao usar streams do DynamoDB, não configure mais de dois consumidores no mesmo fragmento de stream. Se você tiver mais de dois leitores por fragmento, isso pode causar controle de utilização. Se você precisar de mais de dois leitores em um único fragmento de fluxo, use um padrão de distribuição. Configure a função do Lambda para consumir registros do stream e, em seguida, encaminhe-os para outras funções downstream do Lambda ou streams do Amazon Kinesis.

No final do Lambda, use um limite de simultaneidade para evitar o controle de utilização.

Throughput do Lambda

Duração do tempo de execução

Se a métrica Duração de uma função Lambda for alta, isso diminuirá o throughput da função e aumentará o IteratorAge.

Para diminuir a duração do tempo de execução da sua função, use um ou ambos os métodos a seguir:

1.    Aumente a quantidade de memória alocada para a função.

2.    Otimize seu código de função para que seja necessário menos tempo para processar registros.

Execuções simultâneas do Lambda

O número máximo de execuções simultâneas do Lambda é calculado da seguinte forma:

Execuções simultâneas = Número de fragmentos x Lotes simultâneos por fragmento (fator de paralelização)

  • Número de fragmentos: em um stream do DynamoDB, há mapeamento 1<>1 entre o número de partições da tabela e o número de fragmentos de stream. O número de partições é determinado pelo tamanho da tabela e seu throughput. Cada partição na tabela pode servir até 3.000 unidades de solicitação de leitura ou 1.000 unidades de solicitação de gravação ou a combinação linear de ambas. Portanto, para aumentar a simultaneidade, aumente o número de fragmentos aumentando a capacidade provisionada da tabela.
  • Lotes simultâneos por fragmento (Fator de Paralelização): você pode configurar o número de lotes simultâneos por fragmento no mapeamento da origem do evento. O padrão é 1 e pode ser aumentado até 10.

Por exemplo, se a tabela tiver 10 partições e os lotes simultâneos por fragmento estiverem definidos como 5, você poderá ter até 50 execuções simultâneas.

Nota: para processar a modificação no nível do item na ordem correta a qualquer momento, os itens com a mesma chave de partição vão para o mesmo lote. Portanto, certifique-se de que sua chave de partição de tabela tenha alta cardinalidade e que seu tráfego não gere teclas de atalho. Por exemplo, se você definir lotes simultâneos por valor de fragmento como 10 e seu tráfego de gravação estiver direcionado a uma única chave de partição, você poderá ter apenas 1 execução simultânea por fragmento.

Tamanho do lote

Ajustar o valor do tamanho do lote ajuda a aumentar o throughput do Lambda. Se você processar um número baixo de registros por lote, isso diminuirá o processamento do fluxo.

Por outro lado, se você tiver um número alto de registros por lote, isso poderá aumentar a duração da execução da função. Portanto, teste com vários valores para encontrar o melhor valor para seu caso de uso.

Se a duração do tempo de execução da sua função for independente do número de registros em um evento, o aumento do tamanho do lote da função diminuirá a idade do iterador da função.