Compartir vía

Hospedaje del plan Flex Consumption de Azure Functions

  • Artículo

Flex Consumption es un plan de hospedaje de Azure Functions basado en Linux que se basa en el modelo de consumo de facturación sin servidor paga por lo que usa. Ofrece más flexibilidad y personalización mediante la introducción de redes privadas, selección de tamaño de memoria de instancia y características de escalado horizontal rápido y grande, basadas en un modelo sin servidor.

Importante

El Plan Flex Consumption está actualmente en versión preliminar. Para obtener una lista de las limitaciones actuales al usar este plan de hospedaje, consulte Consideraciones. Para obtener información actual sobre la facturación durante la versión preliminar, consulte Facturación.

Puede revisar los ejemplos de un extremo a otro que incluyen el plan Flex Consumption en el repositorio de ejemplos del plan Flex Consumption.

Ventajas

El plan Flex Consumption se basa en los puntos fuertes del plan de consumo, que incluyen el escalado dinámico y la facturación basada en la ejecución. Con Flex Consumption, también obtendrá estas características adicionales:

Esta tabla le ayuda a comparar directamente las características de Flex Consumption con el plan de hospedaje de consumo:

Característica Consumo Flex Consumption
Ajustar a cero ✅ Sí ✅ Sí
Comportamiento de escalado Controlado por eventos Controlado por eventos (rápido)
Redes virtuales ❌ No se admite ✅ Compatible
Proceso dedicado (mitiga los arranques en frío) ❌ Ninguno ✅ Instancias siempre preparadas (opcional)
Facturación Solo tiempo de ejecución Tiempo de ejecución + instancias siempre preparadas
Instancias de escalabilidad horizontal (máx.) 200 1000

Para obtener una comparación completa del plan de consumo flexible con respecto al plan de consumo y todos los demás tipos de plan y hospedaje, consulte opciones de escalado y hospedaje de funciones.

Integración de la red virtual

Flex Consumption amplía las ventajas tradicionales del plan de consumo agregando compatibilidad con integración de red virtual. Cuando las aplicaciones se ejecutan en un plan de consumo flexible, pueden conectarse a otros servicios de Azure protegidos dentro de una red virtual. Al mismo tiempo que le permite aprovechar las ventajas de la facturación y la escala sin servidor, junto con las ventajas de escala y rendimiento del plan de consumo flexible. Para obtener más información, consulte Habilitación de la integración de red virtual.

Memoria de instancia

Al crear la aplicación de funciones en un plan de consumo flexible, puede seleccionar el tamaño de memoria de las instancias en las que se ejecuta la aplicación. Consulte Facturación para obtener información sobre cómo los tamaños de memoria de instancia afectan a los costos de la aplicación de funciones.

Actualmente, Flex Consumption ofrece opciones de tamaño de memoria de instancia de 2 048 MB y 4 096 MB.

Al decidir qué tamaño de memoria de instancia se va a usar con las aplicaciones, estas son algunas cosas que se deben tener en cuenta:

  • El tamaño de memoria de la instancia de 2048 MB es el valor predeterminado y debe usarse para la mayoría de los escenarios. Usa el tamaño de memoria de instancia de 4 096 MB para escenarios en los que la aplicación requiere más simultaneidad o mayor potencia de procesamiento. Para obtener más información, consulte Configuración de la memoria de instancia.
  • Puede cambiar el tamaño de memoria de la instancia en cualquier momento. Para obtener más información, consulte Configuración de la memoria de instancia.
  • Los recursos de instancia se comparten entre el código de función y el host de Functions.
  • Cuanto mayor sea el tamaño de la memoria de instancia, más podrá controlar cada instancia en cuanto a ejecuciones simultáneas o cargas de trabajo más intensivas de CPU o memoria. Las decisiones de escalado específicas son específicas de la carga de trabajo.
  • La simultaneidad predeterminada de los desencadenadores HTTP depende del tamaño de memoria de la instancia. Para obtener más información, consulte Simultaneidad del desencadenador HTTP.
  • Las CPU disponibles y el ancho de banda de red se proporcionan proporcionales a un tamaño de instancia específico.

Escalado por función

La simultaneidad es un factor clave que determina cómo se escalan las aplicaciones de función Flex Consumption. Para mejorar el rendimiento de escala de las aplicaciones con varios tipos de desencadenadores, el plan de consumo flexible proporciona una forma más determinista de escalar la aplicación por función.

Este comportamiento de escalado por función forma parte de la plataforma de hospedaje, por lo que no es necesario configurar la aplicación ni cambiar el código. Para obtener más información, consulte Escalado por función en el artículo Escalado controlado por eventos.

En el escalado por función, se toman decisiones para determinados desencadenadores de función basándose en agregaciones de grupo. En esta tabla se muestra el conjunto definido de grupos de escalado de funciones:

Grupos de escalado Desencadenadores en el grupo Valor de configuración
Desencadenadores HTTP desencadenador HTTP
Desencadenador de SignalR		 http
Desencadenadores de Blob Storage
(Basado en Event Grid)		 Desencadenador de Blob Storage blob
Durable Functions Desencadenador de orquestación
Desencadenador de actividad
Desencadenador de entidad		 durable

