Recientemente decidí experimentar con la API en nuestro sitio web CardGames.io y probar el framework Serverless . En los últimos años, se ha convertido en un tema candente en el mundo de la tecnología, y postergué mi deseo de mantener actualizadas mis habilidades técnicas y probar algo nuevo. Por lo tanto, decidí pasar varias horas estudiando Serverless y ver si hay algún sentido en dicha ubicación de API.

Configuración actual

CardGames.io se ejecuta en AWS. Todas las páginas html, CSS, JavaScript e imágenes se almacenan en S3. Tenemos una API C # alojada en Elastic Beanstalk, se ejecuta en servidores Linux que ejecutan .NET Core con Docker. Finalmente, usamos CloudFront CDN antes de las estadísticas en S3 y API. A continuación se muestra el puntaje EC2 para agosto de 2019. Tenemos varias otras instancias, pero las API funcionan en m1.small (sí, t2.small probablemente funciona mejor) con el equilibrio de carga clásico. Si resume lo resaltado en rojo, entonces sale $ 164.21 al mes, no está mal. Incluso incluí EBS allí, porque no estoy seguro de cómo dividir estos gastos, tenemos varios proyectos en EC2.


Cuenta de AWS para Elastic Beanstalk

Tenemos dos entornos con 1-3 instancias en cada uno: activo e inactivo, porque la implementación de .NET Core en Docker en AWS lleva varios minutos, por lo que lo hacemos en un entorno inactivo y luego cambiamos los registros CNAME al recientemente implementado. La implementación lenta fue una de las razones por las que quería probar algo nuevo. Tenemos varios servidores con aplicaciones node.js en Beanstalk, y se implementan en segundos. Quería que fuera lo mismo para la API.

Cambiar a sin servidor

Estudié un muy buen tutorial de alojamiento de API web ASP.NET con el marco Serverless y descubrí que solo necesita agregar un archivo de configuración simple, una dependencia y una pequeña clase de inicio a un proyecto API existente. La implementación tardó unos veinte segundos, mucho mejor que en Beanstalk. Creo que gracias al soporte incorporado para .NET Core en Lambda (sin embargo, solo 2.2), mientras que en Beanstalk solo es compatible si usa un docker independiente. En cualquier caso, estaba feliz sin pensar en grupos de autoescalado, instancias máximas y similares.

Pruebas de rendimiento

Sin servidor en AWS es Lambda, que realmente aloja sus funciones, y la API de Front Gateway, que le permite agregar cosas como límites de velocidad, claves API y más. Alojé las características de Lambda en la región us-west-2, donde están los servidores de Beanstalk. Luego configuré la instancia de CloudFront para enrutar las solicitudes de uno de nuestros juegos a la nueva configuración sin servidor, y el otro a la configuración anterior de Beanstalk. Luego lanzó una prueba simple en dos URL: una sin servidor y la otra Beanstalk. Ambas URL invocaron la misma API, almacenando el mismo evento en la base de datos. Ejecuté 100 consultas para cada uno, aquí están los resultados:


Comparación de rendimiento

En varias ejecuciones, la configuración sin servidor fue un 15% más lenta (en todo caso, la ejecuté desde Islandia, de ahí el gran ping). La velocidad fue decepcionante, pero se mantuvo bastante alta: me di cuenta de que hay algo de sobrecarga para el frente de API Gateway frente a nuestra API: hay demasiadas funciones, incluso si no las usamos. ¡Entonces, triste, pero no crítico!

Precios

Honestamente, al principio no pensé en los precios. Simplemente decidí que pagar por el uso real probablemente sería más barato que pagar por las instancias 24/7. Por lo tanto, permitió que la nueva instalación sin servidor funcionara durante varios días y luego comenzó a verificar las cuentas. ¡Uy! ¡La factura de Lambda + API Gateway ya superó los cien dólares! Al principio, comencé a jugar con la configuración de Lambda, asignando menos memoria para guardar, pero cuando miré lo que estaba sucediendo bien, se hizo evidente que el problema estaba en la puerta de enlace. Estas son las tarifas de API Gateway:


Tasas de API de puerta de enlace

Nuestra API acepta alrededor de 10 millones de solicitudes por día. Esto es aproximadamente $ 35 por pasarela solo cada día . Además, Lambda cuesta alrededor de $ 10 por día, aunque esto puede reducirse asignando menos memoria. En conjunto, resultan alrededor de $ 45 por día, o $ 1350 por mes , frente a $ 164 por mes en Elastic Beanstalk. ¡Ocho veces más caro ! Me gustan las nuevas tecnologías y una implementación rápida, pero no voy a pagar $ 1200 adicionales por mes por esto. De vuelta a Beanstalk!

Conclusión

¡Probablemente, debería haberme familiarizado con los precios por adelantado y haber hecho algunos cálculos matemáticos! Pero, por supuesto, ¡tendría que hacer un trabajo real y no aprender valiosas habilidades técnicas! Estoy seguro de que, en algunas situaciones, las API de Gateway y Lambda son mejores que Elastic Beanstalk. Simplemente no es nuestro caso. Quizás si usa claves API, límites de velocidad y otras características de API Gateway, entonces tiene sentido pagar $ 3.50 por millón de solicitudes. Sería mejor simplemente poner un equilibrador de carga normal frente a Lambda. Hasta donde sé, esto no es posible; se requiere Gateway API para el acceso http a Lambda.

Pero incluso si acabáramos de pagar por Lambda, a $ 10 por día habría resultado $ 300 por mes en lugar de $ 164. Tenemos muchas consultas, pero cada consulta hace muy poco: básicamente, una llamada a DB por consulta. Quizás las consultas más pesadas que usan más tiempo de computación sean más adecuadas para Lambda, donde paga 100 ms de tiempo de computación. A continuación se muestra un informe para una solicitud. Como puede ver, usamos 3.50 ms de tiempo de cálculo, pero la factura está configurada para 100 ms, esto no es un redondeo débil.


Informe Lambda para una solicitud

Finalmente, no critico las API de Gateway, Lambda o Serverless en absoluto. Solo demostrando que para algunas cargas de trabajo son mucho más caras que el viejo y aburrido EC2 y Elastic Beanstalk. Sobre lo que nos quedaremos. También es probable que haya una forma mucho mejor o más eficiente de configurar el sistema, de ninguna manera soy un experto de AWS, por lo que si ve algún error flagrante, asegúrese de indicarlo en los comentarios.