¿Por qué la tecnología sin servidor puede mejorar la utilización de los recursos?

Autor: Mu Wu Alibaba Experto técnico sénior inteligente en la nube

La carga comercial a menudo no es constante, sino que fluctúa hacia arriba y hacia abajo con el tiempo. La forma tradicional de crear aplicaciones suele ser preparar suficientes recursos para garantizar la disponibilidad comercial, lo que da como resultado una baja utilización de recursos. Con la popularización de la tecnología de contenedores, las aplicaciones pueden mejorar la utilización de los recursos a través del escalado elástico o la hibridación de aplicaciones. Sin embargo, debido a la complejidad de la gestión de recursos, es difícil lograr un buen equilibrio entre la disponibilidad comercial y la utilización de los recursos.

La aparición de plataformas sin servidor traslada la responsabilidad de la gestión de recursos del lado del usuario al lado de la plataforma. Esta transferencia de responsabilidad permite a los usuarios centrarse en el desarrollo empresarial, mientras que la propia plataforma aprovecha su escala de recursos y la diversidad de carga para centrarse en mejorar la utilización de los recursos. El uso de la plataforma sin servidor para empresas puede mejorar en gran medida la utilización de recursos y lograr el efecto de reducción de costos y mejora de la eficiencia.

La cuestión de la utilización

La carga del negocio cambia dinámicamente y la elasticidad de los recursos a menudo no puede mantenerse al día con los cambios de carga, por lo que la utilización de recursos no es alta. Para simplificar la complejidad de la implementación y la operación y el mantenimiento, las aplicaciones generales suelen especificar un número fijo de instancias al implementar. En este momento, los cambios en los recursos y las cargas se muestran en la siguiente figura:

imagen

Se puede ver que se desperdicia mucho tiempo en los recursos, que es menos del 30% según la tasa de utilización de recursos promedio diaria. La tasa de utilización de recursos está directamente relacionada con el costo.Si la tasa de utilización de recursos se duplica, el costo puede reducirse en un 50%. La situación más ideal es que el recurso se ajuste perfectamente a la carga, como se muestra en la siguiente figura:

Pero la realidad es que es muy difícil de hacer, por dos motivos:

Los cambios de carga pueden ser rápidos, pero la creación de recursos lleva más tiempo
La tasa de éxito elástica de los recursos no es del 100 %, y los búferes de recursos deben reservarse por consideraciones de estabilidad

Por lo tanto, el estado real de los recursos se encuentra entre las dos situaciones anteriores, y los desarrolladores de negocios pueden usar algunos medios para mejorar la utilización de los recursos para acercarse al 100 %. A continuación, echemos un vistazo a algunos métodos comúnmente utilizados para mejorar la utilización de recursos.

Mejora de la utilización: escalado elástico

Las aplicaciones en contenedores suelen utilizar el escalado automático para mejorar la utilización de los recursos. La más típica es usar la estrategia K8s HPA [ 1] , establecer un umbral de utilización de la CPU, aumentar automáticamente el contenedor cuando la utilización de la CPU del contenedor supera el umbral y reducir automáticamente el contenedor cuando está por debajo del umbral. Después de usar HPA, la carga del servicio y los cambios en los recursos son los siguientes:

Se puede ver que antes de que se complete la creación de nuevos recursos, se debe reservar algún margen para los recursos existentes para amortiguar el aumento de la carga. ¿Cuál es la tasa de utilización en el caso del cambio de recurso en forma de escalón anterior? Analicémoslo cuantitativamente.

imagen

Se puede observar que los recursos que se deben reservar están relacionados con el aumento de carga y el tiempo de expansión. Suponga que dentro del tiempo de expansión T, la carga aumenta de A a B y los recursos reales requeridos se expanden de xA a xB. Para poder capturar la carga antes de que se creen los recursos, cuando la carga es A, la cantidad de recursos necesarios es xB, y la utilización de recursos es una función de la pendiente de crecimiento de la carga y el tiempo de expansión. Cuando se determina la relación de crecimiento de carga K, la tasa de utilización de recursos Util es una función inversa del tiempo de expansión T, y cuanto más corto sea el tiempo de expansión, mayor será la tasa de utilización de recursos.

Por ejemplo, cuando la carga aumenta en un 100 % por minuto, la relación entre la utilización de recursos y el tiempo de expansión.

Cuando el tiempo de expansión es de 1 minuto, la tasa de utilización de recursos es del 50%
Cuando el tiempo de expansión es de 5 minutos, la tasa de utilización de recursos es del 17%

