Compartir a través de

Trabajos en segundo plano

Muchos tipos de aplicaciones requieren tareas en segundo plano que se ejecutan independientemente de la interfaz de usuario (UI). Entre los ejemplos se incluyen trabajos por lotes, tareas de procesamiento intensivo y procesos de ejecución prolongada, como flujos de trabajo. Los trabajos en segundo plano se pueden ejecutar sin necesidad de interacción del usuario: la aplicación puede iniciar el trabajo y, a continuación, continuar procesando solicitudes interactivas de los usuarios. Esto puede ayudar a minimizar la carga en la interfaz de usuario de la aplicación, lo que puede mejorar la disponibilidad y reducir los tiempos de respuesta interactivos.

Por ejemplo, si se requiere una aplicación para generar miniaturas de imágenes cargadas por los usuarios, puede hacerlo como un trabajo en segundo plano y guardar la miniatura en el almacenamiento cuando se complete, sin que el usuario necesite esperar a que se complete el proceso. De la misma manera, un usuario que realiza un pedido puede iniciar un flujo de trabajo en segundo plano que procese el pedido, mientras que la interfaz de usuario permite al usuario seguir explorando la aplicación web. Una vez completado el trabajo en segundo plano, puede actualizar los datos de pedidos almacenados y enviar un correo electrónico al usuario que confirma el pedido.

Cuando considere si implementar una tarea como un trabajo en segundo plano, el criterio principal es si la tarea se puede ejecutar sin interacción del usuario y sin la interfaz de usuario que necesite esperar a que se complete el trabajo. Es posible que las tareas que requieran que el usuario o la interfaz de usuario esperen mientras se completen no sean adecuadas como trabajos en segundo plano.

Tipos de trabajos en segundo plano

Normalmente, los trabajos en segundo plano incluyen uno o varios de los siguientes tipos de trabajos:

  • Trabajos intensivos de CPU, como cálculos matemáticos o análisis de modelos estructurales.
  • Trabajos intensivos de E/S, como ejecutar una serie de transacciones de almacenamiento o archivos de indexación.
  • Trabajos por lotes, como actualizaciones nocturnas de datos o procesamientos programados.
  • Flujos de trabajo de larga duración, como el suministro de pedidos o los servicios y sistemas de aprovisionamiento.
  • Procesamiento de datos confidenciales donde la tarea se entrega a una ubicación más segura para su procesamiento. Por ejemplo, es posible que no desee procesar datos confidenciales en una aplicación web. En su lugar, puede usar un patrón como el patrón Gatekeeper para transferir los datos a un proceso en segundo plano aislado que tenga acceso al almacenamiento protegido.

Desencadenadores

Los trabajos en segundo plano se pueden iniciar de varias maneras diferentes. Se dividen en una de las siguientes categorías:

Desencadenadores basados en eventos

La invocación controlada por eventos usa un desencadenador para iniciar la tarea en segundo plano. Entre los ejemplos de uso de desencadenadores controlados por eventos se incluyen:

  • La interfaz de usuario u otro trabajo coloca un mensaje en una cola. El mensaje contiene datos sobre una acción que se ha realizado, como el usuario que realiza un pedido. La tarea en segundo plano escucha en esta cola y detecta la llegada de un nuevo mensaje. Lee el mensaje y usa los datos en él como entrada para el trabajo en segundo plano. Este patrón se conoce como comunicación asincrónica basada en mensajes.
  • La interfaz de usuario u otro trabajo guarda o actualiza un valor en el almacenamiento. La tarea en segundo plano supervisa el almacenamiento y detecta los cambios. Lee los datos y lo usa como entrada para el trabajo en segundo plano.
  • La interfaz de usuario u otro trabajo realiza una solicitud a un punto de conexión, como un URI HTTPS o una API que se expone como un servicio web. Pasa los datos necesarios para completar la tarea en segundo plano como parte de la solicitud. El punto de conexión o servicio web invoca la tarea en segundo plano, que usa los datos como entrada.

Entre los ejemplos típicos de tareas adecuadas para la invocación controlada por eventos se incluyen el procesamiento de imágenes, los flujos de trabajo, el envío de información a servicios remotos, el envío de mensajes de correo electrónico y el aprovisionamiento de nuevos usuarios en aplicaciones multiinquilino.

Desencadenadores basados en programación

