Optimización del rendimiento de AWS Lambda

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 aplicar todas las mejores prácticas para mejorar el rendimiento de tu Lambda. En cualquier caso, estoy aquí para ayudarte.

Hoy, voy a cubrir varias ideas sobre cómo puedes optimizar tus cargas de trabajo utilizando funciones Lambda. Pero además, no quiero proporcionar solo ideas abstractas. Quiero mostrarte cuánto puedes realmente exprimir. Mi nombre es Luca. Soy un especialista en sin servidor. Trabajo para AWS y estoy basado en Londres. Sin más preámbulos, vamos a sumergirnos, porque tenemos mucho por cubrir.

Primero que nada, vamos a cubrir dónde puedes optimizar realmente tus funciones Lambda. Más adelante, veremos, digamos, una API común que puedes construir utilizando Lambda. Además, vamos a ver qué podemos mejorar. Y finalmente, encontraremos la solución optimizada donde realmente tenemos la información necesaria para optimizar profundamente lo que estás construyendo.

OK, así que comencemos por dónde puedes optimizar tu función Lambda. Hay dos áreas en las que puedes optimizar en gran medida tu función Lambda. Este es como un diagrama de secuencia que puedes encontrar en la documentación de AWS, donde, como puedes ver, puedes ver 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 básicamente crea 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.

OK, así que comencemos con una solución. Esto es algo clásico que puedes construir cuando estás creando una API con AWS y sin servidor. Como puedes ver aquí, tenemos una puerta de enlace de API que expone nuestra API. Tenemos una función Lambda que depende de varias cosas como CloudWatch, el servicio de administrador de sistemas para recuperar los parámetros necesarios para cargar. Estamos utilizando Aurora sin servidor en este caso, por lo que estamos utilizando un proxy de RDS que se encarga de manejar el grupo de conexiones por nosotros y también los secretos. Entonces no tienes que manejar esto en tu código Lambda, es solo una utilidad o un servicio que puedes usar en conjunto con tu base de datos de Postgres en este caso. Además, una cosa que quiero especificar es que a menudo he visto a los clientes utilizando funciones Lambda con una de las dos arquitecturas disponibles, x86 en este caso. Veremos más adelante cómo podemos optimizar eso.

Entonces, una sugerencia que generalmente recomendamos es utilizar o obtener tus parámetros en la fase de inicialización. De esta manera, los tienes almacenados dentro del sandbox y, por lo tanto, no tienes que obtenerlos en cada solicitud individual. Esta es una buena optimización porque básicamente reduces la comunicación de tu función Lambda hacia nuestro servicio u otros servicios, y podría ser un parámetro, secretos o alguna configuración que necesites obtener al principio y que permanecerá junto al sandbox. Recuerda, el sandbox no está ahí para siempre. Recuperamos el sandbox después de un tiempo y, por lo tanto, tendrás un nuevo sandbox cuando sea necesario. Por lo tanto, el tiempo que almacenas en memoria estas cosas no será nuestro y, por lo tanto, puedes asumir de manera segura que tus secretos o parámetros se volverán a obtener después de un tiempo.

Lo otro que generalmente recomendamos es minimizar tu código de forma predeterminada cuando utilizas CDK o AWS SAM. Proporcionamos el bundler ESBuild y puedes agrupar tu código sin ningún problema. Incluso extraemos una serie de parámetros que puedes ajustar para usar ESBuild con CDK. Obviamente, también puedes agrupar por ti mismo utilizando, no sé, Terraform o lo que sea. Primero agrupas y luego usas Terraform para implementar. Esa es otra opción. Pero en este caso, tienes ESBuild disponible para ti.