El tiempo de expansión es la clave para mejorar la utilización de los recursos. Desde el comienzo del aumento de la carga hasta la finalización de la creación de nuevos contenedores, el tiempo total de expansión se puede descomponer en la siguiente figura:

imagen

Tiempo de reacción

1. Tiempo de recopilación de indicadores: por ejemplo, la recopilación de indicadores de CPU debe tomar la utilización promedio de CPU durante un período de tiempo
2. Tiempo de toma de decisiones: por ejemplo, la recopilación de indicadores de CPU debe ser mayor que el umbral N veces seguidas antes de activar la expansión

Hora de inicio

1. Arranque en frío del sistema: tiempo para que el sistema prepare el entorno de la máquina y el contenedor
2. Inicio en frío de la aplicación: el tiempo de inicialización de la aplicación después de que se inicia el contenedor, como el inicio de JVM, la inicialización del middleware, la carga de datos, etc.

¿Cómo acortar el tiempo de expansión? A continuación se compara la optimización de K8s y Function Compute FC [ 2] en cada etapa:

tiempo	k8s	Función Calcular FC
Tiempo de recolección del indicador	15s	0 la concurrencia se calcula en tiempo real de acuerdo con la solicitud
tiempo de decisión	La ventana de estabilización predeterminada de 0K8s [ 3] es 0	0 la concurrencia se calcula en tiempo real de acuerdo con la solicitud
Arranque en frío del sistema	Duplicación: control de ~30 s + programación + inicio del contenedor	Paquete de código: espejo de 200 ms: agrupación de contenedores de 3 s, paquete de código/aceleración de espejo
Aplicación de arranque en frío	10ms ~ 10min	10ms ~ 10min

La función Compute FC reduce el tiempo de respuesta a cero a través de la programación de nivel de solicitud y optimiza el tiempo de inicio en frío a un mínimo de 200 ms a través del paquete de código y la aceleración de imágenes. Con la condición de que el tiempo de inicio en frío de la aplicación sea el mismo, el tiempo de expansión de Function Compute FC es 1 minuto más rápido que el de K8s. Si el inicio en frío de la aplicación es más rápido (10 s), la utilización de recursos de Function Compute FC será significativamente mejor que la de K8s; si el inicio en frío de la aplicación es lento (1 min), la brecha entre la utilización de K8s y La función Calcular FC se reducirá. Como se muestra abajo:

La optimización del tiempo de inicio en frío de la aplicación puede mejorar en gran medida la utilización de recursos en los escenarios de Function Compute FC. Sin embargo, debido a que el inicio en frío de la aplicación está relacionado con la lógica de la aplicación específica, es difícil realizar una optimización general. Algunas posibles direcciones de optimización son:

Transformación de aplicaciones : transforme las aplicaciones de Java en funciones livianas como Nodejs/Python y transforme las imágenes espejo en paquetes de código, pero los costos de transformación son relativamente altos.
Instantánea de la función : cree una imagen reflejada de una instancia de función inicializada y extraiga rápidamente una nueva instancia a través de la imagen reflejada. Sin embargo, la duplicación rompe la unicidad de las instancias. Por ejemplo, los UUID generados por algunas inicializaciones de aplicaciones pueden entrar en conflicto en instancias extraídas del mismo espejo.
Aceleración de carga de datos : algunas aplicaciones necesitan cargar una gran cantidad de datos desde OSS durante la inicialización, y el sistema puede acelerar la carga de datos a través de Cache/P2P y otros métodos

Resumir algunos de los problemas existentes en HPA:

Problema de velocidad elástica: la velocidad elástica lenta da como resultado una gran retención de búfer y una baja utilización
El problema de la velocidad de contracción: la velocidad de contracción es lenta y hay una ventana de observación
El umbral de la CPU es difícil de establecer: dependiendo de la experiencia comercial, a menudo es demasiado bajo

Mejora de la tasa de utilización: las piezas mixtas están sobrevendidas

Otra forma de que las aplicaciones en contenedores mejoren la utilización de los recursos es a través de la localización y la sobreventa. Hay dos modos de uso de los clústeres de contenedores:

Modo K8s clásico : hay un grupo de nodos, los pods se crean en los nodos y se debe prestar atención a la utilización de contenedores y la asignación de recursos de nodos
Modo K8s sin servidor : sin grupo de nodos, el contenedor sin servidor transporta el pod, solo es necesario prestar atención a la utilización de recursos del contenedor

