Se preparó una traducción del artículo específicamente para estudiantes del curso de Servicios en la nube . ¿Es interesante desarrollar en esta dirección? Vea una clase magistral de Egor Zuev (TeamLead en InBit) “AWS EC2 Service” y únase al grupo de cursos más cercano: comience el 26 de septiembre.

Cada vez más personas se están cambiando a AWS Lambda por escalabilidad, rendimiento, ahorro de costos y la capacidad de procesar millones o incluso billones de solicitudes por mes. Para hacer esto, no necesita administrar la infraestructura en la que funciona el servicio. Y el escalado automático le permite atender miles de solicitudes simultáneas por segundo. Creo que AWS Lambda puede llamarse legítimamente uno de los servicios de AWS más populares.

AWS Lambda

AWS Lambda es un servicio informático sin servidor orientado a eventos que le permite ejecutar código sin asignar y administrar servidores y complementar otros servicios de AWS basados ​​en la lógica del usuario. Lambda responde automáticamente a varios eventos (los llamados disparadores), por ejemplo, a solicitudes HTTP a través de Amazon API Gateway, cambios de datos en cestas de Amazon S3 o tablas de Amazon DynamoDB; O puede ejecutar su código a través de llamadas API utilizando AWS SDK y transiciones de estado en AWS Step Functions.

Lambda ejecuta código en una infraestructura informática altamente accesible y es totalmente responsable de administrar la plataforma subyacente, incluido el mantenimiento del servidor y del sistema operativo, la asignación de recursos, el escalado automático, el monitoreo de código y el registro. Es decir, solo necesita cargar su código y configurar cómo y cuándo debe ejecutarse. A su vez, el servicio se encargará de su lanzamiento y garantizará una alta disponibilidad de su aplicación.

¿Cuándo actualizar a Lambda?

AWS Lambda es una plataforma informática conveniente para muchos escenarios de aplicación, por supuesto, si el servicio y el tiempo de ejecución de su código son compatibles. Si desea centrarse en el código y la lógica empresarial con el mantenimiento del servidor, el aprovisionamiento y la ampliación a un proveedor externo por un precio razonable, definitivamente debe actualizar a AWS Lambda.

Lambda es ideal para crear interfaces de software, y si usa el servicio con API Gateway, puede reducir significativamente los costos e ingresar al mercado más rápido. Hay varias formas de usar las funciones y opciones de Lambda para organizar una arquitectura sin servidor: todos podrán elegir algo adecuado en función de su objetivo.

Lambda le permite realizar una amplia gama de tareas. Entonces, gracias al soporte de CloudWatch, puede crear tareas pendientes y automatizar procesos individuales. No existen restricciones sobre la naturaleza e intensidad del uso del servicio (se tienen en cuenta el consumo de memoria y el tiempo), y nada le impide trabajar sistemáticamente en un microservicio completo basado en Lambda.

Aquí puede crear acciones orientadas al servicio que no se realizan constantemente. Un ejemplo típico es el escalado de imágenes. Incluso en el caso de sistemas distribuidos, las funciones de Lambda no pierden relevancia.

Por lo tanto, si no desea participar en la asignación y administración de recursos informáticos, pruebe AWS Lambda; si no necesita computación pesada e intensiva en recursos, pruebe AWS Lambda; si su código se ejecuta periódicamente; todo es correcto, debe probar AWS Lambda.

Seguridad

Hasta el momento, no hay quejas sobre seguridad. Por otro lado, dado que muchos procesos internos y características de implementación de este modelo están ocultos para el usuario del tiempo de ejecución administrado de AWS Lambda, algunas reglas de seguridad en la nube generalmente aceptadas ya no son relevantes.

Al igual que la mayoría de los servicios de AWS, Lambda se brinda sobre la base de la responsabilidad compartida entre AWS y el cliente con respecto a la seguridad y el cumplimiento normativo. Este principio reduce la carga operativa en el cliente, ya que AWS asume las tareas de servicio, administración y control de los componentes del servicio, desde el sistema operativo host y el nivel de virtualización hasta la seguridad física de los objetos de infraestructura.

Hablando específicamente sobre AWS Lambda, AWS es responsable de administrar la infraestructura subyacente, los servicios subyacentes relacionados, el sistema operativo y la plataforma de aplicaciones. Si bien el cliente es responsable de la seguridad de su código, el almacenamiento de datos confidenciales, el control de acceso a los mismos, así como a los servicios y recursos de Lambda (Identity and Access Management, IAM), incluso dentro del alcance de las funciones utilizadas.

