AWS Lambda Performance Tuning

Hola, si estás aquí, probablemente eres un desarrollador de Node.js que busca optimizar sus funciones Lambda para la carga de trabajo actual que se está ejecutando en AWS. O tal vez solo tienes curiosidad y quieres entender cómo funciona Lambda y cómo puedes exprimir todas las mejores prácticas en el rendimiento de tu Lambda. En cualquier caso, te tengo cubierto.

Así que hoy, voy a cubrir bastantes ideas sobre cómo puedes optimizar tus cargas de trabajo usando funciones Lambda. Pero además, no quería proporcionar solo ideas abstractas. Solo quiero mostrarte cuánto puedes realmente exprimir. Mi nombre es Luca. Soy un especialista en serverless. Trabajo para AWS y estoy basado en Londres. Así que sin más preámbulos, vamos a sumergirnos, porque tenemos mucho terreno que cubrir.

Así que primero que todo, vamos a cubrir cuál es el área en la que realmente puedes optimizar tus funciones Lambda. Más adelante, comenzamos a ver, digamos, una API común que puedes construir usando Lambda. Además, vamos a ver qué podemos mejorar. Y finalmente, vamos a encontrar la solución optimizada donde realmente tenemos la información que se necesita para realmente optimizar profundamente lo que estás construyendo.

Bien, así que comencemos donde puedes optimizar tu función Lambda. Hay dos áreas en las que puedes optimizar en gran medida tu función Lambda. Esto es como un diagrama de secuencia que puedes encontrar en la documentación de AWS, donde como puedes ver, puedes ver que el ciclo de vida de una función Lambda cuando creamos un sandbox. Las dos áreas que son realmente pesadas y clave para la optimización son la fase de inicialización, donde tu función Lambda está básicamente creando un sandbox. Y luego descargamos el código en esa etapa. Tenemos una fase de inicialización donde puedes cargar, por ejemplo, cosas específicas como, no sé, las claves para una base de datos o algunos parámetros del servicio de almacenamiento de parámetros o algo así. De lo contrario, puedes optimizar cuando se trata de la parte de ejecución en ambas áreas. Veremos algunas optimizaciones durante esta charla.

Bien, así que comencemos con una solución. Esto es algo clásico que puedes construir cuando estás creando una API con AWS y serverless. Así que como puedes ver aquí, tenemos un API gateway exponiendo nuestra API. Tenemos una función Lambda que depende de un montón de cosas como CloudWatch, el administrador de sistemas almacenamiento de parámetros para recuperar los parámetros necesarios para cargar. Estamos usando Aurora serverless en este caso, y por lo tanto estamos usando un proxy RDS que se encarga de manejar el pool de conexiones por nosotros y también los secretos. Así que no tienes que manejar esto, tu código Lambda, así que es solo una utilidad o un servicio que puedes usar junto con tu base de datos Postgres en este caso. Así que además, una cosa que quiero especificar es que muy a menudo he visto a clientes usando funciones Lambda con una de las dos arquitecturas que están disponibles, x86 en este caso. Veremos más adelante cómo podemos optimizar eso.

Así que una sugerencia que usualmente recomendamos es usar o obtener tus parámetros en la fase de inicialización. Así que luego los tienes almacenados dentro del sandbox y por lo tanto no tienes que obtenerlos para cada solicitud. Esa es una buena optimización porque básicamente reduces la verbosidad de tu función Lambda hacia nuestro servicio, otros servicios, y no podría ser que podría ser parámetro, podrían ser secretos, podrían ser algunas configuraciones que necesitas encontrar al principio que estarán junto al sandbox. Recuerda, el sandbox no está allí viviendo para siempre. Reclamamos el sandbox después de un tiempo y por lo tanto vas a tener un nuevo sandbox cuando sea necesario. Así que esa cantidad de tiempo que estás almacenando en memoria, estas cosas, no va a ser nuestra y por lo tanto estás seguro de asumir que tus secretos o tu parámetro serán obtenidos nuevamente después de un tiempo.