imagen

En el modo clásico de K8s, el escalado elástico de los contenedores no mejora la utilización de los recursos, incluso si se elimina el contenedor, el nodo sigue ahí. El escalado elástico de los nodos no es tan flexible como los contenedores. En este caso, la mezcla y la sobreventa son prácticas comunes para mejorar la utilización de los recursos.

En K8s, resource.request [ 4] < resource.limit se usa para lograr la sobreventa: K8s asigna contenedores de acuerdo con resource.request durante la programación, pero limita el uso de recursos de los contenedores de acuerdo con resource.limit.

imagen

Se puede ver que la suma de los recursos máximos utilizados por los contenedores en un nodo excederá el límite de recursos del nodo. La suposición de que esto se puede hacer es que el uso de recursos de cada contenedor no alcanzará el límite de recursos al mismo tiempo, de lo contrario, se producirá una competencia de recursos, lo que provocará una degradación del rendimiento o incluso OOM. Pero tal suposición no siempre es cierta, el uso de recursos de cada contenedor cambia dinámicamente, por lo que existe una cierta probabilidad de que ocurra una competencia por los recursos. No es fácil lograr buenos resultados en la sobreventa de piezas mixtas. Los factores que afectan el efecto de las piezas mixtas incluyen el tamaño del conjunto de recursos, la diversidad de carga, la estabilidad del rendimiento y la estrategia de migración de sobrecarga.

El primero es el tamaño del grupo de recursos: cuanto mayor sea el grupo de recursos, menor será la probabilidad de competencia por los recursos. Cuantifiquemos la probabilidad de competencia: supongamos que hay 4 aplicaciones, cada una con un 50 % de probabilidad de uso de recursos de 1 y un 50 % de probabilidad de 2. Comparemos la probabilidad de contención entre colocarlos en un grupo de recursos grande y dos grupos de recursos pequeños:

Se puede ver que la probabilidad de grandes conjuntos de recursos es significativamente menor que la de pequeños conjuntos de recursos. De manera más intuitiva, cuando A y C son 2 al mismo tiempo, la competencia inevitablemente ocurrirá en el modo de grupo de recursos pequeños, pero la competencia no necesariamente ocurrirá en el modo de grupo de recursos grande. Para aplicaciones comerciales específicas, debido a que la escala de carga no es grande, el grupo de recursos es relativamente pequeño y la probabilidad de competencia entre departamentos mixtos es relativamente alta.

El segundo es la diversidad de cargas.Cuanto más diversas y complementarias sean las cargas, mejor será el efecto del despliegue híbrido y mayor será la tasa de utilización de los recursos. Esta diversidad no solo incluye la diversidad de requisitos de recursos, por ejemplo, algunas cargas hacen un uso intensivo de la CPU y otras son de tipo IO; también incluye la diversidad de fluctuaciones de tiempo, por ejemplo, algunas cargas son picos matutinos y otras vespertinos.

Para aplicaciones comerciales específicas, la diversidad de carga no es suficiente y es difícil mejorar aún más la utilización de recursos.

El último es la migración de sobrecarga: cuando la carga en un nodo es demasiado alta, algunos contenedores deben migrarse a otros nodos. Este proceso de migración debe ser fluido sin afectar el negocio. En K8s, el programador no está al tanto del tráfico de solicitud de la aplicación. Por lo tanto, al sobrecargar la migración, la capa de la aplicación debe cooperar con la migración a través de mecanismos como controles de estado y fuera de línea y fuera de línea. Si no se migra a tiempo, la solicitud fallará y la calidad del servicio se verá afectada.

Resume algunos de los problemas en el departamento mixto:

El grupo de recursos no es lo suficientemente grande: la probabilidad de competencia por los recursos es alta
Diversidad de carga insuficiente: alta probabilidad de competencia de recursos y baja utilización
Migración de sobrecarga irregular: migración de tráfico irregular cuando los nodos están sobrecargados

Mejora de la utilización: sin servidor

El escalado automático y la sobreventa híbrida son formas efectivas de mejorar la utilización de los recursos, pero debido a sus atributos de complejidad inherente, los desarrolladores de negocios a menudo necesitan invertir más energía para lograr mejores resultados, y estos trabajos relacionados con la infraestructura, a menudo no son la competitividad central de los desarrolladores de negocios. . La razón por la que los desarrolladores de negocios necesitan encontrar formas de mejorar la utilización de los recursos es que el problema más fundamental es que las máquinas pertenecen a los desarrolladores de negocios. ¿Pueden los desarrolladores de negocios liberarse de la operación y el mantenimiento de las máquinas? Serverless proporciona una forma de producto que transfiere la responsabilidad de la gestión de recursos del lado del usuario al lado de la plataforma. De esta forma, los desarrolladores de servicios solo necesitan pagar por las solicitudes de servicio, en lugar de prestar atención a la utilización de recursos y centrarse en la innovación de servicios.

