Protección de su cuenta de AWS frente a gastos inesperados mediante soluciones sin servidor

Por Luiz Yanai, arquitecto de soluciones y especialista sin servidor, AWS Brasil

El entorno de nube de AWS nos permite instanciar fácilmente varios recursos en cuestión de minutos para admitir la creciente demanda de solicitudes. Sin embargo, hay casos en que el crecimiento de las solicitudes se debe a errores de ejecución de la aplicación, ya sea debido a un problema de código o a la indisponibilidad momentánea de algún recurso. En ambos casos, para el modelo de precios en la nube, solo paga por el uso del servicio. Sin embargo, en el segundo caso pagaremos por un tráfico que no genera necesariamente valor para el negocio. Además, dependiendo de la implementación utilizada, se puede crear inesperadamente un alto costo. Este artículo presenta un escenario real donde ocurrió este problema y las alternativas arquitectónicas para evitarlo.

El escenario en el que se observó el problema es similar al siguiente dibujo. Es una arquitectura común sin servidor que utiliza los servicios de Amazon Simple Queue Service (SQS), AWS Lambda y Amazon DynamoDB.

Figura 1: Escenario común de procesamiento de mensajes asincrónicos

ESCENARIOS DE ERRORES COMUNES

En la arquitectura presentada anteriormente, varios tipos de errores pueden ocurrir generando algunos comportamientos específicos:

Tiempo de espera de la función A: En una función Lambda es posible establecer el tiempo de espera de ejecución de la rutina al valor máximo de 15 minutos. Si el tiempo de ejecución de la función excede el valor utilizado en la configuración, el procesamiento se detiene, es decir, no se termina correctamente y el mensaje no se elimina de la cola SQS entrante. Después de que expire el tiempo de invisibilidad del mensaje, otra instancia de la función Lambda puede intentar realizar el procesamiento de este mismo mensaje. En la configuración predeterminada de una cola SQS, una cola de mensajes muertas (DLQ) no está definida para recibir mensajes sin procesar (Figura 2). Por lo tanto, si hay una configuración de tiempo de espera deficiente y no se han configurado directivas DLQ, el mensaje se volverá a procesar varias veces mientras el mensaje está en la cola (definida por la propiedad configurable MessageRetentionPeriod que es de 4 días de forma predeterminada) consumiendo el tiempo de ejecución de cálculo de Lambda.

Figura 2 — Configuración de uso de DLQ en una cola de SQS

Tiempo de espera de la función A.1: En el escenario anterior, la función Lambda ‘función A.1 ‘está siendo invocada de forma asíncrona por la función ‘función A’. De la misma manera que en la situación anterior, durante la ejecución rutinaria puede encontrar un error de tiempo de espera. Debido a que es una llamada asíncrona, la función Lambda hace uso de una cola interna para controlar el procesamiento. Hay un comportamiento predeterminado en el procesamiento: si se produce un error en la función antes de la ejecución, Lambda devuelve el evento a la cola e intenta ejecutar la función de nuevo durante un máximo de 6 horas. Si el error ocurre después de la ejecución, Lambda intenta ejecutar hasta 2 veces. Recientemente, se ha incluido soporte para ajustar estos dos parámetros: duración máxima del evento de cola (60 s hasta 6 horas) y máximos intentos para llamadas asincrónicas. También puede configurar una cola DLQ para recibir mensajes que la función Lambda no procesa de forma asíncrona.

Figura 3: Configuración de procesamiento asíncrono de Lambda

Indisponibilidad de recursos externos ‘Recurso externo’: Debido a algún problema de falta de disponibilidad o error de comunicación, un servicio externo puede presentar problemas para ser invocados por la función Lambda. Imaginando un escenario donde un registro ya se ha insertado en una tabla de DynamoDB y luego se produce un error en la llamada a recursos externos, si no hay control de excepciones y compensación y la función Lambda devuelve un error, se generan registros duplicados en DynamoDB debido a nuevos intentos de ejecución que Lambda lo hace de forma predeterminada.

En todos los escenarios anteriores, los errores generados pueden conducir a un crecimiento en el uso de tiempo de cómputos de las funciones de Lambda y también a la generación de solicitudes duplicadas generando gastos adicionales.

