Ahorrando $5,473 al Eliminar Balanceadores de Carga Redundantes

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:

Después de discutir esto con el equipo, fui el encargado de realizar la migración. Se solucionó rápidamente, ya que simplemente creamos un balanceador de carga principal usando IaC y, desde cada plantilla de servicio, solo lo asociamos con el balanceador de carga. Todo estuvo bien en general, pero tuvimos un inconveniente inesperado.

Como parte del plan, éramos conscientes de un posible corto tiempo de caida del servicio durante la ejecución de los nuevos cambios y se notificó a la empresa sobre esto, por lo que estábamos cubiertos. Además, estos cambios fueron planificados para ser ejecutados durante el período de menor actividad, minimizando el impacto para los clientes. Como teníamos 2 ambientes para pruebas, la lógica aquí es realizar los cambios allí primero para asegurarme de que todo esté funcionando antes de desplegar cualquier cambio en la infraestructura de Producción.

Los servicios de DEV fueron completamente migrados en pocas horas sin muchos problemas, lo usual, escribir mal una referencia y después de arreglar eso todas las otras plantillas fueron migradas sin problemas. Al día siguiente era el momento de migrar el ambiente QA y todo se veía bien hasta que empecé a migrar el servicio de Tax API, durante unos 10 minutos el servicio estuvo inactivo hasta que me di cuenta de ello gracias a las alertas configuradas para todas las API request realizadas desde la App de Producción. Inmediatamente supe que algo andaba mal con los cambios y realicé un rollback. Esto tomó como 15 minutos más y al final los errores desaparecieron y nuestra app de Producción estaba funcionando nuevamente.

Después de solucionar el problema, informé al CTO al respecto, mi sospecha era que probablemente el ambiente QA estaba configurado como referencia para el de Producción y termino siendo algo similar, mientras tanto el CTO y yo estábamos revisando la base de datos para determinar el tiempo total offline y el total de transacciones perdidas, para nuestra sorpresa no perdimos ninguna pero dejamos de recaudar impuestos de algunas transacciones, algo que el equipo de finanzas pudo arreglar manualmente en los libros.

Sabiendo que las operaciones no se vieron afectadas, comencé a investigar el problema, después de unos minutos leyendo el código, la razón era evidente, la referencia al API en el código tenía un valor por defecto para usar en caso de que la variable faltara. Sí, después de la implementación del Tax API, nadie agregó la variable y por default, los 3 ambientes apuntaban a QA.

Después de solucionar el problema, comencé a crear el documento Post Mortem como parte de nuestro protocolo en estos casos. Nuestro procedimiento Post Mortem es crear el documento basado en toda la información que encontramos sobre el problema, el tiempo registrado para cada evento, incluyendo las acciones y recomendaciones para el caso, y lo más importante Sin culpar a nadie. El documento no proporciona ningún nombre, solo eventos, la idea es averiguar qué está mal y compartirlo con todo el equipo para evitar los mismos eventos en el futuro.

Ahora que el problema principal estaba resuelto, continué con la migración, QA fue completamente migrado y al día siguiente era el momento de Producción, realicé los cambios durante el tiempo que consideramos seguro y que solo unas pocas transacciones se vieron afectadas, para asegurarnos de esto mapeamos todas las transacciones usando Grafana.

Reporte de Transacciones Individuales:

Mapa de Calor de Transacciones:

Después de la migración solo había 3 ALBs corriendo lo que significa alrededor de $57 mensuales o $684, lo que significa $5,473 en ahorros.