La invocación controlada por programación usa un temporizador para iniciar la tarea en segundo plano. Entre los ejemplos de uso de desencadenadores controlados por programación se incluyen:

  • Un temporizador que se ejecuta localmente dentro de la aplicación o como parte del sistema operativo de la aplicación invoca una tarea en segundo plano de forma periódica.
  • Un temporizador que se ejecuta en una aplicación diferente, como Azure Logic Apps, envía una solicitud a una API o un servicio web de forma periódica. La API o el servicio web invoca la tarea en segundo plano.
  • Un proceso o aplicación independientes inicia un temporizador que hace que la tarea en segundo plano se invoque una vez después de un retraso de tiempo especificado o en un momento específico.

Entre los ejemplos típicos de tareas adecuadas para la invocación controlada por programación se incluyen rutinas de procesamiento por lotes (como actualizar listas de productos relacionados para los usuarios en función de su comportamiento reciente), tareas de procesamiento de datos rutinarias (como actualizar índices o generar resultados acumulados), análisis de datos para informes diarios, limpieza de retención de datos y comprobaciones de coherencia de datos.

Si usa una tarea controlada por programación que debe ejecutarse como una sola instancia, tenga en cuenta las siguientes consideraciones:

  • Si se escala la instancia de cómputo que ejecuta el programador (por ejemplo, una máquina virtual utilizando tareas programadas de Windows), entonces es posible que tenga varias instancias del programador en ejecución. Esto podría iniciar varias instancias de la tarea. Para obtener más información sobre esto, lea esta entrada de blog sobre idempotence.
  • Si las tareas se ejecutan durante más tiempo que el período entre eventos del programador, el programador podría iniciar otra instancia de la tarea mientras el anterior todavía se está ejecutando.

Devolución de resultados

Los trabajos en segundo plano se ejecutan de forma asincrónica en un proceso independiente, o incluso en una ubicación independiente, desde la interfaz de usuario o el proceso que invocó la tarea en segundo plano. Idealmente, las tareas en segundo plano son operaciones de "iniciar y olvidar", y su progreso de ejecución no tiene ningún impacto en la interfaz de usuario o en el proceso de llamada. Esto significa que el proceso de llamada no espera a que se completen las tareas. Por lo tanto, no se puede detectar automáticamente cuando finaliza la tarea.

Si necesita una tarea en segundo plano para comunicarse con la tarea de llamada para indicar el progreso o la finalización, debe implementar un mecanismo para ello. Algunos ejemplos son:

  • Escriba un valor de indicador de estado en el almacenamiento accesible para la interfaz de usuario o la tarea de llamada, que puede supervisar o comprobar este valor cuando sea necesario. Otros datos que la tarea en segundo plano debe devolver al autor de la llamada se pueden colocar en el mismo almacenamiento.
  • Se establece una cola de respuesta en la que escucha la interfaz de usuario o la llamada. La tarea en segundo plano puede enviar mensajes a la cola que indique el estado y la finalización. Los datos que la tarea en segundo plano deben devolver al autor de la llamada se pueden colocar en los mensajes. Si usa Azure Service Bus, puede usar las propiedades ReplyTo y CorrelationId para implementar esta funcionalidad.
  • Exponga una API o un punto de conexión de la tarea en segundo plano al que la interfaz de usuario o el autor de la llamada puedan acceder para obtener información sobre el estado. Los datos que la tarea en segundo plano debe devolver al autor de la llamada se pueden incluir en la respuesta.
  • Haga que la tarea en segundo plano vuelva a llamar a la interfaz de usuario o al autor de la llamada a través de una API para indicar el estado en puntos predefinidos o al finalizar. Esto puede deberse a eventos generados localmente o a través de un mecanismo de publicación y suscripción. Los datos que la tarea en segundo plano debe devolver al autor de la llamada se pueden incluir en la solicitud o carga del evento.

Entorno de hospedaje

Puede hospedar tareas en segundo plano mediante una variedad de diferentes servicios de la plataforma Azure:

  • Azure Web Apps y WebJobs. Puede usar WebJobs para ejecutar trabajos personalizados en función de un rango de diferentes tipos de scripts o programas ejecutables en el contexto de una aplicación web.
  • Azure Functions. Puede usar funciones para trabajos en segundo plano que no se ejecutan durante mucho tiempo. Otro caso de uso es si la carga de trabajo ya está hospedada en el plan de App Service y está infrautilizada.
  • Máquinas virtuales de Azure. Si tiene un servicio de Windows o quiere usar el Programador de tareas de Windows, es habitual hospedar las tareas en segundo plano dentro de una máquina virtual dedicada.
  • Azure Batch. Batch es un servicio de plataforma que programa el trabajo intensivo de proceso para ejecutarse en una colección administrada de máquinas virtuales. Puede escalar automáticamente los recursos de proceso.
  • Azure Kubernetes Service (AKS). Azure Kubernetes Service proporciona un entorno de hospedaje administrado para Kubernetes en Azure.
  • Azure Container Apps. Azure Container Apps permite crear microservicios sin servidor basados en contenedores.

