Usar o Lambda com o Amazon SQS

É possível usar uma função do Lambda para processar mensagens em uma fila do Amazon Simple Queue Service (Amazon SQS). O Lambda oferece suporte a filas padrão e filas FIFO (primeiro a entrar, primeiro a sair) para mapeamentos de origem de eventos. Também é possível usar o modo provisionado para alocar recursos de sondagem dedicados para seus mapeamentos da origem do evento do Amazon SQS. A função do Lambda e a fila do Amazon SQS devem estar na mesma Região da AWS, embora possam estar em diferentes Contas da AWS.

Ao processar mensagens do Amazon SQS, é necessário implementar uma lógica de resposta parcial em lote para evitar que as mensagens processadas com êxito sejam repetidas quando algumas mensagens em um lote falham. O utilitário Processador em lote do Powertools para AWS Lambda simplifica essa implementação ao lidar automaticamente com a lógica de resposta parcial em lote, reduzindo o tempo de desenvolvimento e melhorando a confiabilidade.

Entender o comportamento de sondagens e lotes para mapeamentos de origem de eventos do Amazon SQS

Com os mapeamentos de origem de eventos do Amazon SQS, o Lambda sonda a fila e invoca sua função de forma síncrona com um evento. Cada evento pode conter um lote de várias mensagens da fila. O Lambda recebe esses eventos um lote por vez e invoca sua função uma vez para cada lote. Quando sua função processa um lote com êxito, o Lambda exclui suas mensagens da fila.

Quando o Lambda recebe um lote, as mensagens permanecem na fila, mas permanecem ocultas durante o tempo limite de visibilidade da fila. Se a função processar com êxito todas as mensagens no lote, o Lambda excluirá as mensagens da fila. Por padrão, se a sua função encontrar um erro durante o processamento de um lote, todas as mensagens naquele lote se tornarão visíveis na fila novamente após o tempo limite de visibilidade expirar. Por conta disso, o código da função deve ter a capacidade de processar a mesma mensagem várias vezes sem causar efeitos colaterais não intencionais.

Para evitar que o Lambda processe uma mensagem diversas vezes, é possível configurar o mapeamento de origem de eventos para incluir falhas de itens de lote na resposta da função ou usar a API DeleteMessage para remover mensagens da fila à medida que a função do Lambda as processa com êxito.

Para obter informações sobre os parâmetros de configuração aceitos pelo Lambda para mapeamentos de origem de eventos do SQS, consulte Criar um mapeamento de origem de evento do SQS.

Uso do modo provisionado com mapeamentos da origem do evento do Amazon SQS

Para workloads em que você precisa ajustar o throughput do mapeamento da origem de eventos, você pode usar o modo provisionado. No modo provisionado, você define limites mínimos e máximos para a quantidade de agentes de sondagem de eventos provisionados. Esses agentes de sondagem de eventos provisionados são dedicados ao mapeamento da origem do evento e podem lidar com picos inesperados de mensagens por meio do ajuste de escala automático responsivo. O mapeamento da origem do evento do Amazon SQS configurado com o modo provisionado é escalado 3 vezes mais rápido (até 1.000 invocações simultâneas por minuto) e suporta uma simultaneidade 16x maior (até 20.000 invocações simultâneas) do que o recurso padrão de mapeamento da origem do evento do Amazon SQS. Recomendamos que você use o modo provisionado para workloads orientadas a eventos do Amazon SQS que tenham requisitos rígidos de performance, como empresas de serviços financeiros que processem feeds de dados de mercado, plataformas de comércio eletrônico que forneçam recomendações personalizadas em tempo real e empresas de jogos que gerenciem interações com jogadores ao vivo. O uso do modo provisionado incorre em custos adicionais. Para obter detalhes sobre preços, consulte Definição de preços do AWS Lambda.

Cada agente de sondagem de eventos no modo provisionado pode tratar até 1 MB/s de throughput, até 10 invocações simultâneas ou até 10 chamadas da API de sondagem do Amazon SQS por segundo. O intervalo de valores aceitos para o número mínimo de agentes de sondagem de eventos (MinimumPollers) é entre 2 e 200, com um padrão de 2. O intervalo de valores aceitos para o número máximo de agentes de sondagem de eventos (MaximumPollers) é entre 2 e 2.000, com um padrão de 200. MaximumPollers deve ser maior ou igual a MinimumPollers.

Determinação dos agentes de sondagem de eventos necessários

Para estimar o número de agentes de sondagem de eventos necessários para garantir a performance ideal do processamento de mensagens ao usar o modo provisionado para o ESM do SQS, reúna as métricas a seguir para sua aplicação: pico de eventos de SQS por segundo que exijam processamento de baixa latência, tamanho médio da carga útil do evento de SQS, duração média da função do Lambda e tamanho do lote configurado.

Primeiro, é possível estimar o número de eventos de SQS por segundo (EPS) com suporte em um agente de sondagem de eventos para sua workload usando a fórmula a seguir:

EPS per event poller = 
        minimum(
            ceiling(1024 / average event size in KB),
            ceiling(10 / average function duration in seconds) * batch size, 
            min(100, 10 * batch size)
                )

Em seguida, é possível calcular o número mínimo de sondagens necessárias usando a fórmula abaixo. Esse cálculo garante que você provisione capacidade suficiente para tratar seus requisitos de pico de tráfego.

Required event pollers = (Peak number of events per second in Queue) / EPS per event poller