El siguiente diagrama muestra el modelo de responsabilidad compartida aplicable a AWS Lambda. El área de responsabilidad de AWS es naranja, y la responsabilidad del cliente es azul. Como puede ver, AWS asume más responsabilidad por las aplicaciones implementadas en el servicio.

Modelo de responsabilidad compartida aplicable a AWS Lambda

Lambda Runtime

La principal ventaja de Lambda es que, al realizar una función en su nombre, el servicio en sí asigna los recursos necesarios. Puede ahorrar tiempo y esfuerzo en la administración del sistema y centrarse en la lógica empresarial y la escritura de códigos.

El servicio Lambda se divide en dos planos. El primero es el plano de control. Según Wikipedia, el plano de control es la parte de la red responsable de señalizar el tráfico y el enrutamiento. Es el componente principal que toma decisiones globales sobre la asignación, mantenimiento y distribución de cargas de trabajo. Además, el plano de control actúa como la topología de red del proveedor de soluciones, que es responsable del enrutamiento y la gestión del tráfico.

El segundo plano es el plano de datos. Al igual que el plano de control, tiene sus propias tareas. El plano de administración proporciona una API para administrar funciones (CreateFunction, UpdateFunctionCode) y controla la interacción de Lambda con otros servicios de AWS. El plano de datos está controlado por la API Invoke, que invoca las funciones Lambda. Después de llamar a la función, el plano de control selecciona o selecciona el tiempo de ejecución existente preparado de antemano para esta función, y luego ejecuta el código en él.

AWS Lambda admite muchos lenguajes de programación, incluidos Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2 y otros, a través de sus respectivos tiempos de ejecución. AWS los actualiza regularmente, distribuye parches de seguridad y realiza otras operaciones de mantenimiento en estos entornos. Lambda le permite usar otros idiomas, siempre que usted mismo implemente el tiempo de ejecución apropiado. Y luego tendrá que ocuparse de su mantenimiento, incluida la supervisión de la seguridad.

¿Cómo funciona todo y cómo realizará el servicio sus funciones?

Cada función funciona en uno o varios entornos seleccionados que existen solo durante el ciclo de vida de esta función y luego se destruyen. En cada entorno, solo se realiza una llamada a la vez, pero se reutiliza si hay muchas llamadas en serie de la misma función. Todos los tiempos de ejecución se ejecutan en máquinas virtuales con virtualización de hardware, en el llamado microVM. Cada microVM se asigna a una cuenta de AWS específica y los entornos pueden reutilizarlo para realizar diversas funciones en esa cuenta. Los MicroVM están empaquetados en los bloques de construcción de la plataforma de hardware Lambda Worker, que AWS posee y opera. El mismo tiempo de ejecución no puede ser utilizado por diferentes funciones, al igual que los microVM son únicos para diferentes cuentas de AWS.

Modelo de aislamiento AWS Lambda

El aislamiento en tiempo de ejecución se implementa utilizando varios mecanismos. En el nivel más alto de cada entorno, hay copias separadas de los siguientes componentes:

• Código de función
• Cualquier capa Lambda seleccionada para la función
• Tiempo de ejecución de la función
• Espacio de usuario mínimo de Amazon Linux

Los siguientes mecanismos se utilizan para aislar diferentes entornos de tiempo de ejecución:

• cgroups: restricción de acceso a los recursos de la CPU, la memoria, el ancho de banda de la unidad y la red para cada entorno de tiempo de ejecución;
• espacios de nombres: ID de proceso de agrupación, ID de usuario, interfaces de red y otros recursos administrados por el kernel de Linux. Cada tiempo de ejecución se ejecuta en su propio espacio de nombres;
• seccomp-bpf: restricción de llamadas al sistema que se pueden usar en el entorno de tiempo de ejecución;
• iptables y tablas de enrutamiento: aislamiento de entornos de tiempo de ejecución entre ellos;
• chroot: proporciona acceso limitado al sistema de archivos subyacente.

Combinados con la tecnología patentada de aislamiento de AWS, estos mecanismos aseguran una separación confiable de los entornos de tiempo de ejecución. Los medios aislados de esta manera no pueden acceder o modificar datos de otros medios.

Aunque se pueden ejecutar múltiples tiempos de ejecución de la misma cuenta de AWS en el mismo microVM, bajo ninguna circunstancia se pueden compartir microVM entre diferentes cuentas de AWS. AWS Lambda usa solo dos mecanismos para aislar microVM: instancias EC2 y Firecracker. El aislamiento de invitados en Lambda basado en instancias EC2 ha estado en uso desde 2015. Firecracker es el nuevo hipervisor de código abierto diseñado específicamente por AWS para cargas de trabajo sin servidor e introducido en 2018. El equipo físico en el que se ejecutan los microVM se comparte entre las cargas de trabajo de diferentes cuentas.

