Modos de escalabilidade de sondagem de eventos do Apache Kafka no Lambda

É possível escolher entre dois modos de escalabilidade de sondagem de eventos para o mapeamento da origem do evento do Apache Kafka autogerenciado:

Modo sob demanda (padrão)

Quando você cria inicialmente uma origem do evento do Kafka, o Lambda aloca um número padrão de sondagem de eventos para processar todas as partições no tópico do Kafka. O Lambda aumenta ou diminui automaticamente o número de agentes de sondagem de eventos com base na carga de mensagens.

A cada um minuto, o Lambda avalia o atraso de deslocamento de todas as partições do tópico. Se o atraso de deslocamento for muito alto, a partição está recebendo mensagens mais rápido do que o Lambda pode processá-las. Se necessário, o Lambda adiciona ou remove os agentes de sondagem de eventos do tópico. Esse processo de ajuste de escala automático para adicionar ou remover agentes de sondagem de eventos ocorre em até três minutos após a avaliação.

Se a função do Lambda de destino sofrer um controle de utilização, o Lambda reduzirá o número de agentes de sondagem de eventos. Essa ação reduz a workload na função, reduzindo o número de mensagens que os agentes de sondagem de eventos podem recuperar e enviar para a função.

Modo provisionado

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. Recomendamos que você use o modo provisionado para workloads do Kafka que tenham requisitos rigorosos de performance.

No Lambda, um agente de sondagem de eventos é uma unidade computacional com recursos de throughput que variam de acordo com o tipo da origem do evento. Para o Amazon MSK e o Apache Kafka autogerenciado, cada agente de sondagem de eventos pode lidar com até 5 MB/seg de throughput, ou até 5 invocações simultâneas. Por exemplo, se sua origem de eventos produzir uma carga útil média de 1 MB e a duração média de sua função for de 1 segundo, um único agente de sondagem de eventos do Kafka poderá oferecer suporte a um throughput de 5 MB/seg e 5 invocações do Lambda simultâneas (supondo que não haja transformação da carga útil). Para o Amazon SQS, cada agente de sondagem de eventos pode lidar com até 1 MB/s de throughput, ou até 10 invocações simultâneas. O uso do modo provisionado incorre em custos adicionais com base no uso do agente de sondagem de eventos. Para obter detalhes de preço, consulte Definição de preço do AWS Lambda.

No modo provisionado, o intervalo de valores aceitos para o número mínimo de agentes de sondagem de eventos (MinimumPollers) está entre 1 e 200, inclusive. O intervalo de valores aceitos para o número máximo de agentes de sondagem de eventos (MaximumPollers) está entre 1 e 2.000, inclusive. O valor de MaximumPollers deve ser maior que ou igual ao valor de MinimumPollers. Além disso, para manter o processamento ordenado nas partições, o Lambda limita o valor de MaximumPollers ao número de partições no tópico.

Para obter mais detalhes sobre como escolher valores mínimo e máximo apropriados de agentes de sondagem de eventos, consulte Práticas recomendadas.

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

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

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 Métricas de mapeamento da origem do evento.

Para desativar o modo provisionado e retornar ao modo padrão (sob demanda), você pode usar o seguinte comando da CLI UpdateEventSourceMapping:

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

Atributos avançados de tratamento de erros e performance

Para mapeamentos da origem do evento do Kafka com o modo provisionado habilitado, é possível configurar atributos adicionais para melhorar a performance e o tratamento de erros:

Práticas recomendadas e considerações ao usar o modo provisionado

A configuração ideal de agentes de sondagem de eventos mínimos e máximos para o mapeamento da origem de eventos depende dos requisitos de performance da sua aplicação. Recomendamos que você inicie por um mínimo padrão de agentes de sondagem de eventos para definir o perfil de performance básico. Ajuste sua configuração com base nos padrões de processamento de mensagens observados e no perfil de performance desejado.

Para workloads com tráfego intenso e necessidades rigorosas de performance, aumente o número mínimo de agentes de sondagem de eventos para lidar com picos repentinos de mensagens. Para determinar os agentes de sondagem de eventos mínimos necessários, considere as mensagens de sua workload por segundo e o tamanho médio da carga útil e use a capacidade de throughput de um único agente de sondagem de eventos (até 5 MBps) como referência.

Para manter o processamento ordenado em uma partição, o Lambda limita o máximo de agentes de sondagem de eventos ao número de partições no tópico. Além disso, o número máximo de agentes de sondagem de eventos para os quais o mapeamento da origem de eventos pode ser escalado depende das configurações de simultaneidade da função.

Ao ativar o modo provisionado, atualize suas configurações de rede para remover os endpoints de VPC do AWS PrivateLink e as permissões associadas.

Otimização de custos para o modo provisionado

Definição de preços do modo provisionado

