Resumen: Basado en la exploración y práctica de FinOps de FunctionGraph en el campo sin servidor, este documento propone el primer modelo de estimación de costo total de función sin servidor de la industria.
历川：华为云Serverless研发专家
平山：华为云中间件Serverless负责人
冯嘉：华为云中间件首席专家Conclusiones clave:
1) Aunque el rápido desarrollo de serverless ha atraído una atención amplia y profunda, la estimación previa del costo total de las funciones serverless aún carece de una guía teórica efectiva. Basado en la exploración y práctica de FinOps de FunctionGraph en el campo sin servidor, este documento propone el primer modelo de estimación de costo total de función sin servidor de la industria;
2) Con base en el análisis de los factores clave del modelo de costos, se proponen cinco métodos de optimización para el costo operativo de las funciones; al mismo tiempo, para ayudar mejor a los usuarios a reducir costos y aumentar la eficiencia, HUAWEI CLOUD propone un método transparente, eficiente, "función de usuario" de un solo clic por primera vez. Cost Research Center".
Introducción al problema
El modelo de pago por uso con precisión de milisegundos de Serverless elimina la necesidad de que los usuarios paguen por el tiempo de inactividad de los recursos. Sin embargo, para una función de aplicación dada, debido a que los factores que afectan su costo de facturación no son únicos, se vuelve una tarea difícil para los usuarios estimar con precisión la facturación total durante el período de ejecución de la función .
Tomando como ejemplo el modelo de arrendamiento cíclico de los recursos tradicionales de la nube, al multiplicar el número del ciclo por el precio unitario del ciclo, los usuarios pueden estimar fácilmente el costo total del período de arrendamiento y formar una expectativa psicológica clara , incluso si la plataforma en la nube adopta niveles. fijación de precios o discriminación de precios En el caso de una estrategia, no es difícil calcular el costo total de arrendamiento.
Sin embargo, en escenarios sin servidor, todavía no existe una guía teórica efectiva para estimar el costo total de las funciones por adelantado. Por un lado, los factores clave que afectan la facturación de la función no son únicos , como las especificaciones de la memoria de la función, la concurrencia de una sola instancia, el tiempo de ejecución de la función, etc.; "Pay-As-You-Go" tiene mayor incertidumbre.
Por supuesto, la guía teórica para encontrar la facturación de funciones es principalmente proporcionar una base efectiva para que los usuarios evalúen el costo total de las funciones, pero lo que es más importante, cómo seguir utilizando el modelo de estimación para ayudar a los usuarios a optimizar las funciones de la aplicación y sus opciones de configuración , de ese modo. reduciendo significativamente el costo total de las funciones del usuario El costo es una pregunta urgente para FinOps en el campo sin servidor.
FinOps se enfoca en la gestión de recursos de la nube y la optimización de costos, y optimiza los costos de los recursos de la nube para usuarios, empresas y organizaciones mediante la vinculación orgánica de tecnología, negocios y profesionales financieros, y mejora la relación de entrada-salida del negocio de la nube [1]. Basado en la exploración y práctica de FinOps de HUAWEI CLOUD FunctionGraph en el campo sin servidor, este documento analiza el modelo de facturación de funciones y los factores clave que influyen en el escenario sin servidor, y presenta un marco modelo para preestimar la facturación total durante la operación de la función; lo que es más importante , el modelo proporciona una base efectiva para ayudar a los usuarios a optimizar el costo total de la operación de funciones, mejorar el rendimiento de la administración de recursos sin servidor en la nube del usuario y lograr una economía sin servidor .
1. Glosario y conocimientos previos
Primero, se da una breve descripción de varios conceptos enumerados en la Tabla 1.
Tabla 1: Sustantivos comunes para funciones sin servidor
Especificación de memoria (Memory) : la especificación de memoria, también conocida como especificación de función y especificación de instancia de función, indica el tamaño del recurso asignado por la plataforma Serverless para una sola instancia de la función, generalmente expresado como el tamaño de la memoria que la función puede usar, que es especificado por el usuario; la CPU que la instancia puede usar Los recursos compartidos son proporcionales al tamaño de la memoria. Las plataformas en la nube sin servidor generalmente brindan una variedad de especificaciones para que los usuarios elijan.Tomando FunctionGraph como ejemplo, los usuarios pueden elegir entre 15 especificaciones de funciones, como se muestra en la Figura 1.
Figura 1: FunctionGraph proporciona varias especificaciones de memoria de funciones
Tiempo de ejecución de la función: se refiere al tiempo consumido por la ejecución de la función en sí misma en el proceso de completar una respuesta a la solicitud de llamada, que está determinado principalmente por la lógica del código de la función. En general, para las funciones que hacen un uso intensivo de la CPU, aumentar la especificación de recursos de la función (memoria-CPU compartida) puede reducir significativamente el retraso en la ejecución de la función. Sin embargo, para funciones que dedican la mayor parte de su tiempo a E/S de red y otras operaciones, aumentar la especificación de recursos tendrá una mejora muy limitada en la latencia de ejecución.
Máximo de solicitudes por instancia: la cantidad máxima de solicitudes que una sola instancia de la función puede procesar al mismo tiempo, principalmente adecuado para escenarios donde hay un tiempo significativo esperando el regreso de los servicios posteriores durante la ejecución de la función, como las operaciones de acceso a la base de datos. o E/S de disco, etc. Para la misma carga de tráfico, aumentar la simultaneidad de una sola instancia de una función puede reducir la cantidad de instancias por metro, ahorrar en las facturas de los usuarios y reducir la tasa de inicio en frío de las solicitudes de llamada de función.
Instancias máximas por función : se refiere al límite superior del número de instancias de la misma función que se ejecutan al mismo tiempo al mismo tiempo. Para los usuarios, el número máximo de instancias puede evitar que el costo se salga de control debido a la expansión excesiva de la plataforma en la nube durante picos de tráfico anormales o fallas de funciones; para las plataformas en la nube, el número máximo de instancias puede evitar que los recursos de la plataforma se utilicen parcialmente. utilizado en condiciones anormales consume luz, lo que garantiza el aislamiento del rendimiento entre las diferentes funciones.
2. Modelo de costes y facturación de funciones
Para el modelo de estimación de facturación de funciones desde la perspectiva de una sola instancia, consulte [2]. En un entorno de producción real, además de las funciones asincrónicas, las plataformas en la nube sin servidor suelen utilizar FCFS (First Come First Serve) para responder a las solicitudes de llamadas. Para las fluctuaciones de marea en el tráfico de funciones, la plataforma se adapta a través del escalado automático de instancias y se ejecuta en La variación del número de instancias concurrentes con el tiempo se puede caracterizar completamente mediante una función lineal constante por partes, como se muestra en la Figura 2.
Figura 2: El número de instancias simultáneas de la función cambia con el proceso de escalado
Aunque existen diferencias en los métodos de facturación entre los diferentes proveedores de nube sin servidor, la facturación de funciones generalmente incluye dos partes: la facturación de los recursos utilizados por la función y la facturación de la cantidad de solicitudes , de la siguiente manera:
La segunda mitad representa la cantidad total de facturación gratuita proporcionada por la plataforma en la nube, independientemente del tráfico de llamadas de funciones y la configuración de funciones.
3. Discusión sobre métodos de optimización de costos
Con el modelo de estimación del costo funcional, se pueden discutir los factores clave que afectan el costo del usuario. En la fórmula de estimación (1), ignorando la carga gratuita total proporcionada por la plataforma en la nube, la estructura del costo mensual total de la función es la siguiente:
Punto 1: Optimice la lógica del código de función para reducir el retraso en la ejecución de la función
Para la misma carga de tráfico de funciones, una menor latencia de ejecución puede ahorrar a los usuarios más costos de facturación. Bajo la premisa de la lógica comercial del usuario, es el requisito natural de la ingeniería de software optimizar continuamente el código de función y mejorar la eficiencia de ejecución de la función, pero en el escenario sin servidor, esto es aún más urgente.
Específicamente, considere el uso de lenguajes de programación livianos como Python y Nodejs para reducir elementos innecesarios en la configuración de inicialización de la función, y mueva la operación de conexión de otros servicios, como bases de datos, a la etapa de inicialización antes de la entrada de ejecución de la función tanto como sea posible para simplificar la lógica del código, etc.
Además, para ayudar a los usuarios a comprender el estado de ejecución de las funciones, FunctionGraph proporciona una visualización detallada y observabilidad de las funciones de la aplicación, y admite la configuración de indicadores de observación enriquecidos, incluida la cantidad de llamadas, la cantidad de errores y la ejecución. El tiempo de ejecución de la función se muestra en la Figura 3. Ejemplo de monitoreo.
Figura 3: Ejemplo de supervisión del tiempo de ejecución de la función FunctionGraph
Punto 2: paquete de código de función optimizado, paquete de dependencia, tamaño de imagen
Cuando una llamada de función desencadena un inicio en frío, desde la perspectiva de la facturación, la demora del inicio en frío se incluye en la demora de ejecución y se factura en conjunto, mientras que la plataforma en la nube consume una proporción considerable de la demora del inicio en frío de los servicios de almacenamiento de terceros. (como Descargar el paquete de código del usuario y el paquete de dependencia del Servicio de almacenamiento de objetos (OBS) de HUAWEI CLOUD, o extraer la imagen de la aplicación del usuario del servicio de repositorio de imágenes, como se muestra en la Figura 4. Aunque la mayoría de las plataformas en la nube utilizan actualmente varios mecanismos de almacenamiento en caché para almacenar previamente en caché el código de usuario y las imágenes a fin de optimizar el rendimiento del arranque en frío, el retraso en la carga del código de usuario durante el inicio de la instancia sigue siendo muy significativo . Por lo tanto, el tamaño del paquete de código de función debe optimizarse tanto como sea posible, incluida la reducción de paquetes e imágenes dependientes, para reducir el tiempo de facturación.
Figura 4: Tiempo de facturación y puntos de optimización bajo arranque en caliente y en frío
Punto 3: escribir funciones ligeras centradas en funciones
Bajo el marco de programación sin servidor, las funciones deben escribirse como un código de programa liviano y centrado en la función tanto como sea posible, es decir, "las funciones deben ser pequeñas y diseñadas específicamente" [3]; deje que " una función solo haga una cosa ", a Por un lado, el retraso de ejecución de una función con una sola función es más fácil de optimizar de manera específica; por otro lado, cuando se implementan varias funciones en una función al mismo tiempo, existe una alta probabilidad de que todas Al mismo tiempo, las funciones se verán comprometidas en el rendimiento. Como resultado, la facturación total por la duración de la ejecución de la función termina aumentando.
Figura 5: Ejemplo del flujo de la función FunctionGraph de HUAWEI CLOUD
Si la función de la aplicación realmente necesita proporcionar múltiples funciones, puede considerar descomponer la función grande en múltiples funciones pequeñas y luego implementar la lógica general a través de la disposición de funciones, como se muestra en la función de flujo de la función FunctionGraph que se muestra en la Figura 5. La descomposición de funciones grandes también es una de las mejores prácticas para que los usuarios manejen escenarios anormales, como los tiempos de espera en la computación sin servidor [4].
Punto 4: bajo la premisa del soporte del modelo de negocio, se adopta la concurrencia múltiple de instancia única
De la estructura de costos de la función de la fórmula (2) se puede observar que, bajo la premisa del modelo de negocio del usuario, configurar una cierta concurrencia de instancia única puede reducir efectivamente el costo mensual total de la función ; si el usuario no la configura , el valor predeterminado de la plataforma en la nube suele ser 1, es decir, una sola instancia solo puede procesar una solicitud al mismo tiempo; por lo tanto, cuando se llama a la función al mismo tiempo, la plataforma iniciará varias instancias para responder, aumentando así la número de instancias de facturación, como se muestra en la Figura 6; el uso de una sola instancia con múltiples simultaneidades también puede mejorar el retraso de cola de la solicitud de llamada en el estado de espera.
Figura 6: Simultaneidad de instancia única: perspectiva de horas de facturación y perspectiva de recuento de instancias
Por supuesto, cuanto mayor sea la concurrencia de una sola instancia, mejor Por ejemplo, una configuración de concurrencia excesivamente alta intensificará la competencia de recursos entre múltiples subprocesos en una instancia de función (por ejemplo, contención de CPU), lo que conducirá al deterioro de la respuesta de la función rendimiento y afectar el rendimiento de la aplicación del usuario Indicadores de QoS, etc. Al mismo tiempo, como se menciona en el conocimiento previo de este artículo, no todas las funciones de la aplicación son adecuadas para configurar la concurrencia múltiple de instancia única. La concurrencia múltiple de instancia única es principalmente adecuada para escenarios donde una proporción considerable de la demora se consume en el proceso de ejecución de la función esperando el regreso de los servicios posteriores. en espera, como acceder a bases de datos y colas de mensajes, y otro middleware, o E/S de disco, E/S de red, etc. La concurrencia múltiple de instancia única también requiere que los usuarios adapten la captura de errores (p. ej., considere la granularidad de captura de errores a nivel de solicitud) y la seguridad de subprocesos (p. ej., protección de bloqueo) de variables compartidas globales en el código de función.
Punto 5: La selección de las especificaciones de los recursos de la función debe considerar el impacto en el retraso de la ejecución
Finalmente, se discute la elección de la especificación de recursos de funciones. Se puede ver claramente en la fórmula (2) que una mayor especificación de memoria de instancia corresponde a un mayor costo de facturación. Sin embargo, la elección de la especificación de memoria debe considerar el impacto en el retraso de ejecución de la función al mismo tiempo. Desde la perspectiva de las funciones del usuario, el retraso en la ejecución de la función no solo está determinado por la lógica comercial del código en sí, sino que también se ve afectado por el tamaño de los recursos disponibles cuando se ejecuta la instancia. Los tamaños de instancia más grandes corresponden a una memoria utilizable más grande y más recursos compartidos de CPU, lo que puede mejorar significativamente el rendimiento de ejecución de funciones con uso intensivo de memoria o CPU y reducir la latencia de ejecución; por supuesto, hay un límite superior para esta mejora , después de un cierto se excede la especificación de recursos, el efecto del aumento de recursos en la reducción del retraso de ejecución de la función es casi insignificante, como se muestra en la línea discontinua en la Figura 7. Los hechos anteriores muestran que, para una determinada función de usuario, con el fin de reducir el costo total de facturación, es necesario configurar un tamaño de instancia razonable para lograr el valor mínimo tanto como sea posible, como lo muestra la línea continua en la Figura 7.
Figura 7: La elección de la especificación de la función debe considerar el impacto tanto en el costo como en la latencia de ejecución
Figura 8: Análisis de factores clave del costo de facturación de funciones
4. Centro de investigación de costos de funciones sin servidor
Reducir costos y aumentar la eficiencia para los usuarios es el concepto central de FunctionGraph. Si bien los cinco métodos de optimización de costos de funciones analizados anteriormente se analizan desde la perspectiva de los usuarios, creemos que estos problemas están lejos del alcance que los usuarios deben considerar; por el contrario, FunctionGraph continúa explorando cómo ayudar a los usuarios en la mayor medida posible. el campo sin servidor. Para lograr el mejor efecto FinOps, los usuarios pueden realmente disfrutar de los beneficios de Economical Serverless ; por ejemplo, bajo la premisa de visualización profunda y observabilidad a nivel de instancia, ayuda a los usuarios a automatizar todo el proceso de FinOps funcional , y proporciona a los usuarios servicios de gestión de recursos y optimización de costos transparentes, eficientes y con función de un solo clic.
Figura 9. Percepción del consumo de recursos en línea y recomendación de especificación dinámica
Con este fin, en base a la práctica interna, FunctionGraph lanzará el " Centro de investigación de costos de función de usuario - Centro de optimización y análisis de costos" en un futuro cercano, que brinda a los usuarios ajuste de energía fuera de línea, percepción y optimización del consumo de recursos en línea. incluida la recomendación de recursos en línea (recomendación de recursos en línea, como se muestra en la Figura 9), la vista previa de escalado automático predictivo, etc., minimizan el umbral técnico para que los usuarios implementen las funciones de FinOps. El desarrollo empresarial del usuario, la transformación sin servidor, etc., brindan una comodidad extrema.
V. Resumen y perspectivas
Este documento analiza principalmente el problema FinOps en el escenario de la computación sin servidor, brinda el primer modelo de estimación del costo total de la función de usuario de la industria y, basado en este modelo, proporciona referencia teórica y práctica para que los usuarios optimicen las funciones de la aplicación, mejoren la eficiencia de la administración de recursos sin servidor y reduzcan costos totales de acuerdo con.
Con el surgimiento de un campo de tecnología emergente, la primera pregunta que debe responderse es "¿Por qué y valor? Como el servicio de computación y orquestación de funciones sin servidor de próxima generación respaldado por Huawei Yuanrong, FunctionGraph, combinado con FinOps y otros conceptos técnicos, continúa brindando a los usuarios servicios económicos sin servidor. En el seguimiento, compartiremos más teorías de vanguardia y prácticas de casos en torno a un escenario completo de propósito general sin servidor, y retribuiremos a la comunidad, incluida la experiencia práctica de FunctionGraph en microservicios sin servidor.
Referencias:
[1] Qué es FinOps: https://www.finops.org/introduction/what-is-finops/
[2] Ejecución de funciones Lambda de forma más rápida y económica: https://levelup.gitconnected.com/running-lambda-functions-faster-and-cheaper-416260fbc375?gi=4370e4c57684
[3] Estrategias de optimización de costos de AWS Lambda que funcionan. https://dashbird.io/blog/aws-lambda-cost-optimization-strategies/
[4] Mejores prácticas de tiempo de espera. https://lumigo.io/learn/aws-lambda-timeout-best-practices/
Haga clic en Seguir para conocer las nuevas tecnologías de HUAWEI CLOUD por primera vez~