Entienda el consumo de servicios

Para comprender el impacto financiero en la ocurrencia de los errores anteriores, es importante saber cómo cobrar los servicios involucrados. En las tablas siguientes se enumeran los factores clave que influyen en el precio del uso del servicio para la arquitectura anterior. Los valores se basan en la región de Virginia del Norte.

SQS

SQS tiene un costo basado principalmente en la cantidad de pedidos. El reprocesamiento de mensajes puede dar lugar a un aumento de los costos. Por lo tanto, la cantidad de intentos de retrabajo antes de enviar a una cola fallida o cola DLQ debe evaluarse correctamente.

Lambda

Para Lambda, lo que más debería impactar en el costo es el consumo de tiempo de cómputos. Es por eso que es importante controlar el tiempo de espera y el comportamiento de los mensajes para cumplir con los requisitos de las aplicaciones y evitar el consumo innecesario.

DynamoDB

En el caso de DynamoDB, si se utiliza la modalidad de capacidad aprovisionada, un aumento en el número de solicitudes no debería afectar al costo porque las solicitudes superiores a la capacidad aprovisionada serán aceleradas y gratuitas. Si se utiliza la opción Bajo demanda, la capacidad se ajusta a la demanda y puede generar gastos adicionales para solicitudes duplicadas.

CÓMO PROTECER SU CUENTA

Una forma fácil y práctica de proteger su cuenta de AWS de costes superiores a los esperados es utilizar buenas prácticas de supervisión del uso de recursos. Las dos opciones principales para hacer este control se presentan en la figura a continuación

Figura 4: Notificación de consumo mediante Amazon CloudWatch y AWS Budgets

Amazon CloudWatch es la solución estándar para supervisar sus recursos en la nube de AWS (y, en algunos casos, incluso en las instalaciones) y permite, por ejemplo, supervisar el gasto estimado en su cuenta y activar notificaciones configurando una alarma. La alarma cuenta la métrica de gasto y se compara con un umbral definido por el usuario. Si el valor supera el valor establecido, se puede enviar una notificación utilizando un tema de SNS.

Otra opción es utilizar AWS Budgets, que funciona de manera similar, pero le permite definir presupuestos por servicio o grupo de servicios, y también controlar el uso de instancias reservadas y la nueva función Saving Plans. El uso de un tema de SNS permite la notificación a través de diferentes medios, como correo electrónico, mensajes SMS, e incluso realizar una lógica personalizada a través de AWS Lambda.

A veces, una notificación simple puede no ser efectiva para una acción más rápida. En este caso, la recomendación es hacer automatización a través de la función Lambda para, por ejemplo, deshabilitar una fuente de eventos de la función Lambda que presenta el problema. Puede deshabilitar el consumo de eventos a través del SDK de AWS con la operación UpdateEventSourceMapping.

Con respecto a la comunicación asíncrona mediante AWS Lambda, una nueva funcionalidad que permite un mayor control en la gestión de errores de integración es AWS Lambda Destinations.

Figura 5: Configuración de destinos de eventos de éxito/fallo mediante la funcionalidad de destinos de Lambda

En la configuración de Lambda Destinations es posible establecer el destino de los mensajes de evento en la ocurrencia de errores, así como en caso de éxito. Los destinos pueden ser otra función de Lambda, un tema de SNS, una cola de SQS o Amazon EventBridge.

Figura 6: Configuración de las versiones de Lambda en la consola de AWS

Finalización y próximos pasos

En esta entrada de blog, describimos nuevas características que le permiten proteger sus cuentas de AWS de sorpresas facturadas no deseadas debido al elevado consumo de recursos mediante servicios sin servidor y buenas prácticas de administración.

Para obtener más información sobre las características y características utilizadas, visite los siguientes vínculos:

Sobre el autor

Luiz Yanai es arquitecto de soluciones en AWS y experto en tecnologías sin servidor, asiste a clientes de varios segmentos en sus viajes a la nube. Con más de 15 años de experiencia en arquitectura y desarrollo de soluciones que involucran negocios y sistemas de misión crítica

Blog de Amazon Web Services (AWS)