Modos de escalado del sondeo de eventos de Apache Kafka en Lambda

Puede elegir entre dos modos de escalado del sondeo de eventos para las asignaciones de orígenes de eventos de Amazon MSK y Apache Kafka autoadministrado:

Modo bajo demanda (predeterminado)

Cuando crea inicialmente un origen de eventos de Kafka, 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 inicio 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.

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 mediante un ajuste de escalado automático adaptable. Recomendamos que utilice el modo aprovisionado para las cargas de trabajo de Kafka que tengan requisitos de rendimiento estrictos.

En Lambda, un sondeador de eventos es una unidad de cómputo con capacidades de rendimiento que varían según el tipo de origen del evento. En el caso de Amazon MSK y Apache Kafka autoadministrado, cada sondeador de eventos puede gestionar hasta 5 MB/s de rendimiento o hasta 5 invocaciones simultáneas. Por ejemplo, si el origen de eventos produce una carga útil media de 1 MB y la duración media de la función es de 1 segundo, un único sondeador de eventos de Kafka puede admitir un rendimiento de 5 MB/s y 5 invocaciones simultáneas de Lambda (si se supone que no haya transformación de la carga útil). En el caso de Amazon SQS, cada sondeador de eventos puede gestionar hasta 1 MB/s de rendimiento o hasta 10 invocaciones simultáneas. El uso del modo aprovisionado incurre en costos adicionales en función del uso de sondeadores de eventos. Para obtener más información sobre precios, consulta 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.

Puede configurar el modo aprovisionado para la asignación de orígenes de eventos de Kafka 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 '{}'

Gestión avanzada de errores y características de rendimiento

En el caso de las asignaciones de orígenes de eventos de Kafka con el modo aprovisionado habilitado, puede configurar características adicionales para mejorar la gestión de errores y el rendimiento:

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.

Optimización de costos para el modo aprovisionado

Precios del modo aprovisionado

El modo aprovisionado se cobra en función del mínimo de sondeadores de eventos aprovisionados y de los sondeadores de eventos consumidos durante el escalado automático. Los cargos se calculan mediante una unidad de facturación denominada unidad de sondeador de eventos (EPU). Usted paga por la cantidad y la duración de las EPU utilizadas, medidas en horas-por-unidad-de-sondeador-de-eventos. Puede utilizar el modo aprovisionado con una sola ESM para aplicaciones sensibles al rendimiento o puede agrupar varias ESM en la misma VPC para compartir la capacidad y los costos de la EPU. Analizaremos en profundidad dos capacidades que lo ayudarán a optimizar los costos del modo aprovisionado. Para obtener más información sobre los precios, consulte Precios de AWS Lambda.

Utilización mejorada de la EPU

Cada EPU admite una capacidad de rendimiento de hasta 20 MB/s para el sondeo de eventos y admite un valor predeterminado de 10 sondeadores de eventos. Cuando crea un modo aprovisionado para la ESM de Kafka mediante el establecimiento de un número mínimo y máximo de sondeadores, se utiliza un número mínimo de sondeadores para aprovisionar las EPU, según el valor predeterminado de 10 sondeadores de eventos por EPU. Sin embargo, cada sondeador de eventos se puede escalar de forma independiente para admitir una capacidad de rendimiento de hasta 5 MB/s, lo que puede requerir una menor densidad de sondeadores de eventos en una EPU específica y desencadenar el escalado de las EPU. El número de sondeadores de eventos asignados a una EPU depende de la capacidad de cómputo que consuma cada sondeador de eventos. Este enfoque de utilización mejorada de la EPU permite que los sondeadores de eventos con diferentes requisitos de rendimiento utilicen la capacidad de la EPU de forma eficaz, lo que reduce los costos de todas las ESM.

Agrupación de ESM

Para optimizar aún más los costos del modo aprovisionado, puede agrupar varias ESM de Kafka para compartir la capacidad de la EPU. Con la agrupación de ESM y el uso mejorado de la EPU, puede reducir los costos del modo aprovisionado hasta un 90 % para las cargas de trabajo de bajo rendimiento en comparación con el uso de un solo modo de ESM. Todas las ESM que requieran una capacidad inferior a 1 EPU se beneficiarán de la agrupación de ESM. Estas ESM suelen requerir unos pocos sondeadores de eventos como mínimo para satisfacer sus necesidades de rendimiento. Esta capacidad le permitirá adoptar el modo aprovisionado para todas sus cargas de trabajo de Kafka y beneficiarse de funciones como la validación de esquemas, el filtrado de eventos de Avro/Protobuf, las invocaciones de baja latencia y la mejora de la gestión de errores, que solo están disponibles en el modo aprovisionado.

Cuando configura el parámetro PollerGroupName con el mismo valor para varias ESM dentro de la misma Amazon VPC, esas ESM comparten los recursos de la EPU en lugar de que cada una requiera una capacidad de EPU dedicada. Puede agrupar hasta 100 ESM por grupo de sondeadores y, en total, el número máximo de sondeadores de todas las ESM de un grupo no puede superar las 2000.

Cómo configurar la agrupación de ESM (consola)

Cómo configurar la agrupación de ESM (CLI de AWS)

Con el siguiente ejemplo se crea una ESM con un grupo de sondeadores denominado production-app-group:

aws lambda create-event-source-mapping \
  --function-name myFunction1 \
  --event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster/abcd1234 \
  --topics topic1 \
  --starting-position LATEST \
  --provisioned-poller-config '{
    "MinimumPollers": 1, 
    "MaximumPollers": 10, 
    "PollerGroupName": "production-app-group"
  }'

Para añadir otra ESM al mismo grupo (que comparta la capacidad de la EPU), utilice el mismo PollerGroupName:

aws lambda create-event-source-mapping \
  --function-name myFunction2 \
  --event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster/abcd1234 \
  --topics topic2 \
  --starting-position LATEST \
  --provisioned-poller-config '{
    "MinimumPollers": 1, 
    "MaximumPollers": 10, 
    "PollerGroupName": "production-app-group"
  }'

# Move ESM to a different group
aws lambda update-event-source-mapping \
  --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
  --provisioned-poller-config '{
    "MinimumPollers": 1, 
    "MaximumPollers": 10, 
    "PollerGroupName": "new-group-name"
  }'

# Remove ESM from group (use dedicated resources)
aws lambda update-event-source-mapping \
  --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
  --provisioned-poller-config '{
    "MinimumPollers": 1, 
    "MaximumPollers": 10, 
    "PollerGroupName": ""
  }'

Consideraciones relativas a la estrategia de agrupación

Ejemplo de optimización de costos

Considere un escenario en el que tiene 10 ESM, cada una configurada con un sondeador de eventos y un rendimiento inferior a 2 MB/s:

Sin agrupamiento:

Con agrupamiento: