Configurar as origens de eventos do Amazon MSK para o Lambda

Para usar um cluster do Amazon MSK como origem de eventos para a função do Lambda, você cria um mapeamento da origem do evento que conecta os dois recursos. Esta página descreve como criar um mapeamento da origem do evento para o Amazon MSK.

Esta página pressupõe que você já configurou adequadamente o cluster do MSK e a Amazon Virtual Private Cloud (VPC) em que ele reside. Se você precisar configurar o cluster ou a VPC, consulte Configurar o cluster do Amazon MSK e a rede do Amazon VPC para o Lambda.

Usar um cluster do Amazon MSK como uma origem de eventos

Quando você adiciona seu cluster do Apache Kafka ou do Amazon MSK como um gatilho para a função do Lambda, o cluster é usado como uma origem de eventos.

O Lambda lê os dados de eventos dos tópicos do Kafka que você especifica como Topics em uma solicitação de CreateEventSourceMapping com base na posição inicial especificada. Após o processamento bem-sucedido, seu tópico do Kafka é confirmado no cluster do Kafka.

O Lambda lê as mensagens sequencialmente para cada partição de tópico do Kafka. Uma única carga do Lambda pode conter mensagens de várias partições. Quando mais registros ficam disponíveis, o Lambda continua processando os registros em lotes, com base no valor de BatchSize especificado na solicitação de CreateEventSourceMapping, até a função estar atualizada com o tópico.

Depois que o Lambda processa cada lote, ele confirma os deslocamentos das mensagens nesse lote. Se sua função retorna um erro para qualquer uma das mensagens em um lote, o Lambda tenta novamente todo o lote de mensagens até que o processamento seja bem-sucedido ou as mensagens expiram. É possível enviar registros que apresentaram falha em todas as tentativas a um destino em caso de falha para processamento posterior.

Criar um mapeamento da origem do evento para uma origem de eventos do Amazon MSK

Para criar um mapeamento da origem do evento, você pode usar o console do Lambda, a AWS Command Line Interface (CLI) ou um SDK da AWS.

As etapas do console a seguir adicionam um cluster do Amazon MSK como acionador da função do Lambda. Nos bastidores, isso cria um recurso de mapeamento da origem do evento.

Você também pode criar o mapeamento da origem do evento usando a AWS CLI com o comando create-event-source-mapping. O exemplo a seguir cria um mapeamento da origem do evento para mapear a função do Lambda my-msk-function para o tópico AWSKafkaTopic, começando pela mensagem LATEST. Esse comando também usa o objeto SourceAccessConfiguration para instruir o Lambda a usar a autenticação SASL/SCRAM quando se conectar ao cluster.

aws lambda create-event-source-mapping \
  --event-source-arn arn:aws:kafka:us-east-1:111122223333:cluster/my-cluster/fc2f5bdf-fd1b-45ad-85dd-15b4a5a6247e-2 \
  --topics AWSKafkaTopic \
  --starting-position LATEST \
  --function-name my-kafka-function
  --source-access-configurations '[{"Type": "SASL_SCRAM_512_AUTH","URI": "arn:aws:secretsmanager:us-east-1:111122223333:secret:my-secret"}]'

Se o cluster usar a autenticação mTLS, inclua um objeto SourceAccessConfiguration que especifique a CLIENT_CERTIFICATE_TLS_AUTH e o ARN de uma chave do Secrets Manager. Isso é mostrado no seguinte comando:

aws lambda create-event-source-mapping \
  --event-source-arn arn:aws:kafka:us-east-1:111122223333:cluster/my-cluster/fc2f5bdf-fd1b-45ad-85dd-15b4a5a6247e-2 \
  --topics AWSKafkaTopic \
  --starting-position LATEST \
  --function-name my-kafka-function
  --source-access-configurations '[{"Type": "CLIENT_CERTIFICATE_TLS_AUTH","URI": "arn:aws:secretsmanager:us-east-1:111122223333:secret:my-secret"}]'

Quando o cluster usa a autenticação do IAM, você não precisa de um objeto SourceAccessConfiguration. Isso é mostrado no seguinte comando:

