Recomendaciones para desarrollar trabajos en segundo plano

  • Artículo

Se aplica a esta recomendación de lista de comprobación de confiabilidad de Azure Well-Architected Framework:

RE:07 Fortalecer la resistencia y la capacidad de recuperación de la carga de trabajo mediante la implementación de medidas de autoconservación y recuperación automática. Cree funcionalidades en la solución mediante patrones de confiabilidad basados en infraestructura y patrones de diseño basados en software para controlar errores de componentes y errores transitorios. Cree funcionalidades en el sistema para detectar errores de componentes de solución e iniciar automáticamente acciones correctivas mientras la carga de trabajo sigue funcionando con funcionalidad completa o reducida.

Guías relacionadas:Errores transitorios | Auto-conservación

En esta guía se describen las recomendaciones para desarrollar trabajos en segundo plano. Los trabajos en segundo plano se ejecutan automáticamente sin necesidad de interacción del usuario. Muchas aplicaciones requieren trabajos en segundo plano que se ejecutan independientemente de la interfaz de usuario.

Algunos ejemplos de trabajos en segundo plano incluyen trabajos por lotes, tareas de procesamiento intensivo y procesos de larga duración, como flujos de trabajo. La aplicación inicia el trabajo y procesa las solicitudes interactivas de los usuarios. Por ejemplo, si una aplicación necesita generar miniaturas de imágenes que los usuarios cargan, se puede realizar un trabajo en segundo plano para generar la miniatura y guardarla en el almacenamiento. El usuario no tiene que esperar a que se complete el proceso. Como otro ejemplo, un cliente realiza un pedido, que inicia un flujo de trabajo en segundo plano que procesa el pedido. El cliente continúa explorando la aplicación web mientras se ejecuta el trabajo en segundo plano. Una vez finalizado el trabajo en segundo plano, actualiza los datos del pedido almacenado y envía un correo electrónico al cliente para confirmar el pedido.

Los trabajos en segundo plano ayudan a minimizar la carga en la interfaz de usuario de la aplicación, lo que mejora la disponibilidad y reduce el tiempo de respuesta interactivo.

Estrategias de diseño principales

Para elegir qué tarea designar como un trabajo en segundo plano, tenga en cuenta si la tarea se ejecuta sin interacción del usuario y si la interfaz de usuario debe esperar a que se complete la tarea. Las tareas que requieren que el usuario o la interfaz de usuario esperen mientras se ejecutan normalmente no son trabajos en segundo plano adecuados.

Tipos de trabajos en segundo plano

Algunos ejemplos de trabajos en segundo plano son:

  • Trabajos de uso intensivo de la CPU, tales como cálculos matemáticos o análisis de modelo estructural.

  • Trabajos intensivos de E/S, como ejecutar una serie de transacciones de almacenamiento o archivos de indexación.

  • Trabajos por lotes, tales como actualizaciones de datos por la noche o procesamiento programado.

  • Flujos de trabajo de larga duración, como el suministro de pedidos o los servicios y sistemas de aprovisionamiento.

  • Procesamiento de datos confidenciales que transfiere la tarea a una ubicación más segura para su procesamiento. Por ejemplo, quizás no quiera procesar datos confidenciales en una aplicación web. En su lugar, puede usar un patrón como el patrón de operador de control para transferir los datos a un proceso en segundo plano aislado que tenga acceso al almacenamiento protegido.

Desencadenadores

Inicie trabajos en segundo plano con:

Desencadenadores impulsados por eventos

