Procesamiento de mensajes de Apache Kafka autoadministrado con Lambda

Agregar un clúster de Kafka como origen de eventos

Para crear una asignación de orígenes de eventos, agregue su clúster de Kafka como un desencadenador de una función de Lambda a través de la consola de Lambda, un AWS SDK, o el AWS Command Line Interface (AWS CLI).

En esta sección se describe cómo crear una asignación de orígenes de eventos mediante la consola de Lambda y la AWS CLI.

Requisitos previos

ID del grupo de consumidores personalizable

Al configurar Kafka como origen de eventos, puede especificar un ID de grupo de consumidores. Este ID de grupo de consumidores es un identificador existente para el grupo de consumidores de Kafka al que desea que se una la función de Lambda. Puede utilizar esta característica para migrar sin problemas cualquier configuración de procesamiento de registro de Kafka en curso de otros consumidores a Lambda.

Si especifica un ID de grupo de consumidores y hay otros sondeadores activos dentro de ese grupo de consumidores, Kafka distribuirá los mensajes entre todos los consumidores. En otras palabras, Lambda no recibe todos los mensajes del tema Kafka. Si desea que Lambda gestione todos los mensajes del tema, desactive los demás sondeadores de ese grupo de consumidores.

Además, si especifica un ID de grupo de consumidores y Kafka encuentra un grupo de consumidores existente válido con el mismo ID, Lambda ignora el parámetro StartingPosition para la asignación de orígenes de eventos. En cambio, Lambda comienza a procesar los registros de acuerdo con la compensación comprometida del grupo de consumidores. Si especifica un ID de grupo de consumidores y Kafka no puede encontrar un grupo de consumidores existente, Lambda configura el origen de eventos con el StartingPosition especificado.

El ID del grupo de consumidores que especifique debe ser único entre todos los orígenes de eventos de Kafka. Tras crear una asignación de origen de eventos de Kafka con el ID de grupo de consumidores especificado, no puede actualizar este valor.

Agregar un clúster de Kafka autoadministrado (consola)

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

Agregar un clúster Kafka autoadministrado (AWS CLI)

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

Uso de SASL/SCRAM

Si los usuarios de Kafka acceden a los agentes de Kafka a través de Internet, especifique el secreto de Secrets Manager que creó para la autenticación con SASL/SCRAM. En el siguiente ejemplo se utiliza el comando create-event-source-mapping de la AWS CLI para asignar una función de Lambda llamada my-kafka-function a un tema de Kafka llamado AWSKafkaTopic.

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

Uso de una VPC

Si solo los usuarios de Kafka de su VPC acceden a sus agentes de Kafka, debe especificar su VPC, subredes y grupo de seguridad de VPC. En el siguiente ejemplo se utiliza el comando create-event-source-mapping de la AWS CLI para asignar una función de Lambda llamada my-kafka-function a un tema de Kafka llamado 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:111122223333:function:my-kafka-function \
  --self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc3.xyz.com:9092", "abc2.xyz.com:9092"]}}'

Visualización del estado mediante la AWS CLI

En el siguiente ejemplo se utiliza el comando get-event-source-mapping de la AWS CLI para describir el estado de la asignación de orígenes de eventos que ha creado.

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

Parámetros de configuración de Apache Kafka autoadministrado

Todos los tipos de fuente de eventos Lambda comparten las mismas operaciones CreateEventSourceMapping y UpdateEventSourceMapping de la API. Sin embargo, solo algunos de los parámetros se aplican a Apache Kafka.

Utilizar un clúster de Kafka como origen de eventos

Cuando agrega su clúster de Apache Kafka o Amazon MSK como desencadenador para su función de Lambda, el clúster se utiliza como origen de eventos.

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

Si especifica la StartingPosition como LATEST, Lambda comienza a leer el último mensaje de cada partición que pertenece al tema. Debido a que puede haber algún retraso después de la configuración del desencadenador antes de que Lambda comience a leer los mensajes, Lambda no lee ningún mensaje producido durante este plazo.

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. Una sola carga de Lambda puede contener mensajes de varias particiones. Cuando hay más registros disponibles, Lambda continúa procesando registros en lotes, en función del valor BatchSize que especifique en una solicitud de CreateEventSourceMapping, hasta que la función se ponga al día con el tema.

Si su función devuelve un error para cualquiera de los mensajes de un lote, Lambda reintenta todo el lote de mensajes hasta que el procesamiento sea correcto o los mensajes caduquen. Puede enviar los registros con error en todos los reintentos a un destino en caso de error para su posterior procesamiento.

Posiciones iniciales de flujos y sondeo

Tenga en cuenta que el sondeo de flujos durante la creación y las actualizaciones de la asignación de orígenes de eventos es, en última instancia, coherente.

Este comportamiento significa que, si especifica LATEST como posición inicial del flujo, la asignación de orígenes de eventos podría omitir eventos durante la creación o las actualizaciones. Para garantizar que no se pierda ningún evento, especifique la posición inicial del flujo como TRIM_HORIZON o AT_TIMESTAMP.

Comportamiento de escalado del rendimiento de mensajes para asignaciones de orígenes de eventos de Apache Kafka autoadministradas

Puede elegir entre dos modos de comportamiento de escalado del rendimiento de mensajes para su asignación de orígenes de eventos de Amazon MSK:

Modo predeterminado (bajo demanda)

Al crear inicialmente un origen de eventos de Apache Kafka autoadministrado, Lambda asigna una cantidad predeterminada de sondeos de eventos para procesar todas las particiones en el tema de Kafka. Lambda reduce o escala verticalmente de forma automática el número de sondeos de eventos en función de la carga de mensajes.

