Integración de Event Hubs con funciones sin servidor en Azure

Las soluciones que usan Azure Event Hubs junto con Azure Functions se benefician de una arquitectura sin servidor escalable, rentable y capaz de procesar grandes volúmenes de datos casi en tiempo real. Tanto como estos servicios funcionan perfectamente juntos, hay muchas características, configuraciones y laberintos que agregan complejidad a su relación. En este artículo se proporciona una guía sobre cómo aprovechar eficazmente esta integración; para ello, se resaltan las consideraciones y técnicas clave para el rendimiento, la resistencia, la seguridad, la observabilidad y la escala.

Conceptos básicos de Event Hubs

Azure Event Hubs es un servicio de procesamiento de eventos altamente escalable que puede recibir millones de eventos por segundo. Antes de entrar en los patrones y procedimientos recomendados para la integración con Azure Functions, es mejor comprender los componentes fundamentales de Event Hubs.

En el siguiente diagrama se muestra la arquitectura de procesamiento del flujo de Event Hubs:

Eventos

Un evento es un cambio de estado o notificación que se representa como un hecho que se produjo en el pasado. Los eventos son inmutables y se conservan en un centro de eventos, también denominado tema en Kafka. Un centro de eventos consta de una o varias particiones.

Particiones

Cuando el remitente no especifica una partición, los eventos recibidos se distribuyen entre las particiones del centro de eventos. Cada evento se escribe exactamente en una partición y no se envía a varias particiones. Cada partición funciona como un registro en el que los registros se escriben en un patrón de solo anexar. La analogía de un registro de confirmación se usa con frecuencia para describir la naturaleza de cómo se agregan los eventos al final de una secuencia de una partición.

Cuando se usa más de una partición, se pueden usar registros paralelos desde el mismo centro de eventos. Este comportamiento proporciona varios grados de paralelismo y mejora el rendimiento de los consumidores.

Consumidores y grupos de consumidores

Más de un consumidor puede consumir una partición, y cada uno lee y administra sus propios desplazamientos.

Event Hubs incluye el concepto de grupos de consumidores, que habilita varias aplicaciones consumidoras para que cada una tenga una vista separada del flujo de eventos y lea el flujo de forma independiente a su propio ritmo y con sus propios desplazamientos.

Para obtener más información, consulte Análisis en profundidad de los conceptos y características de Event Hubs.

Consumo de eventos con Azure Functions

Azure Functions admite los enlaces de desencadenador y salida para Event Hubs. En esta sección se describe cómo Azure Functions responde a los eventos enviados a un flujo de eventos del centro de eventos mediante desencadenadores.

Cada instancia de una función desencadenada de Event Hubs está respaldada por una única instancia de EventProcessorHost. El desencadenador (con tecnología de Event Hubs) garantiza que solo una instancia de EventProcessorHost puede obtener una concesión en una partición determinada.

Por ejemplo, piense en un centro de eventos con las siguientes características:

• 10 particiones.
• 1000 eventos distribuidos uniformemente en todas las particiones, con un número variable de mensajes en cada partición.

Cuando se habilita la función por primera vez, solo hay una instancia de la función. Vamos a llamar a esta instancia de función Function_1. Function_1 tiene una sola instancia de EventProcessorHost que contiene una concesión en las 10 particiones. Esta instancia lee eventos de las particiones 1-10. A partir de este punto, se producirá una de las siguientes acciones:

• No se necesitan nuevas instancias de función: Function_1 puede procesar los 1000 eventos antes de que la lógica de escalado de Azure Functions surta efecto. En este caso, Function_1 procesa los 1000 mensajes.

  

• Se agrega una instancia adicional de función: el escalado basado en eventos u otra lógica manual o automatizada podría determinar que Function_1 tiene más mensajes de los que puede procesar y, a continuación, crear una nueva instancia de la aplicación de funciones (Function_2). Esta nueva función también tiene asociada una instancia de EventProcessorHost. Como el centro de eventos subyacente detecta que una nueva instancia de host está tratando de leer mensajes, efectúa un equilibrio de carga de las particiones entre las instancias de host. Por ejemplo, las particiones 1-5 pueden asignarse a Function_1 y las particiones 6-10, a Function_2.

  

• Se agregan N instancias de función más: el escalado basado en eventos u otra lógica manual o automatizada determina que tanto Function_1 como Function_2 tienen más mensajes de los que pueden procesar, y se crean N instancias de aplicación de funciones de _. Las instancias se van creando hasta que N es igual o mayor que el número de particiones del centro de eventos. En nuestro ejemplo, Event Hubs vuelve a equilibrar la carga de las particiones, en este caso, entre las instancias Function_1...Function_10.

  

Cuando se produce el escalado, N instancias puede ser un número mayor que el número de particiones del centro de eventos. Esta situación puede producirse mientras el escalado controlado por eventos estabiliza los recuentos de instancias o porque otra lógica manual o automatizada creó más instancias que particiones. En este caso, las instancias de EventProcessorHost solo obtendrán bloqueos en las particiones a medida que estén disponibles en otras instancias, ya que en un momento dado solo una instancia de función del mismo grupo de consumidores puede acceder o leer desde las particiones en las que tiene bloqueos.

Cuando se completa la ejecución de todas las funciones con o sin errores, se agregan puntos de comprobación a la cuenta de almacenamiento asociada. Cuando estos puntos de conexión se agregan correctamente, los 1000 mensajes ya no se vuelven a recuperar.

El escalado dinámico basado en eventos es posible con los planes de Consumo y Premium de Azure. Las aplicaciones de funciones hospedadas de Kubernetes también pueden aprovechar el escalador KEDA para Event Hubs. El escalado basado en eventos no es posible actualmente cuando la aplicación de funciones se hospeda en un plan Dedicado (App Service), que requiere que determine el número correcto de instancias en función de la carga de trabajo.

Para obtener más información, consulte Enlaces de Azure Event Hubs para Azure Functions y Desencadenador de Azure Event Hubs para Azure Functions.

Pasos siguientes

Recursos relacionados

• La supervisión del procesamiento de eventos sin servidor proporciona instrucciones sobre la supervisión de arquitecturas controladas por eventos sin servidor.
• Procesamiento de eventos sin servidor es una arquitectura de referencia que detalla una arquitectura típica de este tipo, con ejemplos de código y análisis de las consideraciones importantes.
• Eliminación de la agrupación por lotes y filtrado en el procesamiento de eventos sin servidor con Event Hubs describe con más detalle cómo funcionan estas partes de la arquitectura.