Consolida varias tareas u operaciones en una sola unidad de cálculo. Esta consolidación puede aumentar el uso de recursos de proceso y reducir los costes y la sobrecarga de administración asociados a la realización del procesamiento de procesos en aplicaciones hospedadas en la nube.
Contexto y problema
Con frecuencia una aplicación en la nube implementa diversas operaciones. En algunas soluciones, resulta conveniente seguir el principio de diseño de separación inicial de problemas y dividir estas operaciones en unidades de cálculo independientes que se hospedan e implementan de manera individual (por ejemplo, como aplicaciones web de App Service independientes o Virtual Machines independientes). Sin embargo, aunque esta estrategia puede ayudar a simplificar el diseño lógico de la solución, la implementación de un gran número de unidades de cálculo como parte de la misma aplicación puede aumentar los costes de hospedaje en tiempo de ejecución y dificultar la administración del sistema.
Por ejemplo, en la ilustración se muestra la estructura simplificada de una solución hospedada en la nube que se implementa mediante más de una unidad de cálculo. Cada unidad de cálculo se ejecuta en su propio entorno virtual. Cada función se ha implementado como una tarea independiente (etiquetadas de la tarea A-a la tarea E) que se ejecuta en su propia unidad de cálculo.
Cada unidad de cálculo consume recursos facturables, incluso cuando está inactiva o se usa poco. Por lo tanto, esta solución no es siempre la más rentable.
En Azure, este problema se aplica a App Services, Container Apps y Virtual Machines. Estos elementos se ejecutan en su propio entorno. La ejecución de una colección de sitios web, microservicios o máquinas virtuales independientes que están diseñados para realizar un conjunto de operaciones bien definidas, pero que necesitan comunicarse y colaborar como parte de una única solución, puede suponer un uso ineficiente de los recursos.
Solución
Para ayudar a reducir los costes, aumentar la utilización, mejorar la velocidad de comunicación y reducir la administración, es posible consolidar varias tareas u operaciones en una sola unidad de cálculo.
Las tareas se pueden agrupar según criterios basados en las características que proporciona el entorno y los costes asociados con estas características. Un enfoque común consiste en buscar las tareas que tienen un perfil similar en lo relativo a sus requisitos de escalabilidad, duración y procesamiento. Cuando se agrupan juntas se pueden escalar como una unidad. La elasticidad que proporcionan muchos entornos de nube permite que se inicien y detengan instancias adicionales de una unidad de cálculo según la carga de trabajo. Por ejemplo, Azure ofrece escalado automático que se puede aplicar a App Services y al conjunto de escalado de máquinas virtuales. Para más información, consulte Guía de escalado automático.
Como ejemplo de contador para mostrar cómo se puede usar la escalabilidad para determinar qué operaciones no deben agruparse, tenga en cuenta las dos tareas siguientes:
- La tarea 1 sondea los mensajes poco frecuentes e independientes del tiempo enviados a una cola.
- La tarea 2 controla las ráfagas de gran volumen del tráfico de red.
La segunda tarea requiere elasticidad que puede implicar iniciar y detener un gran número de instancias de la unidad de cálculo. Aplicar la misma escala a la primera tarea simplemente supondría que más tareas escuchan mensajes poco frecuentes en la misma cola, lo que es una pérdida de recursos.
En muchos entornos de nube, es posible especificar los recursos disponibles para una unidad de cálculo en términos del número de núcleos de CPU, la memoria, el espacio en disco, etc. Por lo general, cuantos más recursos se especifican, mayor es el coste. Para ahorrar dinero, es importante maximizar el trabajo que realiza una unidad de cálculo y no permitir que se vuelva inactiva durante un período de tiempo prolongado.
Si hay tareas que requieren gran cantidad de potencia de CPU en ráfagas cortas, considere la posibilidad de consolidar estos elementos en una sola unidad de cálculo que proporcione la potencia necesaria. Sin embargo, es importante equilibrar esta necesidad de mantener ocupados los recursos costosos con la contención que podría producirse si se someten a una sobrecarga. Las tareas de proceso intensivo de larga duración no deben compartir la misma unidad de cálculo, por ejemplo.
Problemas y consideraciones
Tenga en cuenta los puntos siguientes al implementar este patrón:
Escalabilidad y elasticidad. Muchas soluciones de nube implementan escalabilidad y elasticidad en el nivel de la unidad de cálculo mediante el inicio y la detención de instancias de unidades. Evite agrupar tareas que tengan requisitos de escalabilidad en conflicto en la misma unidad de cálculo.
Vigencia. La infraestructura de nube recicla periódicamente el entorno virtual que hospeda una unidad de cálculo. Cuando hay muchas tareas de larga ejecución dentro de una unidad de cálculo, podría ser necesario configurar la unidad para evitar que se recicle hasta que estas tareas hayan terminado. Otra alternativa es diseñar las tareas mediante un enfoque de punto de comprobación que les permite detenerse correctamente y continuar en el punto en que se interrumpieron cuando la unidad de cálculo se reinicie.
Ritmo de lanzamientos. Si la implementación o la configuración de una tarea cambian con frecuencia, podría ser necesario detener la unidad de cálculo que hospeda el código actualizado, volver a configurarla e implementarla y, luego, reiniciarla. Este proceso también exigirá que todas las demás tareas dentro de la misma unidad de cálculo se detengan, se vuelvan a implementar y se reinicien.
Seguridad. Las tareas de la misma unidad de cálculo podrían compartir el mismo contexto de seguridad y acceder a los mismos recursos. Debe haber un alto grado de confianza entre las tareas, y la seguridad de que una tarea no va a dañar o afectar a otra de manera negativa. Además, al aumentar el número de tareas que se ejecutan en una unidad de cálculo, aumenta la superficie expuesta a ataques de la unidad. Cada tarea solo es tan segura como lo sea la que presenta la mayoría de las vulnerabilidades.
Tolerancia a errores. Si se produce un error en una tarea de una unidad de cálculo o la tarea se comporta de forma anómala, puede afectar a las demás tareas que se ejecutan en la misma unidad. Por ejemplo, una tarea que no se inicia correctamente puede provocar que la lógica completa de inicio de la unidad de cálculo produzca un error e impida que se ejecuten otras tareas de la misma unidad.
Contención. Evite la introducción de contención entre tareas que compiten por los recursos de la misma unidad de cálculo. Lo ideal es que las tareas que comparten la misma unidad de cálculo presenten características diferentes en el uso de los recursos. Por ejemplo, dos tareas de proceso intensivo no deberían residir probablemente en la misma unidad de cálculo, y tampoco dos tareas que consuman grandes cantidades de memoria. Sin embargo, mezclar una tarea de proceso intensivo y una tarea que requiere una gran cantidad de memoria es una combinación factible.
Nota
Considere la posibilidad de consolidar los recursos de proceso solo en sistemas que han estado en producción durante un período de tiempo, de forma que los operadores y los desarrolladores puedan supervisar los sistemas y crear un mapa térmico que identifique el modo en que cada tarea usa recursos diferentes. Este mapa se puede utilizar para determinar qué tareas son buenas candidatas a compartir recursos de proceso.
Complejidad. Combinar varias tareas en una sola unidad de cálculo agrega complejidad al código de la unidad, de modo que posiblemente sea más difícil de probar, depurar y mantener.
Arquitectura lógica estable. Diseñe e implemente el código de cada tarea de forma que no sea necesario cambiarlo, incluso si lo hace el entorno físico en el que se ejecuta la tarea.
Otras estrategias. La consolidación de recursos de proceso es solo una manera de ayudar a reducir los costes asociados a la ejecución simultánea de varias tareas. Requiere un planeamiento y una supervisión rigurosos a fin de asegurarse de que siga siendo un enfoque efectivo. Otras estrategias podrían ser más adecuadas, según la naturaleza del trabajo y dónde se encuentren los usuarios que ejecutan estas tareas. Por ejemplo, la descomposición funcional de la carga de trabajo (como se describe en el documento Compute Partitioning Guidance) (Guía de creación de particiones de proceso) podría ser una mejor opción.
Cuándo usar este patrón
Use este patrón con tareas que no sean rentables si se ejecutan en sus propias unidades de cálculo. Si una tarea gasta mucho de su tiempo de inactividad, ejecutar esta tarea en una unidad dedicada puede resultar costoso.
Este patrón podría no ser adecuado con tareas que realizan operaciones críticas de tolerancia a errores, o tareas que procesan datos de alto secreto o privados y requieren su propio contexto de seguridad. Estas tareas se deben ejecutar en su propio entorno aislado, en una unidad de cálculo independiente.
Diseño de cargas de trabajo
El arquitecto debe evaluar cómo se puede usar el patrón de consolidación de recursos del proceso en el diseño de su carga de trabajo para abordar los objetivos y principios tratados en los pilares del Marco de la Well-Architected de Azure. Por ejemplo:
| Fundamento | Cómo apoya este patrón los objetivos de los pilares |
|---|---|
| La optimización de costos se centra en mantener y mejorar el retorno de la inversión de la carga de trabajo. | Este patrón maximiza la utilización de los recursos informáticos evitando la capacidad aprovisionada no utilizada mediante la agregación de componentes o incluso cargas de trabajo completas en una infraestructura agrupada. - CO:14 Consolidación |
| La excelencia operativa ayuda a ofrecer calidad de carga de trabajo a través de procesos estandarizados y cohesión de equipos. | La consolidación puede conducir a una plataforma de proceso más homogénea, lo que puede simplificar la gestión y la observabilidad, reducir los enfoques dispares de las tareas operativas y reducir la cantidad de herramientas necesarias. - OE:07 Sistema de supervisión - OE:10 Diseño de automatización |
| La eficiencia del rendimiento ayuda a que la carga de trabajo satisfaga eficazmente las demandas mediante optimizaciones en el escalado, los datos y el código. | La consolidación maximiza la utilización de los recursos de proceso utilizando la capacidad sobrante de los nodos y reduciendo la necesidad de sobreaprovisionamiento. En el grupo de recursos de estas infraestructuras suelen utilizarse instancias de proceso de gran tamaño (escaladas verticalmente). - PE:02 Planeamiento de capacidad - PE:03 Selección de servicios |
Al igual que con cualquier decisión de diseño, hay que tener en cuenta las ventajas y desventajas con respecto a los objetivos de los otros pilares que podrían introducirse con este patrón.
Elección de la plataforma de aplicaciones
Este patrón puede lograrse de maneras diferentes, en función del servicio de proceso que use. Consulte los siguientes servicios de ejemplo:
- Azure App Service y Azure Functions: implemente planes compartidos de App Service, que representan la infraestructura del servidor de hospedaje. Pueden configurarse una o varias aplicaciones para que se ejecuten en los mismos recursos informáticos (o en el mismo plan de App Service).
- Azure Container Apps: implemente aplicaciones de contenedor en los mismos entornos compartidos. especialmente en situaciones en las que necesita administrar servicios relacionados o cuando necesita implementar aplicaciones diferentes en la misma red virtual.
- Azure Kubernetes Service (AKS): AKS es una infraestructura de hospedaje basada en contenedores en la que se pueden configurar varias aplicaciones o componentes de aplicación para ejecutar la ubicación compartida en los mismos recursos informáticos (nodos), agrupados por requisitos computacionales, como las necesidades de CPU o memoria (grupos de nodos).
- Máquinas virtuales: implemente un único conjunto de máquinas virtuales para que todos los inquilinos lo usen, de esta forma los costos de administración se comparten entre los inquilinos. Virtual Machine Scale Sets es una característica que admite la administración de recursos compartidos, el equilibrio de carga y el escalado horizontal de Virtual Machines.
Recursos relacionados
Los patrones y las directrices siguientes también pueden ser importantes a la hora de implementar este modelo:
Guía de escalado automático. El escalado automático puede utilizarse para iniciar y detener instancias de servicio que hospedan recursos de cálculo, según la demanda prevista de procesamiento.
Compute Partitioning Guidance (Orientación sobre la creación de particiones de proceso). Se describe cómo asignar los servicios y componentes de un servicio en la nube de tal forma que ayude a reducir los costes de ejecución mientras se mantiene la escalabilidad, el rendimiento, la disponibilidad y la seguridad del servicio.
Enfoques de arquitectura para el proceso en soluciones multiinquilino. Proporciona instrucciones sobre las consideraciones y los requisitos que son esenciales para los arquitectos de soluciones cuando planean los servicios de proceso de una solución multiinquilino.