Elegir la plataforma informática de AWS para su carga de trabajo en términos de costo no es una tarea fácil. Hice el cálculo para uno de los proyectos en los que trabajo y decidí compartir mis hallazgos. En este artículo, haré una comparación simplificada y de muy alto nivel para delinear una forma de hacer la comparación.

Como no soy un experto en el uso de todas las opciones de cómputo, lo animo a que use la sección de comentarios para corregir mis suposiciones incorrectas o sugerir mejoras e ideas que deberían incorporarse en el esfuerzo de comparación.

Ajuste de configuración

Con la Calculadora de precios de AWS , podemos comparar el costo mensual de los servicios de configuraciones aproximadamente equivalentes en potencia informática. Ya encontré que esto es una tarea difícil de hacer. Cada servicio tiene su propio tipo de configuración para elegir, con diferentes especificaciones no solo para vCPU y memoria, sino también para limitaciones en el ancho de banda de la red, restricciones para usar GPU o volúmenes EBS, etc.

Para simplificar las cosas, comparemos los servicios con requisitos solo para tener disponible 1 vCPU y aproximadamente 2 GB de memoria. Para Lambda, vCPU escala junto con el tamaño de memoria configurable. Lambda obtiene 1 vCPU por cada 1,769 GB de memoria , por lo que esta será nuestra elección para Lambda. Fargate tiene un número de vCPU y un tamaño de memoria configurables, por lo que podemos elegir exactamente 1 vCPU y 2 GB de memoria para que estén disponibles. Para EC2, para un valor tan bajo de vCPU y memoria en la generación actual de los tipos de instancia EC2, nuestra única opción es optar por la familia T que tiene un rendimiento explosivo. Esto trae otro nivel de complejidad, ya que el precio de la instancia se basa en una utilización inferior o igual al rendimiento de la CPU de referencia, y se aplican cargos adicionales cuando el consumo supera la referencia. Sin embargo, en los tipos de instancias de la generación anterior , el tipo de instancia m1.small se ajusta bastante bien a los requisitos con 1 vCPU y 1,7 GB de memoria, por lo que lo usaremos en lugar del tipo de instancia de la familia T. Además, las siguientes opciones no se consideraron en la comparación en aras de la simplicidad:

• CPU de arquitectura ARM
• Sistema operativo no Linux
• Detecte instancias y identifique tareas de Fargate
• Transferencia y almacenamiento de datos
• Instancias reservadas y planes de ahorro informático

Intuitivamente, EC2 debería ser el servicio menos costoso, seguido de Fargate y Lambda. El razonamiento es que cada próximo servicio requiere menos administración de infraestructura que el anterior, dejando las tareas de administración de infraestructura a AWS. El siguiente gráfico muestra el precio mensual de cada servicio en función de un porcentaje de utilización del tiempo.

El precio de EC2 es, de hecho, el más bajo, seguido de cerca por Fargate, mientras que el precio de Lambda es aproximadamente el doble de Fargate. El precio de EC2 podría reducirse aún más utilizando el tipo de instancia ampliable de la familia T, según las necesidades reales de su carga de trabajo.

Factores de facturación y puesta en marcha

Como vimos anteriormente, el costo de ejecutar Lambda es bastante alto en comparación con Fargate y EC2. Examinemos ahora los factores que pueden afectar por qué todavía podemos elegir Lambda para la informática a pesar de su precio más alto.

Lo primero a considerar es el intervalo de facturación de los servicios. EC2 se factura por segundo, con una duración mínima de 60 segundos. La facturación comienza cuando se lanza la instancia y se detiene cuando la instancia finaliza o se detiene. Fargate se factura por segundo, también con una duración mínima de 60 segundos. La facturación comienza cuando se extrae la imagen y se detiene cuando finaliza la tarea. Lambda, por otro lado, se factura por milisegundos sin umbral mínimo. La facturación comienza cuando su código de inicialización o controlador comienza a ejecutarse y se detiene cuando su código regresa o finaliza de otra manera.

Esta es una de las razones por las que Lambda es una buena opción para las cargas de trabajo que se ejecutan con poca frecuencia y son de corta duración.