Lo otro es que en este caso, estoy usando ESM porque quiero usar la espera de nivel superior que básicamente es la capacidad que has visto antes para cargar un parámetro antes de aprovechar o llamar básicamente el controlador de tu función donde se encuentra tu lógica empresarial. Por último, pero no menos importante, tenemos una serie de módulos que debemos, digamos, externalizar y no agrupar, como todas las herramientas de Power Tools que veremos en un momento qué son. Por último, pero no menos importante, un truco rápido, si estás utilizando el SDK de AWS como lo estamos haciendo en este ejemplo, siempre agrégalo junto con tu código porque en ese caso, cuando lo agrupas, es mucho más rápido leer desde la memoria que leer desde el disco. También ofrecemos para el tiempo de ejecución de Node.js la posibilidad de usar el que está disponible en el sandbox cuando estamos construyendo. Pero generalmente recomendamos agrupar las bibliotecas del SDK junto con tu lógica empresarial para que se ejecute más rápido. Lo otro que es bastante genial es Power Tools. Power Tools es una biblioteca de código abierto que utilizamos para, digamos, ocuparnos de la observabilidad de tus funciones Lambda. En este caso, manejamos métricas, registros, trazas y seguimiento. Y lo que generalmente recomendamos es usar MIDI. Hay otra biblioteca de código abierto para inicializar todo esto. Como puedes ver, el fragmento de código está ahí. MIDI es una biblioteca realmente genial. Si no estás familiarizado con ella, te recomiendo encarecidamente que la uses cuando utilices funciones de Lambda. Lo otro 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ápido 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 utilizar los curadores para las clases internas con el fin de, digamos, agilizar estas cosas para que no tengas que crear segmentos. Y otra cosa que puedes hacer es crear un decorador que indique que es un subconjunto que tomará la función completa como un segmento para que puedas encontrar tu servicio de seguimiento distribuido llamado X-Ray, cómo funciona y qué hace.

Ahora, como dije, hemos creado esta función Lambda. Obviamente, para optimizarla, necesitamos tener una referencia. Y para hacer eso, estoy utilizando una metodología de pruebas que básicamente utiliza Artillery para las pruebas de carga. Estoy utilizando diferentes tipos de pruebas de 45 segundos, 50 segundos hasta dos minutos. Y luego estoy utilizando dos desde cero hasta 20 usuarios virtuales y luego hasta 100 usuarios.

OK, entonces aquí, otro truco cuando estás buscando los inicios de código para entender cuántos inicios de código tuviste dentro de la API específica o cuando estás utilizando una función Lambda en general, hay un fragmento de una consulta que puedes utilizar en CloudWatch que es este. Puedes encontrarlo en este enlace 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 sencilla. Pasamos de una fase de rampa de 10 segundos de cero a 20 solicitudes por segundo. Luego pasamos de 50 segundos, lo siento, 50 solicitudes por segundo de una vez. Como un gran aumento. Entonces, en el primer ejemplo, tuvimos 18 inicios de código. Eso es interesante, es digamos bastante normal, porque si comienzas a aumentar y el tiempo de ejecución de una función Lambda tarda más, vas a tener múltiples sandboxes que deben iniciarse. Ten en cuenta que no puedes comparar la cantidad de solicitudes por segundo y hacer coincidir con el entorno de ejecución con las sandboxes. ¿Por qué? Porque tal vez tu tiempo de respuesta es inferior a un segundo y, por lo tanto, esa sandbox específica 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 supera los dos segundos. Eso es otra cosa que debemos tener en cuenta. Y luego intentamos ver más en detalle cómo funcionaban las cosas. Nos estamos enfocando en el tiempo de ejecución de una función Lambda específica porque esa es la parte que realmente puedes ajustar, obviamente. En este caso, tenemos nuestra ejecución, el peor caso de inicio, inicio en frío. Eso es cuando iniciamos una sandbox y cargamos tu código y básicamente lo ejecutamos. Esto es de 1.43 segundos. El mejor fue de 1.21. Y luego, cuando miramos el inicio en caliente, donde básicamente ya has hecho la inicialización, estamos reutilizando la sandbox para responder a una solicitud, es de 228 milisegundos y 167.