La otra cosa es que usualmente recomendamos minificar tu código por defecto cuando estás usando CDK o usando AWS SAM. Proporcionamos el empaquetador ESBuild y puedes empaquetar tu código sin ningún problema. Incluso extraemos para ti un montón de parámetros que puedes ajustar para usar ESBuild con CDK. Obviamente puedes incluso empaquetar por ti mismo usando, no sé, Terraform o lo que sea. Así que primero empaquetas y luego usas Terraform para desplegar. Así que esa es otra opción. Pero en este caso, tienes ESBuild que está disponible para ti.

La otra cosa es que en este caso, estoy usando ESM porque quiero usar top level await que es básicamente la capacidad que has visto antes para cargar un parámetro antes de que puedas aprovechar o básicamente llamar al manejador de tu función donde básicamente tu lógica de negocio reside. Por último, pero no menos importante, tenemos un montón de módulos que tenemos que, digamos, externalizar y no empaquetar como todas las power tools que vamos a ver en un segundo qué son. Por último, pero no menos importante, truco rápido, si estás usando AWS SDK como estamos haciendo en este ejemplo, siempre empaquétalo junto con tu código porque en ese caso, cuando estás empaquetando, es mucho más rápido leer desde la memoria que leer desde el disco. También ofrecemos para el runtime de Node.js la posibilidad de usar el que está disponible en el sandbox cuando estamos construyendo. Pero usualmente recomendamos empaquetar las bibliotecas del SDK junto con tu lógica de negocio para que sea más rápido de ejecutar. Así que la otra cosa que es bastante genial es power tools. Power tools es una biblioteca de código abierto que usamos para, digamos, encargarnos de la observabilidad de tus funciones Lambda. En este caso, manejamos como métricas, logs, trazador y trazas. Y una cosa que usualmente recomendamos es usar MIDI. Hay otra biblioteca de código abierto para inicializar todo esto. Como puedes ver, el fragmento de código está allí. MIDI es una gran biblioteca. Si no estás familiarizado con eso, te recomiendo encarecidamente que cuando uses funciones Lambda. La otra cosa es que power tools es bastante genial. Como dije, puedes usarlo, por ejemplo, en conjunto con X-Ray para crear segmentos. Si quieres entender qué tan rápida es una consulta o qué tan rápido es un algoritmo que has escrito dentro de tu función Lambda, puedes hacerlo fácilmente con este fragmento de código. O de lo contrario, puedes usarlos.

También puedes usar los curators para dentro de las clases con el fin de, digamos, agilizar estas cosas para que no tengas que crear segmentos. Y otra cosa es que simplemente creas un decorador diciendo que esto es un subconjunto destinado a que tomarás toda la función como un segmento para que puedas encontrar tu servicio de trazado distribuido que se llama X-Ray, cómo funciona y qué hace.

Ahora, como dije, hemos creado esta función Lambda. Obviamente, para optimizar, necesitamos tener una línea base. Y para hacer eso, estoy usando una metodología de prueba que básicamente utiliza artillery para pruebas de carga. Estoy usando un tipo diferente de prueba de 45 segundos, 50 segundos a dos minutos. Y luego estoy usando de cero a 20 usuarios virtuales y luego hasta 100 usuarios.

Bien, entonces aquí, otro truco cuando estás buscando inicios de código para entender cuántos inicios de código tuviste dentro de la API específica o cuando estás usando la función Lambda en general, hay un fragmento de una consulta que puedes usar dentro de CloudWatch que es este aquí. Puedes encontrarlo en este enlace aquí y recuperará cuántos inicios de código tienes para una función Lambda específica. Eso es muy útil, para ser honesto.

