Patrón Queue-based Load Leveling

Use una cola que actúe como búfer entre una tarea y el servicio que invoca. Este enfoque suaviza las cargas elevadas esporádicas que podrían hacer que el servicio falle o que la tarea exceda el tiempo de espera. Ayuda a minimizar el impacto de los picos de demanda en la disponibilidad y la capacidad de respuesta de la tarea y del servicio.

Contexto y problema

Muchas soluciones de la nube ejecutan tareas que invocan servicios. En este entorno, las cargas pesadas intermitentes pueden causar problemas de rendimiento o confiabilidad para un servicio.

Un servicio podría formar parte de la misma solución que las tareas que la usan o podría ser un servicio de asociado que proporcione acceso a los recursos usados con frecuencia. Algunos ejemplos de estos tipos de servicios incluyen una memoria caché o un servicio de almacenamiento. Cuando varias tareas se ejecutan simultáneamente y usan el mismo servicio, es difícil predecir el volumen de solicitudes en cualquier momento.

Un servicio puede experimentar picos de demanda que lo sobrecargan y hacen que el servicio no pueda responder a las solicitudes rápidamente. Sobrecargar un servicio con muchas solicitudes simultáneas también puede hacer que el servicio falle si no puede gestionar la contención que provocan estas solicitudes.

Solución

Coloque una cola entre la tarea y el servicio. La tarea y el servicio se ejecutan de manera asincrónica. La tarea envía un mensaje que contiene los datos que requiere el servicio en la cola. La cola actúa como búfer y almacena el mensaje hasta que el servicio lo recupera. El servicio recupera los mensajes de la cola y los procesa. Las solicitudes de varias tareas, que se pueden generar a velocidades muy variables, se pueden pasar al servicio a través de la misma cola de mensajes. El siguiente diagrama muestra cómo una cola puede nivelar la carga en un servicio.

La cola desacopla las tareas del servicio para que este pueda procesar los mensajes a su propio ritmo, incluso cuando las tareas concurrentes generan un gran volumen de solicitudes. Además, las tareas no se retrasan si el servicio no está disponible cuando publican mensajes en la cola.

Este modelo proporciona las siguientes ventajas:

• Ayuda a maximizar la disponibilidad porque los retrasos en el servicio no afectan de forma inmediata y directa a la aplicación. La aplicación puede seguir publicando mensajes en la cola incluso cuando el servicio no está disponible o no está procesando mensajes actualmente.

• Ayuda a maximizar la escalabilidad porque el número de colas y el número de servicios puede variar para satisfacer la demanda.

• Ayuda a controlar los costos porque solo necesita suficientes instancias de servicio para cumplir los requisitos de una carga media en lugar de la carga máxima.

Problemas y consideraciones

Tenga en cuenta los siguientes puntos a medida que decida cómo implementar este patrón:

• Implemente la lógica de aplicación que controla la velocidad a la que los servicios controlan los mensajes para evitar sobrecargar el recurso de destino. Evite trasladar los picos de demanda a la siguiente etapa del sistema. Pruebe el sistema bajo carga para asegurarse de que proporciona la nivelación requerida. Para lograr la ordenación por niveles necesaria, ajuste el número de colas y el número de instancias de servicio que controlan los mensajes.

• Las colas de mensajes son un mecanismo de comunicación unidireccional. Si una tarea espera una respuesta de un servicio, es posible que tenga que implementar un mecanismo que el servicio pueda usar para enviar una respuesta. Para obtener más información, consulte Asynchronous messaging options in Azure.

• El escalado automático, sin limitar la tasa agregada de los consumidores hacia las dependencias descendentes, no hace más que trasladar la sobrecarga a dichas dependencias. Esta sobrecarga puede aumentar la contención por los recursos compartidos por estos servicios y disminuir la eficacia de la cola para equilibrar la carga.

• Si la tasa media de productor supera la tasa de consumidor, la cola sigue creciendo y aumenta la latencia. Controle la profundidad de la cola y escale los consumidores dentro de límites seguros, o reduzca la carga en el productor.

• Este patrón depende de la durabilidad de la cola para evitar la pérdida de mensajes. Si el intermediario de mensajes no conserva los mensajes en un almacenamiento persistente, un fallo o un límite de capacidad puede hacer que los datos en cola se pierdan antes de que los consumidores los procesen. Elija un servicio de cola que conserve los mensajes en el disco o el almacenamiento replicado y comprenda sus cuotas de tamaño y sus límites de retención. En el caso de las cargas de trabajo que requieren mensajes para sobrevivir a errores regionales, evalúe las opciones de recuperación ante desastres geográficas.

• La mayoría de los servicios de cola proporcionan mensajes con semántica de al menos una vez, lo que significa que los consumidores pueden recibir el mismo mensaje más de una vez. Diseñe la lógica del consumidor para que sea idempotente, de modo que procesar el mismo mensaje varias veces produzca el mismo resultado y evite problemas como registros duplicados o cargos repetidos.