Lo que hacemos en esta carga de trabajo es muy simple. Simplemente consultamos Postgres, recuperamos, digamos, todos los data específicos de los estadios de la NFL en Estados Unidos. Y enviamos la respuesta de vuelta. No estamos haciendo algo demasiado complicado. Pero esos son los data que tendremos en este caso.

OK. Ahora, el otro punto interesante es la segunda prueba. En este caso, comenzamos desde un inicio en frío y nos encontramos con 50 solicitudes por segundo de inmediato. Como puedes ver, tenemos muchos más inicios en frío. Y también tendremos, digamos, un P99 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áneas cada segundo durante 50 segundos comienzan a manejar una carga mucho mayor. Obviamente, esos son data que pueden ser más que suficientes para ti y tal vez no tengas SLA's fuertes. Pero por el bien del argumento, quiero mostrarte, digamos, lo que podrías hacer si comienzas a optimizar en gran medida tu función Lambda.

Ahora, cuando pienso en esta architecture, comienzo a pensar, OK, ¿qué pasa si tenemos estadios de la NFL? Los estadios de la NFL no van a cambiar cada segundo. Es algo lo suficientemente estable y tal vez no tengo una CDN y necesito, digamos, utilizar algún nivel de caché dentro de mis funciones Lambda. En este caso, estaba pensando, ¿por qué necesito hacer una consulta a Postgres cada vez para recibir exactamente lo mismo o aprovechar el índice de Postgres para devolver la respuesta? ¿Por qué no puedo simplemente usar Elastic Cache con Redis en este caso y tener una base de datos en memoria para aplicar un patrón de caché aparte? Y además, comencé a implementar otras cosas. En primer lugar, cambié la architecture a ARM. ARM es un conjunto de chips propietario que llamamos Graviton. Y en este caso, estamos utilizando Graviton2, lo que te permite ahorrar dinero y performance, 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, utilizo un patrón de caché aparte y el patrón de caché aparte en este caso es muy simple. Primero, confío en la caché. Verifico si la caché está habilitada. Si encuentro la respuesta que estoy buscando en la caché, obviamente configuro todo de manera que se pueda eliminar la 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, comienzo a realizar una consulta hacia Postgres. Pero en este caso, lo hago mucho menos.

Lo otro genial de utilizar Elastic Cache es que se extiende a todos los entornos. Por lo tanto, en cada uno de los entornos, confiamos en la caché caliente. Imagina que tienes 10 entornos, cuando se llama al primero. Este crea su consulta de performance a Postgres, almacena todo en Redis. Y luego, todos los demás entornos confían en el hecho de que Redis ya está caliente. Por lo tanto, obtienes un mejor rendimiento de forma predeterminada en todos los entornos que dependen de esos datos específicos. Eso es genial.