Guardar entornos y estados del proceso

Aunque los tiempos de ejecución de Lambda son únicos para diferentes funciones, la misma función se puede volver a llamar en ellos, es decir, el tiempo de ejecución puede durar varias horas antes de ser destruido.

Cada tiempo de ejecución de Lambda también tiene un sistema de archivos de permisos de escritura, accesible a través del directorio / tmp. No se puede acceder a su contenido desde otros tiempos de ejecución. Con respecto a la preservación de los estados del proceso, los archivos grabados en / tmp existen durante todo el ciclo de vida del tiempo de ejecución. Debido a esto, es posible acumular los resultados de varias llamadas, lo cual es especialmente útil para operaciones tan costosas como cargar modelos de aprendizaje automático.

Transferencia de datos de llamadas

La API de invocación se puede utilizar en dos modos: en modo de evento y en modo de solicitud-respuesta. En el modo de evento, la llamada se agrega a la cola para su posterior ejecución. En el modo "solicitud-respuesta", la función se llama instantáneamente con la carga útil proporcionada, después de lo cual se devuelve la respuesta. En cualquier caso, la función se ejecuta en el entorno Lambda, pero con diferentes rutas de carga útil.

Durante las llamadas de solicitud-respuesta, la carga proviene de la API de procesamiento de solicitudes (API Caller), como AWS API Gateway o AWS SDK, al equilibrador de carga y luego al Servicio de ejecución de llamadas Lambda (Servicio de invocación). Este último determina el entorno apropiado para ejecutar la función y transfiere allí la carga útil para completar la llamada. El equilibrador de carga recibe tráfico con protección TLS a través de Internet. El tráfico dentro del servicio Lambda, después del equilibrador de carga, pasa a través de la VPC interna en una región específica de AWS.

Modelo de procesamiento de llamadas de AWS Lambda: modo de solicitud-respuesta

Las llamadas a eventos se pueden hacer de inmediato o agregarse a la cola. En algunos casos, la cola se implementa utilizando el servicio Amazon SQS (Amazon Simple Queue Service), que transfiere llamadas al servicio de ejecución de llamadas Lambda a través de un proceso de sondeo interno. El tráfico transmitido está protegido por TLS y no se proporciona cifrado adicional de los datos almacenados en Amazon SQS.

Las llamadas a eventos no devuelven respuestas: Lambda Worker simplemente ignora cualquier información de respuesta. Lambda maneja las llamadas basadas en Amazon S3, Amazon SNS, CloudWatch y otras fuentes en modo evento. Las llamadas de las transmisiones de Amazon Kinesis y DynamoDB, las llamadas de las colas SQS, el equilibrador de carga de la aplicación y las API de Gateway se manejan en un modo de solicitud-respuesta.

Monitoreo

Puede supervisar y auditar las funciones de Lambda utilizando diversos mecanismos y servicios de AWS, incluidos los siguientes.

Amazon Cloudwatch
Recopila varias estadísticas, como el número de solicitudes, la duración de las solicitudes y el número de solicitudes que fallaron.

Amazon CloudTrail
Le permite iniciar sesión, monitorear continuamente y guardar la información de actividad de la cuenta asociada con su infraestructura de AWS. Tendrá una cronología completa de las acciones realizadas con la consola de administración de AWS, el SDK de AWS, las herramientas de línea de comandos y otros servicios de AWS.

Rayos X de AWS
Proporciona visibilidad completa de todas las etapas del procesamiento de solicitudes en su aplicación en función de un mapa de sus componentes internos. Le permite analizar aplicaciones durante el desarrollo y en el entorno de producción.

Configuración de AWS
Podrá realizar un seguimiento de los cambios en la configuración de las funciones de Lambda (incluida su eliminación) y tiempos de ejecución, etiquetas, nombres de manejador, tamaño de código, asignación de memoria, latencia y configuraciones de concurrencia, así como la función, subred y enlaces de grupos de seguridad de Lambda IAM.

Conclusión

AWS Lambda ofrece un poderoso conjunto de herramientas para crear aplicaciones seguras y escalables. Muchos de los métodos de seguridad y cumplimiento normativo en AWS Lambda no son diferentes de los utilizados en otros servicios de AWS, aunque hay excepciones. A partir de marzo de 2019, Lambda cumple con SOC 1, SOC 2, SOC 3, PCI DSS, la Ley de Responsabilidad y Continuidad del Seguro Médico de EE. UU. (HIPAA) y otras regulaciones. Por lo tanto, cuando piense en implementar otra aplicación, considere el servicio AWS Lambda; quizás sea el más adecuado para su tarea.