Una acción desencadena una invocación controlada por eventos que inicia la tarea en segundo plano. Algunos ejemplos de desencadenadores controlados por eventos son:

  • La interfaz de usuario o un trabajo diferente coloca un mensaje en una cola, como se describe en el estilo de arquitectura Web-Queue-Worker. El mensaje contiene datos sobre una acción realizada anteriormente, como un cliente que realizó un pedido. El trabajo en segundo plano supervisa esta cola y detecta la llegada de un nuevo mensaje. Lee el mensaje y usa los datos del mensaje como entrada para el trabajo en segundo plano. Este patrón se denomina comunicación asincrónica basada en mensajes.

  • La interfaz de usuario o un trabajo diferente guarda o actualiza un valor que está en el almacenamiento. El trabajo en segundo plano supervisa el almacenamiento y detecta los cambios. Lee los datos y los usa como entrada para el trabajo en segundo plano.

  • La interfaz de usuario o un trabajo diferente realiza una solicitud a un punto de conexión, como un URI HTTPS o una API que se expone como un servicio web. Como parte de la solicitud, la interfaz de usuario o el trabajo transfiere los datos que requiere la tarea en segundo plano. El punto de conexión o servicio web invoca la tarea en segundo plano, que usa los datos como entrada.

Otros ejemplos de tareas que son adecuadas para la invocación controlada por eventos 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 impulsados por programación

Un temporizador desencadena una invocación controlada por programación que inicia la tarea en segundo plano. Algunos ejemplos de desencadenadores controlados por programación son:

  • Un temporizador que se ejecuta localmente dentro de la aplicación o como parte del sistema operativo de la aplicación invoca regularmente una tarea en segundo plano.

  • Un temporizador que se ejecuta en una aplicación diferente, como Azure Logic Apps, envía regularmente una solicitud a una API o un servicio web. La API o servicio web invoca la tarea en segundo plano.

  • Un proceso o aplicación independiente inicia un temporizador que invoca la tarea en segundo plano después de un retraso de tiempo o en un momento específico.

