Recomendaciones para diseñar una estrategia de escalado confiable

  • Artículo

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

RE:06 Implemente una estrategia de escalado oportuna y confiable en los niveles de aplicación, datos e infraestructura.

Guía relacionada:Creación de particiones de datos

En esta guía se describen las recomendaciones para diseñar una estrategia de escalado confiable.

Definiciones

Término Definición
Escalado vertical Enfoque de escalado que agrega capacidad de proceso a los recursos existentes.
Escalado horizontal Enfoque de escalado que agrega instancias de un tipo determinado de recurso.
Escalado automático Un enfoque de escalado que agrega o quita automáticamente los recursos cuando se cumple un conjunto de condiciones.

Nota

Las operaciones de escalado pueden ser estáticas (el escalado diario programado regularmente para dar cabida a patrones de carga normales), automático (un proceso automatizado en respuesta a las condiciones que se cumplen) o manual (un operador realiza una operación de escalado único en reacción a un cambio de carga imprevisto). El escalado vertical y horizontal se puede realizar a través de cualquiera de estos métodos. Sin embargo, el escalado vertical automático requiere un desarrollo de automatización personalizado adicional y puede provocar tiempo de inactividad en función de los recursos que se escalan.

Estrategias de diseño principales

Para diseñar una estrategia de escalado confiable para las cargas de trabajo, céntrese en identificar patrones de carga para los flujos de usuario y del sistema para cada carga de trabajo que conduce a una operación de escalado. Estos son ejemplos de los diferentes patrones de carga:

  • Estático: cada noche por 11 p. m. est, el número de usuarios activos es inferior a 100 y el uso de CPU para los servidores de aplicaciones cae un 90 % en todos los nodos.

  • Dinámica, normal y predecible: todos los lunes por la mañana, 1000 empleados de varias regiones inician sesión en el sistema ERP.

  • Dinámico, irregular y predecible: se produce un lanzamiento de producto el primer día del mes y hay datos históricos de los lanzamientos anteriores sobre cómo aumenta el tráfico en estas situaciones.

  • Dinámico, irregular e imprevisible: un evento a gran escala provoca un pico en la demanda de un producto. Por ejemplo, las empresas que fabrican y venden dehumidificadores pueden experimentar un aumento repentino en el tráfico después de un huracán u otro evento de inundación cuando las personas en áreas afectadas necesitan secar habitaciones en su hogar.

Después de identificar estos tipos de patrones de carga, puede hacer lo siguiente:

  • Identifique cómo afecta el cambio de carga asociado a cada patrón de la infraestructura.

  • Compile la automatización para abordar el escalado de forma confiable.

En los ejemplos anteriores, las estrategias de escalado podrían ser:

  • Estático: tiene una escala programada de los nodos de proceso al recuento mínimo (2) entre las 11 p. m. y las 6 a. m. est.

  • Dinámica, normal y predecible: tiene una escalabilidad horizontal programada de los nodos de proceso a la capacidad diaria normal antes de que la primera región comience a funcionar.

  • Dinámica, irregular y predecible: se define una escala vertical programada única de las instancias de proceso y base de datos en la mañana de un lanzamiento de producto y se reduce verticalmente después de una semana.

  • Dinámico, irregular e imprevisible: tiene umbrales de escalado automático definidos para tener en cuenta los picos de tráfico no planeados.

Al diseñar la automatización de escalado, asegúrese de tener en cuenta estos problemas:

  • Que todos los componentes de la carga de trabajo deben ser candidatos para la implementación de escalado. En la mayoría de los casos, los servicios globales, como Microsoft Entra id. se escalan automáticamente y de forma transparente para usted y sus clientes. Asegúrese de comprender las funcionalidades de escalado de los controladores de entrada y salida de red y la solución de equilibrio de carga.

  • Esos componentes que no se pueden escalar horizontalmente. Un ejemplo sería bases de datos relacionales grandes que no tienen habilitado el particionamiento y no se puede refactorizar sin un impacto significativo. Documente los límites de recursos publicados por el proveedor de nube y supervise esos recursos estrechamente. Incluya esos recursos específicos en su planeación futura para migrar a servicios escalables.

  • El tiempo necesario para realizar la operación de escalado para que programe correctamente la operación para que se produzca antes de que la carga adicional alcance la infraestructura. Por ejemplo, si un componente como API Management tarda 45 minutos en escalarse, ajustar el umbral de escalado al 65 % en lugar del 90 % podría ayudarle a escalar antes y prepararse para el aumento previsto de la carga.

  • La relación de los componentes del flujo en términos de orden de las operaciones de escalado. Asegúrese de que no sobrecarga accidentalmente un componente de nivel inferior mediante el escalado primero de un componente ascendente.

  • Cualquier elemento de aplicación con estado que se pueda interrumpir mediante una operación de escalado y cualquier afinidad de sesión (o permanencia de sesión) que se implemente. La permanencia puede limitar la capacidad de escalado e introducir puntos únicos de error.

  • Posibles cuellos de botella. El escalado horizontal no corrige todos los problemas de rendimiento. Por ejemplo, si la base de datos de back-end es el cuello de botella, no ayuda a agregar más servidores web. Identifique y resuelva primero los cuellos de botella en el sistema antes de agregar más instancias. Los elementos con estado del sistema son la causa más probable de los cuellos de botella.

