Plataformas de NuvemConfirmado.AWS Lambda agora suporta filas para Apache Kafka em fontes de eventos auto-gerenciadas, permitindo maior escalabilidade e resiliência para cargas de trabalho orientadas por eventos, dissociando paralelismo da contagem de partições.
AWS Lambda agora suporta filas para Apache Kafka em mapeamentos de fonte de eventos Kafka autogeridos (ESM). Essa capacidade se estende aos clusters Kafka que os clientes operam e gerenciam ofertas como a Confluent Cloud. O recurso permite que os clientes escalem o processamento de cargas de trabalho Kafka além da contagem de partição de um tópico, aumentando a produtividade durante os picos de tráfego e melhorando a resiliência do processamento.
O suporte da fila para os ESMs Kafka autogerenciados é construído em grupos de ações Kafka, que geralmente estão disponíveis no Apache Kafka 4.2 e mais tarde. O lançamento permite que vários pesquisadores de eventos consumam concomitantemente da mesma partição, com cada pesquisador de eventos suportando até 10 invocações simultâneas. Isso dissocia paralelismo da contagem de partições sem mudanças necessárias para os produtores, configuração de tópico ou código de função.
O modo fila não preserva a ordenação de partição e é destinado a cargas de trabalho que não requerem ordens estritas. A capacidade requer um cluster Kafka com grupos de ações habilitados, como Apache Kafka 4.2 ou posterior, e está disponível em todas as regiões comerciais da AWS onde o ESM Kafka está disponível. Os clientes podem criar um ESM Kafka auto-gerenciado com ConsumptionMode definido para filar através do AWS Management Console, Lambda API, AWS CLI, AWS CloudFormation, AWS SAM ou AWS CDK.
O preço padrão da Lambda se aplica. Clientes que configuram o modo provisionado para seu ESM Kafka autogerenciado também pagam pelo uso da Unidade Event Poller (EPU). Anteriormente, os ESMs de Kafka usavam o protocolo do grupo de consumidores de Kafka, que atribui cada partição a exatamente um consumidor dentro de um grupo de consumidores. Os clientes que precisavam de maior paralelismo tiveram que sobreparticionar tópicos ou mover o tráfego para um sistema de fila separado, adicionando infraestrutura para operar e código de produção para manter.
A introdução do consumo baseado na fila para fontes de eventos Kafka autogerenciadas representa uma mudança fundamental em como Lambda escala cargas de trabalho Kafka. Sob o protocolo tradicional do grupo de consumidores, a contagem de partições de um tópico estabelece um teto duro sobre paralelismo: cada partição pode ser atribuída a apenas um consumidor dentro de um grupo. Essa restrição forçou os arquitetos a entrar em um dilema - ou sobrepartição de tópicos na hora da criação (incorrendo em sobrecarga operacional e potencial desequilíbrio de partição) ou aceitar gargalos de transferência durante picos de tráfego. O novo modo de fila, construído em grupos de compartilhamento Kafka (KIP-932), remove este teto permitindo que vários pesquisadores de eventos leiam da mesma partição simultaneamente.
De uma perspectiva de engenharia, a dissociação do paralelismo da contagem de partições tem várias consequências diretas. Primeiro, elimina a necessidade de planejamento de partição preditiva. As equipes não precisam mais estimar o pico de rendimento e as divisórias pré-fornecidas de acordo, em vez disso, o escalonamento de eventos de Lambda pode responder à carga real. Segundo, reduz o raio de explosão de invocações lentas ou falhando. No modo grupo consumidor, um único registro lento bloqueia o progresso em toda sua partição. Com o modo de fila, outros pesquisadores podem continuar processando registros subsequentes da mesma partição, melhorando a latência da cauda e resiliência geral. Em terceiro lugar, simplifica a lógica do produtor: os produtores não precisam mais implementar estratégias personalizadas de particionamento ou rota para sistemas alternativos de fila para alcançar maior paralelismo.
A restrição que o modo de fila não preserva a ordenação de partição é uma troca deliberada documentada no anúncio. Cargas de trabalho que exigem encomendas por chave, como processamento de transações financeiras ou agregações de estado chaveadas por identificação de entidade, devem continuar usando o modo de grupo de consumidores ou implementar garantias de encomenda na camada de aplicação. O anúncio identifica casos de uso adequados: codificação de imagem e vídeo, detecção de fraude, entrega de notificação e ingestão de telemetria. Estes compartilham uma característica comum: cada evento é uma unidade independente de trabalho onde a velocidade de processamento importa mais do que ordens estritas. Os engenheiros devem avaliar seus pedidos antes de migrar os ESMs existentes para o modo de fila.
O modelo de preços introduz uma nova dimensão de custo para usuários de modo provido: unidades de polimento de eventos (EPUs). Enquanto o preço padrão Lambda se aplica às invocações sob demanda, os clientes de modo provido pagam pelo uso da EPU, além de taxas padrão. O anúncio não revela a taxa de preços da EPU ou o mapeamento entre a contagem de eleitores e o consumo de EPU. Esta lacuna de informação significa que equipes em modo provido não podem modelar totalmente implicações de custos sem consultar a página de preços Lambda ou documentação. Para cargas de trabalho sob demanda, o modelo de custo permanece inalterado - pagamento por pedido e duração - mas o aumento do potencial de concorrência pode aumentar a contagem total de invocações durante períodos de ruptura.
Adotar o modo de fila requer um cluster Kafka rodando Apache Kafka 4.2 ou posterior com grupos de compartilhamento ativados. Este requisito de versão pode restringir a adoção para equipes em grupos auto-gerenciados mais velhos ou serviços gerenciados que ainda não atualizaram. O anúncio não especifica se ofertas Kafka gerenciadas pela AWS (como o Amazon MSK) suportam essa característica, nem detalha os passos de configuração de grupo de compartilhamento necessários no lado do cluster. Engenheiros operando clusters auto-gerenciados devem verificar a disponibilidade de grupos de compartilhamento e quaisquer alterações de configuração associadas antes de ativar o modo de fila.
O modelo de concorrência — até 10 invocações simultâneas por poller de eventos, com vários pollers por partição — introduz uma nova dinâmica de escala. O comportamento de escalador de Lambda para o modo de fila não está descrito no anúncio. No modo grupo de consumo, Lambda escala os pesquisadores baseados na contagem de partições e métricas de atraso. Com o modo de fila, os sinais de escala e limites podem diferir. As equipes devem monitorar a concorrência de invocação, as taxas de aceleração e as métricas de votação após a migração para entender o novo perfil de escala. O anúncio não revela contagens máximas por ESM ou por partição.
Erro de manipulação e repetição semântica pode diferir entre os modos de consumo. O anúncio diz que um evento lento ou fracassado não mais sustenta outros eventos na mesma partição, implicando isolamento de falhas por registro. No entanto, não especifica se os registros fracassados são repetidos dentro do mesmo poller, re-queued para outro poller, ou enviados para uma fila de letras mortas. A seção Lambda Developer Guide sobre votação de filas Kafka (referido no anúncio) precisaria ser consultada para esses detalhes. Equipes com rigorosos requisitos de processamento devem verificar a semântica de entrega antes de mudar de modo.
O anúncio enfatiza que o modo fila não requer mudanças nos produtores, configuração de tópicos ou código de função. Esta é uma vantagem operacional significativa: funções de Lambda existentes processando eventos Kafka podem mudar os modos de consumo atualizando o parâmetro ConsumoMode do ESM. No entanto, a mudança de garantia de encomendas significa que as funções que dependem da ordenação de partição para correção exibirão comportamento diferente. As equipes devem auditar sua lógica de função para ordenar dependências, tais como agregações de estado, deduplicação baseada em sequência de partição, ou sistemas a jusante esperando entrega ordenada, antes de migrar.
O anúncio não aborda se um ESM existente pode ser trocado do modo grupo de consumo para o modo fila no lugar, ou se um novo ESM deve ser criado. Também não descreve nenhuma ferramenta de migração, procedimentos de retrocesso ou padrões de coexistência (por exemplo, executando ambos os modos no mesmo tópico com diferentes grupos de consumidores). A referência ao Guia de Desenvolvedor Lambda sugere que esses detalhes operacionais estão documentados lá. Engenheiros que planejam a migração devem consultar esse guia para procedimentos passo a passo e quaisquer limitações na mudança de modo.
Para equipes usando infraestrutura-como-código (CloudFormation, SAM, CDK), a adição do parâmetro ConsumoMode significa que as atualizações do modelo são simples. O anúncio lista todas as principais ferramentas de IAC como apoiado. No entanto, não especifica o nome exato do parâmetro ou formato de valor para cada ferramenta, nem se os recursos existentes do ESM suportam atualizações no local ou requerem substituição. Os usuários de CDK e CloudFormation devem verificar a especificação de recursos para AWS:Lambda::EventSourceMapping para entender o comportamento de atualização.