Otros ejemplos de tareas adecuadas para la invocación controlada por programación incluyen rutinas de procesamiento por lotes (como actualizar listas de productos relacionados para clientes en función de su comportamiento reciente), tareas rutinarias de procesamiento de datos (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 se debe ejecutar como una sola instancia, revise las consideraciones siguientes:

  • Si la instancia de proceso que ejecuta el programador, como una máquina virtual (VM) que usa tareas programadas de Windows, se escala, ejecuta varias instancias del programador. Varias instancias del programador pueden iniciar varias instancias de la tarea. Para obtener más información, consulte ¿Qué significa idempotente en los sistemas de software?

  • Si las tareas se ejecutan más tiempo que el período entre los eventos del programador, el programador podría iniciar otra instancia de la tarea mientras se ejecuta la tarea anterior.

Devolver los 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ó el trabajo en segundo plano. Idealmente, los trabajos en segundo plano se activan y olvidan las operaciones. Su progreso en tiempo de ejecución no tiene ningún efecto en la interfaz de usuario ni en el proceso de llamada, lo que significa que el proceso de llamada no espera a que se completen las tareas. La interfaz de usuario y el proceso de llamada no pueden detectar cuándo 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. Algunos ejemplos son:

  • Escriba un valor de indicador de estado en el almacenamiento al que se pueda acceder a la interfaz de usuario o a la tarea del autor de la llamada, que puede supervisar o comprobar este valor. Otros datos que la tarea en segundo plano devuelve al autor de la llamada se pueden colocar en el mismo almacenamiento.

  • Establezca una cola de respuesta que supervisa la interfaz de usuario o el autor de la llamada. La tarea en segundo plano puede enviar mensajes a la cola que indican el estado. Los datos que la tarea en segundo plano devuelve al autor de la llamada se pueden colocar en los mensajes. Para Azure Service Bus, use las ReplyTo propiedades y CorrelationId para implementar esta funcionalidad.

  • Exponer una API o punto de conexión desde la tarea en segundo plano a la que pueda acceder la interfaz de usuario o la llamada para obtener información sobre el estado. La respuesta puede incluir los datos que la tarea en segundo plano devuelve al autor de la llamada.

  • Configure la tarea en segundo plano para que 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. Puede usar eventos generados localmente o un mecanismo de publicación y suscripción. La solicitud o la carga del evento pueden incluir los datos que la tarea en segundo plano devuelve al autor de la llamada.

Creación de particiones de trabajos en segundo plano

Si incluye trabajos en segundo plano en una instancia de proceso existente, tenga en cuenta cómo afectan estos cambios a los atributos de calidad de la instancia de proceso y al trabajo en segundo plano. Tenga en cuenta estos factores para decidir si colocar las tareas con la instancia de proceso existente o separarlas en una instancia de proceso diferente:

  • Disponibilidad: es posible que las tareas en segundo plano no necesiten el mismo nivel de disponibilidad que otras partes de la aplicación, en particular la interfaz de usuario y los elementos que implican directamente la interacción del usuario. Las tareas en segundo plano pueden tener una mayor tolerancia a la latencia, los errores de conexión reintentados y otros factores que afectan a la disponibilidad porque las operaciones se pueden poner en cola. Sin embargo, debe haber suficiente capacidad para evitar las solicitudes de copia de seguridad que pueden bloquear las colas y afectar a toda la aplicación.

  • Escalabilidad: es probable que las tareas en segundo plano tengan requisitos de escalabilidad diferentes en comparación con la interfaz de usuario y las partes interactivas de la aplicación. Es posible que tenga que escalar la interfaz de usuario para satisfacer los picos de demanda. Las tareas en segundo plano pendientes se pueden ejecutar durante tiempos menos ocupados y con menos instancias de proceso.

  • Resistencia: si se produce un error en una instancia de proceso que hospeda solo tareas en segundo plano, es posible que no afecte gravemente a toda la aplicación. Las solicitudes de estas tareas se pueden poner en cola o posponer hasta que la tarea esté disponible. Si la instancia de proceso o las tareas se pueden reiniciar dentro de un intervalo adecuado, es posible que no afecte a los usuarios de la aplicación.

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

  • Rendimiento: elija el tipo de instancia de proceso para las tareas en segundo plano que coincidan específicamente con los requisitos de rendimiento de la tarea. Puede usar una opción de proceso menos costosa si las tareas no requieren las mismas funcionalidades de procesamiento que la interfaz de usuario. O bien, puede usar una instancia mayor si las tareas requieren más capacidad y recursos.

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

  • Costo: si agrega instancias de proceso para ejecutar tareas en segundo plano, los costos de hospedaje aumentan. Considere cuidadosamente el equilibrio entre más capacidad y costos adicionales.

Para obtener más información, consulte Patrón de elección de líder y Patrón de consumidores competidores.

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 de disponibilidad del servicio y dañar la integridad de los datos que están en el almacenamiento. Resuelva la contención de recursos mediante un enfoque de bloqueo pesimista. Este enfoque impide que las instancias de una tarea compitan simultáneamente accedan a un servicio o dañen los datos.

Otro enfoque para resolver conflictos es definir tareas en segundo plano como singleton, de modo que solo se ejecute una instancia. Sin embargo, este enfoque elimina las ventajas de confiabilidad y rendimiento que proporciona una configuración de varias instancias. Esta desventaja es especialmente cierta si la interfaz de usuario proporciona suficiente trabajo para mantener ocupadas más de una tarea en segundo plano.

Asegúrese de que la tarea en segundo plano se pueda reiniciar automáticamente y que tenga capacidad suficiente para controlar los picos de demanda. Asigne una instancia de proceso con recursos suficientes, implemente un mecanismo de puesta en cola que almacene las solicitudes para ejecutarse cuando disminuya la demanda o use una combinación de estas técnicas.

Coordinación

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

Puede ser un desafío coordinar varias tareas y pasos, pero hay tres patrones comunes para guiar la solución:

  • Descompone una tarea en varios pasos reutilizables. Una aplicación puede ser necesaria para realizar varias tareas de complejidad diferente en la información que procesa. Un enfoque sencillo pero inflexible para implementar este tipo de aplicación es realizar este procesamiento como módulo monolítico. Pero es probable que este enfoque reduzca las oportunidades de refactorizar el código, optimizarlo o reutilizarlo si la aplicación requiere partes del mismo procesamiento en otro lugar. Para más información, consulte el artículo sobre el patrón de canalizaciones y filtros.

  • Administre la orquestación de los pasos de una tarea. Una aplicación puede realizar tareas que comprenden muchos pasos, algunos de los cuales pueden invocar servicios remotos o acceder a recursos remotos. A veces, los pasos individuales son 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 de agente de programador.

  • Administre la recuperación de los pasos de tarea que producen un error. Si se produce un error en uno o varios de los pasos, es posible que una aplicación tenga que deshacer el trabajo que realiza una serie de pasos, que juntos definen una operación finalmente coherente. Para obtener más información, vea Patrón de transacción de compensación.

Consideraciones de resistencia

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

  • Las tareas en segundo plano deben controlar correctamente los reinicios sin dañar los datos ni introducir incoherencia en la aplicación. Para las tareas de ejecución prolongada o de varios pasos, considere la posibilidad de usar puntos de control. Use puntos de control para guardar el estado de los trabajos en el almacenamiento persistente o como mensajes en una cola. Por ejemplo, puede almacenar información de estado en un mensaje que se encuentra en una cola y actualizar incrementalmente esta información de estado con el progreso de la tarea. La tarea se puede procesar desde el último punto de control conocido en lugar de reiniciarse desde el principio.

    Para las colas de Service Bus, use sesiones de mensajes para este fin. Con las sesiones de mensajes, guarde y recupere 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 y flujos de trabajo de varios pasos confiables, consulte Patrón supervisor del agente de Scheduler.

  • Cuando use las colas para comunicarse con las tareas en segundo plano, las colas pueden actuar como un búfer para almacenar las solicitudes que se envían a las tareas cuando la aplicación se encuentra con una mayor carga que la habitual. Las tareas pueden ponerse al día con la interfaz de usuario durante períodos menos ocupados y los reinicios no bloquean la interfaz de usuario. Para más información, consulte Patrón Queue-Based Load Leveling. Si algunas tareas son más importantes que otras, considere la posibilidad de implementar el patrón Cola de prioridad para asegurarse de que estas tareas se ejecutan primero.

error de Hadoop

Configure tareas en segundo plano iniciadas por mensajes o que procesen mensajes para controlar incoherencias, como mensajes que llegan desordenados, mensajes que provocan repetidamente un error (mensajes dudosos) y mensajes que se entregan más de una vez. Tenga en cuenta las recomendaciones siguientes:

  • A veces, necesita que los mensajes se procesen en un orden específico, como los mensajes que cambian los datos en función del valor de datos existente, por ejemplo, agregando un valor a un valor existente. Los mensajes no siempre llegan en el orden en que se enviaron. Además, diferentes instancias de una tarea en segundo plano pueden procesar mensajes en un orden diferente debido a cargas variables en cada instancia.

    En el caso de los mensajes que se deben procesar en un orden específico, incluya un número de secuencia, una clave u otro indicador que las tareas en segundo plano puedan usar para procesar mensajes en el orden correcto. Para Service Bus, use sesiones de mensajes para garantizar el orden correcto de entrega. Es más eficaz diseñar el proceso para que el orden de los mensajes no sea importante. Para obtener más información, consulte secuenciación de mensajes y marcas de tiempo.

  • Normalmente, una tarea en segundo plano examina los mensajes de la cola, que los oculta temporalmente de otros consumidores de mensajes. Una vez que la tarea procesa correctamente el mensaje, elimina el mensaje. Si se produce un error en una tarea en segundo plano cuando procesa un mensaje, ese mensaje vuelve a aparecer en la cola después de que expire el tiempo de espera de inspección. Una instancia diferente de la tarea procesa el mensaje o el siguiente ciclo de procesamiento de la instancia original procesa el mensaje.

    Si el mensaje produce un error de forma coherente en el consumidor, bloquea la tarea, la cola y, finalmente, la propia aplicación cuando la cola se llena. Es fundamental detectar y quitar mensajes dudosos de la cola. Si usa Service Bus, mueva automáticamente o manualmente mensajes dudosos a una cola de mensajes fallidos asociada.

  • Las colas son mecanismos de entrega al menos una vez , pero pueden entregar el mismo mensaje más de una vez. 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 estará disponible para su procesamiento de nuevo.

    Las tareas en segundo plano deben ser idempotentes, lo que significa que, cuando la tarea procesa el mismo mensaje más de una vez, no provoca un error ni una incoherencia en los datos de la aplicación. Algunas operaciones son naturalmente idempotentes, por ejemplo, si un valor almacenado se establece en un nuevo valor específico. Sin embargo, algunas operaciones provocan incoherencias, por ejemplo, si se agrega un valor a un valor almacenado existente sin comprobar que el valor almacenado sigue siendo el mismo que cuando se envió originalmente el mensaje. Configure colas de Service Bus para quitar automáticamente los mensajes duplicados. Para obtener más información, consulte Procesamiento de mensajes idempotentes.

  • Algunos sistemas de mensajería, como las colas de Azure Storage y las colas de Service Bus, admiten una propiedad count de puesta en cola que indica cuántas veces se lee un mensaje de la cola. Estos datos son útiles para controlar mensajes repetidos y mensajes dudosos. Para obtener más información, consulte Patrones de identificación e identificación de mensajería asincrónica.

Consideraciones de escalado y rendimiento

Las tareas en segundo plano deben ofrecer un rendimiento suficiente para asegurarse de que no bloquean la aplicación ni retrasan la operación cuando el sistema está bajo carga. Normalmente, el rendimiento mejora al escalar 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 relacionados con la escalabilidad y el rendimiento:

  • Azure Virtual Machines y la característica Web Apps de Azure App Service pueden hospedar implementaciones. Admiten el escalado automático, tanto el escalado horizontal como el escalado horizontal. El escalado automático viene determinado por la demanda y carga o una programación predefinida. Use el escalado automático para ayudar a garantizar que la aplicación tenga suficientes funcionalidades de rendimiento, a la vez que minimiza los costos en tiempo de ejecución.

  • Algunas tareas en segundo plano tienen una funcionalidad de rendimiento diferente en comparación con otras partes de una aplicación, por ejemplo, la interfaz de usuario o los componentes, como la capa de acceso a datos. En ese escenario, hospede las tareas en segundo plano en un servicio de proceso independiente para que la interfaz de usuario y las tareas en segundo plano se puedan escalar de forma independiente para administrar la carga. Si varias tareas en segundo plano tienen funcionalidades de rendimiento significativamente diferentes, dividalas y escale cada tipo de forma independiente. Esta técnica puede aumentar los costos en tiempo de ejecución.

  • Para evitar la pérdida de rendimiento bajo carga, es posible que también tenga que escalar las colas de almacenamiento y otros recursos, por lo que un único punto de la cadena de procesamiento no provoca un cuello de botella. 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.

  • Diseñar tareas en segundo plano para el escalado. Por ejemplo, las tareas en segundo plano deben detectar dinámicamente el número de colas de almacenamiento utilizadas para supervisar los mensajes o enviar mensajes a la cola adecuada.

  • De forma predeterminada, un Trabajo web se escala con su instancia de Web Apps asociada. Sin embargo, si desea que un Trabajo web se ejecute como solo una instancia, puede crear un archivo Settings.job que contenga los datos { "is_singleton": true }JSON . Este método obliga a Azure a ejecutar solo una instancia del Trabajo web, incluso si hay varias instancias de la aplicación web asociada. Esta técnica es útil para los trabajos programados que deben ejecutarse como una sola instancia.

  • Los trabajos en segundo plano pueden crear desafíos para la sincronización de datos y la coordinación de procesos, especialmente si las tareas en segundo plano dependen entre sí o de otros orígenes de datos. Por ejemplo, los trabajos en segundo plano pueden controlar problemas de coherencia de datos, condiciones de carrera, interbloqueos o tiempos de espera.

  • Los trabajos en segundo plano pueden afectar a la experiencia del usuario si los resultados de las tareas en segundo plano se presentan al usuario. Por ejemplo, los trabajos en segundo plano pueden requerir que el usuario espere una notificación, actualice la página o compruebe manualmente el estado de la tarea. Estos comportamientos pueden aumentar la complejidad de la interacción del usuario y afectar negativamente a la experiencia del usuario.

Compensación: los trabajos en segundo plano introducen más componentes y dependencias en el sistema, lo que puede aumentar la complejidad y los costos de mantenimiento de la solución. Por ejemplo, los trabajos en segundo plano pueden requerir un servicio de cola independiente, un servicio de trabajo, un servicio de supervisión y un mecanismo de reintento.

Facilitación de Azure

En las secciones siguientes se describen los servicios de Azure que puede usar para hospedar, ejecutar, configurar y administrar trabajos en segundo plano.

Entornos de host

Hay varios servicios de plataforma Azure que pueden hospedar tareas en segundo plano:

  • Web Apps y WebJobs: use la característica WebJobs de App Service para ejecutar trabajos personalizados basados en diferentes scripts o programas que puede ejecutar en una aplicación web.

  • Azure Functions: use aplicaciones de funciones para trabajos en segundo plano que no se ejecuten durante mucho tiempo. También puede usar aplicaciones de funciones si hospeda la carga de trabajo en un plan de App Service infrautilizado.

  • Virtual Machines: si tiene un servicio de Windows o quiere usar el Programador de tareas de Windows, hospede las tareas en segundo plano en una máquina virtual dedicada.

  • Azure Batch: Batch es un servicio de plataforma que puede usar para programar 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): AKS proporciona un entorno de hospedaje administrado para Kubernetes en Azure.

  • Azure Container Apps: con Container Apps, puede crear microservicios sin servidor basados en contenedores.

