Autoescalado

método utilizado en computación en la nube para administrar la cantidad de servidores activos basado en la demanda

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]

Ventajas editar

El autoescalado ofrece ventajas como:

  • Ahorro de electricidad en empresas con infraestructura de servidores propia, dado que los servidores se activan y desactivan automáticamente. También permite ahorrar agua (y su costo) en servidores de refrigeración líquida.[2]
  • Ahorro en costos para empresas con infraestructuras basadas en la nube. La gran mayoría de proveedores factura el uso de servidores por reserva (equipos o instancias reservadas), tiempo de uso y procesamiento empleado. A menor reserva, menor costo.[3]
  • Venta de procesamiento adicional en equipos reservados que se encuentran en reposo o con baja carga.[4]
  • Protección contra fallos de hardware, red y aplicaciones para sistemas que soporten el reemplazo automático de instancias inestables o dañadas.[5]
  • Mayor tiempo de actividad y disponibilidad en casos donde la carga de trabajo pueda llegar a ser variable e impredecible.

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]

Terminología editar

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.

Práctica editar

Amazon Web Services (AWS) editar

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.

Microsoft Azure editar

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 editar

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.

Google Cloud Platform editar

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]

Facebook editar

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]

Autoescalado horizontal de pod en Kubernetes editar

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]

Netflix editar

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]

Enfoques alternativos editar

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.

Enfoque de autoescalado programado editar

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.

Enfoque de autoescalado predictivo editar

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]

  • Identificar grandes picos de demanda y preparar la capacidad con un mínimo de anticipación.
  • Lidiar con interrupciones a gran escala, falla en zonas y regiones de disponibilidad completa.
  • Lidiar con patrones de tráfico variables, brindando más flexibilidad en la tasa de escalado horizontal o vertical en función del nivel típico y la tasa de cambio en la demanda en varios momentos del día.

Véase también editar

Referencias editar

  1. «Above the Clouds: A Berkeley View of Cloud Computing». Berkeley EECS. 10 de febrero de 2009. Consultado el 21 de marzo de 2015. 
  2. a b c Wu, Qiang (8 de agosto de 2014). «Making Facebook’s software infrastructure more energy efficient with Autoscale». Facebook Code Blog. Consultado el 21 de marzo de 2015. 
  3. Laderman, Zev (22 de abril de 2012). «The 10 Biggest Mistakes Made With Amazon Web Services». Consultado el 21 de marzo de 2015. 
  4. Park, Andrew (18 de septiembre de 2015). «Creating Your Own EC2 Spot Market». Netflix. Consultado el 16 de diciembre de 2016. 
  5. Wittig, Michael (26 de diciembre de 2015). «5 AWS mistakes you should avoid». cloudonaut. Consultado el 16 de diciembre de 2016. 
  6. a b Orzell, Greg (18 de enero de 2012). «Auto Scaling in the Amazon Cloud». Netflix Tech Blog. Consultado el 21 de marzo de 2012. 
  7. Cubrilovic, Nik (24 de agosto de 2006). «Almost Exclusive: Amazon Readies Utility Computing Service». Consultado el 4 de diciembre de 2016. 
  8. Barr, Jeff (25 de agosto de 2006). «Amazon EC2 Beta». Amazon Web Services Blog. Consultado el 31 de mayo de 2013. 
  9. Work, Henry (3 de abril de 2008). «Scalr: The Auto-Scaling Open-Source Amazon EC2 Effort». Consultado el 21 de marzo de 2015. 
  10. Howlett, Dennis (25 de junio de 2008). «RightScale cloud management extends to MySQL. RightScale, which specializes in cloud computing management for the Amazon Web Services platform today announced support for MySQL Enterprise. The service, which goes live July 1, provides automated deployment, management and scaling, coupled with MySQL Enterprise premium-level support for large database applications.». Consultado el 16 de diciembre de 2016. 
  11. von Eicken, Thorsten (23 de abril de 2008). «Animoto's Facebook Scale-Up». Archivado desde el original el 20 de diciembre de 2016. Consultado el 16 de diciembre de 2016. 
  12. «What is autoscaling?». TechTarget. Archivado desde el original el 29 de abril de 2019. Consultado el 21 de marzo de 2015. 
  13. «Cloud computing/Amazon Web Services/AWS Command Line Tool (CLI) - Wikiversity». en.wikiversity.org. Consultado el 6 de junio de 2020. 
  14. Lardinois, Frederic (27 de junio de 2013). «Microsoft Adds Auto Scaling To Windows Azure». Consultado el 21 de marzo de 2015. 
  15. «Microsoft to add autoscaling, alerts to Windows Azure». 27 de junio de 2013. Consultado el 21 de marzo de 2015. 
  16. Butler, Brandon (7 de agosto de 2013). «Google, Microsoft play catch up to Amazon, add load balancing, auto-scaling to their clouds». Network World. Archivado desde el original el 18 de mayo de 2018. Consultado el 21 de marzo de 2015. 
  17. «Autoscaling Guidance». Microsoft Developer Network. 
  18. «The Autoscaling Application Block». Microsoft Developer Network. Consultado el 21 de marzo de 2015. 
  19. «Administering PaaS Services». Oracle Help Center (en inglés estadounidense). Consultado el 16 de mayo de 2018. 
  20. Balejko, Filip (17 de noviembre de 2014). «Autoscaling, welcome to Google Compute Engine». Google Cloud Platform blog. Consultado el 21 de marzo de 2015. 
  21. Protalinski, Emil (17 de noviembre de 2014). «Google Compute Engine gets Autoscaler to adjust app resources based on varying traffic and workloads». Consultado el 21 de marzo de 2015. 
  22. Lardinois, Frederic (17 de noviembre de 2014). «Google Brings Autoscaling To Compute Engine». Consultado el 21 de marzo de 2015. 
  23. Verge, Jason (17 de noviembre de 2014). «Google Launches Autoscaling Beta on Compute Engine». Data Center Knowledge. Consultado el 21 de marzo de 2015. 
  24. a b «Autoscaling: How the Cloud Provides a Tremendous Boost». Morpheus. 2 de noviembre de 2016. Archivado desde el original el 25 de septiembre de 2019. Consultado el 16 de diciembre de 2016. 
  25. «Horizontal Pod Autoscaler Walkthrough» (en inglés estadounidense). Consultado el 21 de junio de 2018. 
  26. Jacobson, Daniel. «Scryer: Netflix’s Predictive Auto Scaling Engine». The Netflix Tech Blog. Netflix. Consultado el 28 de mayo de 2015. 

Enlaces externos editar