Seguir el patrón de diseño de stamps de implementación ayuda con la administración general de la infraestructura. Basar el diseño de escalado en sellos, ya que las unidades de escala también son beneficiosas. Además, le ayuda a controlar estrechamente las operaciones de escalado en varias cargas de trabajo y subconjuntos de cargas de trabajo. En lugar de administrar las programaciones de escalado y los umbrales de escalado automático de muchos recursos distintos, puede aplicar un conjunto limitado de definiciones de escalado a un stamp de implementación y, a continuación, reflejarlo en los stamps según sea necesario.

Equilibrio: el escalado vertical tiene implicaciones de costos, por lo que optimizar la estrategia para reducir verticalmente lo antes posible para ayudar a mantener los costos bajo control. Asegúrese de que la automatización que emplea para escalar verticalmente también tiene desencadenadores para reducir verticalmente.

Facilitación de Azure

Hay disponible una característica de escalado automático en muchos servicios de Azure. Permite configurar fácilmente las condiciones para escalar automáticamente instancias horizontalmente. Algunos servicios tienen funcionalidades limitadas o no integradas para escalar horizontalmente de forma automática, así que asegúrese de documentar estos casos y definir procesos para tratar el escalado.

Muchos servicios de Azure ofrecen API que puede usar para diseñar operaciones de escalado automático personalizadas mediante Azure Automation, como los ejemplos de código en Escalabilidad automática del Azure IoT Hub. Puede usar herramientas como KEDA para el escalado automático controlado por eventos, que está disponible en Azure Kubernetes Service y Azure Container Apps.

El escalado automático de Azure Monitor proporciona un conjunto común de funcionalidades de escalado automático para Azure Virtual Machine Scale Sets, Azure App Service, Azure Spring Apps y mucho más. El escalado se puede realizar según una programación o en función de una métrica en tiempo de ejecución, como el uso de CPU o memoria. Consulte la guía de Azure Monitor para conocer los procedimientos recomendados.

Compromisos

Consideraciones sobre el escalado automático

El escalado automático no es una solución instantánea. La simple adición de recursos a un sistema o la ejecución de instancias adicionales de un proceso no garantiza que mejorará el rendimiento del sistema. Tenga en cuenta lo siguiente a la hora de diseñar una estrategia de escalado automático:

El sistema debe diseñarse para el escalado horizontal. Evite realizar suposiciones sobre la afinidad de instancia. No diseñe soluciones que requieran que el código siempre se ejecute en una instancia específica de un proceso. Al escalar horizontalmente un servicio en la nube o un sitio web, no suponga que una serie de solicitudes del mismo origen siempre se enrutan a la misma instancia. Por la misma razón, diseñe los servicios sin estado para evitar la necesidad de disponer de una serie de solicitudes de que una aplicación siempre se dirija a la misma instancia de un servicio. Al diseñar un servicio que lee y procesa mensajes de una cola, no haga ninguna suposición sobre qué instancia de servicio controla un mensaje específico. El escalado automático podría iniciar más instancias de un servicio a medida que crece la longitud de la cola. El patrón de consumidores simultáneos describe cómo administrar este escenario.

Si la solución implementa una tarea de ejecución prolongada, diseñe esta tarea para que admita el escalado horizontal (tanto reducción como ampliación). Sin cuidado debido, esta tarea podría impedir que una instancia de un proceso se apague limpiamente cuando el sistema se escale verticalmente. O bien, podría perder datos si el proceso finaliza forzosamente. De manera ideal, refactorice una tarea de ejecución prolongada y divida el procesamiento que realiza en fragmentos más pequeños y discretos. El patrón Canalizaciones y filtros proporciona un ejemplo de cómo puede lograr esta solución.

Como alternativa, puede implementar un mecanismo de punto de comprobación que registre información de estado sobre la tarea a intervalos regulares. Después, puede guardar este estado en un almacenamiento duradero al que puede acceder cualquier instancia del proceso que ejecuta la tarea. De este modo, si el proceso se cierra, otra instancia puede reanudar el trabajo que estaba realizando desde el último punto de control. Hay bibliotecas que proporcionan esta funcionalidad, como NServiceBus y MassTransit. Conservan de forma transparente el estado, donde los intervalos se alinean con el procesamiento de mensajes de las colas en Azure Service Bus.