imagen

Sin servidor no significa que no haya servidor, sino que la gestión, la operación y el mantenimiento, y la mejora de la utilización del servidor se concentran en el lado de la plataforma, y las ventajas de la plataforma en la escala de recursos y la diversidad de carga se utilizan para mejorar el recurso. utilización de la máquina. La siguiente figura muestra la arquitectura interna del sistema Serverless. La utilización de recursos del clúster se mejora a través de la gestión del tráfico del lado del sistema, el escalado elástico y la sobreventa híbrida:

A través de una optimización vertical profunda, se mejora la velocidad de arranque en frío para lograr un rebote rápido
Al absorber diferentes cargas comerciales, expandir la escala de los grupos de recursos, aumentar la diversidad de cargas y mejorar la eficiencia de los departamentos mixtos

imagen

Desde el lado del usuario, use las capacidades proporcionadas por la plataforma sin servidor para mejorar la utilización de recursos en el lado comercial:

a. Programación de solicitudes [ 5] : la facturación se basa en el tiempo de solicitud, el tiempo de inactividad no se factura y la tasa de utilización del tiempo de la instancia es del 100 %.

b. Facturación inactiva [ 6] : en respuesta a la empresa con un inicio lento en frío de la aplicación, se proporciona facturación inactiva de instancias reservadas. Cuando no hay una solicitud de instancia, el costo se reduce a 1/10

c. Simultaneidad dinámica: para el problema de que el umbral de la CPU se establece demasiado bajo, el sistema determina dinámicamente la mejor simultaneidad de acuerdo con el tráfico real y busca el punto de inflexión del rendimiento.

imagen

en conclusión

Debido al cambio dinámico de la carga, la evaluación de la capacidad de los recursos y la mejora de la tasa de utilización son problemas que afectan a los desarrolladores de negocios. El método de mejorar la utilización de recursos a través del escalado elástico y la sobreventa híbrida no es ideal debido a su complejidad inherente. La plataforma sin servidor transfiere la responsabilidad de la gestión de recursos del lado del usuario al lado de la plataforma, lo que permite a los desarrolladores comerciales centrarse en el desarrollo empresarial, mientras que la plataforma en sí aprovecha su escala de recursos y la diversidad de carga para centrarse en mejorar la utilización de los recursos para lograr una ganancia común. .

Para los desarrolladores de negocios, de acuerdo a las características de la aplicación, se pueden tomar las siguientes rutas de selección:

Para las aplicaciones que se inician rápidamente, use el modo de pago por uso directamente para lograr una utilización del 100 %
Para las aplicaciones que se inician lentamente, puede optar por optimizar la velocidad de inicio o puede optar por utilizar el modo reservado + facturación inactiva para mejorar la utilización
Puede comenzar a usar aplicaciones sin servidor de inmediato: tareas programadas, web-hooks

imagen

experiencia de recompensa

Alibaba Cloud proporcionará recursos de productos Function Compute FC gratuitos y lo invitará a experimentar [Tongyi Qianwen] Implementación con un solo clic de la experiencia previa de Tongyi Qianwen. Este experimento se basa en Function Compute, lo que le permite implementar su propio robot de chat en Alibaba Cloud con un clic ¡Ven y construye tu propio asistente de IA!

Configuración de doble premio:

Complete la activación de funciones informáticas y la implementación de aplicaciones, y gane 400 puntos de la comunidad de desarrolladores;

¡Participa en el concurso de imágenes generadas por IA para ganar AirPods (tercera generación), altavoces Bluetooth personalizados de Alibaba Cloud y Qingya Cup personalizados de Alibaba Cloud!

Enlaces relacionados:

[1] estrategia HPA

https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

[2] Función Calcular FC

https://www.aliyun.com/product/fc

[3] Ventana de estabilización

https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#default-behavior

[4] recurso.solicitud

https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

[5] Programación de solicitudes

https://help.aliyun.com/document_detail/179379.htm?spm=a2c4g.54301.0.0.474b5feezaRWiK#p-kwb-hz6-6e3

[6] Facturación inactiva