Todas las demás funciones de la aplicación se escalan individualmente en su propio conjunto de instancias, a las que se hace referencia mediante la convención function:<NAMED_FUNCTION>.

Instancias siempre preparadas

Flex Consumption incluye una característica de siempre preparada que permite elegir instancias que siempre se ejecutan y se asignan a cada uno de los grupos o funciones de escalado por función. Esta es una excelente opción para escenarios en los que debe tener un número mínimo de instancias siempre listos para controlar las solicitudes, por ejemplo, para reducir la latencia de inicio en frío de la aplicación. El valor predeterminado es 0 (cero).

Por ejemplo, si establece siempre listo para 2 para el grupo http de funciones, la plataforma mantiene dos instancias siempre en ejecución y asignadas a la aplicación para las funciones HTTP de la aplicación. Esas instancias procesan las ejecuciones de función, pero, en función de la configuración de simultaneidad, la plataforma se escala más allá de esas dos instancias con instancias a petición.

Para obtener información sobre cómo configurar instancias siempre listas, consulte Establecimiento de recuentos de instancias siempre listos.

Simultaneidad

La simultaneidad hace referencia al número de ejecuciones paralelas de una función en una instancia de la aplicación. Puede establecer un número máximo de ejecuciones simultáneas que cada instancia debe controlar en cualquier momento dado. Para obtener más información, consulte Simultaneidad del desencadenador HTTP.

La simultaneidad tiene un efecto directo sobre cómo se escala la aplicación porque, en niveles de simultaneidad inferiores, necesita más instancias para controlar la demanda controlada por eventos de una función. Aunque puede controlar y ajustar la simultaneidad, proporcionamos valores predeterminados que funcionan en la mayoría de los casos. Para obtener información sobre cómo establecer límites de simultaneidad para las funciones de desencadenador HTTP, consulte Establecimiento de límites de simultaneidad HTTP.

Implementación

Las implementaciones del plan Consumo flexible siguen una única ruta de acceso. Una vez compilado y comprimido el código del proyecto en un paquete de aplicación, se implementa en un contenedor de almacenamiento de blobs. Al iniciarse, la aplicación obtiene el paquete y ejecuta el código de función desde este paquete. De forma predeterminada, la misma cuenta de almacenamiento que se usa para almacenar metadatos de host internos (AzureWebJobsStorage) también se usa como contenedor de implementación. Sin embargo, puede usar una cuenta de almacenamiento alternativa o elegir el método de autenticación preferido configurando la configuración de implementación de la aplicación. Al simplificar la ruta de acceso de implementación, ya no es necesario que la configuración de la aplicación influye en el comportamiento de la implementación.

Facturación

Hay dos modos por los que los costos se determinan al ejecutar las aplicaciones en el plan de consumo flexible. Cada modo se determina por instancia.

Modo de facturación Descripción
A petición Cuando se ejecuta en modo a petición, solo se le factura la cantidad de tiempo que se ejecuta el código de función en las instancias disponibles. En el modo a petición, no se requiere ningún recuento mínimo de instancias. Se le factura por:

• La cantidad total de memoria aprovisionada mientras cada instancia a petición ejecuta activamente funciones (en GB-segundos), menos una concesión gratuita de GB al mes.
• Número total de ejecuciones, menos una concesión gratuita (número) de ejecuciones al mes.
Siempre preparada Puede configurar una o varias instancias, asignadas a tipos de desencadenadores específicos (HTTP/Durable/Blob) y funciones individuales, que siempre están disponibles para poder controlar las solicitudes. Cuando tenga habilitadas instancias siempre preparadas, se le factura lo siguiente:

• La cantidad total de memoria aprovisionada en todas las instancias siempre preparadas, conocidas como línea base (en GB-segundos).
• La cantidad total de memoria aprovisionada durante el tiempo cada instancia siempre preparada está ejecutando activamente funciones (en GB-segundos).
• Número total de ejecuciones.

En la facturación siempre lista, no hay concesiones gratuitas.

El período mínimo de ejecución facturable para ambos modos de ejecución es de 1000 ms. Después de eso, el período de actividad facturable se redondea hasta los 100 ms más cercanos. Puede encontrar detalles sobre los medidores de facturación del plan de consumo flexible en la referencia de supervisión.

Para obtener más información sobre cómo se calculan los costos cuando se ejecuta en un plan de consumo flexible, incluidos ejemplos, consulte Costos basados en el consumo.

Para obtener la información más actualizada sobre los precios de ejecución, los costos de línea base siempre listos y las concesiones gratuitas para las ejecuciones a petición, consulte la página de precios de Azure Functions.

Versiones admitidas de la pila de lenguajes

En esta tabla se muestran las versiones de la pila de lenguajes que se admiten actualmente para las aplicaciones Flex Consumption:

