Utilizar Lambda con un Apache Kafka clúster - AWS Lambda

Utilizar Lambda con un Apache Kafka clúster

Apache Kafka es un almacén de datos distribuido optimizado para ingerir y procesar datos de streaming en tiempo real.

Kafka se utiliza principalmente para crear canalizaciones de datos de streaming y aplicaciones que se adaptan a los flujos de datos. Combina mensajería, almacenamiento y procesamiento de secuencias para permitir el almacenamiento y el análisis de datos históricos y en tiempo real.

AWS proporciona un servicio de Kafka administrado o puede utilizar un clúster que no sea deAWS Kafka con Lambda.

Alojamiento de un clúster Apache Kafka

Puede alojar un clúster de Apache Kafka en AWS o en cualquier otro proveedor de nube de su elección. Lambda admite Kafka como un origen del evento independientemente de dónde esté alojado, siempre y cuando Lambda pueda acceder al clúster.

Uso Amazon MSK

Para hospedar el Apache Kafka clúster y los temas, puede usar Amazon Managed Streaming for Apache Kafka (Amazon MSK).

Para obtener más información acerca del uso de una MSK clúster, consulte Uso de Lambda con Amazon MSK.

Uso de un proveedor Kafka autoadministrado.

Para alojar el clúster Apache Kafka y los temas, puede utilizar cualquier proveedor que no seaAWS en la nube, como CloudKarafka.

También puede utilizar otras opciones de alojamiento AWS para el Apache Kafka clúster y los temas. Para obtener más información, consulte Prácticas recomendadas para ejecutar Apache Kafka AWSen el blog de AWS Big Data.

Para obtener más información sobre el uso de un clúster de Kafka autoadministrado, consulte Usar Lambda con self-managed Apache Kafka.

Utilizar un clúster Apache Kafka como origen de eventos para Lambda

Puede alojar un clúster de Apache Kafka en AWS o en cualquier otro proveedor de nube de su elección. Lambda admite Kafka como un origen del evento independientemente de dónde esté alojado, siempre y cuando Lambda pueda acceder al clúster.

Requisitos previos

Cómo funciona

Cuando agrega el clúster de Apache Kafka como desencadenador de la función Lambda, el clúster se utiliza como un origen del evento. Cuando agrega el clúster y el tema de Kafka como origen de eventos, Lambda crea un grupo de consumidores con un origen de eventos UUID.

  • Si utiliza un clúster Amazon Managed Streaming for Apache Kafka (Amazon MSK) como origen de eventos en EventSourceArn, Lambda lee los datos de eventos mediante el Amazon MSK clúster y el tema Kafka que especifique.

  • Si utiliza un clúster de Apache Kafka no alojado en AWS—o un clúster de Apache Kafka alojado en AWS en otro servicio de AWS—como origen de evento en SelfManagedEventSource, Lambda lee los datos del evento mediante el host Kafka, tema y detalles de conexión que especifique.

  • Lambda lee los datos de eventos de los temas de Kafka que especifique en Topics función de la posición inicial que especifique en StartingPosition. Después de un procesamiento exitoso, su tema de Kafka se compromete a su clúster de Kafka.

  • Lambda procesa registros de una o más particiones de temas de Kafka que especifique y envía una carga JSON a su función Lambda. Cuando hay más registros disponibles, Lambda continúa procesando registros en lotes, según el valor que especifique en BatchSize, hasta que la función se ponga al día con el tema.

  • Lambda soporta autenticación simple y autenticación de capa de seguridad/mecanismo de autenticación de respuesta por desafío salado (SASL/SCRAM) para sus brokers de Kafka. Lambda utiliza el nombre de usuario SASL/SCRAM y la contraseña que especifique en su AWS Secrets Manager secreto en SourceAccessConfigurations.

Para Amazon MSK y self-managed Apache Kafka, la cantidad máxima de tiempo que Lambda permite que una función se ejecute antes de detenerla es de 14 minutos.

Operaciones de API de origen de eventos

Cuando agrega su clúster de Kafka como un origen del evento para su Lambda función mediante la consola Lambda, un AWS SDK o el AWS Command Line Interface (AWS CLI), Lambda utiliza API para procesar su solicitud.

Para administrar un origen de eventos con la AWS CLI o el SDK de AWS, puede utilizar las siguientes operaciones de la API:

Errores de mapeo de origen de eventos

Cuando agrega el clúster Apache Kafka como un origen del evento para su función Lambda, si su función encuentra un error, su consumidor de Kafka deja de procesar registros. Los consumidores de una partición de tema son aquellos que se suscriben, leen y procesan sus registros. Sus otros consumidores de Kafka pueden continuar procesando registros, siempre que no encuentren el mismo error.

