Azure Functions: Conceptos Avanzados y Consideraciones de Rendimiento

Continuamos la serie de artículos sobre Serverless, Azure Functions y Azure Durable Functions con esta entrega sobre Conceptos Avanzados y Consideraciones de Rendimiento.

¿Qué es exactamente el estado en Azure Durable Functions?

Este artículo ha estado mencionando continuamente el concepto de estado del workflow o estado personalizado almacenado en Workflow Custom Status. Conviene profundizar un poco en estos aspectos si se desea entender completamente cómo el framework gestiona el estado en su conjunto y las ejecuciones de las tareas. Estos son los conceptos fundamentales que deberías conocer: Task Hub, Event-sourcing model, Checkpoints y Replays.

Task Hub

Consiste en un conjunto de componentes incluido en Azure Storage y definido en configuración (fichero host.json) que sirven para almacenar el estado de la ejecución de los workflows y controlar su propia ejecución. Los componentes fundamentales son:

· Queues de control y ejecución de acciones. Sirven para activar la ejecución de las funciones.

· Tabla de Históricos: histórico de todos los eventos y acciones realizadas en cada workflow. Utilizada por el propio workflow para reconstruir el último estado almacenado.

· Tabla de Instancias: guarda información a nivel de instancia de workflow, entre ellas el Workflow Custom Status (hasta 16kb). En dicho campo se puede almacenar cualquier objeto personalizado que refleja el estado del workflow de forma adicional a los registros que proporciona el propio framework.

Por tanto, el estado del workflow queda definido por la información almacenada en estas dos tablas.

Event-Sourcing Model

Cada orquestador almacena su estado utilizando un patrón de diseño conocido como event-sourcing.

Este patrón de diseño se basa en registrar de forma secuencial todos los eventos que recibe una única instancia de un orquestador, entendiendo como evento cualquier acción realizada por el orquestador tal como ejecución de funciones de actividad, recepción de eventos externos, ejecución de timers, etc. De esta manera, una instancia puede reconstruir su estado real simplemente reproduciendo todo el histórico de eventos almacenados.

Checkpoints

Cada vez que se va a ejecutar una nueva tarea en el orquestador, el framework guarda automáticamente un registro en la tabla de históricos. Posteriormente, las funciones de actividad son invocadas de forma asíncrona y el workflow queda a la espera de dicha ejecución. El workflow no queda bloqueado, sino que se libera de la memoria y queda suspendido.

Mientras el orquestador está suspendido no incurre en costes. No ocurre lo mismo con las funciones de actividad, las cuales generan costes mientras se están ejecutando, queden a la espera o no de resultado externo. Tenlo muy en cuenta a la hora de diseñar tu arquitectura.

Una vez la función de actividad termina el orquestador es reanudado, se carga en memoria todo el histórico de eventos previamente registrado para recuperar el estado real y se guarda un nuevo registro con el resultado de la función de actividad.

Este proceso de registro en la tabla de históricos antes y después de cada operación asíncrona con sus datos de entrada y salida se conoce como Checkpoint. Asegura que el estado nunca se pierde ante procesos de reciclado de memoria o suspensiones inesperadas de la ejecución del workflow.

Replays

Cuando el workflow se reanuda tras la suspensión de su ejecución a la espera de la devolución de resultados de una función de actividad, se reproduce toda la secuencia de eventos registrada en la tabla de históricos.

Esta reproducción se conoce como replay. No obstante, hay una diferencia muy importante cuando se reproduce un evento previamente registrado. En lugar de volver a ejecutar las funciones de actividad u otros tipos de eventos, se recupera directamente la salida de dichas llamadas directamente de la tabla de históricos. Por ello es muy importante que los workflows sean deterministas.

Consideraciones de Rendimiento

Estos son algunos consejos básicos para mejorar el rendimiento de la ejecución de los workflows:

· Como se ha mencionado en el capítulo anterior toda la información de estado se almacena en la tabla de históricos. Esta tabla es consultada en Azure Storage y cargada en memoria cada vez que se reanuda la ejecución del workflow. La información de salida de cada función de actividad es almacenada y cargada en memoria. Por tanto:

• Usa funciones de actividad que generen resultados lo más ligeros posible.
• Valora el uso de suborquestadores ya que en los replay se toma directamente su salida, sin necesidad de iterar por las funciones de actividad de dichos suborquestadores.

· Considera eliminar registros obsoletos de la tabla de instancias e históricos mediante jobs recurrentes.

· Considera el uso de Extended Sessions:

• Esta propiedad de configuración permite establecer un tiempo mínimo durante el cual el estado del workflow queda almacenado en memoria antes de suspenderse su ejecución.
• Como el estado permanece en memoria durante un intervalo configurado no es necesario acceder a Azure Storage para recuperarlo.
• La mejora de rendimiento se consigue cuando el valor seleccionado es suficientemente alto como para evitar replays y bajo para evitar que el estado del workflow quede almacenado en memoria más tiempo del que necesitan las funciones de actividad para ser ejecutadas.
• Las propiedades (fichero host.json) que controlan este comportamiento son extendedSessionsEnabled y extendedSessionIdleTimeoutInSeconds.

Autor del artículo

Jose Antonio Muro

Solution Architect de Consultoría Tecnológica de Deloitte