aws lambda create-event-source-mapping \
  --event-source-arn arn:aws:kafka:us-east-1:111122223333:cluster/my-cluster/fc2f5bdf-fd1b-45ad-85dd-15b4a5a6247e-2 \
  --topics AWSKafkaTopic \
  --starting-position LATEST \
  --function-name my-kafka-function

Configurar os métodos de autenticação de cluster

O Lambda precisa de permissão para acessar o cluster do Amazon MSK, recuperar registros e realizar outras tarefas. O Amazon MSK é compatível com vários métodos de autenticação com o cluster do MSK.

Acesso não autenticado

Se nenhum cliente acessar o cluster pela Internet, você poderá usar o acesso não autenticado.

Autenticação SASL/SCRAM

O Lambda é compatível com autenticação Simple Authentication and Security Layer/Salted Challenge Response Authentication Mechanism (SASL/SCRAM), com a função de hash SHA-512 e com a criptografia de Transport Layer Security (TLS). Para que o Lambda se conecte ao cluster, armazene as credenciais de autenticação (nome de usuário e senha) em um segredo do Secrets Manager e referencie esse segredo quando configurar o mapeamento da origem do evento.

Para obter mais informações sobre o uso do Secrets Manager, consulte Sign-in credentials authentication with Secrets Manager no Amazon Managed Streaming for Apache Kafka Developer Guide.

Autenticação TLS mútua

O Mutual TLS (mTLS) fornece autenticação bidirecional entre o cliente e o servidor. O cliente envia um certificado ao servidor para que o servidor verifique o cliente. O servidor também envia um certificado para o cliente para que ele verifique o servidor.

Para integrações do Amazon MSK com o Lambda, o cluster do MSK atua como servidor e o Lambda atua como cliente.

O Amazon MSK não é compatível com certificados de servidor auto-assinados. Todos os agentes no Amazon MSK usam certificados públicos assinados por CAs do Amazon Trust Services, em que o Lambda confia por padrão.

-----BEGIN CERTIFICATE-----  
        <certificate contents>
-----END CERTIFICATE-----      

-----BEGIN PRIVATE KEY-----  
         <private key contents>
-----END PRIVATE KEY-----            

-----BEGIN ENCRYPTED PRIVATE KEY-----  
          <private key contents>
-----END ENCRYPTED PRIVATE KEY-----           

{
 "privateKeyPassword": "testpassword",
 "certificate": "-----BEGIN CERTIFICATE-----
MIIE5DCCAsygAwIBAgIRAPJdwaFaNRrytHBto0j5BA0wDQYJKoZIhvcNAQELBQAw
...
j0Lh4/+1HfgyE2KlmII36dg4IMzNjAFEBZiCRoPimO40s1cRqtFHXoal0QQbIlxk
cmUuiAii9R0=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFgjCCA2qgAwIBAgIQdjNZd6uFf9hbNC5RdfmHrzANBgkqhkiG9w0BAQsFADBb
...
rQoiowbbk5wXCheYSANQIfTZ6weQTgiCHCCbuuMKNVS95FkXm0vqVD/YpXKwA/no
c8PH3PSoAaRwMMgOSA2ALJvbRz8mpg==
-----END CERTIFICATE-----",
 "privateKey": "-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIFKzBVBgkqhkiG9w0BBQ0wSDAnBgkqhkiG9w0BBQwwGgQUiAFcK5hT/X7Kjmgp
...
QrSekqF+kWzmB6nAfSzgO9IaoAaytLvNgGTckWeUkWn/V0Ck+LdGUXzAC4RxZnoQ
zp2mwJn2NYB7AZ7+imp0azDZb+8YG2aUCiyqb6PnnA==
-----END ENCRYPTED PRIVATE KEY-----"
} 

Para obter mais informações sobre o mTLS para Amazon MSK e instruções para gerar um certificado de cliente, consulte Mutual TLS client authentication for Amazon MSK no Amazon Managed Streaming for Apache Kafka Developer Guide.

Autenticação do IAM

Você pode usar o AWS Identity and Access Management (IAM) para autenticar a identidade dos clientes que se conectam ao cluster do MSK. Com a autenticação do IAM, o Lambda depende das permissões do perfil de execução da função para se conectar ao cluster, recuperar registros e realizar outras ações necessárias. Para ver um exemplo de política com as permissões necessárias, consulte Create authorization policies for the IAM role no Amazon Managed Streaming for Apache Kafka Developer Guide.

Se a autenticação do IAM estiver ativa no cluster do MSK e você não fornecer um segredo, o Lambda usará automaticamente a autenticação do IAM por padrão.

Para obter mais informações sobre a autenticação do IAM no Amazon MSK, consulte IAM access control.

Como o Lambda escolhe um operador de bootstrap

O Lambda escolhe um operador de bootstrap com base nos métodos de autenticação disponíveis no cluster e dependendo de você fornecer um segredo para autenticação. Se você fornecer um segredo para mTLS ou SASL/SCRAM, o Lambda escolherá esse método de autenticação automaticamente. Se você não fornecer um segredo, o Lambda selecionará o método de autenticação mais forte que estiver ativo no seu cluster. Veja a seguir a ordem de prioridade na qual o Lambda seleciona um operador, da autenticação mais forte para a mais fraca:

ID de grupo de consumidores personalizável

Ao configurar o Kafka como uma origem de eventos, você pode especificar o ID de um grupo de consumidores. Esse ID de grupo de consumidores é um identificador existente para o grupo de consumidores do Kafka no qual você deseja que a função do Lambda ingresse. Você pode usar esse recurso para migrar facilmente qualquer configuração de processamento em andamento de registros do Kafka de outros consumidores para o Lambda.

O Kafka distribui mensagens para todos os consumidores de um grupo de consumidores. Se você especificar o ID de um grupo de consumidores que tenha outros consumidores ativos, o Lambda receberá apenas uma parte das mensagens do tópico do Kafka. Se você quiser que o Lambda lide com todas as mensagens do tópico, desative todos os outros consumidores desse grupo de consumidores.

Além disso, se você especificar o ID de um grupo de consumidores e o Kafka encontrar um grupo de consumidores válido já existente com o mesmo ID, o Lambda ignorará a StartingPosition no mapeamento da origem do evento. Em vez disso, o Lambda começará a processar registros de acordo com o deslocamento confirmado do grupo de consumidores. Se você especificar um ID de grupo de consumidores e o Kafka não conseguir encontrar um grupo de consumidores existente, o Lambda configurará a origem de eventos com a StartingPosition especificada.

O ID do grupo de consumidores que você especificar deverá ser exclusivo entre todas as origens de eventos do Kafka. Após criar um mapeamento de origem de eventos do Kafka com o ID do grupo de consumidores especificado, você não poderá atualizar esse valor.

Posições iniciais de sondagem e fluxo

O parâmetro StartingPosition informa ao Lambda quando começar a ler as mensagens do fluxo. Existem três opções à escolha:

A pesquisa de fluxo durante a criação ou atualização de um mapeamento da origem do evento acaba sendo consistente:

Esse comportamento significa que, se você especificar LATEST como posição inicial do fluxo, o mapeamento da origem do evento poderá ignorar alguns eventos durante a criação ou a atualização. Para garantir que nenhum evento seja ignorado, especifique TRIM_HORIZON ou AT_TIMESTAMP.

Modos de escalação do pesquisador de eventos

É possível escolher entre dois modos de escalação de pesquisador de eventos para o mapeamento da origem do evento do Kafka:

Modo sob demanda (padrão)

Quando você cria inicialmente uma origem de eventos do Amazon MSK, o Lambda aloca um número padrão de pesquisadores de eventos para processar todas as partições no tópico do Kafka. O Lambda aumenta ou diminui automaticamente o número de pesquisadores 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 pesquisadores de eventos do tópico. Esse processo de ajuste de escala automático para adicionar ou remover pesquisadores 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 pesquisadores de eventos. Essa ação reduz a workload na função, reduzindo o número de mensagens que os pesquisadores 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 pesquisadores de eventos provisionados. Esses pesquisadores 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 pesquisador de eventos é uma unidade computacional capaz de lidar com até 5 MBps de throughput. Como referência, suponha que sua origem de eventos produza uma carga útil média de 1 MB e que a duração média da função seja de 1 segundo. Se a carga útil não passar por nenhuma transformação (como filtragem), um único pesquisador oferece suporte a um throughput de 5 MBps e 5 invocações simultâneas do Lambda. O uso do modo provisionado incorre em custos adicionais. Para estimativas de preços, consulte Preços do AWS Lambda.

No modo provisionado, o intervalo de valores aceitos para o número mínimo de pesquisadores de eventos (MinimumPollers) está entre 1 e 200, inclusive. O intervalo de valores aceitos para o número máximo de pesquisadores 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 pesquisadores de eventos, consulte Práticas recomendadas e considerações ao usar o modo provisionado.

Você pode configurar o modo provisionado para o mapeamento da origem de eventos do Amazon MSK usando o console ou a API do Lambda.

Você pode 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 pesquisadores 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 '{}'

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

A configuração ideal de pesquisadores 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 pesquisadores 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 pesquisadores de eventos para lidar com picos repentinos de mensagens. Para determinar os pesquisadores 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 pesquisador de eventos (até 5 MBps) como referência.

Para manter o processamento ordenado em uma partição, o Lambda limita o máximo de pesquisadores de eventos ao número de partições no tópico. Além disso, o número máximo de pesquisadores 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.

Criar mapeamentos da origem do evento entre contas

Você pode usar a conectividade privada com várias VPCs para conectar uma função do Lambda a um cluster DO MSK provisionado em outra Conta da AWS. A conectividade com várias VPCs usa AWS PrivateLink, que mantém todo o tráfego na rede da AWS.

Para criar um mapeamento da origem de eventos entre contas, primeiro você precisa configurar a conectividade com várias VPCs para o cluster do MSK. Ao criar o mapeamento da origem de eventos, use o ARN da conexão VPC gerenciada, em vez do ARN do cluster, conforme mostrado nos exemplos a seguir. A operação CreateEventSourceMapping também difere dependendo do tipo de autenticação usado pelo cluster do MSK.

aws lambda create-event-source-mapping \
  --event-source-arn arn:aws:kafka:us-east-1:111122223333:vpc-connection/444455556666/my-cluster-name/51jn98b4-0a61-46cc-b0a6-61g9a3d797d5-7 \
  --topics AWSKafkaTopic \
  --starting-position LATEST \
  --function-name my-kafka-function

aws lambda create-event-source-mapping \
  --event-source-arn arn:aws:kafka:us-east-1:111122223333:vpc-connection/444455556666/my-cluster-name/51jn98b4-0a61-46cc-b0a6-61g9a3d797d5-7 \
  --topics AWSKafkaTopic \
  --starting-position LATEST \
  --function-name my-kafka-function \
  --source-access-configurations '[{"Type": "SASL_SCRAM_512_AUTH","URI": "arn:aws:secretsmanager:us-east-1:444455556666:secret:my-secret"}]'

aws lambda create-event-source-mapping \
  --event-source-arn arn:aws:kafka:us-east-1:111122223333:vpc-connection/444455556666/my-cluster-name/51jn98b4-0a61-46cc-b0a6-61g9a3d797d5-7 \
  --topics AWSKafkaTopic \
  --starting-position LATEST \
  --function-name my-kafka-function \
  --source-access-configurations '[{"Type": "CLIENT_CERTIFICATE_TLS_AUTH","URI": "arn:aws:secretsmanager:us-east-1:444455556666:secret:my-secret"}]'

Parâmetros de configuração de origem do evento do Amazon MSK

Todos os tipos de origem de evento Lambda compartilham o mesmoCreateEventSourceMappingeUpdateEventSourceMappingOperações de API do. Porém, apenas alguns dos parâmetros se aplicam ao Amazon MSK, como mostra a tabela a seguir.