Así que comencemos con la primera prueba. La primera prueba es muy simple. Pasamos de 10 segundos de aumento a de cero a 20 solicitudes por segundo. Luego pasamos de 50 segundos, perdón, 50 solicitudes por segundo de una vez. Así que como un gran salto. Así que en el primer ejemplo, tuvimos 18 inicios de código. Eso es interesante, es digamos bastante normal, porque si comienzas a decir aumentar y tienes tu tiempo de ejecución de una función Lambda que toma más tiempo, vas a tener múltiples sandboxes que tienen que iniciarse. Ten en cuenta que no puedes comparar la cantidad de solicitudes por segundo y emparejar en el entorno de ejecución a sandboxes. ¿Por qué eso? Porque tal vez tu tiempo de respuesta es menor a un segundo, y por lo tanto ese sandbox específico puede manejar múltiples solicitudes. Por ejemplo, en este ejemplo, como puedes ver, llegamos a tener 50 usuarios virtuales y por lo tanto 50 solicitudes por segundo. Pero solo tuvimos 18 sandboxes. Aquí, el P99 es más de dos segundos. Esa es la otra cosa que necesitamos tener en cuenta. Y luego tratamos de ver más en detalle cómo estaban funcionando las cosas. Así que nos estamos enfocando en el tiempo de ejecución de una Lambda específica porque esa es la parte que realmente puedes ajustar, obviamente. Así que en este caso, tenemos nuestra ejecución, peor caso de inicio, inicio en frío. Eso es cuando iniciamos un sandbox y cargamos tu código y básicamente lo ejecutamos. Esto es 1.43 segundos. El mejor fue 1.21. Y luego cuando miramos el inicio en caliente, donde básicamente ya has hecho la inicialización, estamos reutilizando el sandbox para responder a una solicitud es 228 milisegundos y 167.

Lo que hacemos con eso en esta carga de trabajo es muy simple. Estamos literalmente consultando Postgres, recuperando, digamos, todos los datos específicos sobre los estadios, estadios de la NFL en los EE. UU. Y estamos enviando de vuelta la respuesta. Así que no estamos haciendo algo demasiado complicado.

Pero esos son los datos que vamos a tener en este caso. OK. Ahora, el otro punto interesante es la segunda prueba. Así que en este caso, comenzamos desde un inicio en frío y simplemente comenzamos con 50 solicitudes por segundo de inmediato. Como puedes ver, tenemos muchos más inicios en frío. Y también vamos a tener, digamos, un P99 que es más alto porque el sistema tiene que ponerse al día con todas las solicitudes simultáneas que están ocurriendo. Así que 50 solicitudes simultáneamente cada segundo durante 50 segundos está comenzando a, digamos, manejar mucha más carga. Obviamente, esos son datos que podrían ser más que suficientes para ti y tal vez no tienes SLA's fuertes.

Pero por el bien del argumento, quiero proporcionarte, digamos, lo que podrías hacer si comienzas a optimizar fuertemente tu función Lambda. Así que ahora cuando pienso en esta arquitectura, empiezo a pensar, OK, qué es lo que tenemos como estadios de la NFL. Los estadios de la NFL no van a cambiar cada segundo. Es algo que es lo suficientemente estable y tal vez no tengo un CDN y necesito, digamos, usar algún nivel de almacenamiento en caché que pueda estar dentro de mis funciones Lambda. En este caso, estaba pensando, OK, ¿por qué necesito cada vez hacer una consulta a Postgres para recibir exactamente lo mismo o aprovechar el índice de Postgres para devolver la respuesta? ¿Por qué no puedo usar simplemente Elastic Cache usando Redis en este caso y tener una base de datos en memoria para aplicar un patrón de cache aside? Y además, comencé a implementar otras cosas. Así que primero, cambio la arquitectura a ARM. ARM es un chipset propietario que llamamos Graviton. Y en este caso, estamos usando Graviton2, y te permite realmente ahorrar en dinero y rendimiento, especialmente si no tienes una biblioteca específica que dependa de x86. Y muy a menudo en Node, tenemos este tipo de cargas de trabajo que te permiten hacer eso. En segundo lugar, como dije, uso un patrón de cache aside y el patrón de cache aside en este caso es muy simple. Primero, dependo del caché. Verifico cuando el caché está habilitado. Si encuentro la respuesta que estoy buscando en el caché, obviamente configuro todo de manera que puedan eliminar el caché después de un cierto período de tiempo. Si recuerdo bien, en este ejemplo, uso 10 segundos. Y luego, si no encuentro nada, empiezo a realizar una consulta hacia Postgres.

