El autoescalado, también conocido como escalado automático o autoscaling, es un método utilizado en computación en la nube por el cual la cantidad de recursos computacionales en un sistema de servidores, medido a partir del número de servidores activos, varía automáticamente en consecuencia de la carga total. Esto significa que la cantidad de servidores aumenta o disminuye dependiendo de la actividad (a más actividad más carga, y en consecuencia, más servidores se activarán). Es un concepto parecido al de balance de carga, y puede ser implementado en conjunto.[1]
El autoescalado ofrece ventajas como:
El autoescalado difiere de un sistema de ciclo fijo de uso de servidores, en el cual el patrón inicial de carga está dado por la estimación que se presupone para los distintos momentos del día. Esto se traduce en un despropósito de exceso o falta de servidores para balancear una carga en un momento específico. Por ejemplo, en una configuración fija de servidores, si durante la noche se programa que la mitad de los equipos descansen porque se estipula que (por lo general) habrá bajo tráfico, podría ocurrir que cierto día la carga se desborde (por un pico de tráfico) y los servidores se saturen, dejando de responder. El autoescalado previene esta situación activando o desactivando los servidores dependiendo del tráfico actual, por lo cual puede manejar mejor los picos de tráfico.[2][6]
A continuación, utilizaremos la terminología utilizada por Amazon Web Services para detallar los elementos que componen un sistema de autoescalado, sin mencionar los nombres específicos de los servicios provistos por la empresa. Se mencionan, también, nombres alternativos empleados en otras plataformas (Google Cloud, Microsoft Azure y otros).
Nombre (AWS) | Descripción | Nombre alternativo |
---|---|---|
Instancia | Un único servidor o máquina que forma parte del grupo de máquinas sujetas a la configuración de autoescalado. | |
Grupo de autoescalado | El grupo de instancias sujetas a la configuración de autoescalado, junto con todas las políticas asociadas e información de estado. | Grupo de instancias administradas (Google Cloud) |
Tamaño | El número de instancias que conforman el grupo de autoescalado. | |
Capacidad deseada (o tamaño deseado) | El número de instancias que el grupo de autoescalado debería alcanzar en un momento dado. Si el tamaño es menor que el tamaño deseado, el grupo de escalado automático intentará lanzar (aprovisionar y adjuntar) nuevas instancias. Si el tamaño es mayor que el tamaño deseado, el grupo de autoescalado intentará eliminar (separar y terminar) las instancias sobrantes. | |
Tamaño mínimo | Un número de instancias mínimo a mantener activas. La capacidad deseada no puede caer por debajo de este nivel. | |
Tamaño máximo | Un número de instancias máximo a lanzar. La capacidad deseada no puede sobrepasar este nivel. | |
Métrica | Una medida (como la utilización de CPU, uso de memoria, o uso de red) asociada con el grupo de autoescalado, para la cual se generan regularmente una serie temporal de puntos de datos. Los umbrales para las métricas pueden utilizarse para establecer políticas de autoescalado. Las métricas pueden basarse en agregados de métricas o en equilibradores de carga asociados con el grupo de autoescalado. | |
Política de autoescalado | Una política que especifica un cambio en la capacidad deseada del grupo de autoescalado en respuesta a métricas que cruzan umbrales (o puntos de datos) específicos. | |
Salud | Una forma en que el grupo de autoescalado determine si las instancias adjuntas funcionan correctamente. Una comprobación de estado puede basarse en si la instancia todavía existe y es accesible, o en si la instancia sigue registrada y en servicio con un equilibrador de carga asociado. | |
Lanzar configuración | Una descripción de los parámetros y scripts utilizados al iniciar una nueva instancia. Esto incluye el tipo de instancia, las opciones de compra, zonas de disponibilidad, imagen de la máquina y scripts para ejecutar durante el lanzamiento. | Plantilla de instancia (Google Cloud) |
Escala manual | Una acción de escala ejecutada manualmente. | |
Escalado programado | Una política de escalado que se ejecuta a una hora específica, por ejemplo, una hora del día, semana, mes o año. |
Amazon Web Services lanzó el servicio Amazon Elastic Compute Cloud (EC2) en agosto de 2006, el cual permitió a los desarrolladores crear y terminar instancias (máquinas) programáticamente.[7][8] Al momento del lanzamiento, AWS no ofrecía autoescalado, pero la capacidad de crear y terminar instancias de esta modo les brindó a los desarrolladores la flexibilidad necesaria para diseñar su propia estrategia de escalamiento.
Software de terceros para autoescalado apareció aproximadamente en abril de 2008. Estos incluyeron herramientas de Scalr[9] y RightScale. Animoto utilizó RightScale, el cual fue capaz de manejar el tráfico de Facebook mediante la adopción de esta técnica.[10][11]
El 18 de mayo de 2009, Amazon lanzó su propia función de autoescalado junto con Elastic Load Balancing como parte de Elastic Compute Cloud, el cual pasó a ser un componente integral del servicio.[12] La configuración puede realizarse a través de un navegador web o la utilidad de línea de comandos (aws-cli).[13] A partir de mayo de 2016, el autoescalado también se ofrece para el servicio AWS ECS.
El 27 de junio de 2013, Microsoft anunció el agregado de soporte de autoescalado para su plataforma Microsoft Azure.[14][15][16] La documentación oficial se encuentra disponible en la Red de desarrolladores de Microsoft .[17][18]
Oracle Cloud Platform permite que las instancias de servidor escalen automáticamente un clúster dentro o fuera mediante la definición de reglas.[19] Estas reglas se basan en la utilización de la CPU y/o la memoria, y determinan cuándo agregar o quitar nodos.
El 17 de noviembre de 2014, Google Compute Engine anunció una versión pública de su función de autoescalado para usar en aplicaciones de Google Cloud Platform.[20][21][22][23]
En una publicación de agosto de 2014, un ingeniero de Facebook reveló que la compañía había comenzado a utilizar autoescalado dentro de su propia infraestructura para reducir sus costos de energía. La empresa informó una disminución del 27 % en el uso de energía para las horas de poco tráfico (alrededor de la medianoche) y una disminución de entre el 10 y el 15 % durante el ciclo típico de 24 horas.[2][24]
El autoescalado horizontal de pods de Kubernetes escala automáticamente el número de pods en un controlador de replicación, implementación o conjunto de réplicas en función de la utilización observada de la CPU (o, con soporte beta, en alguna otra métrica proporcionada por la aplicación).[25]
Un ejemplo de los grandes beneficios de usar autoescalado en empresas de alto consumo de tráfico es Netflix, el proveedor de video bajo demanda, quien documentó cómo el uso de esta técnica ayudó a satisfacer sus necesidades de consumo altamente variables.[6]
El autoescalado por defecto usa un enfoque reactivo para tratar con el escalado del tráfico: el escalado sólo ocurre en respuesta a cambios en tiempo real en las métricas. En algunos casos, particularmente cuando los cambios ocurren demasiado rápido, el enfoque reactivo puede resultar insuficiente. A continuación se describen enfoques alternativos.
En este enfoque se programan cambios en el tamaño mínimo, máximo o la capacidad deseada en momentos específicos del día. El escalado programado es útil, por ejemplo, si se conoce de antemano el aumento o disminución de la carga en determinados momentos, pero los cambios son tan repentinos que el autoescalado reactivo no logra responder a tiempo.
Este enfoque utiliza análisis predictivos. La idea es combinar tendencias de uso recientes con datos de uso históricos, así como otros tipos de datos, para predecir el uso en el futuro, y escalar automáticamente en función de estas predicciones.
Por ejemplo, para partes de su infraestructura y cargas de trabajo específicas, Netflix descubrió que Scryer, su motor de análisis predictivo, daba mejores resultados que el enfoque reactivo de escalado automático de Amazon. En particular, fue mejor para:[26][24]