microsoft - El precio y el tiempo de espera de Azure Functions

porta azure

Question

Me acabo de dar cuenta recientemente, que las funciones de Azure adquirieron un tiempo de espera de 5 minutos en el nivel de precios dinámicos en algún lugar a lo largo de la línea de tiempo. Como he estado ocupado haciendo otras cosas, esto pasó por debajo de mi radar, hasta que noté que algunas funciones largas no se completaban.

Así que fui a excavar y descubrí que hay dos niveles de precios: el dinámico y el servicio de aplicaciones. El sitio es un poco vago en todo el concepto, pero según lo entiendo, así es como se mantiene:

Dinámico: cargado por tiempo de uso y asignación de memoria por parte del usuario. Tiempo de espera de 5 minutos (tan inútil para operaciones de larga duración).

Servicio de aplicación: una VM de nivel básico o estándar, ejecutándose a tiempo completo, esperando desencadenantes. Sin tiempo de espera para hablar.

Ahora, la primera me decepciona, ya que vi funciones como una solución para mis trabajos que necesitan ser disparadas una o dos veces al año, pero luego me toma uno o dos días para completar (copia de seguridad completa y empaquetamiento de datos para exportar).

El segundo me confunde: ¿significa esto que la función sin estado ahora se ejecuta como una aplicación web y que me cobrarán por ello como tal? Si este es el caso, el concepto completo de funciones ahora es inútil para mis propósitos, a menos que implemente un procesador Cell, disparando 80000 instancias de función sobre un desencadenante para realizar el trabajo a tiempo. Si eso es posible.

¿Podría alguien explicar el modelo detrás del precio de Functions y cuál sería la mejor solución para mi problema?

Gracias.

Answer 1

El servicio Azure Batch es lo que buscas.

Básicamente, puede aumentar los recursos de cómputo requeridos, cuando sea necesario, y solo paga por el tiempo de cómputo que usa, el Servicio por lotes en sí mismo (que proporciona todo tipo de bondades como detección de errores, reintentos, escalado automático) no incurre un cargo adicional. (Por cierto, tiene su propia API, por lo que puede automatizarlo por completo, si es necesario)

Puede instalar software personalizado en cada máquina virtual del conjunto antes de que comience a funcionar.

Puede dejar que el servicio por lotes se escale automáticamente en función de una regla personalizable, o puede simplemente crear un grupo de un tamaño fijo y escalarlo manualmente.

https://azure.microsoft.com/en-gb/services/batch/

Actualización : según los comentarios sobre este problema de GitHub, si su aplicación de función está utilizando un plan de servicio de aplicación existente, entonces el tiempo de espera no se aplica. Aparentemente, la opción dinámica o el tiempo de espera del "Plan de consumo" tiene que ver con el tiempo de espera de instancias de VM de la plataforma subyacente. Entonces, esa podría ser otra ruta: pagar por un plan de servicio de aplicación, luego puedes usar la bondad de la aplicación Function sin tiempos de espera.

Answer 2

Como alguien en este hilo dijo que debería intentar ver la automatización azul o algo así si su proceso se usa con menos frecuencia y además tarda unos días en completarse.

Sin conocer exactamente la escala (n. ° de archivos / fuente y destino del archivo y la copia de seguridad), podría dividir la solución en fragmentos más pequeños (tareas => funciones) e implementar los fragmentos en planes de aplicaciones por separado

1. Dominar

   • Esto sería responsable de determinar una lista de artículos de línea que deben respaldarse.
   • El maestro simplemente levantaría un ticket en una cola o haría un ping a un trabajador.
   • ¡Esta función maestra se puede implementar en lo que se denomina "Plan de servicio de aplicación" y puede ejecutarse durante más de 5 minutos !!

2. Obrero

   • Esto sería en realidad responsable de la copia de seguridad de una sola unidad de trabajo.
   • Esta función de trabajador se puede implementar en un llamado ahora "Plan de consumo" conocido anteriormente como "Plan dinámico".
   • En un plan de consumo (AFAIK), puede tener 32 instancias de la función azure ejecutándose en paralelo.
   • Incluso puede clonar la aplicación de la función de trabajo y realizar una copia de seguridad de 32/64/128 unidades de trabajo en paralelo

Desde el punto de vista monetario, tiene todo el sentido que en un plan de consumo en el que se le cobran alrededor de Gb / s (memoria y tiempo de ejecución utilizado) de que el host evite ejecuciones de ejecución prolongada.

Espero que esto ayude

Answer 3

Las funciones están diseñadas para manejar tareas cortas (menos de 5 minutos). Pero hay soluciones. Puede crear una Plantilla ARM para implementar una Aplicación de función con un Nivel de servicio de aplicación web y eliminarla una vez que se haya completado el procesamiento. Puede usar webjobs en lugar de funciones (pero aún tiene que pagar por la aplicación web).

Answer 4

Este hilo merece un poco más de claridad. En primer lugar, si lleva un tiempo completar la llamada a su función, va a querer que sea asincrónica. En segundo lugar, si lo hace asincrónico, no se agotará después de 5 minutos.

Dale una oportunidad: P

DateTime d = DateTime.Now;
Task t = new Task(() =>
{
    log.Info("Doing long task");
    for (int cnt = 0; cnt < 100; cnt++)
    {
        log.Info(DateTime.Now.Subtract(d).ToString());
        System.Threading.Thread.Sleep(10000);
    }
});
t.Start();

Actualmente los estoy ejecutando en un plan de consumo durante más de 5 minutos, según mi publicación. Hay un tiempo de espera, pero obviamente no está en el tiempo de ejecución ya que los estoy ejecutando más de 5 minutos. El tiempo de espera está en el mecanismo de llamada que ejecuta la función. Si lo hace asincrónico, la persona que llama vuelve y la función continúa ejecutándose. Es una práctica común colocar tareas de larga ejecución en un subproceso / proceso separado que el subproceso / proceso de llamada. Mantener la capa de orquestación de la plataforma de funciones bloqueada durante largos períodos de tiempo simplemente tiene sentido. No debe bloquear la capa de llamada para las funciones de ejecución prolongada, ya que degradará seriamente la plataforma.