Ronald Hudson - Fotolia
Evalúe los costos de los servicios AWS sin servidor y aprenda cómo reducirlos
Las arquitecturas sin servidor ayudan a los equipos a implementarse más rápidamente, pero también a introducir una estructura de costos completamente nueva. Use este ejemplo paso a paso para saber qué esperar en una factura.
Las arquitecturas sin servidor pueden ayudarle a configurar rápidamente un punto final API y la lógica que lo respalda, así como a conservar los datos, sin la necesidad de iniciar o mantener un servidor. Estas arquitecturas también pueden reducir significativamente el tiempo que se tarda en enviar aplicaciones a la producción.
Muchos servicios en la nube de Amazon, como API Gateway, Lambda, Kinesis y DynamoDB, son componentes esenciales en arquitecturas sin servidor. Pero, aunque estas arquitecturas pueden negar el costo del mantenimiento del servidor, hay casos en que los costos sin servidor pueden sumarse rápidamente. Por lo tanto, es importante entender cómo los factores de costo en una plataforma sin servidor, especialmente a escala, para evitar una desagradable sorpresa en la facturación de AWS.
Echemos un vistazo a un patrón común sin servidor –una corriente de ingestión de datos– que podría consistir en los siguientes componentes:
- Datos entrantes, que incluyen métricas de sistema y aplicación, datos de registro y datos en tiempo real, como feeds de medios sociales, transacciones entrantes y clics en anuncios;
- Kinesis Data Streams, el cual ingiere cualquier volumen de datos entrantes, lo almacena temporalmente y luego lo pone a disposición para aplicaciones de consumidores. Kinesis conserva los datos para un valor predeterminado de 24 horas y hasta siete días. Es posible hacer que varios clientes escriban datos en Kinesis y consuman datos del servicio;
- Las funciones Lambda procesan los datos entrantes de Kinesis. Por ejemplo, puede configurar funciones de Lambda para realizar cálculos, ajustar el formato de datos y enviarlo a un almacenamiento permanente; y
- DynamoDB, que almacena datos permanentemente, donde otras aplicaciones pueden acceder.
Revisemos algunos escenarios de ingestión de datos y dividamos los costos sin servidores, servicio por servicio.
Amazon Kinesis
En Kinesis, usted paga proporcionalmente la frecuencia de los registros entrantes y la cantidad de datos en esos registros.
Una unidad de capacidad se denomina fragmento, el cual puede manejar hasta 1,000 transacciones por segundo y un ingreso de 1 Mbps. Si necesita ingerir datos a una velocidad mayor, puede agregar más fragmentos a su secuencia de Kinesis. Cada fragmento cuesta alrededor de $ 11 dólares por mes.
AWS también cobra por unidad de carga útil Kinesis PUT, que se mide en bloques de 25 KB. Cuantos más datos se ingresen en Kinesis, mayor será el costo.
AWS Lambda
En AWS Lambda, se paga por el número de ejecuciones de funciones, recursos informáticos que se consumieron y transferencias de datos. AWS cobra por ejecuciones de funciones a $0.20 centavos de dólar por millón, y cobra la fracción de $0.00001667 por gigabytes por segundo (GBps) de recursos de cómputo consumidos.
A medida que aumente la asignación de memoria o el tiempo de ejecución por función, también lo hará el consumo de cómputo utilizado. En muchos casos, una mayor asignación de memoria da como resultado ejecuciones más rápidas, lo que puede disminuir el tiempo de ejecución y, por lo tanto, el costo. Por lo tanto, debe encontrar el equilibrio correcto entre memoria, tiempo de ejecución y costo. Prueben diferentes asignaciones de memoria, optimicen su código y hagan pruebas, muchas.
Amazon DynamoDB
En DynamoDB, usted paga por el número de transacciones de lectura y escritura (también denominadas unidades de capacidad de lectura/escritura) que admite su tabla y también por la cantidad de datos almacenados en sus tablas. Cada unidad de capacidad de escritura cuesta $0,47 centavos de dólar, mientras que cada unidad de capacidad de lectura cuesta $0,09 centavos de dólar. AWS factura el almacenamiento de datos por hora a $0.25 centavos por GB.
Las unidades de capacidad de lectura/escritura miden el número de transacciones por segundo (TPS) y si las lecturas son fuertemente consistentes o parcialmente consistentes.
Registros de Amazon CloudWatch
Cuando se escribe software, también se deben escribir salidas de registro para propósitos informativos, de depuración o de monitoreo. Las funciones de Lambda no se ejecutan en un servidor que usted controla, por lo que escriben salidas de registro en registros de CloudWatch.
CloudWatch Logs cobra a los clientes según la cantidad de datos que se ingieren y almacenan. La ingestión de datos cuesta $0.50 centavos de dólar por GB, y el almacenamiento de datos cuesta $0.03 centavos por GB al mes. En la mayoría de los escenarios de bajo volumen, probablemente no se incurrirá en cargos significativos. Sin embargo, una vez que se ejecutan transacciones a escala, los costos de los registros de CloudWatch realmente pueden sumarse.
Costos muestra de la aplicación en tiempo real
Los escenarios de costos sin servidores variarán enormemente, pero echemos un vistazo a algunas cargas de trabajo de muestra para contextualizar los precios.
Digamos que tiene una función Lambda con 128 MB de memoria asignada. Esta función recibe eventos entrantes de una transmisión Kinesis y tarda un promedio de 100 ms en ejecutarse. Cada ejecución da como resultado 1 KB de datos enviados a CloudWatch Logs y una sola escritura a DynamoDB. Cada elemento que escribe en DynamoDB es mayor o igual a 1 KB, lo que significa que consume una unidad de capacidad de escritura.
Este es un escenario muy modesto en términos de recursos asignados, ya que demuestra la asignación de memoria más baja posible en una función Lambda y el tiempo de ejecución más bajo facturable. Las unidades de capacidad de escritura DynamoDB y la salida de Logs de CloudWatch por ejecución también conllevan costos modestos.
Si bien AWS tiene un generoso nivel libre, solo le proporciona aproximadamente 3 TPS para ejecuciones Lambda y 5 TPS en DynamoDB. Eso podría ser suficiente para entornos de prueba o incluso algunas aplicaciones de bajo volumen, pero en muchos casos, ese nivel gratuito se excederá rápidamente. Por esa razón, los siguientes cálculos no incluyen el nivel gratuito.
Si duplicamos la asignación de memoria Lambda a 256 MB, el costo aumenta en aproximadamente un 15%. Y, si usamos 128 MB de asignación de memoria Lambda con una carga útil duplicada de 2 KB, vemos que el costo aumenta aproximadamente un 80% en comparación con una carga útil de 1 KB.
La cantidad de datos procesados tiene un efecto más profundo en la etiqueta de precio final de AWS que la asignación de memoria Lambda. Tenga esto en cuenta cuando diseñe su arquitectura sin servidor.
Si 100 TPS, 1,000 TPS o 5,000 TPS suenan como altas tasas de ejecución, piénselo de nuevo. Es común ver crecer arquitecturas y eventualmente ingerir miles de registros por segundo. Si planea lanzar y hacer crecer una aplicación exitosa, debería considerar la posibilidad de ver cientos, o incluso miles, de ejecuciones por segundo.
Reducir la carga útil, optimizar la memoria
En primer lugar, para evitar los altos costos de procesamiento y almacenamiento de datos antes mencionados, reduzca su capacidad de carga de registros tanto como sea posible.
Además, Lambda GBps puede llegar a ser costoso. Encuentre la cantidad correcta de memoria para optimizar los tiempos de ejecución, pero tenga en cuenta estos factores:
- Eventualmente, el costo de memoria adicional excederá la reducción de costos obtenida de una ejecución más rápida.
- En algún momento, el tiempo de ejecución llegará a su límite y no se acelerará incluso cuando agregue memoria adicional.
- Las herramientas, como AWS X-Ray, pueden ayudarlo a depurar problemas de rendimiento.
- En algunos casos, no podrá optimizar los tiempos de ejecución. Por ejemplo, no puede controlar el tiempo que lleva invocar una API externa.
Utilice el procesamiento por lotes, reduzca la salida del registro
Lambda también le permite integrar funciones con una serie de eventos de AWS. En este caso, puede activar una función Lambda para cada registro de Kinesis documentado. Pero también tiene la opción de procesar registros en lotes y especificar un tamaño de lote.
El procesamiento por lotes reduce el número de ejecuciones de Lambda y, lo más probable, la cantidad de GBps consumidos. Por lo tanto, este método reduce los costos potenciales sin servidor, pero también agrega algo de latencia al proceso de registro. Esa latencia adicional solo puede ser de algunos milisegundos, segundos o incluso minutos; dependiendo del tamaño del lote, el tiempo de ejecución de Lambda y la velocidad de los datos entrantes.
Pero, si usted usa lotes entre Kinesis y Lambda, puede complicar el manejo de errores. Lambda sondea la transmisión para obtener registros de Kinesis, y luego ejecuta la función Lambda apropiada. Si la función falla, Lambda reintenta la ejecución hasta que tenga éxito. Si tiene una función Lambda que procesa eventos en lotes, asegúrese de delegar el manejo de errores a esa función.
El procesamiento por lotes puede reducir los costos de los servidores, pero asegúrese de probar esta estrategia a escala, medir la latencia y tener un plan para manejar los errores.
Además, debe reducir la producción a los logs de CloudWatch tanto como sea posible. Los registros de CloudWatch pueden resultar fácilmente en un 30% de su costo en esta arquitectura, lo que puede sumar hasta miles de dólares por año. Por otro lado, los registros detallados pueden dar como resultado una rápida resolución de problemas. Entonces, es importante alcanzar un buen equilibrio y ser consciente de la cantidad de datos que se imprimen en los registros.
Utilice DynamoDB Auto Scaling, Capacidad reservada
Mientras que nuestros cálculos de costos suponen una velocidad de ingesta de datos constante, muchas aplicaciones experimentan una carga variable. En este caso, use el escalamiento automático de DynamoDB para ajustar las unidades de capacidad de lectura/escritura cuando el uso aumente o disminuya para ahorrar dinero.
Pero tenga en cuenta que DynamoDB puede no escalar lo suficientemente rápido. En algunas situaciones, un pico de uso repentino podría desencadenar un evento de escala automática. Pero la capacidad de la tabla no puede aumentar tan rápido como sea necesario, lo que da como resultado excepciones de limitación de DynamoDB. Realice pruebas de carga que simulen los picos de uso más pronunciados antes de confiar completamente en la Escala Automática de DynamoDB.
Si está familiarizado con las instancias reservadas de EC2, DynamoDB ofrece un plan de compra similar, en el que se paga por adelantado la capacidad reservada. Es posible optar por términos de uno o tres años, y se puede ahorrar alrededor del 60% y 90%, respectivamente.
Para 100 unidades de capacidad de escritura con precios a pedido, costaría alrededor de $47 dólares por mes o $564 dólares por año. Sin embargo, se puede pagar $150 dólares por adelantado por un período de un año o $180 dólares por un período de tres años.
Además, se puede usar la capacidad reservada en varias tablas. Por lo tanto, si en algún momento no necesita tanta capacidad para una tabla en particular, AWS calcula el costo en función de la capacidad reservada total comprada en su cuenta de AWS o incluso entre cuentas vinculadas.
Sobre el autor: Ernesto Márquez es propietario y director de proyectos en Concurrency Labs, donde ayuda a nuevas empresas con el lanzamiento e incremento de sus aplicaciones en AWS. Se ha enfocado en construir arquitecturas sin servidor, automatizando todo y ayudando a sus clientes a reducir los costos de AWS. Su experiencia previa incluye empleos a nivel gerencial en AWS y Accenture.
