La Necesidad de Velocidad: Cómo la Nueva JS Runtime de AWS Está Redefiniendo la Latencia en Serverless

Hola a todos. En el mundo actual de las aplicaciones modernas, la capacidad de respuesta rápida es esencial. Los desarrolladores esperan una excelente experiencia donde cada acción desencadena una respuesta inmediata. Los servicios sin servidor como AWS Lambda permiten a los desarrolladores construir aplicaciones modernas sin la necesidad de aprovisionar servidores ni infraestructura adicional.

Sin embargo, estos servicios a veces introducen o agregan un poco de latencia al aprovisionar un nuevo entorno de ejecución para ejecutar el código del cliente. Esto a veces se conoce como inicio en frío. Y aunque las métricas de producción muestran que los inicios en frío ocurren típicamente en menos del 1% de todas las invocaciones, y a veces incluso menos, aún puede ser un poco destructivo para la experiencia de usuario fluida que estamos buscando.

¿Qué tal si les dijera que hay una solución para los inicios en frío? ¿Qué tal si les dijera que pueden ejecutar aplicaciones JavaScript en AWS Lambda con inicios en frío prácticamente despreciables?

Mi nombre es Richard Davison. Trabajo como arquitecto de soluciones asociado, ayudando a los socios a modernizar sus aplicaciones en AWS utilizando tecnologías sin servidor y de contenedores. Y estoy aquí para hablar sobre el proyecto que he estado construyendo durante algún tiempo llamado LLRT y cómo redefine la latencia sin servidor.

Entonces, LLRT es la abreviatura de tiempo de ejecución de baja latencia. Y es un nuevo tiempo de ejecución de JavaScript construido desde cero para abordar la creciente demanda de aplicaciones sin servidor rápidas y eficientes. ¿Por qué deberíamos construir un nuevo tiempo de ejecución de JavaScript? Entonces, JavaScript es una de las formas más populares de construir y ejecutar aplicaciones sin servidor. También a menudo ofrece consistencia de pila completa, lo que significa que la parte trasera y la parte frontal de su aplicación pueden compartir un lenguaje unificado, lo cual es una ventaja adicional. JavaScript también ofrece un ecosistema de paquetes rico y una gran comunidad que puede ayudar a acelerar el desarrollo de sus aplicaciones. Además, JavaScript es reconocido por ser bastante amigable para el usuario, lo que lo hace fácil de aprender, fácil de leer y fácil de escribir. También es un estándar abierto conocido como ECMAScript, que ha sido implementado por diferentes motores, lo cual es algo que discutiremos más adelante en esta presentación.

Entonces, ¿cómo es LLRT diferente de Node, Abun y Ordino? ¿Qué justifica la introducción de otro tiempo de ejecución de JavaScript a la luz de estas alternativas existentes? Entonces, Node, Abun y Ordino representan tiempos de ejecución de JavaScript altamente competentes. Son extremadamente capaces y tienen un rendimiento muy bueno. Sin embargo, están diseñados pensando en aplicaciones de propósito general, y estos tiempos de ejecución no fueron diseñados específicamente para las demandas de los entornos sin servidor, que a menudo se caracterizan por instancias de tiempo de ejecución de corta duración con recursos limitados. También dependen de un compilador justo a tiempo, un componente tecnológico muy sofisticado que permite compilar y optimizar dinámicamente el código de JavaScript durante la ejecución. Si bien un compilador justo a tiempo ofrece ventajas de rendimiento sustanciales a largo plazo, a menudo conlleva una sobrecarga computacional y de memoria, especialmente cuando se hace con recursos limitados.

En contraste, LLRT se distingue por no incorporar un compilador justo a tiempo, lo cual es una decisión estratégica que ofrece dos ventajas significativas. La primera es que, nuevamente, un compilador justo a tiempo es un componente tecnológico notablemente sofisticado que introduce una mayor complejidad del sistema y contribuye sustancialmente al tamaño total del tiempo de ejecución. Y sin esa sobrecarga de JIT, LLRT conserva tanto los recursos de CPU como de memoria que se pueden asignar de manera más efectiva para ejecutar el código que se ejecuta dentro de su función de Lambda y, por lo tanto, reducir los tiempos de inicio de la aplicación. Entonces, nuevamente, un compilador justo a tiempo ofrecería un aumento de rendimiento sustancial a largo plazo, mientras que la falta de un compilador justo a tiempo puede ofrecer beneficios de inicio.