Lo interesante de usar Elastic Cache es que se extiende a todos los entornos aislados. Por lo tanto, en cada entorno aislado, confiamos en el caché cálido. Imagina que tienes 10 entornos aislados, el primero es llamado. Así que crea su consulta performance a Postgres, almacena todo dentro de Redis. Y luego todos los demás entornos aislados, confiamos en el hecho de que Redis ya está cálido. Así que tienes un mejor rendimiento de serie, todos los entornos aislados que dependen de esos datos específicos. Eso es genial.

Lo otro es que, en ES Build, sí, tienes la minificación activada. Genial. Y lo teníamos en el ejemplo anterior, pero también puedes hacer tree shaking que antes no mostramos, porque muy a menudo la gente no sabe que puedes confiar en cualquier argumento que esté disponible en ES Build, pero no exponemos todo eso. Tree shaking es uno de ellos. Así que en tree shaking, necesitas ir a los argumentos y aplicar básicamente tree shaking igual a verdadero, y luego va a funcionar sin ningún problema. Eso es genial porque significa que podemos meter incluso menos código dentro de nuestro paquete. Y eso significa que habría un impacto directo dentro de nuestro inicio de código porque cuanto más pequeño es el código que necesitan buscar en caché y a través de la red, más rápido será mi inicio de código. Ahora, lo otro es que cuando estábamos construyendo nuestra primera implementación, pensábamos, OK, entonces tomemos la biblioteca más popular para consultar Postgres. Y lo que salió es SQLize. SQLize, si miras en NPM, es uno de los más populares, el más actualizado y así sucesivamente. Probablemente aquí es donde un desarrollador empezaría si están pensando, OK, entonces necesito consultar Postgres. ¿Dónde debería mirar? Empiezo por la biblioteca más popular. Sin embargo, cuando hago el paquete y uso tree shaking, todavía tengo 1.6. Eso era bastante, honestamente, para lo que hace. Y empecé a preguntarme, OK, ¿cuál es el problema? Desafortunadamente, SQLize no permite tree shaking. Por lo tanto, si me muevo a la segunda más famosa y había algo que era, digamos, que permite tree shaking, miro en Postgres.js y movemos a 40 kilobytes el tamaño de el mismo código, pero solo reemplazando la biblioteca que estaba usando para eso. Ahora aquí muestra 246 kilobytes porque agregué un montón de otras cosas, bibliotecas que estoy usando para Redis y así sucesivamente. Pero al final eran literalmente 40 kilobytes para hacer exactamente lo mismo sin usar un patrón de caché aparte. Eso es genial, para ser honesto. Así que ten en cuenta para revisar tus bibliotecas. Lo otro es que antes en la solución no optimizada, como la llamo, solo estábamos estimando el tamaño de la memoria para nuestra función Lambda. Como puedes ver aquí, especificamos 256 megabytes. Pero en realidad, por un costo similar, debería haber elegido 512 megabytes porque en ese caso, el tiempo de respuesta era más rápido.

Y esta es una herramienta que ofrecemos en código abierto llamada ajuste de potencia. Y lo que hace es básicamente probar tu función Lambda con diferentes configuraciones, configuraciones de memoria. Y eso puede decirnos y puedes elegir de este diagrama si quieres usarlo para optimizar el coste o el rendimiento. Eso es genial. Cuando empecé a hacer exactamente lo mismo en mi CI usando la versión optimizada encontré el punto óptimo alrededor de 512 megabytes, un gigabyte. Y ten en cuenta, más memoria no significa necesariamente que cuesta más porque pagas por el tiempo de ejecución. Y por lo tanto, significa que en este caso, si tengo más memoria, el tiempo de ejecución es menor. Y por lo tanto, gasto menos. Así que ten en cuenta que menos memoria no se traduce en menores costos. Podría ser que gastes más. Esta es una gran herramienta para probar esto.

Así que ahora cambiamos el tamaño de la memoria. Encontramos el punto óptimo correcto usando el ajuste de potencia. Genial. Y también puedes implementar obviamente tu CI CD si quieres. Lo otro que cambiamos es que antes estábamos llamando a los parámetros que necesitaba para instruir todo el, por ejemplo, no sé, banderas de futuro o lo que sea, que tengo que instruir dentro del código desde la fase de inicialización de la tienda de parámetros.

