Plan prémium de Azure Functions
El plan Elastic Premium de Azure Functions es una opción de hospedaje de escalado dinámico para las aplicaciones de funciones. Para ver otras opciones de plan de hospedaje, consulte este artículo.
Importante
Azure Functions puede ejecutarse en la plataforma Azure App Service. En la plataforma App Service, los planes que hospedan las aplicaciones de funciones de plan Premium se conocen como planes Elastic Premium, con nombres de SKU como EP1. Si decide ejecutar la aplicación de funciones en un plan Premium, asegúrese de crear un plan con un nombre de SKU que comience por "E", como EP1. Nombres de SKU de plan de App Service que comienzan por "P", como P1V2 (plan Premium pequeño V2), son en realidad P1V2. Dado que son Premium dedicados y no elásticos, los planes con nombres de SKU que comienzan por "P" no se escalan dinámicamente y pueden aumentar los costos.
El hospedaje del plan Prémium ofrece las siguientes ventajas para sus funciones:
- Evite los arranques en frío con instancias activas.
- Conectividad de red virtual.
- Admite duraciones de tiempo de ejecución más largas.
- Elección de tamaños de instancia Premium.
- Precios más predecibles, en comparación con el plan de consumo.
- Asignación de aplicaciones de alta densidad para planes con varias aplicaciones de funciones.
- Admite implementaciones de contenedores de Linux.
Cuando se usa el plan Prémium, las instancias del host de Azure Functions se agregan y quitan según el número de eventos entrantes, al igual que con el plan de consumo. Pueden implementarse varias aplicaciones de funciones en el mismo plan Premium. Este plan permite configurar el tamaño de la instancia de proceso, el tamaño del plan base y el tamaño del plan máximo.
Facturación
La facturación del plan Prémium se basa en el número de núcleos por segundo y en la memoria asignada entre instancias. Esta facturación se diferencia del plan de consumo, que se factura en función del consumo y las ejecuciones de recursos por segundo. No hay ningún cargo de ejecución con el plan Premium. Esta facturación da como resultado un costo mensual mínimo por plan activo, independientemente de si la función está activa o inactiva. Tenga en cuenta que todas las aplicaciones de función de un plan Premium comparten instancias asignadas. Para más información, consulte la página de precios de Azure Functions.
Nota
Todos los planes Prémium tendrán al menos una instancia activa (facturada) en todo momento.
Creación de un plan Premium
Al crear una aplicación de funciones en Azure Portal, el plan de consumo es el predeterminado. Para crear una aplicación de función que se ejecute en un plan Prémium, debe crear o elegir explícitamente un plan de hospedaje Premium de Azure Functions con una de las SKU de Elastic Prémium. La aplicación de función que cree se hospeda en este plan. Azure Portal permite crear fácilmente el plan Prémium y la aplicación de funciones al mismo tiempo. Puede ejecutar más de una aplicación de funciones en el mismo plan Premium, pero deben ejecutarse en el mismo sistema operativo (Windows o Linux).
En los artículos siguientes, se muestra cómo crear mediante programación una aplicación de funciones con un plan Premium:
Eliminación de los arranques en frío
Cuando no se producen eventos ni ejecuciones en el plan de consumo, es posible que la aplicación se escale a cero instancias. Cuando se produzcan nuevos eventos, será necesario especializar una nueva instancia con la aplicación que se ejecute en ella. La especialización de nuevas instancias tarda tiempo, en función de la aplicación. Esta latencia extra de la primera llamada también suele denominarse arranque en frío de la aplicación.
El plan Premium proporciona dos características que funcionan juntas para eliminar de forma eficaz los arranques en frío en las funciones: instancias siempre preparadas e instancias activadas previamente. Las instancias siempre preparadas son una categoría de instancias preasignadas que no se ven afectadas por el escalado y las activadas previamente son un búfer a medida que se escala debido a eventos HTTP.
Cuando los eventos empiezan a desencadenar la aplicación, siempre se enrutan primero a las instancias siempre preparadas. A medida que la función se activa debido a eventos HTTP, otras instancias se activan como un búfer. Estas instancias almacenadas en búfer se denominan instancias activadas previamente. Este búfer reduce el arranque en frío para las nuevas instancias necesarias durante el escalado.
Instancias siempre preparadas
En el plan Premium, puede hacer que la aplicación previamente activada esté siempre preparada en un número concreto de instancias. La aplicación se ejecuta continuamente en esas instancias, independientemente de la carga. Si la carga supera lo que las instancias siempre preparadas pueden controlar, se agregan más instancias según sea necesario, hasta el máximo especificado.
Esta configuración de nivel de aplicación también controla las instancias mínimas del plan. Por ejemplo, considere la posibilidad de tener tres aplicaciones de funciones en el mismo plan Premium. Cuando dos de las aplicaciones tienen el número de instancias siempre preparadas establecido en uno y en una tercera se establece en cinco, el mínimo para todo el plan es cinco. Esto también refleja el número mínimo de instancias para las que se factura el plan. El número máximo de instancias siempre preparadas que se admite por aplicación es 20.
Puede configurar el número de instancias siempre preparadas en Azure Portal. Para ello, seleccione una aplicación de funciones en Function App, vaya a la pestaña Características de la plataforma y seleccione las opciones para Escalar horizontalmente. En la ventana de edición de la aplicación de funciones, las instancias siempre preparadas son específicas para esa aplicación.
Instancias activadas previamente
El valor de recuento de instancias activadas previamente proporciona instancias activadas como un búfer durante los eventos de activación y escala HTTP. Las instancias activadas previamente siguen almacenándose en el búfer hasta que se alcanza el límite máximo de escalabilidad horizontal. El número predeterminado de instancias activadas previamente es 1 y, en la mayoría de los escenarios, este valor debería dejarse en 1.
Considere un escenario menos común, como una aplicación que se ejecuta en un contenedor personalizado. Como los contenedores personalizados tienen un calentamiento largo, puede considerar la posibilidad de aumentar este búfer de instancias activadas previamente. Una instancia activada previamente solo se activa después de que todas las instancias activas estén en uso.
También puede definir un desencadenador de activación que se ejecute durante el proceso de activación previa. Puede usar un desencadenador de activación para cargar con antelación dependencias personalizadas durante el proceso de activación previa, de modo que las funciones estén listas para empezar a procesar solicitudes inmediatamente. Para obtener más información, consulte Desencadenador de preparación de Azure Functions.
Tenga en cuenta este ejemplo en el que se muestra el funcionamiento conjunto de las instancias siempre preparadas y las instancias activadas previamente. Una aplicación de funciones Premium tiene configuradas dos instancias siempre preparadas, y una instancia activada previamente como predeterminada.
- Cuando la aplicación está inactiva y no se desencadena ningún evento, se aprovisiona y se ejecuta con dos instancias. En este momento, se le facturan las dos instancias siempre preparadas pero no se factura una instancia activada previamente, ya que no hay ninguna asignada.
- A medida que la aplicación comienza a recibir tráfico HTTP, se equilibra la carga de las solicitudes entre las dos instancias siempre preparadas. En cuanto esas dos instancias inician el procesamiento de eventos, se agrega una instancia para rellenar el búfer activado previamente. Ahora la aplicación se ejecuta con tres instancias aprovisionadas: las dos instancias siempre preparadas y el tercer búfer activado previamente e inactivo. Se le facturan las tres instancias.
- A medida que aumenta la carga y la aplicación necesita más instancias para controlar el tráfico HTTP, esa instancia activada previamente se intercambia a una instancia activa. La carga HTTP ahora se enruta a las tres instancias y se aprovisiona al instante una cuarta instancia para rellenar el búfer activado previamente.
- Esta secuencia de escalado y activación previa continúa hasta que se alcanza el recuento de instancias máximo de la aplicación o disminuye la carga, lo que hace que la plataforma se reduzca horizontalmente después de un período. Ninguna instancia se activa previamente ni se activa por encima del número máximo.
No puede cambiar el valor de recuento de instancias activadas previamente en el portal; en su lugar, debe usar la CLI de Azure o Azure PowerShell.
Número máximo de instancias de aplicación de funciones
Además del plan de número máximo de ráfagas, puede configurar un máximo por aplicación. El máximo de la aplicación se puede configurar mediante el límite de escalabilidad de aplicaciones. El límite máximo de escalabilidad horizontal de la aplicación no puede superar las instancias de ráfagas máximas del plan.
Conectividad de red privada
Las aplicaciones de funciones implementadas en un plan Premium pueden sacar provecho de la integración de red virtual para aplicaciones web. Cuando se configura, la aplicación se puede comunicar con los recursos en la red virtual, o bien protegerse mediante puntos de conexión de servicio. Las restricciones de IP también están disponibles en la aplicación para restringir el tráfico entrante.
Cuando se asigne una subred a la aplicación de funciones en un plan Premium, necesitará una subred con suficientes direcciones IP para cada posible instancia. Se requiere un bloque de direcciones IP con al menos 100 direcciones disponibles.
Para más información, vea Integración de una aplicación de funciones con una red virtual.
Escalado elástico rápido
Se agregan automáticamente más instancias de proceso a la aplicación mediante la misma lógica de escalado rápido que la del plan de consumo. Las aplicaciones dentro del mismo plan de App Service se escalan de forma independiente entre sí y en función de las necesidades de una aplicación individual, pero las aplicaciones de Functions dentro del mismo plan de App Service sí comparten recursos de máquina virtual para contribuir a reducir los costes, siempre que sea posible. El número de aplicaciones asociadas a una máquina virtual depende de la superficie de cada aplicación y del tamaño de la máquina virtual en cuestión.
Para más información sobre cómo funciona el escalado, consulte Escalado basado en eventos en Azure Functions.
Duración de la ejecución más larga
Las funciones en un plan de consumo se limitan a 10 minutos en cada ejecución. En el plan Premium, la duración de ejecución predeterminada es de 30 minutos para evitar ejecuciones descontroladas. Sin embargo, puede modificar la configuración de host.json para que la duración sea ilimitada en las aplicaciones del plan Premium con las siguientes limitaciones:
- Las actualizaciones de la plataforma pueden desencadenar un apagado administrado y detener la ejecución de la función con un período de gracia de 10 minutos.
- Hay un temporizador de inactividad que detiene el trabajo al cabo de 60 minutos sin que se produzcan nuevas ejecuciones.
- El comportamiento de reducción horizontal puede provocar el apagado del trabajo después de 60 minutos.
- Los intercambios de ranuras pueden finalizar las ejecuciones en las ranuras de origen y destino durante el intercambio.
Migración
Si tiene una aplicación de funciones existente, puede usar los comandos de la CLI de Azure para migrar la aplicación entre un plan de consumo y un plan prémium en Windows. Los comandos específicos dependen de la dirección de la migración. Para más información, consulte Migración del plan.
Esta migración no se admite en Linux.
Configuración del plan Premium
Cuando se crea un plan, hay dos configuraciones de tamaño de plan: el número mínimo de instancias (o tamaño de plan) y el límite máximo de ráfaga.
Si la aplicación necesita un número de instancias mayor al de la instancias siempre preparadas, puede seguir escalando horizontalmente hasta que el número de instancias alcance el límite máximo de ráfagas del plan o el límite máximo de escalado horizontal de la aplicación si está configurado. Las instancias solo se le facturan (por segundo) cuando estén en ejecución y las tenga asignadas. La plataforma hace todo lo posible por escalar la aplicación hasta los límites máximos definidos.
Puede configurar el tamaño del plan y establecer valores máximos en Azure Portal; para ello, seleccione las opciones de escalabilidad horizontal en el apartado Configuración de una aplicación de funciones implementada en ese plan.
El mínimo de cada plan premium es de al menos una instancia. El número mínimo real de instancias se determina automáticamente en función de las instancias siempre preparadas que hayan solicitado las aplicaciones del plan. Por ejemplo, si la aplicación A solicita cinco instancias siempre preparadas y la aplicación B solicita dos instancias de este tipo en el mismo plan, el tamaño mínimo del plan se determina como cinco. La aplicación A se ejecuta en las cinco y la aplicación B solo se ejecuta en dos.
Importante
Se le cobrará por cada instancia especificada en el número mínimo de instancias independientemente de si las funciones se ejecutan o no.
En la mayoría de los casos, este mínimo que se calculó automáticamente es suficiente. Sin embargo, el escalado que supere el mínimo se realiza de la mejor manera posible. Es posible, aunque poco probable, que se retrase la escalabilidad horizontal en un momento específico si no hay otras instancias disponibles. Al establecer un valor mínimo superior al mínimo calculado automáticamente, se reservan instancias antes del escalado horizontal.
Puede configurar el número mínimo de instancias en Azure Portal; para ello, seleccione las opciones de escalabilidad horizontal en el apartado Configuración de una aplicación de funciones implementada en ese plan.
SKU de instancias disponibles
Cuando cree o escale un plan, podrá elegir entre tres tamaños de instancia. Se le facturará la cantidad total de núcleos y memoria aprovisionada, por los segundos que tenga asignada cada instancia. La aplicación puede escalar horizontalmente de forma automática en varias instancias cuando sea necesario.
| SKU | Núcleos | Memoria | Storage |
|---|---|---|---|
| EP1 | 1 | 3,5 GB | 250 GB |
| EP2 | 2 | 7 GB | 250 GB |
| EP3 | 4 | 14 GB | 250 GB |
Consideraciones de uso de memoria
La ejecución en una máquina con más memoria no siempre significa que la aplicación de funciones vaya a usar toda la memoria disponible.
Por ejemplo, una aplicación de funciones de JavaScript está restringida por el límite de memoria predeterminado en Node.js. Para aumentar este límite de memoria fijo, agregue la configuración de la aplicación languageWorkers:node:arguments con un valor de --max-old-space-size=<max memory in MB>.
Además, en el caso de los planes con más de 4 GB de memoria, asegúrese de que la configuración de la plataforma de valor de bits esté establecida en 64 Bit en Configuración general.
Escalabilidad horizontal máxima en regiones
Estos son los valores máximos de escalabilidad horizontal actualmente admitidos para un solo plan en cada configuración de región y sistema operativo:
| Region | Windows | Linux |
|---|---|---|
| Centro de Australia | 100 | 20 |
| Centro de Australia 2 | 100 | No disponible |
| Este de Australia | 100 | 40 |
| Sudeste de Australia | 100 | 20 |
| Sur de Brasil | 100 | 20 |
| Centro de Canadá | 100 | 100 |
| Centro de la India | 100 | 20 |
| Centro de EE. UU. | 100 | 100 |
| Este de China 2 | 20 | 20 |
| Norte de China 2 | 20 | 20 |
| Norte de China 3 | 20 | 20 |
| Este de Asia | 100 | 20 |
| Este de EE. UU. | 100 | 100 |
| Este de EE. UU. 2 | 80 | 100 |
| Centro de Francia | 100 | 60 |
| Centro-oeste de Alemania | 100 | 20 |
| Centro de Israel | 100 | 20 |
| Norte de Italia | 100 | 20 |
| Japón Oriental | 100 | 20 |
| Japón Occidental | 100 | 20 |
| JIO de India occidental | 100 | 20 |
| Centro de Corea del Sur | 100 | 20 |
| Corea del Sur | 40 | 20 |
| Centro de México | 20 | 20 |
| Centro-Norte de EE. UU | 100 | 20 |
| Norte de Europa | 100 | 100 |
| Este de Noruega | 100 | 20 |
| Norte de Sudáfrica | 100 | 20 |
| Oeste de Sudáfrica | 20 | 20 |
| Centro-sur de EE. UU. | 100 | 100 |
| Sur de la India | 100 | No disponible |
| Sudeste de Asia | 100 | 20 |
| Centro de España | 20 | 20 |
| Norte de Suiza | 100 | 20 |
| Oeste de Suiza | 100 | 20 |
| Norte de Emiratos Árabes Unidos | 100 | 20 |
| Sur de Reino Unido | 100 | 100 |
| Oeste de Reino Unido | 100 | 20 |
| USGov: Arizona | 20 | 20 |
| USGov: Texas | 20 | No disponible |
| USGov Virginia | 80 | 20 |
| Centro-Oeste de EE. UU. | 100 | 20 |
| Oeste de Europa | 100 | 100 |
| Oeste de la India | 100 | 20 |
| Oeste de EE. UU. | 100 | 100 |
| Oeste de EE. UU. 2 | 100 | 20 |
| Oeste de EE. UU. 3 | 100 | 20 |
Para más información, vea la disponibilidad regional completa de Azure Functions.