Considere uma workload com um tamanho de lote padrão de 10, tamanho médio de evento de 3 KB, duração média da função de 100 ms e um requisito para tratar 1.000 eventos por segundo. Nesse cenário, cada agente de sondagem de eventos oferecerá suporte a aproximadamente 100 eventos por segundo (EPS). Portanto, é necessário definir o mínimo de sondagens como 10 para lidar adequadamente com seus requisitos de pico de tráfego. Se sua workload tiver as mesmas características, mas com duração média de função de 1 segundo, cada agente de sondagem oferecerá suporte apenas a 10 EPS, exigindo que você configure 100 agentes de sondagem no mínimo para tratar 1.000 eventos por segundo em baixa latência.

Recomendamos usar um tamanho de lote padrão de 10 ou mais para maximizar a eficiência dos agentes de sondagem de eventos no modo provisionado. Tamanhos de lote maiores permitem que cada agente de sondagem processe mais eventos por invocação, para melhorar a produtividade e a eficiência de custos. Ao planejar sua capacidade de agentes de sondagem de eventos, considere possíveis picos de tráfego e considere definir o valor de minimumPollers um pouco acima do mínimo calculado para fornecer um buffer. Além disso, monitore as características da workload ao longo do tempo, pois mudanças no tamanho da mensagem, na duração da função ou nos padrões de tráfego podem exigir ajustes na configuração de agentes de sondage de eventos para manter a performance e a eficiência de custos ideais. Para obter um planejamento preciso da capacidade, recomendamos testar sua workload específica para determinar o EPS real que cada agente de sondagem de eventos pode gerar.

Configuração do modo provisionado para mapeamentos da origem do evento do Amazon SQS

É possível configurar o modo provisionado para o mapeamento da origem do evento do Amazon SQS usando o console ou a API do Lambda.

É possível configurar o modo provisionado programaticamente usando o objeto ProvisionedPollerConfig na sua EventSourceMappingConfiguration. Por exemplo, o comando UpdateEventSourceMapping a seguir da CLI configura um valor de MinimumPollers como 5 e um valor de MaximumPollers como 100.

aws lambda update-event-source-mapping \
    --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
    --provisioned-poller-config '{"MinimumPollers": 5, "MaximumPollers": 100}'

Depois de configurar o modo provisionado, você pode observar o uso de agentes de sondagem de eventos para sua workload monitorando a métrica ProvisionedPollers. Para obter mais informações, consulte as métricas do mapeamento da origem do evento.

Para desabilitar o modo provisionado e retornar ao modo padrão (sob demanda), é possível usar o comando UpdateEventSourceMapping a seguir da CLI:

aws lambda update-event-source-mapping \
    --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
    --provisioned-poller-config '{}'

Para obter mais informações sobre como configurar o modo provisionado, consulte Criar e configurar um mapeamento de origem de evento do Amazon SQS.

Exemplo de evento de mensagem de fila padrão

{
    "Records": [
        {
            "messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
            "receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
            "body": "Test message.",
            "attributes": {
                "ApproximateReceiveCount": "1",
                "SentTimestamp": "1545082649183",
                "SenderId": "AIDAIENQZJOLO23YVJ4VO",
                "ApproximateFirstReceiveTimestamp": "1545082649185"
            },
            "messageAttributes": {
                "myAttribute": {
                    "stringValue": "myValue", 
                    "stringListValues": [], 
                    "binaryListValues": [], 
                    "dataType": "String"
                }
            },
            "md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
            "eventSource": "aws:sqs",
            "eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue",
            "awsRegion": "us-east-2"
        },
        {
            "messageId": "2e1424d4-f796-459a-8184-9c92662be6da",
            "receiptHandle": "AQEBzWwaftRI0KuVm4tP+/7q1rGgNqicHq...",
            "body": "Test message.",
            "attributes": {
                "ApproximateReceiveCount": "1",
                "SentTimestamp": "1545082650636",
                "SenderId": "AIDAIENQZJOLO23YVJ4VO",
                "ApproximateFirstReceiveTimestamp": "1545082650649"
            },
            "messageAttributes": {},
            "md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
            "eventSource": "aws:sqs",
            "eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue",
            "awsRegion": "us-east-2"
        }
    ]
}

Por padrão, o Lambda pesquisará até 10 mensagens em sua fila de uma só vez e envia esse lote para sua função. Para evitar a invocação da função com poucos registros, você pode configurar a origem de eventos para armazenar os registros em buffer por até cinco minutos, configurando uma janela de lote. Antes de invocar a função, o Lambda continuará a sondar as mensagens da fila padrão até a janela de lote expirar, a cota de tamanho da carga útil de invocação ser atingida ou o tamanho de lote máximo configurado ser atingido.

Se você estiver usando uma janela em lote e sua fila do SQS contiver um volume de tráfego muito baixo, o Lambda poderá esperar até 20 segundos antes de invocar sua função. Isso será válido mesmo se você definir uma janela de lote inferior a 20 segundos.

Exemplo de evento de mensagem de fila FIFO

Para as filas FIFO, os registros contêm atributos adicionais relacionados a desduplicação e sequenciamento.

{
    "Records": [
        {
            "messageId": "11d6ee51-4cc7-4302-9e22-7cd8afdaadf5",
            "receiptHandle": "AQEBBX8nesZEXmkhsmZeyIE8iQAMig7qw...",
            "body": "Test message.",
            "attributes": {
                "ApproximateReceiveCount": "1",
                "SentTimestamp": "1573251510774",
                "SequenceNumber": "18849496460467696128",
                "MessageGroupId": "1",
                "SenderId": "AIDAIO23YVJENQZJOL4VO",
                "MessageDeduplicationId": "1",
                "ApproximateFirstReceiveTimestamp": "1573251510774"
            },
            "messageAttributes": {},
            "md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
            "eventSource": "aws:sqs",
            "eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:fifo.fifo",
            "awsRegion": "us-east-2"
        }
    ]
}