Pila de lenguajes Versión requerida
C# (modo de proceso aislado)1 .NET 82
Java Java 11, Java 17
Node.js Node 20
PowerShell PowerShell 7.4
Python Python 3.10, Python 3.11

1No se admite el modo en proceso de C#. En su lugar, debe migrar el proyecto de código de .NET para que se ejecute en el modelo de trabajo aislado.
2Requiere la versión 1.20.0 o posterior de Microsoft.Azure.Functions.Worker y la versión 1.16.2 o posterior de Microsoft.Azure.Functions.Worker.Sdk.

Cuotas de memoria de suscripción regionales

Actualmente, en la versión preliminar, cada región de una suscripción determinada tiene un límite de memoria de 512,000 MB para todas las instancias de aplicaciones que se ejecuten en los planes de consumo flexible de esa región. Esto significa que, en una suscripción y región determinadas, puede tener cualquier combinación de tamaños de memoria de instancia y recuentos, siempre y cuando permanezcan por debajo del límite de cuota. Por ejemplo, cada uno de los ejemplos siguientes significaría que se ha alcanzado la cuota y las aplicaciones dejarán de escalarse:

  • Tiene una aplicación de 2048 MB escalada a 100 y una segunda aplicación de 2048 MB escalada a 150 instancias
  • Tiene una aplicación de 2048 MB que se escale horizontalmente a 250 instancias
  • Tiene una aplicación de 4096 MB que se escala horizontalmente a 125 instancias
  • Tiene una aplicación de 4096 MB escalada a 100 y una aplicación de 2048 MB escalada a 50 instancias

Esta cuota se puede aumentar para permitir que las aplicaciones de consumo flexible se escalen más, en función de sus requisitos. Si las aplicaciones requieren una cuota mayor, cree una incidencia de soporte técnico.

Propiedades y configuraciones en desuso

En Flex Consumption, muchas de las propiedades estándar de configuración de aplicación y configuración de sitio usadas en Bicep, las plantillas de ARM y el plano de control general están en desuso o se han movido y no se deben usar al automatizar la creación de recursos de la aplicación de funciones. Para obtener más información, consulte Desusos del plan Flex Consumption.

Consideraciones

Tenga en cuenta estas otras consideraciones al usar el plan Flex Consumption durante la versión preliminar actual:

  • Host: hay un tiempo de espera de 30 segundos para la inicialización de la aplicación. Si la aplicación de funciones tarda más de 30 segundos en iniciarse, verá entradas de System.TimeoutException relacionadas con gRPC. Este tiempo de espera se podrá configurar y se implementará una excepción más clara como parte de este elemento de trabajo de host.
  • Durable Functions: debido a la naturaleza de escalado por función de Flex Consumption, para garantizar el mejor rendimiento para Durable Functions, se recomienda establecer el Recuento de instancias siempre listas para el grupo durable en 1. Además, con el proveedor de Azure Storage, considere la posibilidad de reducir el intervalo de sondeo de la cola a 10 segundos o menos. Solo Azure Storage se admite como proveedor de almacenamiento back-end para las instancias de Durable Functions hospedadas en Flex Consumption.
  • Integración con red virtual: asegúrese de que el proveedor de recursos de Azure Microsoft.App esté habilitado para la suscripción con estas instrucciones. La delegación de subred requerida por las aplicaciones Flex Consumption es Microsoft.App/environments.
  • Desencadenadores: todos los desencadenadores son totalmente compatibles, excepto los desencadenadores de Kafka y Azure SQL. El desencadenador de Blob Storage solo admite el origen de Event Grid. Las aplicaciones de funciones que no son de C# deben usar la versión [4.0.0, 5.0.0) de la agrupación de extensiones o una versión posterior.
  • Regiones: actualmente no se admiten todas las regiones. Para más información, consulte Visualización de regiones admitidas actualmente.
  • Implementaciones: actualmente no se admiten ranuras de implementación.
  • Escala: la escala máxima más baja en versión preliminar es 40. El valor más alto admitido actualmente es 1000.
  • Dependencias administradas: las dependencias administradas en PowerShell no son compatibles con el plan de consumo flexible. En ese caso, deberá definir sus propios módulos personalizados.
  • Configuración de diagnóstico: la configuración de diagnóstico no se admite actualmente.
  • Certificados: actualmente no se admite la carga de certificados con la configuración de la aplicación WEBSITE_LOAD_CERTIFICATES.
  • Referencias de Key Vault: las referencias de Key Vault en la configuración de la aplicación no funcionan cuando Key Vault tiene acceso restringido a la red, incluso si la aplicación de funciones tiene la integración con Virtual Network. La solución alternativa actual consiste en hacer referencia directamente a Key Vault en el código y leer los secretos necesarios.
  • Montaje de recursos compartidos de archivos de Azure Files: Montaje de un recurso compartido de archivos de Azure Files no funciona cuando la aplicación de funciones tiene integración con Virtual Network.

Opciones de hospedaje de Azure FunctionsCreación y administración de aplicaciones de funciones en el plan de consumo flexible