En segundo lugar, activar una nueva instancia de EC2 lleva aproximadamente un minuto o más, de forma similar al inicio de una nueva tarea de Fargate. En comparación, la creación de una nueva instancia de Lambda suele tardar unos pocos cientos de milisegundos para tiempos de ejecución con lenguajes interpretados y hasta unos pocos segundos para tiempos de ejecución con lenguajes compilados.

Dependiendo de su carga de trabajo, puede darse el caso de que no pueda esperar un minuto para iniciar una instancia EC2 o una tarea de Fargate y, por lo tanto, necesite mantener la instancia o la tarea en ejecución. Este no es el caso de Lambda, ya que generalmente espera unos segundos para iniciar una nueva instancia. También puede mantener activa la instancia de Lambda por un precio diminuto haciendo ping cada pocos minutos por evento de CloudWatch.

Para subrayar los dos factores descritos anteriormente, ahora podemos comparar la facturación de servicios para un tipo de computación de controlador de API web, en el que no queremos tener retrasos en el inicio y estar listos para atender el tráfico en cualquier momento.

Tanto la instancia EC2 como la tarea Fargate deben utilizarse el 100 % del tiempo para no sufrir problemas de inicio. La facturación de Lambda, por otro lado, depende del tiempo real en el que se ejecuta el código del controlador para servir el tráfico a la API web. Por lo tanto, es preferible utilizar Lambda hasta que Lambda se utilice entre el 40 y el 50 % del tiempo, a pesar de su precio más alto por la misma potencia informática. Esto hace que Lambda sea adecuado para tareas de procesamiento rápido, por ejemplo, tareas de E/S, como leer datos de DynamoDB, etc.

Ejemplo del mundo real

Utilizamos la función Lambda en uno de nuestros proyectos para manejar solicitudes de API. Tiene una configuración de memoria de 2 GB principalmente para minimizar los retrasos en el arranque en frío, de lo contrario, podría tener una configuración más baja. Utiliza una biblioteca .NET que tiene más de 4 MB, por lo que las diferencias de arranque en frío entre, por ejemplo, 512 MB de memoria y 2 GB son notables.

El tráfico a Lambda aumentó constantemente durante los últimos meses y queremos saber si es hora de considerar la migración a otro servicio.

Según las métricas de utilización diaria, la función se invoca en promedio unas 250 000 veces al día, lo que equivale a 2,89 solicitudes por segundo. La duración media de ejecución es de alrededor de 250 ms. 2,89 por 250 es aproximadamente 723. Esto significa que la función se utiliza aproximadamente el 70 % del tiempo.

Las métricas de intervalos de un minuto más granulares muestran que los patrones de invocación son puntiagudos, sin embargo, en general, la carga es manejada por poco menos de 10 instancias simultáneas de la función.

Las métricas recopiladas indican que hemos superado el umbral en el que la facturación de Lambda era óptima. Potencialmente, para manejar el tráfico con la misma potencia informática y tener espacio para crecer, podríamos utilizar, por ejemplo, 2 tareas Fargate multi-AZ, cada una con 0,5 vCPU y 1 GB de memoria. Según los gráficos anteriores, esto reduciría los costos de facturación mensuales de $53,50 a $36,04. Podríamos intentar reducir aún más los costos utilizando instancias EC2 ampliables del tamaño correcto y alojando el contenedor o la aplicación allí. Por supuesto, esta es solo una idea teórica aproximada que requeriría verificación en la aplicación real.

Como nota final, me gustaría mencionar que los costos brutos de facturación deben ampliarse teniendo en cuenta la complejidad y los costos de gestión de la infraestructura. Para escenarios específicos, podría significar que aunque, por ejemplo, los costos de facturación de EC2 podrían ser un poco más bajos que los de Fargate o Lambda, la diferencia aún no compensa la complejidad adicional de la solución.

Somos ACTUM Digital y este artículo fue escrito por Milan Gatyas , .NET Tech Lead de Apollo Division. Siéntete libre de mantenerte en contacto.