En las secciones siguientes se proporcionan consideraciones para cada una de estas opciones que le ayudarán a elegir la mejor opción.

Web Apps y WebJobs

Puede usar la característica WebJobs para ejecutar trabajos personalizados como trabajos en segundo plano en una aplicación web. Un trabajo web se ejecuta como un proceso continuo en el contexto de la aplicación web. Un Trabajo web también se puede ejecutar en respuesta a un evento de desencadenador de Logic Apps o factores externos, como cambios en blobs de almacenamiento o colas de mensajes. WebJobs se puede iniciar y detener a petición y apagarse correctamente. Si se produce un error en un trabajo web en ejecución continua, se reinicia automáticamente. Puede configurar las acciones de reintento y error.

Cuando configura un WebJob:

  • Si desea que el trabajo responda a un desencadenador controlado por eventos, configúrelo para 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, configúrelo en 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 iniciar el trabajo.

Un trabajo web se ejecuta en el espacio aislado de la aplicación web. Tiene acceso a variables de entorno y puede compartir información, como cadenas de conexión, con la aplicación web. El WebJob tiene acceso al identificador único de la máquina que ejecuta el WebJob. El cadena de conexión denominado AzureWebJobsStorage proporciona acceso a las colas, blobs y tablas de Storage para los datos de la aplicación. También proporciona acceso a Service Bus para la mensajería y la comunicación. El cadena de conexión denominado AzureWebJobsDashboard proporciona acceso a los archivos de registro de acciones de WebJob.

