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

Azure Event Hubs

Funciones de Azure

Azure Monitor

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 profundizar en los patrones y las mejores prácticas para la integración de 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 en todas las particiones, con una cantidad 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. A medida que el centro de eventos subyacente detecta que una nueva instancia de host está intentando leer mensajes, equilibra la carga de las particiones entre las instancias del 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. 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 toda la ejecución de la función (con o sin errores), los puntos de comprobación se confirman en la cuenta de almacenamiento asociada. Cuando el punto de comprobación sea correcto, la función estará lista para procesar un nuevo lote de eventos.

El escalamiento dinámico basado en eventos es posible con los planes Consumo, Flex Consumption y Premiun 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.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

• David Barkol | Especialista en soluciones principales GBB

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

Rendimiento y escalabilidad

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 profundizar en los patrones y las mejores prácticas para la integración de 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 en todas las particiones, con una cantidad 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. A medida que el centro de eventos subyacente detecta que una nueva instancia de host está intentando leer mensajes, equilibra la carga de las particiones entre las instancias del 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. 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 toda la ejecución de la función (con o sin errores), los puntos de comprobación se confirman en la cuenta de almacenamiento asociada. Cuando el punto de comprobación sea correcto, la función estará lista para procesar un nuevo lote de eventos.

El escalamiento dinámico basado en eventos es posible con los planes Consumo, Flex Consumption y Premiun 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.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

• David Barkol | Especialista en soluciones principales GBB

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

Rendimiento y escalabilidad