Cuando las tareas en segundo plano se ejecutan en instancias de proceso independientes, como en roles de trabajo de una aplicación hospedada en servicios en la nube, es posible que tenga que escalar diferentes partes de la aplicación mediante directivas de escalado diferentes. Por ejemplo, es posible que tenga que implementar instancias de proceso de interfaz de usuario (UI) adicionales sin aumentar el número de instancias de proceso en segundo plano o viceversa. Si ofrece distintos niveles de servicio, como los paquetes de servicio básico y premium, es posible que tenga que escalar horizontalmente los recursos de proceso de los paquetes de servicio Premium de forma más agresiva que para los paquetes de servicio básicos para cumplir los acuerdos de nivel de servicio (SLA).

Plantéese la longitud de la cola sobre la que se comunican las instancias de proceso de interfaz de usuario y en segundo plano. Úselo como criterio para la estrategia de escalado automático. Este problema es un indicador posible de un desequilibrio o diferencia entre la carga actual y la capacidad de procesamiento de la tarea en segundo plano. Un atributo ligeramente más complejo pero mejor en el que basar las decisiones de escalado es usar el tiempo entre el momento en que se envió un mensaje y el momento en que se completó su procesamiento. Este intervalo se conoce como el tiempo crítico. Si este valor de tiempo crítico está por debajo de un umbral empresarial significativo, no es necesario escalar, incluso si la longitud de la cola es larga.

Por ejemplo, podría haber 50 000 mensajes en una cola. Pero el tiempo crítico del mensaje más antiguo es de 500 ms y el punto de conexión se ocupa de la integración con un servicio web de terceros para enviar correos electrónicos. Es probable que las partes interesadas de la empresa consideren que es un período de tiempo que no justificaría el gasto de dinero adicional para el escalado.

Por otro lado, podría haber 500 mensajes en una cola, con el mismo tiempo crítico de 500 ms, pero el punto de conexión forma parte de la ruta crítica en algún juego en línea en tiempo real donde las partes interesadas de la empresa definieron un tiempo de respuesta de 100 ms o menos. En ese caso, el escalado horizontal sí que tendría sentido.

Para usar el tiempo crítico en las decisiones de escalado automático, resulta útil que una biblioteca agregue automáticamente la información pertinente a los encabezados de los mensajes mientras se envían y procesan. Una biblioteca que proporciona esta funcionalidad es NServiceBus.

Si basa la estrategia de escalado automático en contadores que miden los procesos empresariales, como el número de pedidos realizados por hora o el tiempo medio de ejecución de una transacción compleja, asegúrese de comprender completamente la relación entre los resultados de estos tipos de contadores y los requisitos de capacidad de proceso reales. Puede ser necesario escalar más de un componente o unidad de proceso en respuesta a los cambios en los contadores de procesos empresariales.

Para evitar que un sistema intente escalar horizontalmente excesivamente y evitar los costos asociados a la ejecución de muchos miles de instancias, considere la posibilidad de limitar el número máximo de instancias que se agregan automáticamente. La mayoría de los mecanismos de escalado automático permiten especificar el número mínimo y máximo de instancias de una regla. Además, considere la posibilidad de degradar correctamente la funcionalidad que proporciona el sistema si se ha implementado el número máximo de instancias y el sistema todavía está sobrecargado.

Tenga en cuenta que el escalado automático podría no ser el mecanismo más adecuado para controlar una ráfaga repentina en una carga de trabajo. Se tarda tiempo en aprovisionar e iniciar nuevas instancias de un servicio o agregar recursos a un sistema, y la demanda máxima podría pasar en el momento en que estos recursos adicionales están disponibles. En este escenario, podría ser mejor limitar el servicio. Para más información, consulte el patrón de limitaciones.

Por el contrario, si necesita la capacidad de procesar todas las solicitudes cuando el volumen fluctúa rápidamente y el costo no es un factor importante que contribuye, considere la posibilidad de usar una estrategia de escalado automático agresiva que inicie más instancias más rápidamente. También puede usar una directiva programada que inicie un número suficiente de instancias como para satisfacer la carga máxima antes de que se espere esa carga.

El mecanismo de escalado automático debe supervisar el proceso de escalado automático y registrar los detalles de cada evento de escalado automático (lo que lo desencadenó, qué recursos se agregaron o quitaron y cuándo). Si crea un mecanismo de escalado automático personalizado, asegúrese de que incorpore esta capacidad. Analice la información para ayudar a medir la eficacia de la estrategia de escalado automático y ajustarla según sea necesario. Puede ajustarla tanto a corto plazo, a medida que los patrones de uso se hagan más evidentes, y a largo plazo, a medida que el negocio se expanda o evolucionen los requisitos de la aplicación. Si una aplicación alcanza el límite superior definido para el escalado automático, el mecanismo también podría alertar a un operador que podría iniciar manualmente más recursos si es necesario. En estas circunstancias, el operador también puede ser responsable de quitar manualmente estos recursos después de que se facilite la carga de trabajo.

Ejemplo

Consulte la guía de escalado de la arquitectura de referencia de línea base de AKS.

Lista de comprobación de confiabilidad

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de confiabilidad