Pero también tengo otro enfoque usando una extensión que es básicamente un subproceso que vive junto a tu código de función Lambda que tiene acceso a la carpeta temporal y todas las demás cosas que están disponibles. Pero es un proceso que está ahí, vive dentro de este entorno de ejecución. Así que no dice compartir nada con ningún otro entorno de ejecución, pero puedo hacer puedo usar eso para aprovechar cosas que están disponibles, como observabilidad, por ejemplo, o en este caso, hay una fantástica extensión que se encarga de no sólo enviar la solicitud hacia tu tienda de parámetros o administrador de secretos, sino también almacenarla en caché localmente. Así que no tengo que realizar una solicitud de HTTP cada vez.

Así que en este caso, puedo configurar a través de un montón de variables de entorno, el TTL de la tienda de parámetros, y por lo tanto sé que cada 100 milisegundos, la caché será evitada y voy a realizar otra búsqueda desde una tienda de parámetros. Pero puedo ajustarlo de la manera que quiera y funciona fácilmente, muy fácilmente con la tienda de parámetros y el administrador de secretos. Así que realmente puedo exprimir bastantes milisegundos allí. Como puedes ver, hay bastantes parámetros y cómo llamas en este caso, a esta tienda de parámetros, pero a través de localhost. Así que la comunicación entre una extensión y mi tienda de parámetros que es o caché tienda de parámetros que están allí son literalmente de esta manera. Esto es genial porque obviamente sólo estoy comunicando de esta manera. Puedes llamar por HTTP, HTTPS, como quieras. Pero de nuevo, es una gran manera de hacer eso. Lo otro que necesitas tener en cuenta, necesitas pasar el token de sesión de AWS que está disponible en cada función lambda para realizar esta charla dentro del encabezado. Eso es, como puedes ver, en la parte inferior de este fragmento de código.

Pero aparte de eso, esa idea de usar un subproceso para obtener estos data se encarga del caché y TTL y desalojo y todo es genial porque descarga mucho de tráfico que va hacia otro servicio. Así que gran cosa.

Entonces, cuando comenzamos a hacer la misma prueba y avanzamos con pruebas similares, hicimos como un aumento gradual de cero a 10 solicitudes por segundo, luego sostenido a 50 solicitudes por segundo, nos movimos con este código optimizado a nueve inicios de llamada. Así que absolutamente genial. Así que tenemos un número de llamadas. Pero además, mira el P99. P99 al principio era de más de dos segundos. Ahora ya no.

Y cuando avanzo aún más y empiezo a tener en cambio, digamos diferentes métricas para el inicio de la llamada, miramos eso y seleccionamos 794, 800 milisegundos, OK, mucho menos de lo que era antes en el peor inicio de llamada e incluso mejor, medio segundo, más o menos en el mejor inicio de llamada. Pero mira el tiempo de ejecución cuando esas API están calientes. Nos movimos a 73 milisegundos en el peor, pero el mejor fue de seis milisegundos.

Ahora tuve varios de ellos cuando estaba haciendo esta testing que estaba alrededor de seis, siete milisegundos. Estaba oscilando entre estos números. Pero la belleza de este enfoque es que realmente puedes exprimir. Ahora, es por eso que tienes mucho menos código, porque puedes exprimir mucho más respuesta en un segundo porque solo toma seis milisegundos obtener la respuesta. Así que obviamente, cuanto más rápido, mejor. Así que pagas menos. Lo otro genial de esto es que si piensas en eso, si tienes una solicitud múltiple, hemos creado una caja de arena. Tenemos por defecto, el límite de concurrency de mil es un límite suave que puedes aumentar. Solo pregunta a tu arquitecto de soluciones en AWS o abre un ticket con el soporte y puedes aumentar el límite de tu función lambda. Así que eso es una buena pista. Ese es solo un límite suave.