Los trabajos web tienen las siguientes características:

  • Seguridad: las credenciales de implementación de la aplicación web proporcionan protección para WebJobs.

  • Tipos de archivo admitidos: defina WebJobs mediante scripts de comandos (.cmd), archivos por lotes (.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 y .jar).

  • Implementación: puede implementar scripts y ejecutables mediante la Azure Portal, Visual Studio o el SDK de WebJobs, o bien puede copiarlos directamente en las siguientes ubicaciones:

    • Para la implementación desencadenada: site/wwwroot/app_data/jobs/triggered/<job name>

    • Para la implementación continua: site/wwwroot/app_data/jobs/continuous/<job name>

  • Archivos de registro: Console.Out se trata o marca como INFO. Console.Error se trata como ERROR. Use el portal para acceder a la información de supervisión y diagnóstico. Descargue los archivos de registro directamente desde el sitio web. Los archivos de registro se guardan en las siguientes ubicaciones:

    • Para la implementación desencadenada: Vfs/data/jobs/triggered/<job name>

    • Para la implementación continua: Vfs/data/jobs/continuous/<job name>

  • Configuración: configure WebJobs mediante el portal, la API REST y PowerShell. Use un archivo de configuración denominado settings.job, que se encuentra en el mismo directorio raíz que el script de WebJob, para proporcionar información de configuración para un Trabajo web. Por ejemplo:

    • { "stopping_wait_time": 60 }

    • { "is_singleton": true }