Lo otro es, en ES Build, sí, tienes la minimización activada. Genial. Y en el ejemplo anterior, pero también puedes hacer eliminación de árboles, que antes no mostramos, porque a menudo las personas no saben que pueden confiar en cualquier argumento que esté disponible en ES Build, pero no exponemos todo eso. La eliminación de árboles es uno de ellos. Entonces, en la eliminación de árboles, debes ir a los argumentos y aplicar básicamente la eliminación de árboles igual a verdadero, y luego funcionará sin ningún problema. Eso es genial porque significa que podemos incluir aún menos código en nuestro paquete. Y eso significa que habrá un impacto directo en el inicio de nuestro código porque cuanto más pequeño sea el código, menos necesitará buscar en la caché y a través de la red, más rápido será el inicio de mi código. Ahora, lo otro es que cuando estamos construyendo nuestra primera implementación, estábamos pensando, OK, así que tomemos la biblioteca más popular para consultar Postgres. Y lo que salió fue SQLize. SQLize, si buscas en NPM, es uno de los más populares, el más actualizado y así sucesivamente. Probablemente aquí es donde un desarrollador comenzaría si está pensando, OK, así que necesito consultar Postgres. ¿Dónde debería buscar? Comienzo por la biblioteca más popular. Sin embargo, cuando lo empaqueto y utilizo la eliminación de árboles, todavía tengo 1.6. Eso fue bastante, honestamente, para lo que hace. Y comencé a preguntarme, OK, ¿cuál es el problema? Desafortunadamente, SQLize no es compatible con la eliminación de árboles. Por lo tanto, si paso a la segunda más famosa y hay algo que es, digamos, compatible con la eliminación de árboles, miro a Postgres.js y reducimos a 40 kilobytes el tamaño del mismo código, pero simplemente reemplazando la biblioteca que estaba usando para eso. Ahora aquí muestra 246 kilobytes porque agregué muchas otras cosas, bibliotecas que estoy usando para Redis, etc. 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 revisar tus bibliotecas. Lo otro es que antes, en la solución no optimizada, como la llamo, simplemente estimábamos el tamaño de memoria para nuestra función Lambda. Como puedes ver aquí, especificamos 256 megabytes. Pero en realidad, por costos similares, 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 de código abierto llamada ajuste de potencia. Y lo que hace básicamente es probar tu función Lambda con diferentes configuraciones, configuración de memoria. Y eso nos puede decir a ti y puedes elegir a partir de este diagrama si quieres optimizar para costo o para rendimiento. Eso es genial. Cuando comencé a hacer exactamente lo mismo en mi CI utilizando 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 cueste más porque se paga 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 una menor memoria no se traduce en menores costos. Puede ser que gastes más. Esta es una gran herramienta para probar esto.

Ahora cambiamos el tamaño de memoria. Encontramos el punto óptimo correcto utilizando el ajuste de potencia. Muy bien. Y también puedes implementarlo obviamente en tu CI CD si quieres. Lo otro que cambiamos es que antes estábamos llamando a los parámetros que necesitaba para instruir todo, por ejemplo, no sé, futuras banderas o lo que sea, que tenía que instruir dentro del código desde la fase de inicialización del almacén de parámetros.

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

Entonces, en este caso, puedo configurar a través de un montón de variables de entorno, el TTL de almacén de parámetros, y por lo tanto, sé que cada 100 milisegundos, la caché se eliminará y realizaré otra búsqueda desde el almacén de parámetros. Pero puedo ajustarlo de la manera que desee y funciona fácilmente, muy fácilmente con el almacén de parámetros y el administrador de secretos. Por lo tanto, realmente puedo ahorrar una buena cantidad de milisegundos allí. Como puedes ver, hay bastantes parámetros y cómo llamas en este caso, a este almacén de parámetros, pero a través de localhost. La comunicación entre una extensión y mi almacén de parámetros o almacén de caché está literalmente de esta manera. Esto es genial porque obviamente estoy comunicándome de esta manera. Puedes llamar por HTTP, HTTPS, como prefieras. Pero nuevamente, es una excelente manera de hacerlo. Lo otro que debes tener en cuenta es que debes pasar el token de sesión de AWS que está disponible en cada función lambda para realizar esta comunicación dentro del encabezado. Como puedes ver, en la parte inferior de este fragmento de código.

Pero aparte de eso, la idea de usar un subproceso para obtener estos data se encarga de la caché y el TTL y la eliminación y todo es genial porque descarga mucho tráfico que se dirige hacia otro servicio. Así que es genial.

Entonces, cuando comenzamos a hacer la misma prueba y nos movemos con pruebas similares, hicimos una rampa desde cero hasta 10 solicitudes por segundo, luego se mantuvo en 50 solicitudes por segundo, nos movimos con este code optimizado a nueve inicios de llamadas. Así que absolutamente genial. Tenemos un número de llamadas. Pero además, mira el P99. Al principio, el P99 era de más de dos segundos. Ahora ya no lo es.