En las secciones siguientes se describen estas opciones con más detalle e incluyen consideraciones que le ayudarán a elegir la opción adecuada.

Azure Web Apps y WebJobs

Puede usar Azure WebJobs para ejecutar trabajos personalizados como tareas en segundo plano dentro de una aplicación web de Azure. WebJobs se ejecuta dentro del contexto de la aplicación web como un proceso continuo. WebJobs también se ejecutan en respuesta a eventos desencadenantes de Azure Logic Apps o factores externos, como cambios en los blobs de almacenamiento y las colas de mensajes. Los trabajos se pueden iniciar y detener a petición, y cerrarse correctamente. Si se produce un error en un webJob en ejecución continua, se reiniciará automáticamente. Las acciones de reintento y error se pueden configurar.

Cuando configura un trabajo web:

  • Si desea que el trabajo responda a un desencadenador controlado por eventos, debe configurarlo como Ejecutar continuamente. El script o programa se almacena en la carpeta denominada site/wwwroot/app_data/jobs/continuous.
  • Si desea que el trabajo responda a un desencadenador controlado por programación, debe configurarlo como Ejecutar según una programación. El script o programa se almacena en la carpeta denominada site/wwwroot/app_data/jobs/triggered.
  • Si elige la opción Ejecutar a petición al configurar un trabajo, ejecuta el mismo código que la opción Ejecutar según una programación al iniciarlo.

Azure WebJobs se ejecuta dentro del espacio aislado de la aplicación web. Esto significa que pueden acceder a variables de entorno y compartir información, como cadenas de conexión, con la aplicación web. El trabajo tiene acceso al identificador único de la máquina que está ejecutando el trabajo. La cadena de conexión denominada AzureWebJobsStorage proporciona acceso a las colas, blobs y tablas de Azure Storage para los datos de la aplicación y el acceso a Service Bus para la mensajería y la comunicación. La cadena de conexión denominada AzureWebJobsDashboard proporciona acceso a los archivos de registro de acciones del trabajo.

Azure WebJobs tiene las siguientes características:

  • Seguridad: WebJobs están protegidos por las credenciales de implementación de la aplicación web.
  • Tipos de archivo admitidos: puede definir WebJobs mediante scripts de comandos (), archivos por lotes (.cmd.bat), scripts de PowerShell (.ps1), scripts de shell de Bash (.sh), scripts php (.php), scripts de Python (.py), código javaScript (.js) y programas ejecutables (.exe, .jar, etc.).
  • Implementación: puede implementar scripts y ejecutables mediante Azure Portal, mediante Visual Studio, mediante el SDK de Azure WebJobs o copiandolos directamente en las siguientes ubicaciones:
    • Para la ejecución desencadenada: site/wwwroot/app_data/jobs/triggered/{job name}
    • Para la ejecución continua: site/wwwroot/app_data/jobs/continuous/{job name}
  • Registro: Console.Out se considera (marcado) como INFO. Console.Error se trata como ERROR. Puede acceder a la información de supervisión y diagnóstico mediante Azure Portal. Puede descargar archivos de registro directamente desde el sitio. Se guardan en las siguientes ubicaciones:
    • Para la ejecución desencadenada: Vfs/data/jobs/triggered/jobName
    • Para la ejecución continua: Vfs/data/jobs/continuous/jobName
  • Configuración: puede configurar WebJobs mediante el portal, la API REST y PowerShell. Puede usar un archivo de configuración denominado settings.job en el mismo directorio raíz que el script de trabajo para proporcionar información de configuración para un trabajo. Por ejemplo:
    • { "tiempo_espera_parada": 60 }
    • { "is_singleton": true }

Consideraciones

  • De forma predeterminada, los trabajos web se escalan con la aplicación web. Sin embargo, puede configurar los trabajos para que se ejecuten en una sola instancia estableciendo la propiedad de configuración is_singletonen true. WebJobs de instancia única son útiles para tareas que no desea escalar o ejecutar como múltiples instancias simultáneas, como la reindexación, el análisis de datos y tareas similares.
  • Para minimizar el impacto de los trabajos en el rendimiento de la aplicación web, considere la posibilidad de crear una instancia vacía de Azure Web App en un nuevo plan de App Service para hospedar WebJobs de ejecución prolongada o intensivo en recursos.

