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.

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.

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, los desencadenadores HTTP, Blob (Event Grid) y Durable son casos especiales. Todas las funciones desencadenadas por HTTP de la aplicación se agrupan y se escalan juntas en las mismas instancias, y todas las funciones desencadenadas por Durable (orquestación, actividad o desencadenadores de entidad) se agrupan y se escalan juntas en las mismas instancias. Todas las demás funciones de la aplicación se escalan individualmente.

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 recuperará el paquete y se ejecutará desde él. 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 optimizar la ruta de acceso de implementación, ya no es necesario que la configuración de la aplicación influya 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, 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 ejecutan en los planes de consumo flexible de esa región. Esto significa que, en una determinada suscripción y región, podría tener cualquiera de las siguientes combinaciones de tamaños y recuentos de instancias máximos, todos los cuales alcanzan el límite actual de 512,000 MB. Por ejemplo:

Tamaño de memoria de instancia (MB) Número máximo de instancias (por región)
2048 MB 250
4096 MB 125

Puede tener cualquier otra combinación de tamaños de memoria de instancia y recuentos en una región determinada, siempre y cuando permanezcan por debajo del límite de 512,000 MB. Si las aplicaciones requieren una cuota mayor, puede crear una incidencia de soporte técnico para solicitar un aumento de cuota.

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:

  • Desencadenadores: todos los desencadenadores son totalmente compatibles, excepto los desencadenadores de Kafka, Azure SQL y SignalR. 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 estas características relacionadas con la implementación:
    • Ranuras de implementación
    • Implementación continua mediante Azure DevOps Tasks (AzureFunctionApp@2)
    • Implementación continua mediante Acciones de GitHub (functions-action@v1)
  • Escala: la escala máxima más baja en versión preliminar es 40. El valor más alto admitido actualmente es 1000.
  • Autorización: EasyAuth no se admite actualmente. Actualmente, los autores de llamadas no autenticados no se bloquean cuando EasyAuth está habilitado en una aplicación de plan de consumo flexible.
  • CORS: actualmente no se admite la configuración de CORS. Es posible que se produzcan excepciones si CORS está configurado para aplicaciones de consumo flexible.

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