Para determinar la causa de un consumidor detenido, compruebe el StateTransitionReason campo en la respuesta de EventSourceMapping. En la siguiente lista se describen los errores de origen de eventos que puede recibir:

ESM_CONFIG_NOT_VALID

La configuración de mapeo de origen del evento no es válida.

EVENT_SOURCE_AUTHN_ERROR

Lambda no pudo autenticar el origen del evento.

EVENT_SOURCE_AUTHZ_ERROR

Lambda no tiene los permisos necesarios para acceder al origen del evento.

FUNCTION_CONFIG_NOT_VALID

La configuración de la función Lambda no es válida.

nota

Si los registros de Lambda eventos superan el límite de tamaño permitido de 6 MB, pueden no procesarse.

Usar Lambda con self-managed Apache Kafka

Puede incorporarse a una clúster de Apache Kafka no alojado en AWS—o clúster de Apache Kafka alojado en AWS en otro servicio de AWS—como origen del evento para una función Lambda. Esto le permite activar sus funciones en respuesta a los registros enviados a su clúster de Kafka.

Administrar el acceso y los permisos de un clúster self-managed Apache Kafka

Lambda sondea las particiones del tema de Apache Kafka en busca de nuevos registros e invoca la función Lambda de forma sincrónica. Para actualizar otros recursos de AWS que utiliza el clúster, la función Lambda, así como los usuarios y roles de AWS Identity and Access Management (IAM), deben tener permiso para realizar estas acciones.

En esta página se describe cómo conceder permisos a Lambda y a otros usuarios del clúster de Kafka autogestionado.

Permisos Lambda de función necesarios

Para crear y almacenar registros en un grupo de registro Amazon CloudWatch Logs, la función Lambda debe tener los siguientes permisos en su función de ejecución:

Permisos de función opcional Lambda

Es posible que su Lambda función necesite permiso para describir su AWS Secrets Manager secreto o su AWS Key Management Service (AWS KMS) CMK administrado por el cliente, o para acceder a su Virtual Private Cloud (VPC).

permisos Secrets Manager y AWS KMS

Si sus usuarios de Kafka acceden a sus Apache Kafka corredores a través de Internet, debe especificar un Secrets Manager secreto. Para obtener más información, consulte Uso de la autenticación SASL/SCRAM.

Es posible que su Lambda función necesite permiso para describir su Secrets Manager secreto o descifrar el CMK administrado por el AWS KMS cliente. Para acceder a estos recursos, el rol de ejecución de la función debe tener los siguientes permisos:

Permisos VPC

Si solo los usuarios de la VPC acceden al self-managed Apache Kafka clúster, la Lambda función necesita permiso para acceder a sus recursos Amazon Virtual Private Cloud (Amazon VPC), incluida la VPC, las subredes, los grupos de seguridad y las interfaces de red. Para acceder a estos recursos, el rol de ejecución de la función debe tener los siguientes permisos:

Agregar permisos a su rol de ejecución

Para tener acceso a otros AWS servicios que utiliza el self-managed Apache Kafka clúster, Lambda utiliza las directivas de permisos que defina en el rol de ejecución de la función.

De forma predeterminada, Lambda no está permitido realizar las acciones necesarias u opcionales para un clúster self-managed Apache Kafka. Debe crear y definir estas acciones en una directiva de confianza IAM y, a continuación, adjuntarla a su rol de ejecución. En este ejemplo se muestra cómo puede crear una directiva que permita a Lambda tener acceso a los recursos Amazon VPC.

{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "ec2:CreateNetworkInterface", "ec2:DescribeNetworkInterfaces", "ec2:DescribeVpcs", "ec2:DeleteNetworkInterface", "ec2:DescribeSubnets", "ec2:DescribeSecurityGroups" ], "Resource":"arn:aws:ec2:us-east-1:01234567890:instance/my-instance-name" } ] }

Para obtener información acerca de cómo crear un documento de directiva JSON en la IAM consola, vea Creación de directivas en la ficha JSON en el Guía del usuario de IAM.

Agregar usuarios a una directiva IAM

De forma predeterminada, los usuarios IAM y las funciones no tienen permiso para realizar operaciones de API de origen de eventos. Para conceder acceso a los usuarios de su organización o cuenta, es posible que deba crear una directiva basada en la identidad. Para obtener más información, consulte Controlar el acceso a AWS recursos mediante directivas en Guía del usuario de IAM.

Uso de la autenticación SASL/SCRAM

importante

Los agentes de texto sin formato no son compatibles si está utilizando la autenticación basada en SASL/SCRAM. Debe utilizar el cifrado TLS para sus agentes.