LLRT se construye desde cero con un enfoque principal, el rendimiento en AWS Lambda. Viene con inicios en frío prácticamente despreciables, y la duración del inicio en frío es inferior a 100 milisegundos para muchos casos de uso y tareas, incluso al realizar llamadas a la versión 3 del SDK de AWS. Utiliza un estándar bastante reciente de ECMAScript, ECMAScript 2020, con muchas API de Node.js. Y el objetivo de esto es hacer que sea una migración lo más simple posible desde Node.

Viene con lo que llamamos baterías incluidas. Por lo tanto, LLRT y el binario en sí mismo ya tienen algunos SDK de AWS v3 incorporados, por lo que no es necesario enviar ni proporcionar esos, lo que también tiene beneficios de rendimiento. Y hablando de beneficios de rendimiento, también hay un beneficio de costos. Un rendimiento más estable, principalmente debido a la falta de un compilador justo a tiempo, puede llevar a una mejora de rendimiento de hasta 2 veces en comparación con otros tiempos de ejecución de JavaScript, y un ahorro de costos del 2x, incluso para inicios en caliente.

Entonces, ¿qué hace que esto sea tan rápido? ¿Qué hay debajo del capó? Utiliza un motor JavaScript diferente en comparación con Dino o BUN. Dino y BUN utilizan motores llamados v8 y JavaScript core. v8 proviene del navegador Chrome y del equipo de Chrome. El equipo de Chrome ha creado un motor JavaScript para su navegador llamado v8, mientras que BUN utiliza un motor llamado JavaScript core que se ha divergido de Safari. Pero Quick.js, por otro lado, es un motor muy ligero. Es muy capaz, pero también es muy ligero. El motor en sí, cuando se compila, tiene menos de un megabyte. Si lo comparamos con JavaScript core y v8, que tienen más de 50 megabytes dentro de Node y BUN. LLRT también está construido en Rust, utilizando el tiempo de ejecución asincrónico de Tokyo. Muchas de sus API implementadas dentro del tiempo de ejecución siguen las especificaciones de Node.js y están implementadas en Rust. El ejecutable en sí tiene menos de tres megabytes, e incluye el SDK de AWS.

Creo que es hora de echar un vistazo a una demostración rápida para ver cómo funciona en acción. Aquí estoy dentro de la consola de AWS Lambda. En este ejemplo, he importado el cliente DynamoDB y el cliente de documentos DynamoDB para poner algunos eventos que llegan a AWS Lambda en DynamoDB. También agrego una ID aleatoria y convierto el evento en una cadena, y simplemente devuelvo un código de estado 200 y OK. Ahora ejecutemos esto utilizando el tiempo de ejecución regular de Node.js 20. Esta vez vemos un inicio en frío. Vamos a la pestaña de pruebas aquí y hacemos clic en el botón de prueba. Ahora se ha ejecutado. Si examinamos los registros de ejecución aquí, podemos ver que Node.js se ejecutó con una duración de 988 milisegundos y una duración de inicio de 366 milisegundos. En total, esto es aproximadamente un poco más de 1.2, 1.3 segundos en realidad. Y consumimos casi 88 megabytes de memoria mientras lo hacíamos. Ahora voy a volver al código. Desplácese hacia abajo hasta la configuración de tiempo de ejecución, haga clic en editar y cambie a Amazon Linux 2023. Siempre solo tiempo de ejecución. Guardar.

Y ahora vamos a ejecutarlo con LLRT. Como puedes ver, esto fue casi instantáneo. Y al examinar los registros de ejecución, podemos ver que ahora tenemos una duración de 29 milisegundos y una duración de inicio de 38. Lo que significa que tenemos una duración total de 69 milisegundos. Así que 69 milisegundos frente a 1,300 o ligeramente por encima para Node.js. Mientras lo hacíamos, solo consumimos alrededor de 20 megabytes de memoria.

Y observa que si ejecuto el code nuevamente, para inicios en caliente, también es muy rápido. Aquí tenemos 45 milisegundos, 16, 13, 14, 9, etc. Por lo tanto, tampoco hay sacrificio en el rendimiento en caliente. Y de hecho, puede ser hasta dos veces menor que el equivalente en Node.js. Principalmente debido a la falta de un compilador justo a tiempo y un motor más simple para menos complejidad. También observa que no cambié ni una sola línea de code. Lo que hice simplemente fue cambiar la configuración de tiempo de ejecución aquí. Y he preparado esta demostración colocando el binario de inicio de LLRT aquí. Así que simplemente descargué LLRT, renombré el binario de inicio y lo puse junto con mi muestra de code aquí.