consideraciones de Web Apps y WebJobs

  • De forma predeterminada, los trabajos web se escalan con la aplicación web. Para configurar WebJobs para que se ejecute en una sola instancia, establezca la is_singleton propiedad truede configuración en . WebJobs de instancia única es útil para las tareas que no desea escalar o ejecutar como simultáneas varias instancias, como la reindexación o el análisis de datos.

  • Para minimizar el efecto de WebJobs en el rendimiento de la aplicación web, cree una instancia de aplicación web vacía en un nuevo App Service plan para hospedar webjos de larga duración o de uso intensivo de recursos.

Azure Functions

Azure Functions es similar a WebJobs. Azure Functions es sin servidor y es más adecuado para los desencadenadores controlados por eventos que se ejecutan durante un breve período. También puede usar Azure Functions para ejecutar trabajos programados a través de desencadenadores de temporizador si configura una función para que se ejecute en momentos especificados.

Azure Functions no se recomienda para tareas de larga duración grandes porque una función puede provocar tiempos de espera inesperados. Sin embargo, en función del plan de hospedaje, considere la posibilidad de usar funciones para desencadenadores controlados por programación.

Azure Functions consideraciones

Si 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 el plan de consumo. Puede configurar el tiempo de ejecución en un tiempo máximo. Una función que se ejecuta más tiempo tiene un costo mayor. Los trabajos que consumen más memoria pueden ser más costosos. Si usa desencadenadores adicionales para los servicios como parte de la tarea, se facturan por separado.