En intervalos de un minuto, Lambda evalúa el retraso de compensación del consumidor de todas las particiones del tema. Si el retraso es demasiado alto, la partición recibe mensajes más rápido de lo que Lambda puede procesarlos. Si es necesario, Lambda agrega o elimina a los sondeos de eventos del tema. Este proceso de escalado automático para agregar o eliminar sondeos de eventos se produce dentro de los tres minutos posteriores a la evaluación.

Si su función de Lambda de destino está limitada, Lambda reduce la cantidad de sondeos de eventos. Esta acción reduce la carga de trabajo de la función al reducir el número de mensajes que los sondeos de eventos pueden recuperar y enviar a la función.

Para monitorear el rendimiento de su tema de Kafka, puede ver las métricas de consumo de Apache Kafka, como consumer_lag y consumer_offset.

Configuración del modo aprovisionado

Para las cargas de trabajo en las que necesite afinar el rendimiento de su asignación de orígenes de eventos, puede utilizar el modo aprovisionado. En el modo aprovisionado, usted define los límites mínimos y máximos para la cantidad de sondeos de eventos aprovisionados. Estos sondeos de eventos aprovisionados están dedicados a la asignación de orígenes de eventos y pueden gestionar los picos de mensajes inesperados al instante cuando se producen. Recomendamos que utilice el modo aprovisionado para las cargas de trabajo de Kafka que tengan requisitos de rendimiento estrictos.

En Lambda, un sondeo de eventos es una unidad de cómputo capaz de gestionar hasta 5 MBps de rendimiento. Como referencia, supongamos que el origen de eventos produce una carga útil media de 1 MB y que la duración media de la función es de 1 segundo. Si la carga útil no sufre ninguna transformación (como un filtrado), un único sondeo puede admitir un rendimiento de 5 MBps y 5 invocaciones de Lambda simultáneas. El uso del modo aprovisionado conlleva costos adicionales. Para obtener estimaciones de precios, consulte Precios de AWS Lambda.

En el modo aprovisionado, el rango de valores aceptados para el número mínimo de sondeos de eventos (MinimumPollers) oscila entre 1 y 200, inclusive. El rango de valores aceptados para el número máximo de sondeos de eventos (MaximumPollers) está comprendido entre 1 y 2000, inclusive. MaximumPollers debe ser mayor o igual que MinimumPollers. Además, para mantener el procesamiento ordenado dentro de las particiones, Lambda limita el número de MaximumPollers al número de particiones del tema.

Para obtener más información sobre cómo elegir los valores de sondeos de eventos mínimos y máximos adecuados, consulte Prácticas recomendadas y consideraciones al usar el modo aprovisionado.

Puede configurar el modo aprovisionado para la asignación de orígenes de eventos de Apache Kafka autoadministrado mediante la consola o la API de Lambda.

Puede configurar el modo aprovisionado por programación mediante el objeto ProvisionedPollerConfig de su EventSourceMappingConfiguration. Por ejemplo, el siguiente comando de la CLI UpdateEventSourceMapping configura un valor MinimumPollers de 5 y un valor MaximumPollers de 100.

aws lambda update-event-source-mapping \
    --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
    --provisioned-poller-config '{"MinimumPollers": 5, "MaximumPollers": 100}'

Tras configurar el modo aprovisionado, puede observar el uso de los sondeos de eventos para su carga de trabajo supervisando la métrica ProvisionedPollers. Para obtener más información, consulte Métricas de asignación de orígenes de eventos.

Para deshabilitar el modo aprovisionado y volver al modo predeterminado (bajo demanda), puede usar el siguiente comando de la CLI UpdateEventSourceMapping:

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

Prácticas recomendadas y consideraciones al usar el modo aprovisionado

La configuración óptima de los sondeos de eventos mínimos y máximos para la asignación de orígenes de eventos depende de los requisitos de rendimiento de la aplicación. Recomendamos que lea los sondeos de eventos mínimos predeterminados para establecer una línea de base del perfil de rendimiento. Ajuste la configuración en función de los patrones de procesamiento de mensajes observados y del perfil de rendimiento deseado.

En el caso de cargas de trabajo con un tráfico intenso y necesidades de rendimiento estrictas, aumente el número mínimo de sondeos de eventos para administrar los picos repentinos de mensajes. Para determinar los sondeos de eventos mínimos necesarios, tenga en cuenta los mensajes de su carga de trabajo por segundo y el tamaño medio de la carga útil y utilice la capacidad de rendimiento de un único sondeo de eventos (hasta 5 MBps) como referencia.

Para mantener el procesamiento ordenado dentro de una partición, Lambda limita el número máximo de sondeos de eventos al número de particiones del tema. Además, el número máximo de sondeos de eventos a los que se puede escalar la asignación de orígenes de eventos depende de la configuración de simultaneidad de la función.

Al activar el modo aprovisionado, actualiza la configuración de la red para eliminar los puntos de conexión de VPC AWS PrivateLink y los permisos asociados.

Métricas de Amazon CloudWatch

Lambda emite la métrica OffsetLag mientras la función procesa los registros. El valor de esta métrica es la diferencia de compensación entre el último registro escrito en el tema de origen de eventos de Kafka y el último registro que procesó el grupo de consumidores de su función. Puede utilizar OffsetLag para estimar la latencia entre el momento en el que se agrega un registro y el momento en el que el grupo lo procesa.

Una tendencia ascendente en OffsetLag puede indicar problemas con los sondeadores en el grupo de consumidores de su función. Para obtener más información, consulte Uso de métricas de CloudWatch con Lambda.