Funciones de Azure

Una opción similar a WebJobs es Azure Functions. Este servicio es sin servidor que es más adecuado para los desencadenadores controlados por eventos que se ejecutan durante un breve período. También se puede usar una función para ejecutar trabajos programados a través de desencadenadores de temporizador, cuando se configura para ejecutarse en momentos establecidos.

Azure Functions no es una opción recomendada para tareas de larga duración grandes, ya que pueden provocar problemas de tiempo de espera inesperados. Sin embargo, en función del plan de hospedaje, se pueden tener en cuenta para los desencadenadores controlados por programación.

Consideraciones

Si se espera que la tarea en segundo plano se ejecute durante un breve período de tiempo en respuesta a un evento, considere la posibilidad de ejecutar la tarea en un plan de consumo. El tiempo de ejecución se puede configurar hasta un tiempo máximo. Una función que se ejecuta durante más tiempo cuesta más. Además, los trabajos con uso intensivo de CPU que consumen más memoria pueden ser más caros. Si usa activadores adicionales para servicios como parte de su tarea, estos se facturan por separado.

El plan Premium es más adecuado si tiene un gran número de tareas que son cortas, pero que se espera que se ejecuten continuamente. Este plan es más caro porque necesita más memoria y CPU. La ventaja es que puede usar características como la integración de red virtual.

El plan Dedicado es más adecuado para los trabajos en segundo plano si la carga de trabajo ya se ejecuta en él. Si tiene máquinas virtuales infrautilizadas, puede ejecutarla en la misma máquina virtual y compartir los costos de proceso.

Para obtener más información, consulte estos artículos:

Azure Virtual Machines

Es posible que las tareas en segundo plano se implementen de una manera que impida que se implementen en Azure Web Apps o que estas opciones no sean convenientes. Algunos ejemplos típicos son servicios de Windows y utilidades de terceros y programas ejecutables. Otro ejemplo podría ser programas escritos para un entorno de ejecución diferente al que hospeda la aplicación. Por ejemplo, puede ser un programa Unix o Linux que quiera ejecutar desde una aplicación de Windows o .NET. Puede elegir entre una variedad de sistemas operativos para una máquina virtual de Azure y ejecutar el servicio o ejecutable en esa máquina virtual.

Para obtener más información, consulte los siguientes recursos:

Para iniciar la tarea en segundo plano en una máquina virtual independiente, tiene una variedad de opciones:

  • Puede ejecutar la tarea a petición directamente desde la aplicación mediante el envío de una solicitud a un punto de conexión que exponga la tarea. Esto pasa en cualquier dato que requiera la tarea. Este endpoint invoca una tarea.
  • Puede configurar la tarea para que se ejecute según una programación mediante un programador o temporizador que esté disponible en el sistema operativo elegido. Por ejemplo, en Windows puede usar el Programador de tareas de Windows para ejecutar scripts y tareas. O bien, si tiene SQL Server instalado en la máquina virtual, puede usar el Agente SQL Server para ejecutar scripts y tareas.
  • Puede usar Azure Logic Apps para iniciar la tarea al agregar un mensaje a una cola en la que escucha la tarea o al enviar una solicitud a una API que la tarea expone.

Consulte la sección anterior Desencadenadores para obtener más información sobre cómo puede iniciar tareas en segundo plano.

Consideraciones

Tenga en cuenta los siguientes puntos cuando decida si va a implementar tareas en segundo plano en una máquina virtual de Azure:

  • Hospedar tareas en segundo plano en una máquina virtual de Azure independiente proporciona flexibilidad y permite un control preciso sobre el inicio, la ejecución, la programación y la asignación de recursos. Sin embargo, aumenta el costo en tiempo de ejecución si se debe implementar una máquina virtual solo para ejecutar tareas en segundo plano.
  • No hay ninguna instalación para supervisar las tareas en Azure Portal y no hay ninguna funcionalidad de reinicio automatizada para tareas con errores, aunque puede supervisar el estado básico de la máquina virtual y administrarla mediante los cmdlets de Azure Resource Manager. Sin embargo, no hay ninguna instalación para controlar los procesos y subprocesos en los nodos de proceso. Normalmente, el uso de una máquina virtual requiere un esfuerzo adicional para implementar un mecanismo que recopila datos de la instrumentación en la tarea y del sistema operativo de la máquina virtual. Una solución que podría ser adecuada es usar el módulo de administración de System Center para Azure.
  • Puede considerar la posibilidad de crear sondeos de supervisión que se exponen a través de puntos de conexión HTTP. El código de estas sondas podría realizar comprobaciones de estado, reunir información operativa y estadísticas, o compilar información de errores y devolverla a una aplicación de gestión. Para más información, consulte el patrón de supervisión del punto de conexión de mantenimiento.

