olcortesbContexto:
Dentro de las características que tiene trabajar con serverless está la gestión de los eventos. Pasar un monolito a una arquitectura serverless o diseñar de cero una arquitectura dirigida por evento implica una gestión detallada de los mismos.
En este camino, uno de los problemas que se presenta con las lambdas como elemento de cómputo principal, es la posibilidad de que se generen loops infinitos, los loops son provocados por eventos que disparan a recursos de cómputo que vuelven a activar estos eventos, miremos en un gráfico:
La figura 1, muestra un diagrama con una lambda y una SQS, donde las flechas indican el sentido de las invocaciones, una lambda que dejar un mensaje en una SQS y una SQS que al tener un mensaje despierta la lambda, esta situación produce un loop infinito.
Esta situación se produce con cualquier recurso de AWS que pueda despertar una lambda con un evento y que a su vez la lambda pueda dejar un mensaje/objeto en el recurso.
El problema:
Lo ideal es evitar este tipo de diseños o tener Circuit Breacker para cortar estos loops infinitos, pero está claro que la programación sigue siendo por ahora humana, y propensa a errores.
Si estos loops no se detectan, pueden incurrir en gastos no deseados, que es una de las principales causas en el Cloud de AWS.
Soluciones
Prevenir antes que lamentar los costos, revisar el diseño, pruebas, una tabla de eventos para tener trazabilidad de lo que puede pasar.
Pero el objetivo de este artículo es hacer una revisión general del estado de este problema y en este aspecto desde el 2023 AWS viene anunciando herramientas como la detección automática y corte del loop sin intervención humana.
Las primeras integraciones fueron lambda + sqs y lambda + sns, pero se han anunciado más integraciones al pasar de los meses:
Anuncio y articulo oficial AWS:
Servicios que no son detectados al momento de escribir este artículo:
When another AWS service such as Amazon DynamoDB or Amazon Simple Storage Service (Amazon S3) forms part of the loop, Lambda can't currently detect and stop it.
Ref: https://docs.aws.amazon.com/lambda/latest/dg/invocation-recursion.html
Resultados y pruebas:
Para probar la detección automática, realice varias pruebas en ambientes controlados, a continuación algunos resultados:
Caso control:
Pruebas con S3:
Se puede observar que no se produjo detección como indica la documentación, realizando investigaciones se confirma que directamente no existe detección automática, que es necesario agregar un elemento a la arquitectura
Detección:
Se realizaron pruebas realizando el despliegue manual, y con infraestructura como código, con Node.js, Python, Java como lenguajes para la lambda.
Paso 1 Se detiene el loop: La figura 3 muestra una SQS más una Lambda en Node.js detenida automáticamente por la detección automática.
Paso 2 Se genera una métrica: Un parámetro importante que identifica cuantas detecciones automáticas tenemos es una métrica específica que creo AWS para este caso:
Paso 3 envíos de la alerta: Y finalmente tendría que llegar un email con esta información de la detección:
Conclusiones:
El sistema de detección automática de loop recursivo funciona para despliegues con y sin infraestructura como código, funciona para los runtime especificados en la documentación y en el caso de SNS, SQS que fueron los probados aquí.
No se puedo hacer saltar el detector de loop con S3 directamente, faltan realizar más pruebas con S3 y DynamoDB pasando por otro de los recursos como SNS o SQS
La herramienta de detección funciona correctamente para los casos de SQS y SNS, se recibieron las alertas y los correos asociados.
Es necesario seguir realizando pruebas en ambientes controlados para seguir estudiando esta herramienta de detección de loops.
¡Gracias por leer hasta la próxima!