De acuerdo, volvamos a la presentación. Entonces, ¿cuáles son los buenos casos de uso para LLRT? Los buenos casos de uso pueden ser aplicaciones críticas en cuanto a latencia, funciones de alto volumen, transformación de datos e integración con diferentes servicios de AWS. Incluso se pueden ejecutar aplicaciones de React renderizadas en el servidor con LLRT. También aplicaciones que consisten en mucho código de enlace. Lo que quiero decir con esto es que son aplicaciones que se integran con otras fuentes de terceros o servicios de AWS, que actúan como enlace entre un servicio y otro.

Cuando no es bueno usar LLRT es cuando se realizan simulaciones o se manejan cientos o miles de iteraciones en bucles. O cuando se realizan simulaciones de Monte Carlo o se transfieren objetos grandes o conjuntos de datos grandes de decenas o incluso cientos de megabytes. Aquí es donde el compilador justo a tiempo realmente destaca, lo cual es una característica que no está disponible en LLRT. Pero lo mejor en este momento es medir y ver. Estoy bastante seguro de que muchos de sus casos de uso se beneficiarían al ejecutar LLRT.

Y nuevamente, ¿cómo puede ser tan rápido? No tiene JIT y el SDK de AWS está optimizado específicamente para Lambda. Esto significa que hemos eliminado algunas de las complejidades que implica el SDK de AWS, como la creación de objetos de caché. Convertimos el SDK a código de bytes Quick JS y aprovechamos otras técnicas que optimizan los inicios de código en Lambda. Por ejemplo, realizamos la mayor cantidad de trabajo posible durante la inicialización de los tiempos de ejecución de Lambda, ya que tienen un impulso de CPU. También escribimos la mayor parte de nuestro código en Rust. De hecho, tenemos una política que dice que se debe escribir la mayor cantidad posible en Rust. Por lo tanto, cuanto más código podamos mover de JavaScript a Rust, habrá un beneficio en el rendimiento. En contraste con Node.js, casi todas sus API están escritas en JavaScript y dependen en gran medida del compilador justo a tiempo del motor V8 para lograr un gran rendimiento. Dado que carecemos de esta capacidad y escribimos la mayor parte del código en Rust, obtenemos beneficios de rendimiento al tiempo que mantenemos el tamaño bajo y obtenemos un beneficio de rendimiento instantáneo sin tener que depender del perfilador JIT para optimizar el código de tareas de larga duración. Básicamente, todo lo que se utiliza en LLRT está escrito en Rust. La consola, los temporizadores, la criptografía, el hash, todo eso está escrito en Rust. Solo hay una pequeña capa de JavaScript encima de eso. Y, por supuesto, su código también se ejecutará en JavaScript. Y también es muy liviano. Solo ocupa unos pocos megabytes. Intentamos mantenerlo lo más liviano posible, minimizando las dependencias pero también minimizando la complejidad.

Entonces, ¿cuál es el truco? Esta es una matriz de compatibilidad de alto nivel. Aquí puedes ver un signo de exclamación y algunas marcas de verificación. Obviamente, debe haber algún tipo de compensación para lograr este nivel de rendimiento. Una de las compensaciones es que no se admiten todas las API de Node.js, pero admitimos algunas de ellas. Y tampoco están completamente admitidas. Aunque hay una marca de verificación aquí, no significa que admita, por ejemplo, el módulo FS completo o el módulo FS promises. Está parcialmente admitido. Pero estamos desarrollando constantemente este tiempo de ejecución y está disponible como versión beta hoy para que puedas probarlo. Más adelante en esta presentación, proporcionaré enlaces a ello.

¿Y cómo se usa? Como viste en la demostración, simplemente descargué la última versión desde la página de GitHub, que es github.com/AWSLabs/LLRT. Agregué el ejecutable de inicio junto con tu código. También puedo usar una capa, si eso es lo que prefieres, o empaquetarlo como una imagen de contenedor. Luego selecciono tiempo de ejecución personalizado en Amazon Linux 3 dentro de Lambda como mi opción de tiempo de ejecución. LLRT se ejecuta en instancias ARM o x86-64. Hay una ligera ventaja al usar ARM debido a los ahorros de costos y también un rendimiento ligeramente mejor. Por lo tanto, esto es algo que recomiendo.