Para obtener más información, consulte:

Azure Batch

Considere Azure Batch si necesita ejecutar cargas de trabajo de informática de alto rendimiento (HPC) grandes y paralelas en decenas, cientos o miles de máquinas virtuales.

El servicio Batch aprovisiona las máquinas virtuales, asigna tareas a las máquinas virtuales, ejecuta las tareas y supervisa el progreso. Batch puede automáticamente escalar horizontalmente las máquinas virtuales en respuesta a la carga de trabajo. Batch también proporciona programación de trabajos. Azure Batch admite máquinas virtuales Linux y Windows.

Consideraciones

Batch funciona bien con cargas de trabajo intrínsecamente paralelas. También puede realizar cálculos paralelos con un paso de reducción al final o ejecutar aplicaciones de interfaz de paso de mensajes (MPI) para tareas paralelas que requieren el paso de mensajes entre nodos.

Un trabajo de Azure Batch se ejecuta en un grupo de nodos (VM). Un enfoque consiste en asignar un grupo solo cuando sea necesario y, a continuación, eliminarlo una vez completado el trabajo. Esto maximiza el uso, ya que los nodos no están inactivos, pero el trabajo debe esperar a que se asignen los nodos. También puede crear un grupo de antemano. Ese enfoque minimiza el tiempo que tarda un trabajo en iniciarse, pero puede dar lugar a que los nodos estén inactivos. Para más información, consulte Vigencia del grupo y del nodo de proceso.

Para obtener más información, consulte:

Azure Kubernetes Service

Azure Kubernetes Service (AKS) administra el entorno de Kubernetes hospedado, lo que facilita la implementación y administración de aplicaciones en contenedores.

Los contenedores pueden ser útiles para ejecutar trabajos en segundo plano. Estas son algunas de las ventajas:

  • Los contenedores admiten hospedaje de alta densidad. Puede aislar una tarea en segundo plano en un contenedor, al colocar varios contenedores en cada máquina virtual.
  • El orquestador de contenedores controla el equilibrio de carga interno, la configuración de la red interna y otras tareas de configuración.
  • Los contenedores se pueden iniciar y detener cuando sea necesario.
  • Azure Container Registry permite registrar los contenedores dentro de los límites de Azure. Esto incluye ventajas de seguridad, privacidad y proximidad.

Consideraciones

  • Requiere una comprensión de cómo usar un orquestador de contenedores.

Para obtener más información, consulte:

Azure Container Apps (Aplicaciones de Contenedor de Azure)

Azure Container Apps permite crear microservicios sin servidor basados en contenedores. Entre las características distintivas de Container Apps se incluyen:

Consideraciones

Azure Container Apps no proporciona acceso directo a las API de Kubernetes subyacentes. Si necesita acceso a las API de Kubernetes y al plano de control, debe usar Azure Kubernetes Service. Sin embargo, si desea compilar aplicaciones de estilo Kubernetes y no requiere acceso directo a todas las API nativas de Kubernetes y a la administración de clústeres, Container Apps proporciona una experiencia totalmente administrada basada en procedimientos recomendados. Por estos motivos, muchos equipos prefieren empezar a compilar microservicios de contenedor con Azure Container Apps.

Para obtener más información, consulte:

Puede empezar a crear tu primera aplicación en contenedor usando las guías de inicio rápido.

Partición

