Escalado de recursos
Una de las principales ventajas de la nube es la capacidad de escalar recursos a un sistema a petición. El escalado vertical (aprovisionamiento de recursos más grandes) o el escalado horizontal (aprovisionamiento de recursos adicionales) pueden ayudar a reducir la carga en un único recurso mediante la disminución del uso como resultado de una mayor capacidad o de una distribución más amplia de la carga de trabajo.
El escalado puede ayudar a mejorar el resultado al aumentar el rendimiento, ya que entonces se puede atender un mayor número de solicitudes. Esto también puede ayudar a reducir la latencia durante las cargas máximas, dado que solo se pone en la cola un número reducido de solicitudes durante las cargas máximas en un único recurso. Además, esto puede ayudar a mejorar la confiabilidad del sistema al reducir el uso de recursos para que se aleje del punto de interrupción del recurso.
Es importante tener en cuenta que, aunque la nube permite aprovisionar fácilmente recursos más nuevos o mejores, el coste es siempre un factor que se debe valorar. Por lo tanto, aunque es beneficioso escalar vertical u horizontalmente, también es importante reconocer cuándo conviene reducir vertical u horizontalmente para ahorrar costos. En una aplicación de n niveles, también es esencial identificar dónde se encuentran los cuellos de botella y qué nivel se debe escalar, ya sea la capa de datos o el nivel de servidor.
El equilibrio de carga facilita el escalado de recursos (se explicó anteriormente), pues ayuda a enmascarar el aspecto de escalado de un sistema ocultándolo detrás de un punto de conexión coherente.
Estrategias de escalado
Escalado horizontal (reducir y escalar horizontalmente)
El escalado horizontal es una estrategia mediante la cual se pueden agregar recursos adicionales al sistema o quitar recursos superfluos. Este tipo de escalado es beneficioso para el nivel de servidor cuando la carga en el sistema es impredecible y fluctúa de forma incoherente. La naturaleza de la carga fluctuante hace que sea esencial aprovisionar de forma eficaz la cantidad correcta de recursos para administrar la carga en todo momento.
Algunas consideraciones que hacen que esta tarea sea complicada es el tiempo de espera de una instancia, el modelo de precios del proveedor de servicios en la nube y la posible pérdida de ingresos de la degradación de la calidad de servicio (QoS), al no escalarse horizontalmente a tiempo. Como ejemplo, considere el siguiente patrón de carga:
Figura 6: Patrón de carga de la solicitud de ejemplo
Suponga que está usando Amazon Web Services. Imagina también que cada unidad de tiempo equivale a tres horas del tiempo real y que necesitamos un servidor que atienda 5000 solicitudes. Si tiene en cuenta la carga durante las unidades de tiempo de 16 a 22, existe una fluctuación enorme en la carga. A la derecha puede detectar un descenso en la demanda en torno a la unidad de tiempo 16 y empezar a reducir el número de recursos asignados. Como se pasa de aproximadamente 50 000 solicitudes a casi 0 solicitudes en el espacio de tres horas, puede ahorrar el costo de 10 instancias que habrían estado en el tiempo 16.
Ahora imagine que cada unidad de tiempo es igual a 20 minutos del tiempo real. En ese caso, al detener todos los recursos de la unidad de tiempo 16 solo para poner en marcha los nuevos recursos después de 20 minutos, se aumentará el costo en lugar de reducirlo, ya que AWS factura cada instancia de proceso por hora.
Además de las dos consideraciones anteriores, un proveedor de servicios también tendrá que evaluar las pérdidas en las que incurrirá al proporcionar una calidad de servicio degradada durante la unidad de tiempo 20, si tiene capacidad solo para 90 000 solicitudes en lugar de 100 000 solicitudes.
El escalado depende de las características del tráfico y de la carga subsiguiente que se genera en un servicio web. Si el tráfico sigue un patrón predecible (por ejemplo, basado en el comportamiento humano, como el streaming de películas desde un servicio web por la noche), el escalado puede ser predictivo para mantener la calidad del servicio. Aun así, en muchos casos, el tráfico no se puede predecir y los sistemas de escalado deben ser reactivos en función de diferentes criterios, como mostraron los ejemplos anteriores.
Escalado vertical (reducir y escalar verticalmente)
Existen ciertos tipos de cargas para los proveedores de servicios que son más predecibles que otros. Por ejemplo, si sabe, por patrones históricos, que el número de solicitudes siempre será entre 10 000 y 15 000, puede suponer que un servidor que puede atender 20 000 solicitudes es lo suficientemente bueno para los fines del proveedor de servicios. Estas cargas pueden aumentar en el futuro, pero siempre que aumenten de forma coherente, el servicio se puede migrar a una instancia mayor que pueda atender más solicitudes. Esto es adecuado para aplicaciones pequeñas que experimentan una cantidad de tráfico reducida.
El desafío del escalado vertical es que el cambio siempre tarda un tiempo, que podría considerarse tiempo de inactividad. Esto se debe a que, para poder trasladar todas las operaciones de la instancia más pequeña a una más grande, aunque el cambio solo tarde unos minutos, la calidad de servicio se degrada durante el intervalo.
Además, la mayoría de los proveedores de nube ofrecen recursos de proceso en una potencia de proceso creciente mediante la duplicación de la potencia de proceso de un recurso. Por lo tanto, la granularidad del escalado vertical no es tan buena como la del escalado horizontal. Por lo tanto, aunque la carga sea predecible e incremente de forma constante a medida que aumenta la popularidad del servicio, muchos proveedores de servicios optan por el escalado horizontal, en lugar de vertical.
Consideraciones para el escalado:
Supervisión
La supervisión es uno de los elementos fundamentales para el escalado eficaz de los recursos, ya que permite tener métricas que se pueden usar para interpretar qué partes del sistema deben escalarse y cuándo es necesario hacerlo. Gracias a la supervisión, se puede efectuar un análisis de los patrones de tráfico o del uso de recursos para valorar de manera fundamentada cuándo y cuánto se deben escalar los recursos a fin de maximizar la calidad del servicio junto con los beneficios.
Para desencadenar el escalado de los recursos, se supervisan diversos aspectos. La métrica más común es el uso de recursos. Por ejemplo, un servicio de supervisión puede realizar un seguimiento del uso de CPU de cada nodo de recursos y escalar los recursos si el uso es excesivo o demasiado bajo. Si, por ejemplo, el uso de cada recurso es superior al 95 %, probablemente sea recomendable agregar más recursos, ya que el sistema está sobrecargado. Normalmente, para decidir cuáles son estos factores desencadenantes, los proveedores de servicios analizan el punto de interrupción de los nodos de recursos, determinan el momento en que empezarán a producirse errores y asignan su comportamiento en varios niveles de carga. Aunque por motivos de coste es importante maximizar el uso de todos los recursos, es aconsejable dejar un margen para que el sistema operativo permita actividades de sobrecarga. Del mismo modo, si el uso está notablemente por debajo de, por ejemplo, un 50 %, es posible que no se requieran todos los nodos de recursos y que algunos puedan desaprovisionarse.
En la práctica, los proveedores de servicios normalmente suelen supervisar una combinación de varias métricas diferentes de un nodo de recursos para evaluar cuándo se deben escalar los recursos. Algunos de estas incluyen el uso de CPU, los consumos de memoria, el rendimiento y la latencia. Azure proporciona Azure Monitor como servicio adicional que puede supervisar cualquier recurso de Azure y proporcionar dichas métricas.
No disponibilidad de estados
Un diseño de servicio sin estado se presta a una arquitectura escalable. Un servicio sin estado significa básicamente que la solicitud de cliente contiene toda la información necesaria para atender una solicitud del servidor. El servidor no almacena ninguna información relacionada con el cliente en la instancia, pero guarda toda la información relacionada con la sesión en la instancia del servidor.
El hecho de tener un servicio sin estado ayuda a cambiar los recursos a voluntad, sin necesidad de ninguna configuración para mantener el contexto (estado) de la conexión de cliente para las solicitudes posteriores. Si se trata de un servicio con estado, el escalado de recursos requiere una estrategia para transferir el contexto de la configuración del nodo existente a la nueva. Tenga en cuenta que existen técnicas para implementar servicios con estado; por ejemplo, mantener una caché de red con Memcached para que el contexto se pueda compartir entre los servidores.
Decida lo que quiere escalar
En función de la naturaleza del servicio, es necesario escalar los distintos recursos según el requisito. En el nivel de servidor, a medida que aumentan las cargas de trabajo, en función del tipo de aplicación, puede aumentar la contención de recursos para la CPU, la memoria, el ancho de banda de red o todo lo anterior. La supervisión del tráfico permite identificar qué recurso se está restringiendo y escalar adecuadamente ese recurso específico. Los proveedores de servicios en la nube no proporcionan necesariamente granularidad de escalabilidad para escalar solo el proceso o la memoria, sino que proporcionan diferentes tipos de instancias de proceso que se ocupan específicamente de cargas que hacen un uso intensivo de los procesos o de gran cantidad de memoria. Por lo tanto, por ejemplo, para una aplicación que tiene cargas de trabajo que usan mucha memoria, sería más recomendable escalar verticalmente los recursos a las instancias optimizadas para memoria. En el caso de las aplicaciones que necesitan atender un gran número de solicitudes que no necesariamente hacen un uso intensivo de los procesos o de gran cantidad de memoria, el escalado horizontal de varias instancias de proceso estándar puede ser una estrategia mejor.
El aumento de los recursos de hardware puede no ser siempre la mejor solución para aumentar el rendimiento de un servicio. Si se aumenta la eficacia de los algoritmos que emplean en el servicio, también se puede ayudar a reducir la contención de recursos y mejorar el uso, lo que elimina la necesidad de escalar los recursos físicos.
Escalado de la capa de datos
En las aplicaciones orientadas a datos, donde hay un elevado número de lecturas y de escrituras (o de ambas) en una base de datos o sistema de almacenamiento, el tiempo de ida y vuelta de cada solicitud suele estar limitado por los tiempos de lectura y escritura de E/S del disco duro. Las instancias más grandes permiten un mejor rendimiento de E/S para las lecturas y escrituras, lo que puede mejorar los tiempos de búsqueda en el disco duro, lo cual, a su vez, puede tener como resultado una considerable mejora en la latencia del servicio. Si tiene varias instancias de datos en el nivel de datos se puede mejorar la confiabilidad y la disponibilidad de la aplicación proporcionando redundancias de conmutación por error. La replicación de datos en varias instancias tiene ventajas adicionales en la reducción de la latencia de red si quien sirve al cliente es un centro de datos físicamente más cercano a él. El particionamiento (o creación de particiones de los datos en varios recursos) es otra estrategia de escalado de datos horizontal, según la cual, en lugar de simplemente replicar los datos entre varias instancias, los datos se dividen en varios segmentos y se almacenan en varios servidores de datos.
Otro desafío a la hora de escalar la capa de datos consiste en mantener la coherencia (una operación de lectura es igual en todas las réplicas), la disponibilidad (las lecturas y las escrituras se producen siempre correctamente) y la tolerancia a particiones (las propiedades garantizadas del sistema se mantienen cuando los errores impiden la comunicación entre los nodos). Esto suele conocerse como teorema CAP, según el cual, en un sistema de base de datos distribuida, es muy difícil obtener las tres propiedades al completo y, por tanto, el sistema puede presentar como mucho una combinación de dos de ellas. Obtendrá más información sobre las estrategias de escalado de bases de datos y el teorema CAP en módulos posteriores.