• Algunos mensajes no se pueden procesar porque contienen datos con formato incorrecto, recursos que faltan referencias o desencadenan errores persistentes. En lugar de dejar que estos mensajes sigan circulando indefinidamente y bloqueen la cola, enrútelos a una cola de mensajes fallidos. Monitorice la profundidad de la cola de mensajes fallidos para que el equipo de operaciones pueda investigar los fallos, corregir el problema subyacente y reenviar los mensajes cuando corresponda.

• Introducir una cola entre un productor y un consumidor no preserva el orden original de envío en todos los casos, especialmente cuando varios consumidores procesan mensajes en paralelo. Si su carga de trabajo requiere un orden estricto, utilice características como sesiones de mensajes en Azure Service Bus. Si no se requiere un orden estricto, diseña los consumidores para que procesen los mensajes sin importar el orden, lo que simplifica la escalabilidad.

Cuándo usar este patrón

Use este patrón cuando:

• La carga de trabajo presenta picos intermitentes que pueden sobrecargar los servicios posteriores.

• Necesita desacoplar la recepción de solicitudes del rendimiento de procesamiento para mejorar la resiliencia y el control de costes.

Este patrón podría no ser adecuado cuando:

• El autor de la llamada requiere una respuesta sincrónica y de baja latencia.

• El volumen de carga de trabajo es predeciblemente bajo y estable, por lo que agregar complejidad de cola proporciona poca ventaja.

Diseño de cargas de trabajo

Evalúe cómo utilizar el patrón de nivelación de carga basado en colas en el diseño de una carga de trabajo para abordar los objetivos y principios tratados en los pilares de Azure Well-Architected Framework. En la tabla siguiente se proporciona una guía sobre cómo este patrón apoya los objetivos de cada pilar.

Si este patrón introduce concesiones dentro de un pilar, considérelas en relación con los objetivos de los otros pilares.

Example

Una aplicación web escribe datos en un almacén de datos externo. Si varias instancias de la aplicación web se ejecutan simultáneamente, es posible que el almacén de datos no pueda responder a las solicitudes lo suficientemente rápido, lo que hace que se agote el tiempo de espera de las solicitudes, se limite o se produzca un error en caso contrario. En el diagrama siguiente se muestra un almacén de datos abrumado por solicitudes simultáneas de instancias de una aplicación.

Para resolver este problema, use una cola para nivelar la carga entre las instancias de aplicación y el almacén de datos. Una aplicación Azure Functions lee los mensajes de una cola de Service Bus y realiza las solicitudes de lectura y escritura en el almacén de datos. Azure Functions puede escalar las instancias en función del backlog de Service Bus mediante el escalado basado en objetivos, dentro de los límites de escalado configurados. También puede ajustar la configuración de simultaneidad del desencadenador para proteger el almacén de datos. Para obtener directrices de implementación, consulte Escalado basado en objetivos y Limitar el escalado horizontal. Sin este ajuste, la capa de procesos de trabajo puede volver a introducir contención en el servidor.

Como variación de tecnología, puede implementar el mismo patrón mediante Azure Container Apps en lugar de Azure Functions. En ese enfoque, un trabajo en contenedor consume mensajes de Service Bus y escribe en el almacén de datos. Container Apps escala el trabajador entre el mínimo y el máximo de réplicas configuradas en función de las reglas de escalado basadas en la cola. También puede implementar el mismo enfoque utilizando Azure Queue Storage como origen del evento. Para obtener instrucciones de implementación, consulte Establecimiento de reglas de escalado en Aplicaciones de contenedor e Implementación de un trabajo controlado por eventos mediante Container Apps.

Pasos siguientes

Las directrices siguientes también pueden ser importantes a la hora de implementar este patrón:

• Opciones de mensajería asincrónica en Azure: Las colas de mensajes son intrínsecamente asincrónicas. Es posible que tenga que rediseñar la lógica de la aplicación de una tarea si se comunica directamente con un servicio. Del mismo modo, es posible que tenga que refactorizar un servicio para aceptar solicitudes de una cola de mensajes.

• Elegir entre los servicios de mensajería de Azure: Obtenga más información que le ayude a elegir un mecanismo de mensajería y puesta en cola en aplicaciones de Azure.

• Recomendaciones para desarrollar trabajos en segundo plano: aplique este patrón a trabajos en segundo plano para que las colas de mensajes puedan almacenar solicitudes de tareas en segundo plano cuando la aplicación experimente una carga elevada.

• Estilo de arquitectura Web-Queue-Worker: la aplicación web y el proceso de trabajo no tienen estado. El estado de sesión se puede almacenar en una memoria caché distribuida. El trabajo funciona de forma asincrónica y puede desencadenarse mediante mensajes en la cola o ejecutarse según una programación para el procesamiento por lotes.

Recursos relacionados

• Patrón de consumidores competidores: puede ser posible ejecutar varias instancias de un servicio, cada una de las cuales actúa como consumidor de mensajes de la cola de nivelación de carga. Puede usar este enfoque para ajustar la frecuencia a la que se reciben los mensajes y se pasan a un servicio.

• Patrón de regulación: una forma sencilla de implementar la regulación en un servicio consiste en usar el equilibrio de carga basado en colas y dirigir todas las solicitudes a un servicio a través de una cola de mensajes. El servicio puede procesar solicitudes a un ritmo que le permite no agotar los recursos que necesita y reducir la posible contención.