Una de las primeras implementaciones de infraestructura que hice fue migrar la app principal de 3 servidores EC2 a ECS Fargate. Este fue el resultado de una conversación que tuve con el CTO cuando propuse ayudar con algunas tareas de DevOps.

Hubo varias razones que me impulsaron a comprometerme con esto. Primero, cuando comencé a trabajar para la compañía tuve acceso a AWS y descubrí que nuestros servidores estaban sobredimensionados y estábamos pagando demasiado por ellos. El uso de CPU del servidor principal estaba por debajo del 5%, este se encargaba de ejecutar un montón de trabajos cron, y los otros 2 servidores estaban por debajo del 2% en uso de CPU. La memoria RAM no era diferente.

Empezar a usar plantillas IaC fue una mejora en nuestras operaciones, ya que cuando queriamos desplegar un nuevo ambiente, simplemente copiamos una plantilla similar y haceiamos algunos pequeños cambios para adaptarla a la nueva infraestructura. Pronto descubrimos un problema con este patrón, estábamos creando balanceadores de carga de aplicación para cada nuevo servicio desplegado.

No eran taaaantos, algo así como 9 servicios tal vez, pero el problema es que también implementamos ambientes para fines de prueba, en nuestro caso Desarrollo y QA además de Producción, y son una réplica exacta, obviamente con menor capacidad, pero cuando hablamos de los ALBs, estos tienen un costo base de alrededor de 19$ por tenerlos corriendo y un costo variable que depende del uso llamado LCU. En la siguiente tabla podemos ver los costos totales asociados:

Antes de que empezara a hacer cambios en la infraestructura, la regla era simplemente subir un nivel en el tamaño del servidor, cada vez que había un pico y se confirmaba que la base de datos era la causa, se aumentaba el tamaño del servidor y en algún momento teníamos una sola instancia 8xlarge para nuestra base de datos principal.

En el pasado no se había implementado ningún sistema de logging y las acciones se basaban únicamente en el uso de recursos. Empezamos a tener una mejor visibilidad de nuestros servicios después de implementar Datadog en AWS, establecimos alertas para el uso de recursos y también habilitamos los logs de la base de datos, incluyendo los slow queries logs.

Podrías estar pensando, ¿Quién despliega una base de datos en una subnet pública? Aún peor, fue desplegada en la VPC pública default de AWS con el acceso público habilitado, esto es lo que pasa cuando los servicios son desplegados solo porque sí, sin pensar en la implementación, sino solo en los requerimientos del negocio.

Al principio fue un poco complejo simplemente cambiar el acceso público a deshabilitado, ya que había algunas herramientas externas de análisis de datos que estaban extrayendo información de la base de datos cada pocas horas, la primera vez que lo intenté, terminé en una llamada con el CTO y el equipo de Análisis de Datos preguntándome por qué deshabilité el acceso público. Respuesta simple - Seguridad.

En el pasado, estábamos usando la solución VPN de AWS, y aunque el costo por hora parece barato, la verdad es que los costos escalan rápidamente cuando todo el equipo necesita estar conectado. Éramos un equipo pequeño.

En algún momento, estuve investigando un pico en la facturación, y marqué migrar de la solución AWS VPN a OpenVPN como una posible mejora.

Costos de AWS VPN:

El servicio de AWS estaba funcionando como se esperaba; no teníamos ninguna queja al respecto. Pero cuando comparamos los costos, usar OpenVPN era mucho más barato que usar el servicio AWS VPN. Para dar una idea de cómo funciona OpenVPN en términos de licenciamiento, proporcionan 2 conexiones gratis, y como estábamos pagando anualmente, cada licencia costaba $7/mes.