OK, entonces si tienes un tiempo de respuesta de 100 milisegundos para una caja de arena, significa que tienes 10 TPS por caja de arena. Pero si lo preguntara, ¿cuántos tengo, dirías que lo duplica? No realmente. Hay otra cosa en la que necesitas pensar porque, ya sabes, tenemos este enfoque de usar cajas de arena y estos viven junto con otros obviamente clientes. Garantizamos que tienes al menos 10 solicitudes por segundo por caja de arena. Puedo garantizarte que cuando probé eso, estaba superando fácilmente las 10 con este enfoque porque estaba, digamos, teniendo un entorno de ejecución muy rápido. Pero eso significa obviamente que si no eres capaz de exprimir en menos de 100 milisegundos, entonces probablemente necesitas pensar en que vas a manejar aproximadamente 10 TPS.

Obviamente, este es como el número garantizado que está disponible en la documentation. Pero de nuevo, es absolutamente genial porque podemos hacer mucho más con esto. Así que ahora en la prueba dos, simplemente comenzamos a correr y alcanzamos 50 TPS de una vez. Como puedes ver aquí, el código comienza en nueve porque fuimos muy rápidos en el tiempo de respuesta. Y también quiero mostrarte un punto de data con y sin caché. Creé una especie de bandera de función que me permitía activar o desactivar la caché de forma remota. Y como puedes ver, la caché puede jugar un papel muy importante aquí porque nos movemos de 124 milisegundos en la versión optimizada sin caché a 39, así que 40 milisegundos con caché. Ese es otro gran punto de data que te muestra que probablemente a veces usar un poco de caché porque no todos los data tienen que ser en tiempo real puede realmente tener un gran beneficio para tu SLA y tu performance de APIs.

OK, lo que hemos visto hasta ahora en esta charla es que movemos tu inicio de código desde un 56 por ciento de mejoras sin ningún problema y un 95 por ciento del inicio en caliente. Esos son grandes números. OK, esos son números realmente interesantes. Así que realmente aplicar pequeñas optimizaciones aquí y allá tienen como prácticas y herramientas como power tuning y otras cosas realmente harán un impacto dentro de tus funciones lambda. Ahora, los puntos clave. En primer lugar, elige tu biblioteca sabiamente porque si no son remodelables, estás perdiendo la posibilidad de optimizar tus cargas de trabajo, especialmente para los inicios en frío. Usa caché donde sea posible. Podría ser en memoria. No tienes que configurar la función lambda en memoria cada vez. No necesitas usar redis cada vez. Podría ser que almacenes alguna información dentro de la carpeta temporal que es accesible dentro de tu función lambda. Podría ser que tengas, digamos, una extensión que está almacenando en caché tus data como hemos visto con el almacenamiento de parámetros. Así que recuerda, hay muchas formas en que puedes optimizar tu código. Piensa en cómo se comporta. ¿Cuáles son los comportamientos que son aceptables para tu negocio e intenta optimizar en ese caso? La extensión puede ser tu mejor amiga. Obviamente, podrías pagar un poco en el inicio en frío, pero luego a largo plazo para el inicio en caliente, tendrás mucho menos sobrecarga y latencia. Y ten en cuenta, si optimizas mucho tu código, no hay forma de que vayas a tener muchos inicios en frío. Así que tu P99 se verá genial. Por último, pero no menos importante, el tamaño del paquete importa. Así que si eliges sabiamente tu biblioteca y usas three shake y usas modificación, definitivamente tendrás un tamaño de paquete más pequeño, y eso significa que tendrás un mejor performance en el inicio en frío. Así que no olvides eso.

Si quieres deep dive en el ejemplo y probar tú mismo el código en la proporción básica, solo los resultados de lo que estaba haciendo. Puedes encontrar un artículo en este enlace donde hay un enlace al repositorio de GitHub. Está disponible en las muestras y puedes encontrar cómo funcionan las cosas y más detalles sobre el tamaño de la optimization que he discutido hoy. Así que muchas gracias por ver. Espero que disfrutes. Si tienes alguna pregunta, no dudes en contactarme en este correo electrónico y gracias de nuevo y disfruta el resto de la conferencia.