Si decide incluir tareas en segundo plano dentro de una instancia de proceso existente, debe tener en cuenta cómo afecta a los atributos de calidad de la instancia de proceso y a la propia tarea en segundo plano. Estos factores le ayudan a decidir si colocar las tareas con la instancia de proceso existente o separarlas en una instancia de proceso independiente:

  • Disponibilidad: es posible que las tareas en segundo plano no necesiten tener el mismo nivel de disponibilidad que otras partes de la aplicación, en particular la interfaz de usuario y otras partes implicadas directamente en la interacción del usuario. Las tareas en segundo plano pueden ser más tolerantes a la latencia, los errores de conexión reintentados y otros factores que afectan a la disponibilidad, ya que las operaciones se pueden poner en cola. Sin embargo, debe haber suficiente capacidad para evitar la copia de seguridad de las solicitudes que podrían bloquear las colas y afectar a la aplicación en su conjunto.

  • Escalabilidad: es probable que las tareas en segundo plano tengan un requisito de escalabilidad diferente que la interfaz de usuario y las partes interactivas de la aplicación. Es posible que sea necesario escalar la interfaz de usuario para satisfacer los picos de demanda, mientras que las tareas en segundo plano pendientes se pueden completar durante tiempos menos ocupados por menos instancias de proceso.

  • Resistencia: el error de una instancia de proceso que simplemente hospeda tareas en segundo plano podría no afectar gravemente a la aplicación en su conjunto si las solicitudes de estas tareas se pueden poner en cola o posponer hasta que la tarea esté disponible de nuevo. Si la instancia de proceso o las tareas se pueden reiniciar dentro de un intervalo adecuado, es posible que los usuarios de la aplicación no se vean afectados.

  • Seguridad: las tareas en segundo plano pueden tener diferentes requisitos de seguridad o restricciones que la interfaz de usuario u otras partes de la aplicación. Con una instancia de proceso independiente, puede especificar un entorno de seguridad diferente para las tareas. También puede usar patrones como Gatekeeper para aislar las instancias de proceso en segundo plano de la interfaz de usuario para maximizar la seguridad y la separación.

  • Rendimiento: puede elegir el tipo de instancia de proceso para las tareas en segundo plano para que coincidan específicamente con los requisitos de rendimiento de las tareas. Esto puede significar el uso de una opción de proceso menos costosa si las tareas no requieren las mismas funcionalidades de procesamiento que la interfaz de usuario o una instancia mayor si requieren capacidad y recursos adicionales.

  • Capacidad de administración: las tareas en segundo plano pueden tener un ritmo de desarrollo e implementación diferente del código de aplicación principal o de la interfaz de usuario. Implementarlos en una instancia de proceso independiente puede simplificar las actualizaciones y el control de versiones.

  • Costo: agregar instancias de proceso para ejecutar tareas en segundo plano aumenta los costos de hospedaje. Debe considerar cuidadosamente el equilibrio entre la capacidad adicional y estos costos adicionales.

Para obtener más información, consulte el patrón de Elección de Líder y el patrón de Consumidores en Competencia.

Conflictos

Si tiene varias instancias de un trabajo en segundo plano, podrían competir por el acceso a recursos y servicios, como bases de datos y almacenamiento. Este acceso simultáneo puede dar lugar a la contención de recursos, lo que podría provocar conflictos en la disponibilidad de los servicios y en la integridad de los datos en el almacenamiento. Puede resolver la contención de recursos usando un modo de bloqueo pesimista. Esto impide que las instancias de competencia de una tarea accedan simultáneamente a un servicio o a datos dañados.

Otro enfoque para resolver conflictos es definir tareas en segundo plano como singleton, de modo que solo haya una instancia en ejecución. Pero esto elimina las ventajas de confiabilidad y rendimiento que puede proporcionar una configuración de varias instancias. Esto es especialmente cierto si la interfaz de usuario puede proporcionar suficiente trabajo para mantener más de una tarea en segundo plano ocupada.

Es fundamental asegurarse de que la tarea en segundo plano se pueda reiniciar automáticamente y que tenga capacidad suficiente para hacer frente a los picos de demanda. Puede lograrlo asignando una instancia de proceso con recursos suficientes mediante la implementación de un mecanismo de puesta en cola que puede almacenar solicitudes para su ejecución posterior cuando se reduce la demanda o mediante una combinación de estas técnicas.

Coordinación

Las tareas en segundo plano pueden ser complejas y pueden requerir que se ejecuten varias tareas individuales para generar un resultado o para cumplir todos los requisitos. Es habitual en estos escenarios dividir la tarea en pasos discretos más pequeños o subtareas que pueden ejecutar varios consumidores. Los trabajos de varios pasos pueden ser más eficaces y flexibles, ya que los pasos individuales pueden ser reutilizables en varios trabajos. También es fácil agregar, quitar o modificar el orden de los pasos.