O modo provisionado é cobrado com base nos agentes de sondagem de eventos mínimos provisionados e nos agentes de sondagem de eventos consumidos durante o escalonamento automático. As cobranças são calculadas usando uma unidade de cobrança chamada unidade de sondagem de evento (EPU). Você paga pelo número e pela duração das EPUs usadas, medidas em horas da unidade de sondagem de eventos. É possível usar o modo provisionado com um único ESM para aplicações sensíveis à performance ou agrupar vários ESMs na mesma VPC para compartilhar a capacidade e os custos da EPU. Vamos nos aprofundar em dois recursos que ajudam você a otimizar seus custos do modo provisionado. Para obter detalhes da definição de preços, consulte Definição de preços do AWS Lambda.

Utilização aprimorada da EPU

Cada EPU oferece suporte à capacidade de throughput de até 20 MB/s para sondagem de eventos e a um padrão de 10 agentes de sondagem de eventos. Quando você cria um modo provisionado para o Kafka ESM definindo um mínimo e um máximo de agentes de sondagem, ele usa o número mínimo de agentes de sondagem para provisionar EPUs com base no padrão de 10 agentes de sondagem de eventos por EPU. No entanto, cada agente de sondagem de eventos pode ser escalado de forma independente para oferecer suporte a até 5 MB/s de capacidade de throughput, o que pode exigir menor densidade de agentes de sondagem de eventos em uma EPU específica e acionar a escalabilidade das EPUs. O número de agentes de sondagem de eventos alocados em uma EPU depende da capacidade computacional consumida por cada agente de sondagem de eventos. Essa abordagem de utilização aprimorada da EPU permite que os agentes de sondagem de eventos com requisitos de throughput variados utilizem a capacidade da EPU de forma eficaz, reduzindo os custos de todos os ESMs.

Agrupamento de ESM

Para otimizar ainda mais os custos do modo provisionado, é possível agrupar vários ESMs de Kafka para compartilhar a capacidade da EPU. Com o agrupamento de ESM e a utilização aprimorada da EPU, é possível reduzir os custos do modo provisionado em até 90% para workloads de baixo throughput em comparação com a execução no modo ESM único. Todos os ESMs que exigem menos de 1 capacidade de EPU se beneficiarão do agrupamento de ESM. Esses ESMs normalmente exigem poucos agentes de sondagem de eventos mínimos para atender às suas necessidades de throughput. Esse recurso permitirá que você adote o modo provisionado para todas as suas workloads do Kafka e se beneficie de atributos como validação de esquema, filtragem de eventos Avro/Protobuf, invocações de baixa latência e tratamento aprimorado de erros, disponíveis somente no modo provisionado.

Quando você configura o parâmetro PollerGroupName com o mesmo valor para vários ESMs dentro da mesma Amazon VPC, esses ESMs compartilham recursos de EPU em vez de cada um exigir capacidade de EPU dedicada. É possível agrupar até 100 ESMs por grupo de agentes de sondagem e agregar o máximo de agentes de sondagem em todos os ESMs em um grupo que não pode exceder 2.000.

Para configurar o agrupamento de ESM (console)

Para configurar o agrupamento de ESM (AWS CLI)

O exemplo a seguir cria um ESM com um grupo de agentes de sondagem chamado production-app-group:

aws lambda create-event-source-mapping \
  --function-name myFunction1 \
  --event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster/abcd1234 \
  --topics topic1 \
  --starting-position LATEST \
  --provisioned-poller-config '{
    "MinimumPollers": 1, 
    "MaximumPollers": 10, 
    "PollerGroupName": "production-app-group"
  }'

Para adicionar outro ESM ao mesmo grupo (compartilhando a capacidade de EPU), use o mesmo PollerGroupName:

aws lambda create-event-source-mapping \
  --function-name myFunction2 \
  --event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster/abcd1234 \
  --topics topic2 \
  --starting-position LATEST \
  --provisioned-poller-config '{
    "MinimumPollers": 1, 
    "MaximumPollers": 10, 
    "PollerGroupName": "production-app-group"
  }'

# Move ESM to a different group
aws lambda update-event-source-mapping \
  --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
  --provisioned-poller-config '{
    "MinimumPollers": 1, 
    "MaximumPollers": 10, 
    "PollerGroupName": "new-group-name"
  }'

# Remove ESM from group (use dedicated resources)
aws lambda update-event-source-mapping \
  --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
  --provisioned-poller-config '{
    "MinimumPollers": 1, 
    "MaximumPollers": 10, 
    "PollerGroupName": ""
  }'

Considerações sobre as estratégias de agrupamento

Exemplo de otimização de custos

Considere um cenário em que você tenha 10 ESMs, cada um configurado com 1 agente de sondagem de eventos e throughput abaixo de 2 MB/s:

Sem agrupamento:

Com agrupamento: