O blog da AWS

Acionando funções AWS Lambda a partir do Amazon Managed Streaming para Apache Kafka hospedado em outra conta AWS

Esta publicação foi escrita por Subham Rakshit, arquiteto de soluções especialista sênior, e Ismail Makhlouf, arquiteto de soluções especialista sênior e adaptada para o português por Helton Ribeiro, arquiteto de aplicações cloud sênior.

Muitas organizações usam a estratégia de instalação de aplicativos de processamento de streams segregadas em várias contas AWS. Isso envolve decompor a arquitetura geral em uma única conta de produtor e várias contas de consumidores. Na AWS, na conta do produtor, você pode usar o Amazon Managed Streaming for Apache Kafka (Amazon MSK) e, em suas contas de consumidor, ter funções do AWS Lambda para consumo de eventos. Esta postagem do blog explica como você pode acionar funções do Lambda a partir de um cluster Amazon MSK provisionado em uma outra conta.

O mapeamento de fornecimento de eventos (ESM) do Lambda para o Amazon MSK consulta continuamente novos eventos do cluster do Amazon MSK, os agrega em lotes e, em seguida, aciona a função Lambda de destino. O ESM para Amazon MSK funciona como um conjunto serverless de consumidores do Kafka que garante que cada evento seja processado pelo menos uma vez. Os eventos são processados na mesma ordem em que são recebidos em cada partição do Kafka. Além disso, o ESM agrupa o fluxo de dados e filtra os eventos com base na lógica configurada.

Visão geral

O Amazon MSK oferece suporte a dois tipos diferentes de implantação: provisionada e serverless. O acionamento de uma função Lambda a partir de um cluster Amazon MSK em uma diferente conta só é suportado com um cluster provisionado implantado na mesma região. Para facilitar essa funcionalidade, o Amazon MSK usa conectividade privada de várias VPCs, desenvolvida pelo AWS PrivateLink, o que simplifica a conexão de consumidores do Kafka hospedados em diferentes contas da AWS a um cluster do Amazon MSK.

O diagrama a seguir ilustra a arquitetura desse exemplo:

A arquitetura é dividida em duas partes: o produtor e o consumidor.

Na conta do produtor, você tem o cluster Amazon MSK com conectividade multi-VPC ativada. A conectividade com várias VPCs só está disponível para clusters autenticados do Amazon MSK. As políticas de cluster são necessárias para conceder permissões a outras contas da AWS, permitindo que elas estabeleçam conectividade privada com o cluster Amazon MSK. Você pode delegar permissões a funções ou usuários relevantes. Quando combinadas com a autenticação de cliente do AWS Identity and Access Management (IAM), as políticas de cluster oferecem controle refinado sobre as permissões do plano de dados do Kafka para conectar aplicativos.

Na conta do consumidor, você tem o Lambda ESM para Amazon MSK e a conexão VPC gerenciada implantada na mesma VPC. A conexão VPC gerenciada permite a conectividade privada da VPC do aplicativo de consumo com o cluster Amazon MSK. O Lambda ESM para Amazon MSK se conecta ao cluster Amazon MSK em outra conta por meio da autenticação do IAM. Ele também oferece suporte a clusters autenticados por SASL/SCRAM e TLS mútuo (mTLS). O ESM recebe o evento do tópico Kafka e invoca a função Lambda para processá-lo.

Implantando o aplicativo de exemplo

Para configurar o gatilho da função Lambda a partir de um cluster Amazon MSK de uma diferente conta como fonte do evento, siga estas etapas. Os modelos do AWS CloudFormation para implementar o exemplo estão acessíveis no repositório do GitHub.

Como parte desse exemplo, alguns dados de amostra são publicados usando o produtor do console Kafka e o Lambda processa esses eventos e grava no Amazon S3.

Pré-requisitos

Para este exemplo, você precisa de duas contas da AWS. Esta postagem usa as seguintes convenções de nomenclatura:

  • Produtor (por exemplo, número da conta: 1111 1111 1111): conta que hospeda o cluster Amazon MSK e a instância do cliente Kafka.
  • Consumidor (por exemplo, número da conta: 2222 2222 2222): conta que hospeda a função Lambda e consome eventos do Amazon MSK.

Para começar:

  1. Clone o repositório localmente: git clone https://github.com/aws-samples/lambda-cross-account-msk.git
  2. Configure a conta do produtor: você deve configurar a rede VPC, implantar o cluster Amazon MSK e uma instância cliente Kafka para publicar dados. Para fazer isso, implante o modelo producer-account.yaml do CloudFormation no console da AWS e anote o MSKClusterARN na guia de saídas do CloudFormation.
  3. Configurar a conta do consumidor: para configurar a conta do consumidor, você precisa da função Lambda, da função IAM usada pela função Lambda e do bucket S3 que recebe os dados. Para isso, implante o modelo consumer-account.yaml do CloudFormation a partir do console da AWS com o parâmetro de entrada MSKAccountId, que é o ID da conta AWS do produtor (por exemplo, ID da conta: 1111 1111 1111). Anote o LambdaRoleArn na guia de saídas do CloudFormation.

Configurando a conectividade de várias VPCs no cluster Amazon MSK

Depois que as contas forem criadas, você deverá ativar a conectividade entre elas. Ao habilitar a conectividade privada de várias VPCs no cluster Amazon MSK, você configura a conexão de rede para permitir que os consumidores de várias contas se conectem ao cluster.

  1. Na conta do produtor, navegue até o console do Amazon MSK.
  2. Escolha producer-cluster e vá para a guia Propriedades.
  3. Role até Configurações de rede, escolha Editar e selecione Ativar conectividade multi-VPC. Isso leva algum tempo e, em seguida, aparece da seguinte forma.
  5. Adicione a política de cluster necessária para permitir que consumidores de várias contas se conectem ao Amazon MSK. Na conta do produtor, implante o modelo producer-msk-cluster-policy.yaml do CloudFormation a partir do console da AWS com os seguintes parâmetros de entrada:
    1. MSKClusterARN — Nome de recurso da Amazon (ARN) do cluster Amazon MSK na conta do produtor. Encontre essas informações na saída do CloudFormation de producer-account.yaml.
    2. LambdaRoleArn — ARN da função do IAM anexada à função Lambda na conta do consumidor. Encontre essas informações na saída do CloudFormation de consumer-account.yaml.
    3. LambdaAccountID — ID da conta do consumidor da AWS (por exemplo, ID da conta: 2222 2222 2222).

Criação de um tópico do Kafka no Amazon MSK e publicação de eventos

Na conta do produtor, navegue até o console do Amazon MSK. Escolha o cluster Amazon MSK chamado producer-cluster. Escolha Exibir informações do cliente para mostrar o servidor bootstrap.

O modelo do CloudFormation também implanta uma instância do cliente Kafka para criar tópicos e publicar eventos.

Para acessar o cliente, acesse o console do Amazon EC2 e escolha a instância Producer-KafkaClientInstance1. Conecte-se à instância do EC2 com o Session Manager:

sudo su - ec2-user

#Set MSK Broker IAM endpoint export BS=< >

<Provide IAM bootstrap address here>

Você deve usar o endpoint privado de VPC única para o cluster Amazon MSK e não o endpoint privado de várias VPC, pois publicará eventos de um produtor de console Kafka a partir da conta do produtor.

Execute esses scripts para criar o tópico do cliente e publicar exemplos de eventos no tópico:

./kafka_create_topic.sh

./kafka_produce_events.sh

Criação de uma conexão VPC gerenciada na conta do consumidor

Para estabelecer uma conexão com o cluster Amazon MSK na conta do produtor, você deve criar uma conexão VPC gerenciada na conta do consumidor. O Lambda se comunica com o Amazon MSK entre contas por meio dessa conexão VPC gerenciada.

Para obter etapas detalhadas de configuração, leia a documentação sobre conexão VPC gerenciada pelo Amazon MSK.

Configurando o Lambda ESM para o Amazon MSK

A etapa final é configurar o Lambda ESM para o Amazon MSK. A configuração do ESM permite que você se conecte ao cluster Amazon MSK na conta do produtor por meio do endpoint VPC gerenciado. Isso permite que você acione a função Lambda para processar os dados produzidos a partir do tópico Kafka:

  1. Na conta do consumidor, acesse o console Lambda.
  2. Abra a função Lambda msk-lambda-cross-account-iam.
  3. Vá para a guia Configuração, selecione Acionadores e escolha Adicionar gatilho.
  4. Para a configuração do Trigger, selecione Amazon MSK.

Para configurar esse gatilho:

  1. Selecione o cluster compartilhado do Amazon MSK. Isso automaticamente assume como padrão a autenticação do IAM que é usada para se conectar ao cluster.
  3. Por padrão, a caixa de seleção Activate trigger está habilitada. Isso garante que o gatilho esteja no estado ativo após a criação. Para os outros valores:
    1. Mantenha o tamanho do lote padrão em 100.
    2. Altere a posição inicial para Trim horizon.
    3. Defina o nome do tópico como cliente.
    4. Defina o ID do grupo de consumidores como msk-lambda-iam.

Role até a parte inferior e escolha Adicionar. Isso começa a criar o gatilho do Amazon MSK, o que leva vários minutos. Após a criação, o estado do gatilho é exibido como Ativado.

Verificando a saída no lado do consumidor

A função Lambda recebe os eventos e os grava em um bucket do S3.

Para validar se a função está funcionando, acesse a conta do consumidor e navegue até o console do S3. Pesquise o bucket cross-account-lambda-consumer-data-<REGION><AWS Account Id>. No bucket, você vê os arquivos customer-data-<datetime>.csv.

Limpando

Você deve esvaziar e excluir manualmente o bucket do S3, a conexão VPC gerenciada e o Lambda ESM para Amazon MSK da conta do consumidor. Em seguida, exclua as pilhas do CloudFormation do console da AWS das contas de produtor e consumidor para remover todos os outros recursos criados como parte do exemplo.

Conclusão

Com o Lambda e o Amazon MSK, agora você pode criar um aplicativo descentralizado distribuído em várias contas da AWS. Esta postagem mostra como você pode configurar o Amazon MSK como uma fonte de eventos para funções Lambda entre contas e também explica a configuração necessária nas contas de produtor e consumidor.

Para ler mais sobre o AWS Lambda com o Amazon MSK como fonte de eventos, acesse a documentação.

Para obter mais recursos de aprendizado serverless, visite Serverless Land.

Este blog é uma tradução do blog original em inglês (link aqui).

Tradutor: Helton Ribeiro | Senior Cloud Application Architect