Prácticas recomendadas para trabajar con funciones AWS Lambda - AWS Lambda

Prácticas recomendadas para trabajar con funciones AWS Lambda

A continuación se indican las prácticas recomendadas para utilizar AWS Lambda:

Para obtener más información acerca de las prácticas recomendadas para las aplicaciones de Lambda, consulte Diseño de aplicaciones en la guía del operador de Lambda.

Código de función

  • Separe el controlador de Lambda de la lógica del núcleo. Esto le permite probar las distintas unidades de la función con mayor facilidad. En Node.js, podría tener este aspecto:

    exports.myHandler = function(event, context, callback) { var foo = event.foo; var bar = event.bar; var result = MyLambdaFunction (foo, bar); callback(null, result); } function MyLambdaFunction (foo, bar) { // MyLambdaFunction logic here }
  • Reutilice el entorno de ejecución para mejorar el rendimiento de la función. Inicialice los clientes de SDK y las conexiones de base de datos fuera del controlador de funciones y almacene localmente en caché los recursos estáticos en el directorio /tmp. Las invocaciones posteriores procesadas por la misma instancia de su función pueden reutilizar estos recursos. Esto ahorra costes al reducir el tiempo de ejecución de la función.

    Para evitar posibles filtraciones de datos entre las invocaciones, no utilice el entorno de ejecución para almacenar datos de usuario, eventos u otra información con implicaciones de seguridad. Si su función se basa en un estado mutable que no se puede almacenar en la memoria dentro del controlador, considere crear una función independiente o versiones independientes de una función para cada usuario.

  • Utilice una directiva keep-alive para mantener conexiones persistentes. Lambda purga las conexiones inactivas a lo largo del tiempo. Si intenta reutilizar una conexión inactiva al invocar una función, se producirá un error de conexión. Para mantener la conexión persistente, use la directiva keep-alive asociada al tiempo de ejecución. Para ver un ejemplo, consulte Reutilización de conexiones con Keep-Alive en Node.js.

  • Utilice variables de entorno para pasar parámetros operativos a su función. Por ejemplo, si está escribiendo en un bucket de Amazon S3, en lugar de codificar de forma rígida el nombre del bucket, configúrelo como una variable de entorno.

  • Controle las dependencias del paquete de implementación de la función. El entorno de ejecución de AWS Lambda contiene una serie de bibliotecas, como el SDK de AWS para los tiempos de ejecución de Node.js y Python (puede encontrar una lista completa aquí: Tiempos de ejecución de Lambda). Para disponer del conjunto más reciente de características y actualizaciones de seguridad, Lambda actualizará periódicamente estas bibliotecas. Estas actualizaciones pueden introducir cambios sutiles en el comportamiento de la función de Lambda. Para disponer de un control total de las dependencias que utiliza la función, empaquete todas las dependencias con el paquete de implementación.

  • Minimice el tamaño del paquete de implementación de acuerdo con las necesidades de su tiempo de ejecución. Esto reducirá la cantidad de tiempo que tarda el paquete de implementación en descargarse y desempaquetarse antes de la invocación. En las funciones creadas en Java o .NET Core, evite cargar toda la biblioteca del SDK de AWS como parte del paquete de implementación. En lugar de ello, cree dependencias selectivas de los módulos que seleccionen los componentes del SDK que necesita (por ejemplo, DynamoDB, módulos del SDK de Amazon S3 y bibliotecas básicas de Lambda).

  • Reduzca el tiempo que tarda Lambda en desempaquetar los paquetes de implementación escritos en Java colocando los archivos .jar de dependencias en un directorio /lib independiente. Esto es más rápido que colocar todo el código de la función en un único archivo jar con un gran número de archivos .class. Para obtener instrucciones, consulte Implementar funciones de Lambda Java con archivos de archivo .zip o JAR.

  • Minimice la complejidad de las dependencias. Son preferibles los marcos de trabajo más sencillos, ya que se cargan rápidamente al arrancar el entorno de ejecución. Por ejemplo, es preferible utilizar los marcos de trabajo de inserción de dependencias (IoC) de Java más sencillos, como Dagger o Guice, que los más complejos, como Spring Framework.

  • Evite utilizar código recursivo en la función de Lambda que haga que esta llame a sí misma automáticamente hasta que se cumplan ciertos criterios arbitrarios. Esto podría producir un volumen no intencionado de invocaciones de la función y costos elevados. Si lo hace accidentalmente, establezca la simultaneidad reservada de funciones en 0 para limitar inmediatamente todas las invocaciones de la función mientras actualiza el código.

  • No utilice API no documentadas y no públicas en el código de la función de Lambda. Para tiempos de ejecución administrados de AWS Lambda, Lambda aplica periódicamente actualizaciones funcionales y de seguridad a las API internas de Lambda. Estas actualizaciones de las API internas pueden ser incompatibles con versiones anteriores, lo que conlleva consecuencias no deseadas, como errores de invocación si su función depende de estas API no públicas. Consulte la referencia de la API para obtener una lista de las API disponibles públicamente.

  • Escriba el código idempotente. Escribir el código idempotente para las funciones garantiza que los eventos duplicados se gestionen de la misma manera. El código debe validar y gestionar correctamente los eventos duplicados. Para obtener más información, consulte ¿Cómo puedo hacer que mi función de Lambda sea idempotente?.

Función de configuración

  • La prueba de desempeño de la función de Lambda es una parte crucial a la hora de garantizar la elección de la configuración de memoria óptima. Cualquier aumento del tamaño de la memoria causa un aumento equivalente de la CPU disponible para la función. El uso de la memoria de la función se determina por invocación y puede visualizarse en Amazon CloudWatch. En cada invocación se genera una entrada REPORT:, tal como se muestra a continuación:

    REPORT RequestId: 3604209a-e9a3-11e6-939a-754dd98c7be3 Duration: 12.34 ms Billed Duration: 100 ms Memory Size: 128 MB Max Memory Used: 18 MB

    Analice el campo Max Memory Used: para determinar si la función necesita más memoria o si ha aprovisionado en exceso el tamaño de la memoria para la función.

    Para encontrar la configuración de memoria adecuada para sus funciones, recomendamos utilizar el proyecto AWS Lambda Power Tuning de código abierto. Para obtener más información, consulte AWS LambdaAjuste de energía en GitHub.

    Para optimizar el rendimiento de las funciones, también recomendamos implementar bibliotecas que puedan aprovechar Advanced Vector Extensions 2 (AVX2). Esto le permite procesar cargas de trabajo exigentes, incluyendo inferencias de machine learning, procesamiento de medios, computación de alto rendimiento (HPC), simulaciones científicas y modelado financiero. Para obtener más información, consulte Creación de funciones de AWS Lambda más rápidas con AVX2.

  • Realice una prueba de carga de la función de Lambda para determinar un valor de tiempo de espera óptimo. Es importante analizar cuánto tiempo se ejecuta la función para determinar más fácilmente los posibles problemas con un servicio de dependencias que puedan aumentar la concurrencia de la función más allá de lo esperado. Esto es especialmente importante cuando la función de Lambda realiza llamadas de red a recursos que pueden no gestionar el escalado de Lambda.

  • Utilice los permisos más restrictivos al establecer las políticas de IAM. Conozca los recursos y las operaciones que la función de Lambda necesita, y limite el rol de ejecución a estos permisos. Para obtener más información, consulte Permisos de Lambda.

  • Familiarícese con los Cuotas de Lambda. A menudo, el tamaño de carga, los descriptores de archivo y el espacio de /tmp se pasan por alto a la hora de determinar los límites de recursos del tiempo de ejecución.

  • Elimine las funciones de Lambda que ya no utilice. Al hacerlo, las funciones no utilizadas no contarán innecesariamente para el límite de tamaño del paquete de implementación.

  • Si utiliza Amazon Simple Queue Service como origen de eventos, asegúrese de que el valor del tiempo de invocación que se espera para la función no sea superior al valor de Tiempo de espera de visibilidad de la cola. Esto se aplica tanto a CreateFunction como a UpdateFunctionConfiguration.

    • En el caso de CreateFunction, AWS Lambda no realizará el proceso de creación de función.

    • En el caso de UpdateFunctionConfiguration, podría dar lugar a invocaciones duplicadas de la función.

Métricas y alarmas

  • Utilice Uso de métricas de funciones de Lambda y Alarmas de CloudWatch en lugar de crear o actualizar una métrica desde dentro de la función de código de Lambda. Es una forma mucho más eficaz de realizar el seguimiento del estado de las funciones de Lambda, y le permitirá identificar los problemas al comienzo del proceso de desarrollo. Por ejemplo, puede configurar una alarma en función de la duración esperada en la invocación de la función de Lambda para solucionar los cuellos de botella o las latencias atribuibles al código de la función.

  • Utilice la biblioteca de registro y las AWS Lambdadimensiones y métricas para detectar los errores de las aplicaciones (por ejemplo, ERR, ERROR, WARNING, etc.)

  • Use Detección de anomalías de costos de AWS para detectar actividad inusual en su cuenta. La detección de anomalías de costos utiliza machine learning para monitorear de forma continua el costo y el uso y, al mismo tiempo, minimizar las alertas positivas falsas. La detección de anomalías de cotso utiliza datos de AWS Cost Explorer, que tiene un retraso de hasta 24 horas. Como resultado de ello, puede tardar hasta 24 horas en detectar una anomalía después de que se produce el uso. Para comenzar a utilizar la detección de anomalías de costo, primero debe registrarse en Cost Explorer. Luego, acceda a Cost Anomaly Detection (Detección de anomalías de costos).

Uso de secuencias

  • Pruebe con diferentes tamaños de lote y de registro para que la frecuencia de sondeo de cada origen de eventos se ajuste a la velocidad con la que la función es capaz de completar su tarea. El parámetro de BatchSize CreateEventSourceMapping controla el número máximo de registros que se pueden enviar a la función en cada invocación. A menudo, un tamaño de lote mayor puede absorber de forma más eficiente el tráfico adicional asociado a un conjunto de registros mayor, mejorando el desempeño.

    De forma predeterminada, Lambda invoca su función tan pronto como los registros estén disponibles. Si el lote que Lambda lee del origen de eventos solo tiene un registro, Lambda envía solo un registro a la función. Para evitar invocar la función con un número de registros pequeño, puede indicar al origen de eventos que almacene en búfer registros durante hasta 5 minutos configurando un plazo de procesamiento por lotes. Antes de invocar la función, Lambda continúa leyendo los registros del origen de eventos hasta que haya recopilado un lote completo, venza el plazo de procesamiento por lotes o el lote alcance el límite de carga de 6 MB. Para obtener más información, consulte Comportamiento de procesamiento por lotes.

  • Aumente el rendimiento del procesamiento de transmisiones de Kinesis añadiendo particiones. Un flujo de Kinesis se compone de una o más particiones. Lambda sondeará cada partición que tenga como máximo una invocación simultánea. Por ejemplo, si su flujo tiene 100 particiones activas, habrá como máximo 100 invocaciones a la función de Lambda ejecutándose simultáneamente. Al aumentar el número de particiones, aumentará directamente el número máximo de invocaciones simultáneas a la función de Lambda, y también puede incrementarse el rendimiento del procesamiento de flujos de Kinesis. Si aumenta el número de particiones de un flujo de Kinesis, asegúrese de que ha elegido una buena clave de partición (consulte Claves de partición) para los datos, de forma que los registros relacionados acaben en las mismas particiones y los datos estén bien distribuidos.

  • Utilice Amazon CloudWatch en IteratorAge para determinar si el flujo de Kinesis se está procesando. Por ejemplo, configure una alarma de CloudWatch con un valor máximo de 30000 (30 segundos).