El plan Premium es adecuado si tiene varias tareas que son cortas, pero se ejecutan continuamente. Este plan es más caro porque necesita más memoria y más CPU. Como ventaja, puede usar otras características, como la integración de red virtual.

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

Para más información, consulte:

Virtual Machines

Puede implementar tareas en segundo plano para que no se implementen en Web Apps. Por ejemplo, puede implementar tareas mediante servicios de Windows, utilidades de terceros o programas ejecutables. También puede usar programas escritos para un entorno en tiempo de ejecución diferente al entorno que hospeda la aplicación. Por ejemplo, puede usar un programa Unix o Linux que quiera ejecutar desde una aplicación de Windows o .NET. Elija entre varios sistemas operativos para una máquina virtual de Azure y ejecute el servicio o ejecutable en esa máquina virtual.

Para más información, consulte:

Para iniciar la tarea en segundo plano en una máquina virtual independiente, puede hacer lo siguiente:

  • Envíe una solicitud a un punto de conexión que la tarea expone para ejecutar la tarea a petición directamente desde la aplicación. La solicitud transfiere los datos que requiere la tarea. El punto de conexión invoca la tarea.

  • Use un programador o un temporizador del sistema operativo elegido para configurar la tarea que se va a ejecutar según una programación. Por ejemplo, en Windows, puede usar el Programador de tareas de Windows para ejecutar scripts y tareas. Si tiene SQL Server instalado en la máquina virtual, use Agente SQL Server para ejecutar scripts y tareas.

  • Use Logic Apps para iniciar la tarea agregando un mensaje a una cola que supervisa la tarea o enviando una solicitud a una API que expone la tarea.

Para obtener más información sobre cómo puede iniciar tareas en segundo plano, consulte la sección Desencadenadores anteriores.

Virtual Machines consideraciones