Coordinar varias tareas y pasos puede ser difícil, pero hay tres patrones comunes que puede usar para guiar la implementación de una solución:

  • Descompone una tarea en varios pasos reutilizables. Es posible que se requiera una aplicación para controlar las tareas de complejidad variable cuando procesa información. Un enfoque sencillo pero inflexible para implementar esta aplicación podría ser realizar este procesamiento como módulo monolítico. Sin embargo, es probable que este enfoque reduzca las oportunidades para refactorizar el código, optimizarlo o reutilizarlo si se requieren partes del mismo procesamiento en otro lugar de la aplicación. Para más información, consulte el artículo sobre el patrón de canalizaciones y filtros.

  • Administrar la ejecución de los pasos de una tarea. Una aplicación puede realizar tareas compuestas de varios pasos y algunos de estos pasos pueden llamar a servicios remotos o acceder a recursos remotos. Los pasos individuales podrían ser independientes entre sí, pero están organizados por la lógica de la aplicación que implementa la tarea. Para más información, consulte el patrón de supervisor del agente de programador.

  • Administrar la recuperación de los pasos de una tarea con error. Es posible que una aplicación tenga que deshacer el trabajo que realiza una serie de pasos (que juntos definen una operación coherente eventualmente) si se produce un error en uno o varios de los pasos. Para obtener más información, consulte el patrón de transacción de compensación.

Consideraciones de resistencia

Las tareas en segundo plano deben ser resistentes para proporcionar servicios confiables a la aplicación. Al planear y diseñar tareas en segundo plano, tenga en cuenta los siguientes puntos:

  • Las tareas en segundo plano deben ser capaces de controlar correctamente los reinicios sin dañar los datos ni introducir incoherencia en la aplicación. Para las tareas de ejecución prolongada o con varios pasos, considere el uso de puntos de comprobación guardando el estado de los trabajos en el almacenamiento persistente o como mensajes en una cola, si fuera apropiado. Por ejemplo, puede conservar la información de estado en un mensaje de una cola y actualizar incrementalmente esta información de estado con el progreso de la tarea para que la tarea se pueda procesar desde el último punto de control correcto conocido, en lugar de reiniciarse desde el principio. Al usar colas de Azure Service Bus, puede usar sesiones de mensajes para habilitar el mismo escenario. Las sesiones permiten guardar y recuperar el estado de procesamiento de la aplicación mediante los métodos SetState y GetState . Para obtener más información sobre el diseño de procesos multipaso y flujos de trabajo confiables, consulte el Scheduler Agent Supervisor pattern.

  • Cuando usa colas para comunicarse con tareas en segundo plano, las colas pueden actuar como un búfer para almacenar las solicitudes que se envían a las tareas mientras la aplicación está sometida a una carga superior a la habitual. Esto permite que las tareas se pongan al día con la interfaz de usuario durante los períodos de menor actividad. También significa que los reinicios no bloquearán la interfaz de usuario. Para obtener más información, consulte el patrón de equilibrio de carga basado en colas. Si algunas tareas son más importantes que otras, considere la posibilidad de implementar el patrón De cola de prioridad para asegurarse de que estas tareas se ejecutan antes de las menos importantes.

  • Las tareas en segundo plano iniciadas por mensajes o mensajes de proceso deben diseñarse para controlar incoherencias, como mensajes que llegan fuera del orden, mensajes que provocan repetidamente un error (a menudo denominado mensajes dudosos) y mensajes que se entregan más de una vez. Tenga en cuenta los siguientes factores:

    • Los mensajes que se deben procesar en un orden específico, como los que cambian los datos en función del valor de datos existente (por ejemplo, agregar un valor a un valor existente), podrían no llegar en el orden original en el que se enviaron. Como alternativa, pueden controlarse mediante instancias diferentes de una tarea en segundo plano en un orden diferente debido a cargas variables en cada instancia. Los mensajes que deben procesarse en un orden específico deben incluir un número de secuencia, una clave u otro indicador que las tareas en segundo plano pueden usar para asegurarse de que se procesan en el orden correcto. Si usa Azure Service Bus, puede usar sesiones de mensajes para garantizar el orden de entrega. Pero normalmente es más eficaz, siempre que sea posible, diseñar el proceso para que el orden del mensaje no sea importante.

    • Normalmente, una tarea en segundo plano inspecciona los mensajes de la cola, lo que los oculta temporalmente de otros consumidores de mensajes. A continuación, elimina los mensajes después de que se procesen correctamente. Si se produce un error en una tarea en segundo plano al procesar un mensaje, ese mensaje vuelve a aparecer en la cola después de que expire el timeout. A continuación, se procesa mediante otra instancia de la tarea o durante el siguiente ciclo de procesamiento de esta instancia. Si el mensaje provoca de forma coherente un error en el consumidor, bloquea la tarea, la cola y, finalmente, la propia aplicación cuando la cola se llena. Por lo tanto, es fundamental detectar y eliminar los mensajes envenenados de la cola. Si estás utilizando Azure Service Bus, los mensajes que provocan un error se pueden mover automáticamente o manualmente a una cola de mensajes muertos asociada.

    • Se garantizan mecanismos de entrega a las colas al menos una vez, aunque podrían entregar el mismo mensaje más de una vez. Además, si se produce un error en una tarea en segundo plano después de procesar un mensaje, pero antes de eliminarlo de la cola, el mensaje vuelve a estar disponible para su procesamiento. Las tareas en segundo plano deben ser idempotentes, lo que significa que procesar el mismo mensaje más de una vez no provoca un error o incoherencia en los datos de la aplicación. Algunas operaciones son naturalmente idempotentes, como establecer un valor almacenado en un nuevo valor específico. Sin embargo, las operaciones como agregar un valor a un valor almacenado existente sin comprobar que el valor almacenado sigue siendo el mismo que cuando el mensaje se envió originalmente provoca incoherencias. Las colas de Azure Service Bus se pueden configurar para quitar automáticamente mensajes duplicados. Para obtener más información sobre los desafíos con la entrega de mensajes al menos una vez, consulte las instrucciones sobre el procesamiento de mensajes idempotentes.

    • Algunos sistemas de mensajería, como Azure Queue Storage y las colas de Azure Service Bus, admiten una propiedad de recuento de eliminación de la cola que indica el número de veces que se ha leído un mensaje de la cola. Esto puede ser útil para controlar mensajes repetidos y mensajes dañinos. Para obtener más información, consulte Introducción a la Mensajería Asíncrona y Patrones de Idempotencia.