Ahora, echemos un vistazo a algunos datos de referencia. Como vimos en la demostración, hicimos una muestra muy rápida, donde vimos que los beneficios de inicio en frío y en caliente eran significativos en comparación con Node.js. Esta diapositiva muestra algunos beneficios de inicio cuando se ejecuta en mi máquina local. Como puedes ver aquí en la demostración, resaltado por la flecha, LLRT se inicia casi seis veces más rápido que Node.js. Esta es una demostración bastante aburrida donde básicamente hacemos una impresión, pero muestra la ligereza del motor, donde no tiene que cargar muchos recursos para iniciar. Por lo tanto, puede ser incluso más rápido que Dino y Bunn. Pero ten en cuenta que gran parte de esta velocidad proviene de la simplicidad. Es muy fácil introducir un nuevo tiempo de ejecución con una API limitada y decir que es más rápido, pero esta es una de las compensaciones, ¿verdad? Lo hacemos muy liviano, por lo tanto, naturalmente es más rápido.

Ahora echemos un vistazo rápido a algunos números de rendimiento al ejecutar LLRT durante un período más largo. Nuevamente, esto se hace con un DynamoDB PUT. Es el mismo código de muestra que vimos en la demostración, pero ahora se ejecuta durante 32,000 invocaciones en ARM64 con 128 megabytes de memoria. Observa aquí que la latencia P99, lo que significa que el 99% de todas las invocaciones están por debajo de este número, tenemos 34 milisegundos para los inicios en caliente y 84 milisegundos para los inicios en frío. En comparación, tenemos el inicio en caliente más rápido posible que es solo 5.29 milisegundos y el inicio en frío más rápido posible que es 48.85 milisegundos. Si lo comparamos con Node.js 18, podemos ver que tenemos una latencia P99 de 164 para los inicios en caliente y 1,306 para los inicios en frío.

Para los tiempos más lentos y los tiempos más rápidos, tenemos 5.85 y 1,141 milisegundos para los inicios en frío. Esto significa que hay una mejora de rendimiento de 23 veces para esta demostración específica en los inicios en frío y una mejora de rendimiento de 15 veces para el peor caso. Por lo tanto, este es el mejor caso frente al peor caso. También observe la cantidad de inicios en frío que se pueden ver aquí. En Lambda, aunque los inicios en frío pueden no ser tan críticos para su aplicación, si podemos mantenerlos más bajos, también significa que es menos probable que ocurran. Esto se debe a que cada vez que Lambda tiene que procesar dos eventos consecutivos y no lo ha hecho antes, lo que significa que no hay instancias listas, debe iniciar una nueva, lo que significa que se introducirá un inicio en frío adicional. En mi ejemplo aquí, podemos ver que LLRT solo introdujo 109 inicios en frío frente a Node.js que tuvo 554 inicios en frío. Nuevamente, esto se debe a que los inicios en frío son mucho más cortos y también menos propensos a ocurrir en primer lugar. También observe aquí el rango de duración de los inicios en caliente, tenemos 158 milisegundos para el más lento hasta la invocación más rápida para el inicio en caliente, frente a solo 29 para P99 con LLRT. Y nuevamente, esto se debe a la falta de un compilador de tiempo de ajuste, lo que hace que la ejecución sea mucho más consistente. Si observamos el desglose de latencia y costo, podemos ver que tenemos una duración de construcción de 22 minutos y 19 segundos para Node.js, mientras que para LLRT solo tenemos 7 minutos y 48 segundos, lo que se traduce en un ahorro de costo de 2.9 veces y un ahorro de tiempo de 3.7 veces. Y la razón por la que estos dos difieren es que depende de cómo se les cobre. Por lo tanto, los tiempos de ejecución proporcionados se cobran de manera un poco diferente en Lambda que los tiempos de ejecución personalizados, pero aún tenemos un ahorro de costo de 2.9x para este ejemplo en particular en 32,000 invocaciones.

Y eso es todo por mi parte. Te animo encarecidamente a probar LLRT. Así que puedes seguir el enlace QR aquí y por favor pruébalo. Todavía es un tiempo de ejecución muy experimental. Así que no lo ejecutes en producción por ahora, pero estamos desarrollando más capacidades cada día. Y esperamos que nos des tu opinión. Y de nuevo, estoy muy, muy agradecido de que hayas tomado el tiempo para escucharme hoy. Y espero que disfrutes el resto del Congreso de Node. Gracias.

