Explorando Límites de AWS Lambda – Porque

Es muy común implementar una solución Serverless en AWS utilizando los servicios API Gateway, AWS Lambda y DynamoDB, y, probar esta arquitectura para nuestro caso de uso es crucial al diseñar una solución.

Así, cuando trabajamos la charla ¿Como manejar 100K conexiones simultáneas en AWS? en Serverless o probamos los nuevos límites de AWS Lambda de acuerdo al anuncio Las funciones de AWS Lambda ahora escalan 12 veces más rápido cuando manejan solicitudes de gran volumen, nos vimos en la necesidad de crear recursos y ambientes, una y otra vez hasta crear el escenario perfecto.

Por eso decidimos crear un proyecto base como infraestructura como código que pueda apoyarlos para sus propias pruebas. El repositorio es público y de código abierto, y lo pueden encontrar aquí serverless-limits-playbook-test.

Arquitectura

La idea principal en esta versión es crear una arquitectura de un API RESTful con API Gateway integrado a un función AWS Lambda para llamadas sincrónicas, y crear una instancia EC2 con una instalación de JMeter para lanzar pruebas de carga.

Aunque en el código podrán observar también:

• Habilitación de CORS
• Bloque de código para llamadas asincrónicas (comentado)
• Configuración para reserve concurrency en AWS Lambda.
• El script setup.sh para adicionar configuraciones a su instancia EC2.
• El script index.mjs para definir la implementación real de su función AWs Lambda.
• Un identificador único para peticiones desde a lambda (opcional podrían eliminarlo).

Prerequisitos

Dependiendo de su caso de uso necesitarán configuraciones generales en su cuenta, pero aquí presentamos las básicas.

• Tener una Default VPC en la region que vayan a probar.
• Crear un Role en IAM que permita escribir desde API Gateway a CloudWatch.
• Asignar dicho rol a las configuraciones del servicio API Gateway en la región donde se va ha hacer pruebas.
• Tener los Server Limits adecuados a su prueba, especialmente los de AWS Lambda “Burst Concurrency” y “Concurrent Executions“.

Despliegue de recursos

Al ser un proyecto IaaC construido con AWS CDK, pues evidentemente usamos los comando apropiados. A continuación la lista de pasos:

• Cambiar las variables const targetRegion y const targetAccount en el archivo de los fuentes /bin/infra.ts apropiadamente.
• Instala AWS CLI la última versión.
• Instala Node.js 20 o superior.
• Instala el último AWS CDK.
• En la carpeta del proyecto corre cdk boostrap para preparar la región para IaaC.
• Ejecuta cdk synth para verificar que tus fuentes estén correctos.
• Ejecuta cdk deploy para crear los recursos descritos en la arquitectura.

Usamos AWS CDK para este proyecto, pero podrías reemplazar o hacer tus versiones con Terraform u OpenTofu respectivamente. Hacerlo con AWS Cloud Formation es otra opción aunque no lo recomiendo.

Lanzamiento de carga masiva

Para ejecutar las pruebas masivas con JMeter es necesario ingresar a la instancia EC2 creada a través de la Consola Web y con EC2 Instance Connect, dado que no se asoció un server key al momento de su creación.

Una vez en el shell los comandos son los siguientes:

• Cambia a root el usuario: sudo -i.
• Edita el archivo LambdaConcurrencyLimits.jmx con vi /tmp/LambdaConcurrencyLimits.jmx con el url de tu API RESTful (esa url la obtienes como salida del comando cdk deploy al final del log).

Ejecuta los test JMeter de carga con