Tenga en cuenta los siguientes puntos al 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 para proporcionar flexibilidad y control preciso sobre el inicio, la implementación, la programación y la asignación de recursos. Sin embargo, los costos en tiempo de ejecución aumentan si implementa una máquina virtual únicamente para tareas en segundo plano.

  • No hay ninguna facilidad para supervisar las tareas en el portal y no hay ninguna funcionalidad de reinicio automatizada para las tareas con errores. Pero puede usar los cmdlets de Azure Resource Manager para supervisar el estado de la máquina virtual y administrarlo. No hay instalaciones para controlar procesos y subprocesos en nodos de proceso. Normalmente, si usa una máquina virtual, debe implementar un mecanismo que recopile datos de la instrumentación en la tarea y también del sistema operativo de la máquina virtual. Puede usar el módulo de administración de System Center para Azure con este fin.

  • Considere la posibilidad de crear sondeos de supervisión que se exponen a través de puntos de conexión HTTP. Puede configurar el código de estos sondeos para realizar comprobaciones de estado y recopilar información operativa y estadísticas. También puede usar los sondeos para intercalar la información de error y devolverla a una aplicación de administración.

Para más información, consulte:

Batch

Considere 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.

Use Batch para preparar las máquinas virtuales, asignar tareas a las máquinas virtuales, ejecutar las tareas, supervisar el progreso y escalar horizontalmente automáticamente las máquinas virtuales en respuesta a la carga de trabajo. Batch también proporciona programación de trabajos y admite máquinas virtuales Linux y Windows.

Consideraciones sobre lotes

Batch es adecuado para cargas de trabajo intrínsecamente paralelas. Puede usar Batch para 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 pasar mensajes entre nodos.

Un trabajo de Batch se ejecuta en un grupo de nodos o máquinas virtuales. Solo puede asignar un grupo cuando sea necesario y, después, eliminarlo una vez finalizado el trabajo. Este enfoque maximiza el uso porque los nodos no están inactivos, pero el trabajo debe esperar a que asigne nodos. Como alternativa, puede crear un grupo con antelación. Este enfoque minimiza el tiempo que tarda un trabajo en iniciarse, pero puede dar lugar a nodos que se encuentran inactivos.

Para más información, consulte:

Azure Kubernetes Service

Use AKS para administrar el entorno de Kubernetes hospedado para poder implementar y administrar fácilmente aplicaciones en contenedores.

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

  • Los contenedores admiten el hospedaje de alta densidad. Puede aislar una tarea en segundo plano en un contenedor y colocar varios contenedores en cada máquina virtual.

  • Use el orquestador de contenedores para realizar el equilibrio de carga interno, configurar la red interna y realizar otras tareas de configuración.

  • Puede iniciar y detener contenedores según sea necesario.

  • Con Azure Container Registry, puede registrar los contenedores dentro de los límites de Azure para proporcionar ventajas de seguridad, privacidad y proximidad.

Consideraciones de AKS

AKS requiere comprender cómo usar un orquestador de contenedores.

Para más información, consulte:

Aplicaciones de contenedor

Con Container Apps, puede crear microservicios sin servidor basados en contenedores. Aplicaciones de contenedor:

  • Está optimizado para ejecutar contenedores de uso general, especialmente las aplicaciones que abarcan muchos microservicios que se implementan en contenedores.

  • Cuenta con tecnología de Kubernetes y tecnologías de código abierto, como Dapr, Escalado automático controlado por eventos de Kubernetes (KEDA) y Envoy.

  • Admite aplicaciones y microservicios de estilo Kubernetes con características como la detección de servicios y la separación del tráfico.

  • Habilita las arquitecturas de aplicaciones controladas por eventos mediante la compatibilidad con el escalado basado en el tráfico y la extracción de orígenes de eventos como colas, incluida la escala a cero.

  • Admite procesos de ejecución prolongada y puede ejecutar tareas en segundo plano.

Consideraciones sobre Las aplicaciones de contenedor

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, use AKS. Si quiere compilar aplicaciones de estilo kubernetes y no necesita acceso directo a las API nativas de Kubernetes y la administración de clústeres, use Container Apps para una experiencia totalmente administrada. Container Apps es más adecuado para compilar microservicios de contenedor.

Para más información, consulte:

Lista de comprobación de confiabilidad

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de confiabilidad