La autenticación de nombre de usuario y contraseña para un self-managed Apache Kafka clúster utiliza Autenticación simple y el Mecanismo de autenticación de respuesta por desafío saltado (SASL/SCRAM). SCRAM utiliza algoritmos hash seguros y no transmite contraseñas de texto sin formato entre el cliente y el servidor. Para obtener más información acerca de la autenticación SASL/SCRAM, consulte RFC 5802.

Para configurar la autenticación de nombre de usuario y contraseña para su clúster de Kafka autogestionado, cree un secreto en AWS Secrets Manager. El proveedor noAWS en la nube debe proporcionar su nombre de usuario y contraseña en formato SASL/SCRAM. Por ejemplo:

{ "username": "ab1c23de", "password": "qxbbaLRG7JXYN4NpNMVccP4gY9WZyDbp" }

Para obtener más información, consulte Tutorial: Creación y recuperación de un secreto en Guía del usuario de AWS Secrets Manager.

Agregar un clúster self-managed Apache Kafka como origen de eventos

Puede utilizar una función Lambda para procesar registros del clúster de Apache Kafka cuando el clúster está configurado como origen de eventos. Para crear un mapeo de origen de eventos, puede agregar el clúster de Kafka como un desencadenador de función Lambda mediante la consola de Lambda, el SDK de AWS o la AWS Command Line Interface (AWS CLI).

En esta sección se describe cómo agregar el clúster y el tema de Kafka como un desencadenador de función mediante la consola de Lambda o la AWS CLI.

Requisitos previos

Añadir un clúster de self-managed Apache Kafka utilizando la consola Lambda

Siga estos pasos para agregar su clúster self-managed Apache Kafka y un tema Kafka como desencadenador de su función Lambda.

Para agregar un disparador Apache Kafka a su función Lambda (consola)

  1. Abra la Página de Funciones de la consola de Lambda.

  2. Elija el nombre de su función Lambda.

  3. En Function overview (Descripción general de la función), elija Add trigger (Agregar disparador).

  4. En Configuración del disparador, elija el tipo de Apache Kafka desencadenador.

  5. Configure las opciones restantes y luego elija Añadir.

Agregar un clúster self-managed Apache Kafka mediante AWS CLI

Utilice los siguientes comandos AWS CLI de ejemplo para crear y ver un desencadenador self-managed Apache Kafka para su función Lambda.

Uso de SASL/SCRAM

Si los usuarios de Kafka acceden a sus brokers de Kafka a través de Internet, debe especificar el AWS Secrets Manager secreto que creó para la autenticación SASL/SCRAM. En el ejemplo siguiente se utiliza el comando de AWS CLI create-event-source-mapping para mapear una función Lambda denominada my-kafka-function en un tema de Kafka denominado AWSKafkaTopic.

aws lambda create-event-source-mapping --topics AWSKafkaTopic --source-access-configuration Type=SASL_SCRAM_512_AUTH,URI=arn:aws:secretsmanager:us-east-1:01234567890:secret:MyBrokerSecretName --function-name arn:aws:lambda:us-east-1:01234567890:function:my-kafka-function --self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc3.xyz.com:9092", "abc2.xyz.com:9092"]}}'

Para obtener más información, consulte la documentación de referencia de la API CreateEventSourceMapping.

Uso de una VPC

Si solo los usuarios de Kafka de su Virtual Private Cloud (VPC) acceden a sus agentes de Kafka, debe especificar su VPC, subredes y grupo de seguridad de VPC. En el ejemplo siguiente se utiliza el comando de AWS CLI create-event-source-mapping para mapear una función Lambda denominada my-kafka-function en un tema de Kafka denominado AWSKafkaTopic.

aws lambda create-event-source-mapping --topics AWSKafkaTopic --source-access-configuration '[{"Type": "VPC_SUBNET", "URI": "subnet:subnet-0011001100"},{"Type": "VPC_SUBNET", "URI": "subnet:subnet-0022002200"},{"Type": "VPC_SECURITY_GROUP", "URI": "security_group:sg-0123456789"}]' --function-name arn:aws:lambda:us-east-1:01234567890:function:my-kafka-function --self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc3.xyz.com:9092", "abc2.xyz.com:9092"]}}'

Para obtener más información, consulte la documentación de referencia de la API CreateEventSourceMapping.

Visualización del estado

En el ejemplo siguiente se utiliza el comando de AWS CLI get-event-source-mapping para describir el estado del mapeo de origen de eventos creado.

aws lambda get-event-source-mapping --uuid dh38738e-992b-343a-1077-3478934hjkfd7