Consideraciones de escalado y rendimiento

Las tareas en segundo plano deben ofrecer un rendimiento suficiente para asegurarse de que no bloquean la aplicación o provocan incoherencias debido a una operación retrasada cuando el sistema está bajo carga. Normalmente, el rendimiento se mejora mediante el escalado de las instancias de proceso que hospedan las tareas en segundo plano. Al planear y diseñar tareas en segundo plano, tenga en cuenta los siguientes puntos en torno a la escalabilidad y el rendimiento:

  • Azure admite el escalado automático (escalar horizontalmente y reducir horizontalmente) en función de la demanda y carga actuales, o según una programación predefinida, para implementaciones hospedadas de Web Apps y Virtual Machines. Use esta característica para asegurarse de que la aplicación en su conjunto tiene suficientes funcionalidades de rendimiento, a la vez que se minimizan los costos en tiempo de ejecución.

  • Cuando las tareas en segundo plano tienen una funcionalidad de rendimiento diferente de las demás partes de una aplicación (por ejemplo, la interfaz de usuario o los componentes, como la capa de acceso a datos), hospedar las tareas en segundo plano en un servicio de proceso independiente permite que la interfaz de usuario y las tareas en segundo plano se escalen de forma independiente para administrar la carga. Si varias tareas en segundo plano tienen funcionalidades de rendimiento significativamente diferentes entre sí, considere la posibilidad de dividirlas y escalar cada tipo de forma independiente. Sin embargo, este enfoque podría aumentar los costos en tiempo de ejecución.

  • Es posible que el escalado de los recursos de proceso no sea suficiente para evitar la pérdida de rendimiento bajo carga. También es posible que necesite escalar las colas de almacenamiento y otros recursos para impedir que un único punto de la cadena de procesamiento general se convierta en un cuello de botella. Además, tenga en cuenta otras limitaciones, como el rendimiento máximo del almacenamiento y otros servicios en los que se basan la aplicación y las tareas en segundo plano.

  • Las tareas en segundo plano deben diseñarse para el escalado. Por ejemplo, el sistema debe poder detectar dinámicamente el número de colas de almacenamiento en uso para monitorear y enviar mensajes a la cola adecuada.

  • De manera predeterminada, los trabajos web se escalan con su instancia asociada de Azure Web Apps. Sin embargo, si desea que un WebJob se ejecute como una sola instancia, puede crear un archivo Settings.job que contenga los datos JSON { "is_singleton": true }. Esto obliga a Azure a ejecutar solo una instancia de WebJob, incluso si hay varias instancias de la aplicación web asociada. Puede ser una técnica útil para los trabajos programados que se deben ejecutar como una sola instancia.

Pasos siguientes

  • Last updated on