Las capas de AWS Lambda cambiaron las reglas del juego para mí. Cuando se usan correctamente, pueden reducir drásticamente el tiempo de implementación y, a su vez, reducir el tiempo de producción en servicios sin servidor que constan de múltiples funciones de AWS Lambda.
Sin embargo, a menudo es una característica que se malinterpreta y finalmente no se utiliza.
Esta publicación de blog cubre los conceptos básicos de las capas de AWS Lambda, sus ventajas y desventajas, y mis prácticas recomendadas.
Mipublicación anterior proporcionó detalles técnicos y ejemplos de código sobre cómo crear una capa Lambda con AWS CDK en Python.
Cómo crear funciones de AWS Lambda con dependencias externas
Cuando crea una función de AWS Lambda, debe proporcionar el código del controlador y sus módulos internos (capa lógica, controladores de base de datos, etc.). Sin embargo, la mayoría de las veces, su código depende de dependencias externas. Cuando se ejecuta su función Lambda, se ejecuta en una imagen base de contenedor de AWS. Es posible que la imagen de contenedor proporcionada por AWS no contenga todas sus dependencias externas. En ese caso, debe proporcionarlas usted mismo.
Tienes cuatro opciones:
Cree y cargue una imagen de contenedor Lambda que cree usted mismo, que incluya el código del controlador y todas las dependencias externas, y cárguela en el repositorio de Amazon ECR. Consulte mi blog anterior sobre el tema .
Cree y cargue un archivo ZIP que contenga todo el código Lambda y las dependencias externas según la función AWS Lambda. Vea ejemplos de código aquí .
Cree y cargue un archivo ZIP que contenga dependencias externas como una capa de AWS Lambda. Vea ejemplos de código y explicaciones técnicas aquí .
Utilice un ARN de capa Lambda existente que contenga las dependencias externas. Vea el ejemplo al final de mipublicación anterior.
Si bien las opciones uno y dos son soluciones razonables, me gustaría centrarme en las opciones tres y cuatro, ya que brindan una oportunidad de optimización única para su aplicación sin servidor.
Supongamos que su aplicación Serverless tiene diez funciones AWS Lambda y que sus dependencias externas pesan aproximadamente 50 megabytes.
Además, todas las dependencias externas se comparten entre las 10 funciones Lambda.
Ahora, recordemos las cuatro opciones que tenemos para cargar las dependencias a AWS.
En la opción uno, debes crear un archivo docker-compose por función Lambda, cada una con sus dependencias, punto de entrada y CMD. Es otro recurso que mantienes, cargas en AWS ECR y pagas por su almacenamiento.
En resumen, a menos que consumas dependencias que tengan un tamaño descomprimido de más de 250 MB, no veo ninguna ventaja en este mecanismo.
En la opción dos, que es la más común, creamos un archivo ZIP por función Lambda. AWS CDK lo hace de forma nativa mediante un contenedor Docker builder que crea el archivo ZIP.
Estos archivos ZIP se cargan en su cuenta de AWS como activos de AWS S3.
Sin embargo, dado que las diez funciones comparten las mismas dependencias, Docker agrupará las mismas dependencias, con un peso de aproximadamente 50 MB en las 10 funciones Lambda.
Se están cargando 500 MB de las mismas dependencias.
Se trata de un tiempo adicional para la implementación. Si se supone que se hace esto por entorno (desarrollo, prueba, ensayo, producción), puede sumar hasta minutos, según la velocidad de Internet.
¿Qué pasaría si hubiera una manera de cargar estas dependencias solo una vez y acelerar el tiempo de implementación general?
Ahí es donde entran en juego las capas Lambda.
Ventajas de las capas de AWS Lambda
Las capas de AWS Lambda se cargan una vez y pueden ser utilizadas por múltiples funciones Lambda.
Ahora recordemos el caso de uso anterior, donde sus funciones Lambda tienen dependencias compartidas que suman hasta 50 MB.
Supongamos que crea una capa a partir de esas dependencias y configura sus funciones Lambda para usarla.
Con este caso de uso en mente, resumamos las ventajas que obtiene al crear la capa Lambda:
Reducir el tamaño del archivo ZIP de la función Lambda. Cada archivo ZIP de Lambda contiene el código del controlador y los módulos internos, pero no contiene dependencias externas.
Reducir el tiempo total de producción: cada archivo ZIP de Lambda es más pequeño y lleva menos tiempo cargarlo. Multiplíquelo por la cantidad de funciones Lambda por la cantidad de cuentas de AWS (desarrollo, prueba, producción) y obtendrá un tiempo mucho más corto para implementar desde la cuenta de desarrollo a la de producción. He visto casos en los que se perdieron varios minutos del tiempo total de implementación.
Puede ver y editar el código de la función Lambda en la consola de AWS: un efecto secundario interesante. Cuando abre la sección de código de la función Lambda de AWS, puede ver el código si el tamaño del archivo ZIP es inferior a 3 MB (según los límites del editor de la consola ).
Desventajas de las capas de AWS Lambda
Repasemos las desventajas de las capas Lambda:
Control de versiones: las capas están versionadas y su función siempre consume una versión específica.
Puede consumir hasta 5 capas Lambda en una función Lambda.
El tamaño total descomprimido de la función y todas las capas no puede exceder la cuota de tamaño del paquete de implementación descomprimido de 250 MB. https://docs.aws.amazon.com/lambda/latest/dg/invocation-layers.html.
Se puede utilizar una capa creada externamente, es decir, capas que se consumen como ARN y que no se crean en el mismo proyecto. Sin embargo, esto presenta desafíos adicionales:
Son más difíciles de consumir y compartir: puedes usar capas creadas e implementadas en una cuenta diferente. Compartir es más complicado entre cuentas de AWS y, al final, dependes de un ARN externo que incluyes en tu código.
Actualizaciones manuales: las capas tienen versiones. La versión es parte del ARN. Debes saber que hay una nueva versión y cambiarla manualmente a la última versión. Las capas Lambda no tienen un administrador de paquetes como Python y otros lenguajes. Como resultado, las actualizaciones se convierten en una tarea manual.
Configurar un entorno de desarrollo local es difícil: es necesario determinar qué dependencias externas traen las capas e instalarlas localmente para probar el código y depurarlo en el IDE. Esto puede resultar complicado, especialmente en casos en los que existen conflictos. Una discrepancia entre el entorno de desarrollo local y el entorno de funciones Lambda puede provocar fallas y errores.
Seguridad. El uso de capas como ARN externo puede exponerlo a un riesgo de seguridad, ya que nunca está seguro de lo que está incluido en la capa. Asegúrese de utilizar AWS Inspector para mitigar esta vulnerabilidad.
Prácticas recomendadas para las capas de AWS Lambda
No utilice capas con ARN externo
Como se vio en el segmento de desventajas anterior en la sección 4, las capas externas tienen muchas desventajas que las hacen irrelevantes y no valen la pena.
Esto me lleva a una aparente resolución: ¡construirlo uno mismo!
Utilice AWS Lambda Layers como optimización de la implementación
La conclusión principal es que debes utilizar capas de AWS Lambda como optimización de implementación y crearlas en el mismo repositorio de código que utiliza la capa.
Deje la gestión de dependencias y el control de versiones a los administradores de paquetes adecuados, es decir, en Python, use pip o poetry y use capas como optimización de la implementación.
Construir la capa en el mismo repositorio que la utiliza disminuirá las desventajas de la capa Lambda números 1 y 4. Las funciones Lambda siempre usarán la última versión automáticamente y cada vez que actualice las dependencias, se creará una nueva capa. Además, el entorno de desarrollo siempre reflejará las mismas dependencias que su capa incluye, ya que están hechas a partir de la misma versión de dependencias.
Capas múltiples
¿Deberías construir múltiples capas en el mismo servicio?
Yo estaría en contra porque añade complejidad y aumenta el tiempo de implementación.
Sugiero dividir las dependencias en múltiples capas solo si una función requiere un paquete drásticamente más grande (lo que aumenta el inicio en frío); de lo contrario, use su criterio y analice el impacto del inicio en frío con/sin la dependencia adicional.
Puede utilizar las capacidades de rastreo de AWS X-Ray; lea más aquí .
Seguridad
Y, por último, la seguridad. Si aún se le solicita que use capas Lambda mediante ARN, asegúrese de habilitar AWS Inspector en sus funciones y capas Lambda.
AWS Inspector escaneará sus capas en busca de vulnerabilidades y le notificará si necesita tomar medidas.
Haga clic aquí para más detalles.
Ejemplo de AWS CDK
¿Quieres aprender a crear capas Lambda con AWS CDK? Consulta mipublicación de blog anterior.
¿Está interesado en un proyecto CDK Serverless totalmente funcional que utilice capas Lambda?
Consulta mi proyecto de plantilla de código abierto: https://github.com/ran-isenberg/aws-lambda-handler-cookbook
Comments