Editor Top
|
|
Hoy anunciamos AWS Lambda MicroVM, una nueva primitiva de computación sin servidor dentro de AWS Lambda que le permite ejecutar código generado por usuarios o IA en entornos de ejecución aislados y con estado. Obtiene aislamiento a nivel de máquina virtual, inicio y reanudación casi instantáneos, y control directo sobre el ciclo de vida y el estado del entorno, todo sin administrar infraestructura ni desarrollar experiencia en tecnologías de virtualización complejas. Las Lambda MicroVM funcionan con Petardola misma tecnología de virtualización liviana que ha impulsado más de 15 billones de invocaciones mensuales de funciones Lambda.
Por qué los clientes necesitan esto
En los últimos años ha surgido una nueva clase de aplicaciones multiinquilino que comparten la necesidad de ofrecer a cada usuario final su propio entorno de ejecución dedicado en el que ejecutar de forma segura código que el desarrollador de la aplicación no escribió. Los asistentes de codificación de IA, los entornos de código interactivo, las plataformas de análisis de datos, los escáneres de vulnerabilidades y los servidores de juegos que ejecutan scripts proporcionados por el usuario se ajustan a este patrón. Desarrollar esa capacidad hoy significa tomar una decisión difícil. Las máquinas virtuales ofrecen un fuerte aislamiento, pero tardan unos minutos en iniciarse. Los contenedores se lanzan en segundos, pero su arquitectura de kernel compartido requiere un importante refuerzo personalizado para contener de forma segura código que no es de confianza. Las funciones como servicio están optimizadas para cargas de trabajo de solicitud-respuesta impulsadas por eventos, pero no están diseñadas para sesiones interactivas de larga duración que necesitan conservar el estado del entorno en las interacciones del usuario. Eso deja a los desarrolladores aceptando compensaciones entre rendimiento y aislamiento, o invirtiendo importantes recursos de ingeniería para construir y operar una infraestructura de virtualización personalizada para lograr una ejecución aislada y al mismo tiempo ofrecer experiencias de baja latencia a los usuarios finales. Esto presenta un esfuerzo que exige una gran experiencia y resta tiempo de ingeniería al producto que realmente están tratando de construir.
Lambda MicroVMs está diseñado específicamente para cubrir exactamente esta brecha. Cada MicroVM proporciona a un único usuario final o sesión su propio entorno aislado que se inicia rápidamente, retiene la memoria y el estado del disco durante la sesión y se detiene a un bajo costo de inactividad cuando el usuario se aleja. Debido a que la misma tecnología Firecracker ya sustenta las funciones Lambda de AWS, usted hereda la madurez operativa de un servicio que ha estado ejecutando esta pila a escala.
Probemoslo
Para comenzar, navegué hasta la consola de AWS Lambda, donde ahora aparece Lambda MicroVM en el menú de navegación de la izquierda. Primero necesito crear una imagen MicroVM.
Empaqueté una aplicación web Flask y su Dockerfile en un archivo zip y lo subí a un depósito de Amazon Simple Storage Service (Amazon S3).
Mi API Flask – app.py
import logging
from flask import Flask, jsonify
app = Flask(__name__)
logging.basicConfig(level=logging.INFO)
@app.route("/")
def hello():
app.logger.info("Received request to hello world endpoint")
return jsonify(message="Hello, World!")
if __name__ == "__main__":
app.run(host="0.0.0.0", port=5000)
Mi archivo Docker
FROM public.ecr.aws/lambda/microvms:al2023-minimal
RUN dnf install -y python3 python3-pip && dnf clean all
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY app.py .
EXPOSE 5000
CMD ["gunicorn", "--bind", "0.0.0.0:5000", "app:app"]
Utilicé el siguiente comando para crear mi imagen MicroVM.
aws lambda-microvms create-microvm-image \
--code-artifact uri= --name \
--base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \
--build-role-arn 
También puede crear la imagen de MicroVM en la consola de AWS como en la imagen de arriba. Una vez que ejecuté el comando, Lambda recuperó el zip, ejecutó el Dockerfile, inicializó la aplicación y tomó una instantánea de Firecracker del disco en ejecución y el estado de la memoria. Cree registros transmitidos en tiempo real a Amazon CloudWatch en /aws/lambda/microvms/y cuando la imagen estuvo lista apareció en la consola con su Nombre de recurso de Amazon (ARN) y número de versión.
aws lambda-microvms run-microvm \
--image-identifier arn:aws:lambda:::microvm-image:my-image \
--execution-role-arn arn:aws:iam:::role/MicroVMExecutionRole \
--idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}'
El lanzamiento también se puede realizar a través de la consola de AWS o la CLI. Pasé el ARN de la imagen y una política inactiva configurada para suspenderse automáticamente después de 15 minutos de inactividad y reanudarse automáticamente en la siguiente solicitud entrante. No se requirió configuración de red. Lambda asignó a MicroVM una ID única, devolvió una URL de punto final dedicada e inició un nuevo MicroVM con mi aplicación Flask ya ejecutándose, ya que se reanudó a partir de una instantánea. Mi aplicación Flask ya se estaba ejecutando en el momento en que se completó el inicio. Una llamada a la API para obtener un entorno informático arrancado y completamente inicializado.
Para enviar tráfico, generé un token de autenticación de corta duración con la CLI y lo adjunté a una solicitud HTTPS simple usando el X-aws-proxy-auth encabezamiento. La solicitud llegó a mi aplicación Flask de inmediato. Luego dejé que MicroVM permaneciera inactivo más allá del umbral de suspensión, momento en el cual se suspendió MicroVM, con su memoria y estado de disco tomados y almacenados. Luego envié otra solicitud y se reanudó con el estado de la aplicación completamente intacto. Desde el lado del cliente, la pausa nunca se produjo.
como funciona
En el fondo, Lambda MicroVM ofrece tres capacidades que, hasta hoy, ningún servicio informático de AWS ofrecía en conjunto. El primero es el aislamiento a nivel de máquina virtual, que proviene de Firecracker. Cada sesión se ejecuta en su propio MicroVM dedicado sin núcleo compartido ni recursos compartidos entre usuarios, por lo que el código no confiable proporcionado por un usuario está contenido en su entorno de ejecución, sin acceso a otros entornos ni al sistema subyacente. El segundo es el inicio y la reanudación rápidos. El modelo es imagen y luego lanzamiento: usted crea una imagen MicroVM proporcionando un Dockerfile y un código empaquetado como un artefacto zip en Amazon S3, y Lambda ejecuta su Dockerfile, inicializa su aplicación y toma una instantánea de Firecracker de la memoria y el estado del disco del entorno en ejecución. Cada MicroVM posterior iniciado desde esa imagen se reanuda a partir de la instantánea preinicializada en lugar de iniciarse en frío, lo que significa que tanto los inicios como las reanudaciones inactivas logran una latencia de inicio casi instantánea. Incluso una sesión interactiva de varios gigabytes vuelve a estar en línea lo suficientemente rápido como para que el usuario final sienta que responde. El tercero es la ejecución con estado. Un MicroVM en ejecución conserva la memoria, el disco y los procesos en ejecución durante la sesión del usuario. Durante los períodos de inactividad, se puede suspender una MicroVM (con la memoria y el estado del disco intactos) y reanudarla cuando llega el tráfico. Los paquetes instalados, los modelos cargados y los conjuntos de archivos en funcionamiento están disponibles cuando el usuario reanuda su sesión. Las MicroVM admiten hasta 8 horas de tiempo de ejecución total y se pueden suspender automáticamente después de una ventana de inactividad configurable, lo que facilita la creación de productos tan variados como escaneos de vulnerabilidades de software que se completan en minutos, aplicaciones de análisis de datos que se ejecutan durante horas y sesiones de codificación interactivas con períodos de inactividad prolongados. Dado que las Lambda MicroVM se inician a partir de instantáneas preinicializadas, es posible que las aplicaciones que generan contenido único, establecen conexiones de red o cargan datos efímeros durante la inicialización deban integrarse con enlaces proporcionados por el servicio para mayor compatibilidad.
Lambda MicroVMs es un nuevo recurso dentro de AWS Lambda, con una superficie API distinta. Lambda Functions sigue siendo la opción correcta para cargas de trabajo de solicitud-respuesta impulsadas por eventos, y Lambda MicroVM está diseñado específicamente para aplicaciones multiinquilino que necesitan entregar a cada usuario final o sesión su propio entorno aislado para ejecutar código generado por el usuario o por IA. Los dos se complementan. Una aplicación que utiliza Lambda Functions para su columna vertebral basada en eventos puede llamar a Lambda MicroVM para realizar los pasos que necesitan ejecutar código que no es de confianza de forma aislada. Usted trae la aplicación y el servicio entrega el entorno de ejecución.
Ahora disponible
AWS Lambda MicroVM está disponible hoy en las regiones EE. UU. Este (Norte de Virginia, Ohio), EE. UU. Oeste (Oregón), Europa (Irlanda) y Asia Pacífico (Tokio), en la arquitectura ARM64, con hasta 16 vCPU, 32 GB de memoria y 32 GB de disco por MicroVM. Las MicroVM inactivas se pueden suspender explícitamente mediante una llamada API o automáticamente mediante una política de ciclo de vida, lo que reduce el costo de funcionamiento y al mismo tiempo preserva el estado completo para una reanudación rápida. Los detalles de precios se pueden encontrar en la página de precios de AWS Lambda.
Para comenzar, visite la consola de AWS Lambda u obtenga más información en la página del producto Lambda MicroVM. Para obtener documentación, consulte la Guía para desarrolladores de Lambda MicroVM.
