Sugerencias
En este documento, se describen las prácticas recomendadas para diseñar, implementar y probar Cloud Run Functions.
Precisión
En esta sección, se describen las prácticas recomendadas generales para diseñar e implementar Cloud Run Functions.
Escribe funciones idempotentes
Tus funciones deben producir el mismo resultado, incluso si se llaman varias veces. Esto te permite reintentar una invocación si la anterior falla a mitad de camino en el código. Para obtener más información, consulta Reintenta las funciones controladas por eventos.
Asegúrate de que las funciones de HTTP envíen una respuesta HTTP
Si tu función se activa con HTTP, recuerda que debes enviar una respuesta HTTP como se muestra más abajo. No hacerlo puede dar como resultado que la función se ejecute hasta el tiempo de espera. Si esto ocurre, se te cobrará por todo el tiempo de espera. Los tiempos de espera también pueden generar un comportamiento impredecible o inicios en frío en invocaciones posteriores, lo que dará como resultado un comportamiento impredecible o una latencia adicional.
Node.js
Python
Go
Java
C#
Ruby
PHP
No inicies actividades en segundo plano
Las actividades en segundo plano son todas las acciones que ocurren después de que finaliza la ejecución de tu función.
La invocación de una función termina cuando esta muestra o indica que se completó su ejecución, por ejemplo, si llama al argumento callback
en las funciones controlada por eventos. El código que se ejecute después de esto no podrá acceder a la CPU y no llevará a cabo ningún progreso.
Además, cuando se ejecutan las invocaciones siguientes en el mismo entorno, se reanuda tu actividad en segundo plano, lo que provoca interferencias en la invocación nueva. Es posible que se generen errores y comportamientos inesperados difíciles de diagnosticar. Acceder a una red después de que una función termina suele generar el restablecimiento de las conexiones (código de error ECONNRESET
).
A menudo, la actividad en segundo plano se puede detectar en los registros de las invocaciones individuales, ya que aparece en las líneas posteriores a la que indica que la invocación finalizó. En otras ocasiones, este tipo de actividad puede estar mucho más oculta en el código, especialmente cuando existen operaciones asíncronas, como devoluciones de llamadas o cronómetros. Revisa tu código para asegurarte de que todas las operaciones asíncronas finalicen antes de que termines la función.
Borra los archivos temporales siempre
El almacenamiento en el directorio temporal del disco local es un sistema de archivos en la memoria. Los archivos que escribes consumen memoria disponible en tu función y, a veces, persisten entre invocaciones. No borrar estos archivos explícitamente podría generar un error por falta de memoria y un posterior inicio en frío.
Para ver la memoria que usa una función específica, selecciónala en la lista de funciones de la consola de Google Cloud y elige el trazado Uso de memoria.
Si necesitas acceso al almacenamiento a largo plazo, considera usar activaciones de volumen de Cloud Run con Cloud Storage o volúmenes NFS.
Puedes reducir los requisitos de memoria si procesas archivos más grandes mediante canalizaciones. Por ejemplo, para procesar un archivo alojado en Cloud Storage, puedes crear un flujo de lectura, pasarlo por un proceso basado en flujos y escribir el flujo de salida directamente en Cloud Storage.
Functions Framework
Para garantizar que las mismas dependencias se instalen de manera coherente en diferentes entornos, te recomendamos que incluyas la biblioteca de Functions Framework en tu administrador de paquetes y fijes la dependencia a una versión específica de Functions Framework.
Para ello, incluye tu versión preferida en el archivo de bloqueo relevante (por ejemplo, package-lock.json
para Node.js o requirements.txt
para Python).
Si Functions Framework no aparece de forma explícita como una dependencia, se agregará automáticamente durante el proceso de compilación con la versión más reciente disponible.
Herramientas
En esta sección, se proporcionan lineamientos sobre cómo usar herramientas para implementar, probar y también interactuar con Cloud Run Functions.
Desarrollo local
La implementación de funciones toma algo de tiempo, por lo que suele ser más rápido probar el código de tu función de manera local.
Informes de errores
En lenguajes que usan el manejo de excepciones, no lances excepciones no detectadas, ya que fuerzan los inicios en frío en las invocaciones futuras. Consulta la guía de registro de errores para obtener información sobre cómo informar errores de forma correcta.
No salgas de forma manual
El cierre manual puede provocar un comportamiento inesperado. En su lugar, usa las siguientes expresiones específicas del lenguaje:
Node.js
No uses process.exit()
. Las funciones de HTTP deben enviar una respuesta con res.status(200).send(message)
y las funciones controladas por eventos se cerrarán una vez que muestren una respuesta (de forma implícita o explícita).
Python
No uses sys.exit()
. Las funciones de HTTP deben mostrar de forma explícita una respuesta como una string, y las funciones controladas por eventos saldrán una vez que muestren un valor (ya sea de forma implícita o explícita).
Go
No uses os.Exit()
. Las funciones de HTTP deben mostrar de forma explícita una respuesta como una string, y las funciones controladas por eventos saldrán una vez que muestren un valor (ya sea de forma implícita o explícita).
Java
No uses System.exit()
. Las funciones de HTTP deben enviar una respuesta con response.getWriter().write(message)
y las funciones controladas por eventos se cerrarán una vez que muestren una respuesta (de forma implícita o explícita).
C#
No uses System.Environment.Exit()
. Las funciones de HTTP deben enviar una respuesta con context.Response.WriteAsync(message)
y las funciones controladas por eventos se cerrarán una vez que muestren una respuesta (de forma implícita o explícita).
Ruby
No uses exit()
ni abort()
. Las funciones de HTTP deben mostrar de forma explícita una respuesta como una string, y las funciones controladas por eventos saldrán una vez que muestren un valor (ya sea de forma implícita o explícita).
PHP
No uses exit()
ni die()
. Las funciones de HTTP deben mostrar de forma explícita una respuesta como una string, y las funciones controladas por eventos saldrán una vez que muestren un valor (ya sea de forma implícita o explícita).
Usa Sendgrid para enviar correos electrónicos
Cloud Run Functions no permite conexiones salientes en el 25, por lo que no puedes establecer conexiones no seguras a un servidor SMTP. Para enviar correos electrónicos, se recomienda usar un servicio de terceros, como SendGrid. Puedes encontrar otras opciones para enviar correos electrónicos en el instructivo sobre cómo enviar correos electrónicos desde una instancia para Google Compute Engine.
Rendimiento
Esta sección describe las recomendaciones para optimizar el rendimiento.
Evita la baja simultaneidad
Debido a que los inicios en frío son costosos, poder reutilizar instancias iniciadas recientemente durante un aumento repentino es una gran optimización para controlar la carga. Limitar la simultaneidad limita la forma en que se pueden aprovechar las instancias existentes, por lo que se generan más inicios en frío.
Aumentar la simultaneidad ayuda a aplazar varias solicitudes por instancia, lo que facilita el control de los aumentos repentinos de carga. Nota: Las funciones de 1ª gen. tienen una simultaneidad limitada a 1. Te recomendamos que migres a las funciones de Cloud Run.Usa las dependencias de manera inteligente
Debido a que las funciones no tienen estado, el entorno de ejecución suele inicializarse desde cero (durante lo que se conoce como inicio en frío). Cuando se genera un inicio en frío, se evalúa el contexto global de la función.
Si tus funciones importan módulos, el tiempo de carga de estos se agrega a la latencia de invocación durante un inicio en frío. Para reducir esta latencia y el tiempo que se requiere para implementar tu función, carga las dependencias correctamente y no cargues las dependencias que tu función no utiliza.
Usa variables globales para volver a usar objetos en invocaciones futuras
No se garantiza que el estado de una función de Cloud Run Functions se conserve para las invocaciones futuras. Sin embargo, Cloud Run Functions suele reciclar el entorno de ejecución de una invocación previa. Si declaras una variable en alcance global, su valor se puede volver a usar en invocaciones posteriores sin tener que volver a procesarse.
De esta manera, puedes almacenar objetos en la caché, ya que volver a crearlos en cada invocación de la función puede ser costoso. Mover estos objetos desde el cuerpo de la función al alcance global puede generar importantes mejoras en el rendimiento. El siguiente ejemplo crea un objeto pesado solo una vez por instancia de la función y lo comparte en todas las invocaciones de la función que alcanzan la instancia determinada:
Node.js
Python
Go
Java
C#
Ruby
PHP
Es muy importante almacenar en caché las conexiones de red, las referencias de la biblioteca y los objetos de cliente de la API en alcance global. Consulta Optimiza las herramientas de redes para ver ejemplos.
Configura una cantidad mínima de instancias para reducir los inicios en frío
De forma predeterminada, Cloud Run Functions escala la cantidad de instancias según la cantidad de solicitudes entrantes. Para cambiar este comportamiento predeterminado, configura una cantidad mínima de instancias que Cloud Run Functions debe tener listas para entregar solicitudes. Establecer una cantidad mínima de instancias reduce los inicios en frío de tu aplicación. Recomendamos que configures una cantidad mínima de instancias y completes la inicialización en el tiempo de carga si tu aplicación es sensible a la latencia.
Para aprender a establecer una cantidad mínima de instancias, consulta Usa la cantidad mínima de instancias.
Notas sobre el inicio en frío y la inicialización
La inicialización global se produce en el tiempo de carga. Sin él, la primera solicitud debería completar la inicialización y cargar módulos, lo que generaría una latencia más alta.
Sin embargo, la inicialización global también tiene un impacto en los inicios en frío. Para minimizar este impacto, inicializa solo lo que se necesita para la primera solicitud, de modo que la latencia de la primera solicitud sea lo más baja posible.
Esto es muy importante si configuraste instancias mínimas como se describió anteriormente para una función sensible a la latencia. En ese caso, completar la inicialización en el tiempo de carga y almacenar en caché datos útiles garantiza que la primera solicitud no tenga que hacerlo y se entregue con baja latencia.
Si inicializas variables en el alcance global, según el lenguaje, los tiempos de inicialización largos pueden generar dos comportamientos: - Para algunas combinaciones de lenguajes y bibliotecas asíncronas, el framework de funciones puede ejecutarse de forma asíncrona y mostrarse de inmediato, lo que hace que el código sigue ejecutándose en segundo plano, lo que podría causar problemas, como no poder acceder a la CPU. Para evitar esto, debes bloquear la inicialización del módulo como se describe a continuación. Esto también garantiza que las solicitudes no se entreguen hasta que se complete la inicialización. - Por otro lado, si la inicialización es síncrona, el tiempo de inicialización prolongado provocará inicios en frío más largos, lo que podría ser un problema, especialmente con funciones de baja simultaneidad durante los aumentos repentinos de carga.
Ejemplo de preparación previa de una biblioteca asíncrona de node.js
Node.js con Firestore es un ejemplo de biblioteca asíncrona de Node.js. Para aprovechar min_instances, el siguiente código completa la carga y la inicialización en el momento de la carga, lo que bloquea la carga del módulo.
Se usa TLA, lo que significa que se requiere ES6, con una extensión .mjs
para el código node.js o agregando type: module
al archivo package.json.
{ "main": "main.js", "type": "module", "dependencies": { "@google-cloud/firestore": "^7.10.0", "@google-cloud/functions-framework": "^3.4.5" } }
Node.js
import Firestore from '@google-cloud/firestore'; import * as functions from '@google-cloud/functions-framework'; const firestore = new Firestore({preferRest: true}); // Pre-warm firestore connection pool, and preload our global config // document in cache. In order to ensure no other request comes in, // block the module loading with a synchronous global request: const config = await firestore.collection('collection').doc('config').get(); functions.http('fetch', (req, res) => { // Do something with config and firestore client, which are now preloaded // and will execute at lower latency. });
Ejemplos de inicialización global
Node.js
Python
Go
Java
C#
Ruby
PHP
Las funciones de PHP no pueden conservar variables entre solicitudes. En el ejemplo de alcance anterior, se usa la carga diferida para almacenar en caché valores de variables globales en un archivo.
Esto es muy importante si defines varias funciones en un solo archivo y si varias funciones usan variables diferentes. A menos que uses la inicialización diferida, puedes perder recursos si inicializas variables que nunca se usan.
Recursos adicionales
Obtén más información sobre cómo optimizar el rendimiento en el video, consulta Tiempo de inicio en frío de Cloud Run Functions. de “Google Cloud Performance Atlas”.