Y cuando avanzo aún más y comienzo a tener, digamos, diferentes métricas para el inicio de llamada, miramos eso y seleccionamos 794, 800 milisegundos, OK, mucho menos que antes en el peor inicio de llamada y aún mejor, medio segundo, más o menos en el mejor inicio de llamada. Pero mira el tiempo de ejecución cuando esas APIs están en caliente. Pasamos a 73 milisegundos en el peor caso, pero el mejor caso fue de seis milisegundos.

Ahora tuve varios de ellos cuando estaba haciendo esta testing que estaban alrededor de seis, siete milisegundos. Oscilaba entre estos números. Pero lo bueno de este enfoque es que realmente puedes exprimir. Ahora, por eso tienes mucho menos code, porque puedes exprimir muchas más respuestas en un segundo porque solo se tarda seis milisegundos en obtener la respuesta. Así que obviamente, cuanto más rápido, mejor. Pagas menos. Lo otro genial de esto es que si piensas en eso, si tienes una solicitud múltiple, creamos un sandbox. Tenemos por defecto un límite de concurrencia de mil, que es un límite suave que puedes aumentar. Solo pregúntale 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. Es solo un límite suave que uno no tiene.

OK, así que si tienes un tiempo de respuesta de 100 milisegundos para un sandbox, significa que tienes 10 TPS por sandbox. Pero si te pregunto cuántos tienes, dirías que lo duplicas. No realmente. Hay otra cosa en la que debes pensar porque, ya sabes, tenemos este enfoque de usar sandbox y convivir junto con otros obviamente clientes. Garantizamos que tienes al menos 10 solicitudes por segundo por sandbox. Te puedo garantizar que cuando lo probé, superé fácilmente las 10 con este enfoque porque tenía, digamos, un entorno de ejecución muy rápido. Pero eso significa obviamente que si no eres capaz de exprimir menos de 100 milisegundos, entonces probablemente necesitas pensar que vas a manejar aproximadamente 10 TPS.

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

OK, hasta ahora en esta charla hemos logrado mejorar el inicio de tu code en un 56 por ciento sin ningún problema y un 95 por ciento en el inicio en caliente. Esos son números grandes. OK, son números realmente interesantes. Así que aplicar pequeñas optimizaciones aquí y allá, como prácticas y herramientas como la afinación de energía y otras cosas, realmente tendrán un impacto en tus funciones lambda. Ahora, los puntos clave. En primer lugar, elige tus bibliotecas sabiamente porque si no son adaptables, estás perdiendo la posibilidad de optimizar tus cargas de trabajo, especialmente para los inicios en frío. Utiliza la caché cuando sea posible. Puede ser en memoria. No tienes que establecer la función lambda en memoria. No necesitas usar Redis todo el tiempo. Puede ser que almacenes información en la carpeta temporal que es accesible dentro de tu función lambda. Puede 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 las que puedes optimizar tu code. Piensa en cómo se comporta. ¿Cuáles son los comportamientos aceptables para tu negocio y trata de optimizar en ese caso? Las extensiones pueden ser tu mejor amiga. Obviamente, es posible que pagues 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 que si optimizas en gran medida tu code, no tendrás 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 el árbol de sacudidas y las modificaciones, definitivamente tendrás un tamaño de paquete más pequeño, y eso significa que tendrás un mejor rendimiento en el inicio en frío. Así que no lo olvides.

Si quieres profundizar en el ejemplo y probar tú mismo el code a la tasa 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 los ejemplos y puedes encontrar cómo funcionan las cosas y más detalles sobre el tamaño de la optimización que he discutido hoy. Así que muchas gracias por ver. Espero que lo disfrutes. Si tienes alguna pregunta, no dudes en contactarme en este correo electrónico y gracias de nuevo y disfruta del resto de la conferencia.