Y en primer lugar, echemos un vistazo a la pregunta de la encuesta que Richard también proporcionó aquí. ¿Qué te gustaría ver en la próxima evolución de los motores y tiempos de ejecución de JavaScript? Y Richard, al ver esto, el mejor soporte para nuevas características del lenguaje y la mejora del rendimiento y la optimización son las dos respuestas principales. ¿Te sorprende eso? En realidad no. Quiero decir, dado la innovación que ha ocurrido en los últimos años, incluso en el ecosistema de Node, no me sorprende que la gente quiera ver más capacidades, pero también un rendimiento mejorado. Así que sí, está alineado con lo que se está viendo ahora con toda la innovación y todos los motores y todos los frameworks y todo lo que está sucediendo en este momento. Súper interesante. Bueno, muchas gracias a todos por participar. Ahora vamos a pasar a sus preguntas y Richard las revisará. No te preocupes, Richard, las leeré por ti.

¿Por qué deberías usar LLRT y cuándo deberías usarlo? Y también, ¿cuándo no deberías usarlo? Un poco, ¿cuál sería el caso en su contra? Y también una pregunta interesante, ¿por qué no te enfocas en hacer que Node.js sea más rápido? Sí, gracias. Es una excelente pregunta. ¿Cuándo deberías usarlo? Creo que un buen lugar para usarlo es cuando tienes funciones serverless más simples. Tenemos funciones que se integran con servicios aguas abajo o fuentes de datos aguas abajo o realizan transformaciones de datos más simples, no aquellas aplicaciones JavaScript muy pesadas o intensivas en JavaScript donde haces, ya sabes, cientos de miles o millones de iteraciones porque entonces es probable que el rendimiento sea mejor con un tiempo de ejecución como Node, Deno o BUN. Pero para ese código de enlace, creo que es un lugar excelente para ejecutar LLRT. Y ¿por qué no hago que Node sea más rápido? Creo que esa también es una buena pregunta. Y es muy complicado hacer que Node sea más rápido. Si fuera sencillo o si pudiera hacerlo, lo intentaría. Creo que mucha gente está trabajando en eso para tratar de mejorar el rendimiento de Node, mientras que tradicionalmente ese no ha sido el enfoque principal del proyecto. Y tal vez también, solo brevemente, si pudieras responder eso, quiero decir, ¿cuál es tu respuesta si alguien dice algo como, bueno, Node es lento, ¿verdad? Podrían simplemente ejecutar una función de Lambda con Go, por ejemplo, escribir un lenguaje compilado. ¿Por qué centrarse en Node.js y hacer que ese tiempo de ejecución sea más rápido? Creo que, ya sabes, el ecosistema de Node es tan enorme. Ya hay mucho software y muchos desarrolladores que conocen JavaScript y quieren, ya sabes, son muy productivos con ese lenguaje.

Así que no es tan simple como cambiar a Rust o Go o a un lenguaje compilado. Por lo tanto, quieren seguir con eso. Y deberíamos apreciar eso y tratar de hacerlo lo mejor posible para esos desarrolladores para que puedan seguir siendo productivos sin tener que saltar a una tecnología completamente nueva, ya sabes, porque tienen sus ventajas y desventajas propias. Correcto. Sí. Dado que estamos en el congreso de Node, estoy totalmente de acuerdo con eso. ¿Cuándo estará listo para su uso en producción? Esa es la siguiente pregunta. Sí, es una muy buena pregunta. Estamos trabajando en ello. Queremos alcanzar lo que llamamos conformidad de Winter CG. No es lo que llamamos, sino la conformidad de Winter CG. Así que cumplir con la especificación mínima de Winter CG antes de que pueda alcanzar, ya sabes, 1.0 o algún tipo de madurez en producción. Aún te animamos a probarlo. Es bastante estable. No debería fallar tanto. Y si lo hace, por favor, envía un informe de errores en nuestro repositorio de código abierto y lo abordaremos lo más rápido posible. Esa es la prioridad principal en este momento. Muy bien. Así que una última pregunta rápida, ya que ya lo mencionaste, ¿cómo pueden los usuarios contribuir al proyecto? ¿Cuál es la mejor manera de empezar para ellos? La mejor manera de empezar sería, una vez más, ir al repositorio de código abierto y revisar los problemas. Y también tenemos un poco de backlog. Algunos de ellos son accesibles públicamente y también tratamos de agregar más problemas para que la gente pueda, ya sabes, empezar a contribuir a pequeñas partes de esta conformidad de Winter CG. Algunas son más complejas que otras, por supuesto, necesitando ayuda o más soporte y un esfuerzo mayor, pero también hay algunas partes en las que necesitamos apoyo. Genial. Muchas gracias. Desafortunadamente, se nos acabó el tiempo. Hay algunas preguntas más realmente interesantes aquí, pero estoy seguro de que puedes contactar a Richard a través de los canales habituales si quieres seguir y discutir un poco más con él. Y con eso, solo voy a pasar el control a mi coanfitrión, Sharon.