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”.

Tipos de Bases de Datos

Antes de empezar a describir las alternativas queremos puntualizar en esta sección los tipos de Bases de Datos comunes que podemos implementar en AWS, para posteriormente analizarlas cada una:

• Relacionales: aquí tenemos las tradicionales que se conceptualizan en base a relaciones de datos, como por ejemplo PostgreSQL, Oracle o SQL Server.
• NO SQL: aquí tenemos las bases de datos que definen a los mismos como Documentos y/o por Clave-Valor, como MongoDB o Redis.
• Datawarehouse: son aquellas usadas para OLAP, en donde se agrupan y procesan grandes cantidades de diferentes fuentes de datos para obtener un resultado, por ejemplo Teradata o Oracle Exadata.

Bases de Datos Relacionales

AWS nos ofrece seis soluciones de Base de Datos como Servicio (DBaaS) que son las siguientes: SQL Server, Oracle, MySQL Server, PostgreSQL, Aurora y MariaDB.

Todas estas incluyen el licenciamiento de uso (si se requiere) y la gestión de actualizaciones y updates del Sistema Operativo, incluido en el servicio, por lo que no tendrá que preocuparse de estos aspectos y costos.

Adicionalmente a la caracterización de cada una, AWS proporciona servicios de Alta Disponibilidad de Disaster Recovery para cada engine, de forma que puede automáticamente recuperarse y gestionar los respaldos; para esto usa Snapshots y varios Data Centers (AZ).

Puede optar por un servicio post pago por hora (on-demand) o pre pago por años (upfront) para el uso, y, tiene al alcance varias configuraciones con diferentes características de RAM y CPU e IOPS (I/O por segundo), además de múltiples opciones de auto escalamiento y monitoreo.

En cuanto a seguridades, se puede activar la encriptación de datos que complementado con redes privadas, administración de accesos de red con firewall (Security Groups) y gestión de usuarios y accesos (IAM) aseguran completamente la información.

Bases de Datos No SQL

AWS ofrece DynamoDB, ElastiCache (Redis y Memcached) como alternativas DBaaS, soluciones orientadas a Documentos y Clave-Valor completamente tolerantes a fallos, altamente disponibles y extremadamente escalables, con latencia de entre milisegundos a microsegundos según la configuración.

DynamoDB es operable a través de un API de acceso y a través de la consola de Administración y funciona completamente en el sentido Serverless. La característica Serverless nos permite solo preocuparnos por crear definiciones, y todo el almacenamiento, respaldos, alta disponibilidad y escalamiento es completamente transparente al uso.

ElastiCache tiene dos opciones Redis y Memcached, que funcionan con el protocolo propio, por lo que no requieren algo adicional en las aplicaciones.

Se puede optar por el uso post pago, tanto por petición o por capacidad provisionada, lo que significa que pagamos por el número de peticiones realizadas en un período o por hora de disponibilidad de una capacidad provisionada dependiendo del servicio. También existe la opción de pre-pago por nodo (instancia) reservada entre 1 a 3 años.

Tienen características de Backup y Restore automático y en el caso de DynamoDB cuenta con el concepto PITR (Point in Time Recovery) llegando a recuperar datos en le periodo de 5 minutos a 35 días en el pasado.

En cuanto las seguridades los datos pueden o son encriptados (dependiendo del engine) usando KMS, lo que de igual forma sumado a estrategias de VPN, Direct Connect, y, gestión de usuarios y accesos (IAM) aseguran completamente la información.

Bases de Datos Datawarehouse

Presentamos en esta sección al Servicio de Amazon Redshift como DBaaS, diseñado para gestionar un Datawarehouse y/o Business Intelligent.

Se trata de una base de datos relacional con excelente performance que puede escalar en orden de los Pentabytes y es almacenada por columna y no por registro, en el concepto “Store Data”, lo que reduce el IOPS (I/O por segundo).

Tiene la opción de gestión de backups automáticos con periodos de retención de 1 a 35 días y cuenta con opciones de configuración por nodos, desde un solo nodo hasta un máximo de 128 nodos. La ventaja de múltiples nodos, significa más computo en paralelo consiguiendo procesar datos y cálculos más rápidamente y tener indicadores en tiempo real.

De igual forma se puede optar por post pago (on-demand) o pre pago (upfront) de 1 a 3 años. El costo esta en relación al número de nodos utilizados/reservados y la configuración de RAM y CPU de cada nodo. Además se cancela un costo por backups y transferencias de datos entre lugares de la VPC (Virtual Private Cloud).

En cuanto a las consideraciones de seguridades, Redshift usa SSL para el tránsito de información y los datos están cifrados con AES-256. De igual forma como en los anteriores escenarios las estrategias firewall (Security Groups), redes privadas y gestión de usuarios y accesos (IAM) complementa la completa seguridad de la información.

EC2 y las Bases de Datos

Evidentemente existe la opción, completamente factible, de gestionar una Base de Datos de forma manual, a través del servicio IaaS AWS Elastic Cloud Computing (EC2).

EC2 nos permitirá provisionar Servidores en AWS con diferentes opciones de Sistemas Operativos y configuraciones en capacidad, como la RAM , el CPU y el Disco Duro, si desea saber más puede ver la Introducción al uso de Servidores en AWS.

Estos servidores combinados con discos de almacenamiento sean Elastic Block Storage (EBS) o Elastic File System (EFS) y un estratégía de Recuperación y Respaldos, nos dan la posibilidad de tener cualquiera de las altenativas descritas (incluso DynamoDB) implementadas manualmente de acuerdo a nuestro requerimiento.

En este escenario es importante considerar que los parches y actualizaciones del Sistema Operativo y el engine de Base de Datos son responsabilidad del usuario.

Otro aspecto importante es que los temas de Failover y Continuidad de Negocio se debe gestionar igualmente de forma manual, con estrategias como disponer nuestras Bases de Datos en diferentes AZ (Data Centers) y/o Regiones y uso de herramientas relacionadas.

En cuanto al tema de costos, se debe considerar aquellos relacionados a las instancias EC2, asi como los discos EBS y/o EFS utilizados, y probablemente la tranferencia de datos entre AZ y/o Regiones que demandaría un esquema de alta disponibilidad (HA).

Declaración

Existen muchas otras soluciones en AWS menos frecuentes pero disponibles, que no se mencionaron en esta Introducción a Bases de Datos en AWS, por temas de tiempo y al ser una introducción.

Las enumeramos con el fin de que ustedes puedan en algún momento investigar más; por supuesto si desean profundizar en alguna lo pueden solicitar en los comentarios. Los Servicios de Base de Datos son: DocumentDB, Keyspaces, Neptune, Timestream y QLDB.

Pensamientos Finales

Esperamos que les sea útil esta Introducción a Bases de Datos en AWS, y podamos haber provisto un vistazo, de forma muy general, a las opciones que disponen aquí.

Hemos visto las alternativas más omunes en diferentes casos e uso de las Bases de Datos y las cuestiones principales relacionadas a las características, su forma de uso, las configuraciones, los costos y las seguridades.

Les animamos a solicitar en los comentarios y/o redes sociales si desean profundizar en algun tema de los revisados.