rm -Rf /var/www/html/stats/* && rm -f /tmp/stats.jtl && /opt/apache-jmeter-5.6.2/bin/jmeter -n -t /tmp/LambdaConcurrencyLimits.jmx -l /tmp/stats.jtl -e -o /var/www/html/stats.

Pruebas en JMeter

Mientras se puede escribir un blog entero de pruebas en JMeter, el archivo creado esta compuesto de las siguintes características:

• Cinco grupos de usuarios (hilos)
• Primer grupo lanza 1001 usuarios en 10 segundos.
• Segundo grupo lanza 2001 usuarios en 20 segundos.
• Tercer grupo lanza 3001 usuarios en 30 segundos.
• Cuarto y quinto grupo lanza 0 usuarios, y están en el archivo jmx para que los usen como lo prefieran para su caso de prueba.
• Se prueba una URL con un HTTP Request de tipo GET al API RESTful creado.
• El URL del API Gateway RESTful esta externalizado en el argumento url-api-gateway.

Evidentemente estas pruebas no se ajustan a tu caso de uso y deberás cambiarlas apropiadamente, sin embargo el mecanismo de lanzamiento y la instancia EC2 configurada va a reducir el tiempo para esta operación.

Métricas

Una vez desplegada la infraestructura, y ejecutados las pruebas podremos monitorear los recursos y tomar las acciones correspondientes.

A continuación algunos gráficos que vamos a poder obtener:

API Gateway

AWS Lambda

Además siempre vamos a tener Grupos de Logs en Amazon CloudWatch apropiados para el caso de uso y por servicio para analizar los resultados:

IMPORTANTE: siempre al finalizar las pruebas no olviden ejecutar cdk destroy para decomisar los recursos usados y evitar facturación innecesaria.

Conclusiones y Pensamientos Finales

En este Playbook Explorando Límites de AWS Lambda, hemos podido plasmar un proyecto de código abierto para que puedan acelerar sus pruebas de implementaciones. Sin embargo hay mucho que mejorar en el mismo, como la inclusión de secrets con Secrets Manager para gestionar números de cuenta y otros parámetros sensibles y que NO deben estar en su repositorio de fuentes.

También este proyecto nos ayuda en la inmersión en el mundo apasionante que significa AWS CDK, y con el cual pueden gestionar su infraestructura de forma completamente automatizada.

Vale mencionar que en un proyecto de AWS CDK jamás deben subir el directorio cdk.out, dado que aquí como resultado de la compilación de los archivos Typescript a archivos propios de AWS Cloud Formation ((JSON por ejemplo), puede y va a quedar información sensible como números de cuenta y/o claves.

Para hacer uso de este enfoque de despliegue es necesario estar familiarizado con AWS CLI ya que con este generarán perfiles que contengan accesos de los usuarios de su cuenta, y con tales accesos se crearán los recursos. Entonces es importante que los usuarios asociados tengan los permisos correspondientes.

Los límites que tengan para su cuenta y por región van a incidir directamente en sus pruebas en caso de altas cargas de procesamiento, por lo que se debe tener en cuenta los mismos al momento de planificar la implementación.

Les animamos a dejar su feedback para mejorar el proyecto, sea aquí o en el repositorio de GitHub, y esperamos que sea de utilidad este proyecto “Explorando Límites de AWs Lambda”.

Esta estrategia, Endpoint Proxy en API Gateway, es muy adecuada especialmente porque tenemos los siguientes beneficios:con

• Implementar el escenario Rehost (lift and shift) para una migración.
• No realizar ninguna modificación a la implementación del API.
• Mantener el servicio web en una red privada y sin acceso a internet.
• Acceder a mejoras de seguridad del API de negocio y poder monitorearlo, dado que vamos a usar API Gateway.
• Posibilita el versionamiento del API de negocio con menor esfuerzo.
• Integración con el escudo de seguridad AWS WAF.

Tutorial Endpoint Proxy con API Gateway

Se piensa en implementar con Amazon API Gateway un Endpoint Proxy de tipo HTTP API, que puede brindar la solución a lo requerido.

Escenario API Público

Para este escenario vamos a utilizar el API ejemplo de Swagger https://petstore.swagger.io/ como referencia, que nos ayuda a probar operaciones RESTful comunes.

Probamos la operación https://petstore.swagger.io/#/pet/findPetsByStatus para mirar los datos disponibles.

Ok, el API está funcionando correctamente.

Definimos una arquitectura Cloud para este efecto en AWS.

Creamos el API Gateway HTTP con el nombre proxy-swagger-api.

Creamos la ruta $default.

La ruta $default actúa como un “catch-all” es decir gestiona cualquier petición que no coincida con otras rutas definidas. Puedes saber más aquí.

Creamos la integración.

Probamos el API RESTful de la misma forma que lo hicimos al inicio.

Debemos cambiar el Endpoint a el nuevo del API Gateway: https://gl1p0rt1gc.execute-api.us-east-2.amazonaws.com/ (reemplaza para tu caso con el apropiado).

Esta vez la prueba la vamos ha hacer desde Postman.

¡Excelente! Funciona igual y como un Endpoint Proxy con las ventajas y funcionalidades que ofrece API Gateway.

Escenario API Privado

¿En la vida real como sería un ejemplo?

Vamos a ver una arquitectura donde este API es una implementación privada que esta en una instancia EC2 en una subred privada de una VPC de la empresa. Por tanto el único que permite acceso y controla los flujos es el API Gateway.

Para este escenario vamos a usar la implementación de un CRUD API RESTful construído con Spring de Código Libre / Opensource en GitHub.

Descargamos el proyecto en la instancia EC2 en la red privada, lo compilamos y corremos de acuerdo a las instrucciones del archivo README.mb en el código .fuente.

Seguido a esto hacemos una prueba. En este caso nos ayudamos de AWS CloudShell.

Son dos comandos curl, que insertan un registro visita y luego recuperan todas los registros visitas.

Cabe mencionar que antes debemos conectarnos a esa máquina con los protocoles estándar de SSH + Server Key, y, primero pasando por un Bastion Host… ya se mucha información pero ese es el camino dado que el servidor EC2 esta en una subred privada.

Creamos un Endpoint Proxy de tipo HTTP API, igual que en primer escenario.

Creamos una Route (ruta) proxy $default.

Para poder direccionar el tráfico a un recurso en una red privada, vamos a usar un Aplication Load Balancer (ALB), el mismo que va incluir en su Target Group a la instancia EC2 que provee el API privado.

El ALB debe ser de tipo “internal” es decir solo se puede usar dentro de la VPC (no desde Internet).

Evidentemente necesitas tener un Target Group que contenga el servidor EC2 privado donde esta el API al cual el ALB va a dirigir las peticiones. Por esto en medio de la creación del ALB tendrás que crear este Target Group.

Debes asegurarte que el grupo de seguridad del ALB permite el tráfico al puerto donde esta el listener.

Continúa con la creación del ALB.

Bien, vamos a continuar con la creación de la integración de nuestro API proxy-api-crud, para esto vamos al servicio API Gateway para iniciar.

La integración debe ser de tipo “Private resource” y en método seleccionamo9s “Select manually” para tener la opción de elegir un ALB/NLB como Target service.

En la lista desplegada de los ALBs, seleccionamos nuestro proxy-alb recién creado.. Además vamos a tener que crear “Create new VPC link” en la selección correspondiente, ya que este será el puente entre nuestro API creado con API Gateway y por defecto en una red propia de AWS, con nuestra VPC propia de la empresa.

Para este caso la VPC es proxy-vpc-vpx, pero debes elegir la correspondiente en tu infraestructura.

Aquí una ampliación al concepto de VPC Link, un VPC Link es un recurso que permite crear una integración con los recursos privados de una VPC desde una ruta del API Gateway de tipo HTTP. De esta forma no tienes que exponer ningún recurso de la VPC al público e igual puedes usarlo como destino final de un API Gateway que si sea público. Si quieres saber más de integraciones privadas para API Gateway HTTP a recursos de tu VPC puedes mirar aquí.

Luego en las opciones siguientes es importante elegir a qué subredes tiene acceso este nuevo VPC Link y que grupos de seguridad se le asignan.

Las subredes son importantes porque deben ser las subredes asociadas a tu ALB y su correspondiente Target Group.

El grupo de seguridad, es que que permite el acceso al puerto correspondiente donde el Listener del ALB esta escuchando peticiones.

Realizada la integración vamos a identificar el url (Invoke URL) del Endpoint Proxy con API Gateway creado.

Listo, con ese url, si todo es correcto podemos hacer las siguientes peticiones:

Para crear una visita:

curl --location 'https://bg4gmloull.execute-api.us-east-2.amazonaws.com/api/visits' \
--header 'Content-Type: application/json' \
--data '{"date":"2024-01-19","name":"Fer","comment":"by CloudIO Strategy"}'

Para consultar visitas:

curl --location 'https://bg4gmloull.execute-api.us-east-2.amazonaws.com/api/visits'

Son las mismas peticiones que usamos con consultar el servicio web RESTful desde el shell de la instancia EC2 mostrada en el ejemplo.

¡Excelente! Hemos creado un Endpoint Proxy con API Gateway, son tocar la implementación, con la funcionalidad esperada y todos los beneficios que tenemos en el servicio Amazon API Gateway.

Conclusiones y pensamientos finales

Hoy en este tutorial hemos visto como podemos implementar un Endpoint Proxy con API Gateway, un requerimiento que viene a partir de una migración al estilo Rehost del cliente que no desea entrar en temas de modificación a sus aplicaciones.

Presentamos dos escenarios, un proxy para un API público, que es infrecuente, y, un proxy a un API privado que si es muy frecuente y en ambos casos el servicio Amazon API Gateway nos permite implementar tal necesidad.

Nuestra arquitectura es solo una posibilidad de implementación del requerimiento, sin embargo en nuestra opinión es la más simple y rápida para dar una respuesta adecuada.

Vimos un concepto “VPC Link” que es importantísimo a la hora de integrar un API HTTP con recursos privados en la VPC, y en nuestro caso, nos integramos a un ABL o Aplication Load Balancer, sin embargo podríamos habernos integrado por ejemplo a AWS Cloud Map. Dado esto, no es la única forma de integración que podrían usar.

El ALB nos habilita todas las ventajas que tenemos de un Load Balancer por ejemplo resiliencia o escalamiento horizontal, y aunque representa un costo adicional es justificable frente a un lineamiento SRT (Server Response Time) del negocio.

Evidentemente, falta muchas configuraciones complementarias a una arquitectura de este estilo, como por ejemplo lo relacionado a las decisiones de stages del API, las seguridades, el monitoreo y la trazabilidad. Además la buena práctica es conectar este API Gateway a un dominio o subdominio apropiado de su empresa para facilidad de uso y estrategias de contingencia, entre otros.

Tecnologías Serverless en AWS

¿Qué es Serverless?

El término “Serverless” se refiere a un enfoque de arquitectura en el cual los desarrolladores no necesitan gestionar ni mantener servidores para ejecutar sus aplicaciones. En lugar de esto, las aplicaciones se construyen utilizando servicios en la nube que automáticamente escalan y se encargan de la administración de recursos, como el cómputo, el almacenamiento y la red.

Ventajas de las tecnologías Serverless

• Costo: Solo pagas por lo que usas, ya que las tecnologías Serverless se facturan según el consumo de recursos y el tiempo de ejecución en lugar de tener costos fijos de servidores. Esto puede resultar en un ahorro significativo en comparación con la administración de infraestructura propia.
• Escalabilidad: Las aplicaciones Serverless escalan automáticamente según la demanda, lo que garantiza un rendimiento óptimo incluso en momentos de alta demanda. Esta escalabilidad dinámica elimina la necesidad de planificar la capacidad de los recursos y facilita el manejo de picos de tráfico inesperados.
• Desacoplamiento: Las tecnologías Serverless permiten desarrollar aplicaciones modulares y desacopladas, lo que facilita la actualización y el mantenimiento del software, a diferencia de un paradigma monolítico.
• Independencia tecnológica: Al no depender de una infraestructura específica, las aplicaciones Serverless pueden adaptarse fácilmente a cambios en los requisitos de negocio o tecnología.
• Foco en el negocio: Los desarrolladores pueden centrarse en la lógica de la aplicación para crear valor al negocio, en lugar de preocuparse por la administración y el mantenimiento de la infraestructura. Esto permite a los equipos de desarrollo ser más ágiles y entregar nuevas funcionalidades más rápidamente.
• Resiliencia: Dado que las aplicaciones Serverless se construyen con servicios en la nube de alta disponibilidad y tolerantes a fallos, es menos probable que experimenten interrupciones o tiempo de inactividad. Además, las aplicaciones Serverless pueden beneficiarse de la redundancia geográfica y el balanceo de carga que ofrecen los proveedores de servicios en la nube como AWS.

Principales servicios Serverless en AWS

Otros Servicios

Dependiendo del caso de uso los siguientes son servicios Serverless que son usados menos frecuentemente o para casos de negocios específicos. Así tenemos: AWS AppSync (servicio que facilita el desarrollo de aplicaciones basadas en datos en tiempo real y offline, utilizando una única API GraphQL), Amazon RDS Proxy (proxy de conexiones a Amazon RDS sin servidor), Amazon Aurora Serverless (base de datos relacional sin servidor), Amazon Redshift Serverless (bodega de datos Bigdata sin servidor), Amazon Neptune Serverless (base de datos de grafos sin servidor), Amazon Opensearch Serverless (base de datos clave-valor sin servidor).

Casos de uso frecuentes de tecnologías Serverless

Aplicaciones web y móviles:

Las tecnologías Serverless en AWS permiten construir aplicaciones web y móviles escalables y de alto rendimiento sin la necesidad de administrar infraestructura. En paradigmas como BaaS y FaaS, los desarrolladores pueden centrarse en la lógica de la aplicación y la experiencia del usuario, mientras que AWS se encarga de la escalabilidad, la seguridad y el mantenimiento de la infraestructura.

Procesamiento de imágenes y vídeos:

Las aplicaciones Serverless pueden procesar y transformar imágenes y vídeos en respuesta a eventos, como la carga de archivos en Amazon S3 o la solicitud de un usuario. Los servicios de AWS, como Amazon Lambda, Amazon Comprehend y/o Amazon Elastic Transcoder, pueden ayudar a automatizar tareas como el redimensionamiento de imágenes, reconocimiento de imágenes, extracción de metadatos y la transcodificación de vídeos.

Análisis de datos en tiempo real:

Las tecnologías Serverless en AWS pueden utilizarse para procesar y analizar grandes volúmenes de datos de diversas fuentes, como registros de aplicaciones, eventos de IoT o transacciones de comercio electrónico. Los servicios de AWS, como Amazon Kinesis, AWS Glue y Amazon Athena, pueden ayudar a extraer información valiosa de los datos y generar informes y visualizaciones en tiempo real o por lotes.

Automatización de flujos de trabajo (Workflows):

Las aplicaciones Serverless pueden automatizar y optimizar procesos empresariales, como la aprobación de documentos y requerimientos internos. Los servicios de AWS, como Step Functions y Amazon Simple Workflow Service (SWF), pueden ayudar a modelar, coordinar y ejecutar flujos de trabajo complejos y tareas de larga duración.

Pensamientos finales

Las tecnologías Serverless en AWS ofrecen una gran cantidad de ventajas y oportunidades para los desarrolladores y las empresas que buscan construir y desplegar aplicaciones en la nube.

Al eliminar la necesidad de aprovisionar, administrar y mantener la infraestructura, las aplicaciones serverless permiten a los equipos centrarse en el desarrollo de nuevas funcionalidades y mejorar la experiencia del usuario.

La escalabilidad y resiliencia implícita en estos servicios nos da la tranquilidad de tener continuidad en el negocio a un costo por uso y reducido frente a un provisionamiento y tecnologías on-demand.

Las tecnologías Serverless en AWS están transformando la forma en que las organizaciones desarrollan y despliegan aplicaciones en la nube. Al adoptar estas tecnologías y seguir las mejores prácticas de arquitectura y desarrollo, las empresas pueden reducir costos, mejorar la eficiencia y entregar soluciones innovadoras que satisfagan las necesidades y expectativas de sus usuarios y clientes.