Cuando miles de compilaciones al mes convirtieron la CI en uno de nuestros tres principales gastos, vimos una oportunidad y la reconstruimos pensando en el coste, la escalabilidad y la resiliencia.
El sistema de Integración Continua (CI) de Webflow es fundamental para el proceso de desarrollo de nuestro monorepo. Como parte de ese proceso, ejecutamos un extenso conjunto de pruebas unitarias y basadas en navegador mediante la fragmentación dinámica de la suite en trabajos de Buildkite y el escalado horizontal según sea necesario para satisfacer la demanda de cómputo. Ejecutar decenas de miles de compilaciones al mes, con un equipo de ingeniería en constante crecimiento en Webflow, ha hecho que nuestras medidas de ahorro de costes anteriores se hayan quedado pequeñas. Por ejemplo, utilizamos el sistema de compilación Nx para optimizar la ejecución de pruebas en nuestro monorepo, pero nuestro complejo grafo de dependencias limita su eficacia. Además, nuestra suite de pruebas de humo está en sus inicios, por lo que seguimos ejecutando todas nuestras 88 000 pruebas (y sumando) para cada rama de prueba de solicitud de extracción en nuestra cola de fusión, que fusiona miles de PR al mes.
Como resultado, los costes de CI del equipo de Delivery Loop son considerables y ocupan el tercer lugar en el gasto general de ingeniería. Este elevado coste se debe principalmente al volumen de instancias EC2 necesarias para ejecutar nuestra suite de pruebas manteniendo un ciclo de retroalimentación corto para los ingenieros. Una ejecución completa de la canalización de Buildkite del monorepo (es decir, la compilación), que incluye compilar nuestro código para las pruebas y luego ejecutarlas, puede llevar más de 30 horas de máquina. Utilizamos más de 9000 vCPU y 36 000 GiB de memoria en los momentos de mayor demanda.
¿Cómo podemos reducir significativamente nuestros costes de CI sin sacrificar la fiabilidad del sistema o el tiempo de ejecución, y sin introducir trabajo manual para los ingenieros? Llevamos a cabo un esfuerzo de optimización específico, centrándonos en áreas clave como las instancias EC2, la configuración de AWS Config y los tamaños de los volúmenes EBS. Según Cost Explorer, estas áreas eran las tres principales fuentes de gasto de nuestra cuenta. Nuestros esfuerzos lograron una reducción del 33 % en los costes mensuales amortizados de CI, manteniendo al mismo tiempo el rendimiento y la fiabilidad.
Aprovechamiento de las instancias Spot
Redujimos significativamente nuestros costes de CI al migrar la mayor parte de nuestras cargas de trabajo a instancias spot de EC2. Aunque teníamos un plan de ahorro de instancias EC2 activo, nos limitaba a una familia de instancias específica, lo que desincentivaba la experimentación con otros tipos. Además, la cobertura del plan de ahorro no era suficiente para las necesidades de cómputo típicas de los días laborables y resultaba un desperdicio los fines de semana, cuando apenas se necesitaba capacidad. Las instancias spot ofrecen flexibilidad y un ahorro de costes sustancial, de hasta el 60 % en comparación con las instancias bajo demanda, lo que aborda directamente el principal factor de coste de nuestro equipo: el gasto en EC2. La mayor parte de nuestra carga de trabajo de cómputo consiste en trabajos de prueba, por lo que los trasladamos gradualmente mientras dejamos intactos los trabajos críticos, como nuestro trabajo de determinación de objetivos. Este movimiento requería abordar el riesgo inherente de que las instancias spot se interrumpan; observamos una tasa de interrupción del 13 % para el mes de abril. Gestionamos el riesgo de dos formas clave: integrando la resiliencia en el sistema y gestionando cuidadosamente el despliegue.
Diseño para interrupciones
Para garantizar que nuestra canalización de CI permaneciera estable a pesar de las posibles interrupciones de las instancias spot, implementamos mecanismos sólidos de reintento y puntos de control de pruebas. Nuestro enfoque aquí refleja las estrategias exitosas utilizadas por otras empresas.
- Utilizar los reintentos automáticos de trabajos de Buildkite. Esta función nos permite especificar que los trabajos interrumpidos por la recuperación de una instancia spot se reinicien automáticamente, evitando la intervención manual de los ingenieros de Webflow. Dado que las interrupciones pueden ocurrir en cualquier momento y un trabajo podría tener la mala suerte de ser interrumpido varias veces, especificamos un límite de 5 reintentos.
- Añadir puntos de control de pruebas. Esta solución, más compleja, nos permite guardar el progreso de las ejecuciones de prueba. Si una instancia spot se interrumpe, podemos reanudar la prueba desde el último punto guardado en lugar de reiniciar todo el archivo. Aprovechamos una instancia de Redis en la VPC de nuestro clúster de CI como un almacén de datos temporal y rápido para esta información de puntos de control. Esta elección se debió al gran volumen de pruebas, al elevado número de compilaciones diarias y a la naturaleza temporal de los datos. Un desafío al que nos enfrentamos aquí fue tener que implementar los puntos de control cuatro veces diferentes para los cuatro ejecutores de pruebas que utilizamos en nuestro monorepo.
Un despliegue gradual y supervisado
Por último, para evitar interrupciones a nuestros ingenieros durante esta transición, gestionamos cuidadosamente el despliegue de las instancias spot.
- Seleccionamos la estrategia de asignación optimizada por precio y capacidad para las instancias Spot. Esta estrategia da lugar a menos interrupciones de spot que una estrategia optimizada por precio, a un coste mayor. Aunque los puntos de control de pruebas reducen el coste de tiempo de una interrupción de spot, sigue existiendo una sobrecarga fija debido a que nuestros agentes necesitan clonar ramas, obtener imágenes de Docker o directorios de node_modules faltantes de nuestra caché e iniciar servicios. Inicialmente, no especificamos suficientes tipos de instancia para la estrategia, por lo que nos encontramos con limitaciones de capacidad porque EC2 no podía proporcionar suficientes instancias spot. Observamos regresiones en el rendimiento de la CI hasta que volvimos manualmente a las instancias bajo demanda. Para resolver el problema dando a la estrategia de asignación más opciones con las que trabajar, utilizamos el Instance Advisor para añadir tipos de instancia similares con el mismo número de vCPU y una baja tasa de interrupción. En algunos casos, eso incluyó tipos de instancia optimizados para red, disco o memoria.
- Realizamos experimentos iniciales en una versión de ensayo de nuestro entorno de CI. Comenzamos interrumpiendo instancias individuales en varios tipos de trabajo y luego pasamos a realizar experimentos de interrupción agresivos utilizando AWS Fault Injection Service (FIS). Estas pruebas nos permitieron identificar y solucionar problemas con nuestra configuración de reintento automático y el código de generación dinámica de canalizaciones sin afectar a las compilaciones de producción.
- Para los cambios que requerían pruebas de carga a nivel de producción, implementamos un sistema ligero de indicadores de funciones. Este sistema nos permitió controlar el uso de instancias spot sin necesidad de fusionar cambios de código en las ramas de PR. El uso de FIS no representaba con precisión las tasas de interrupción de spot del mundo real que veríamos al permitir el escalado automático para nuestras colas de instancias spot hasta sus recuentos máximos de instancias. Si observábamos una cantidad poco saludable de interrupciones, podíamos retroceder a nuestras colas bajo demanda, que seguían estando disponibles.
- Luego seguimos una estrategia de despliegue gradual, comenzando con solicitudes de extracción preliminares, luego expandiéndonos a todas las solicitudes de extracción y finalmente habilitándolas para la cola de fusión. Este enfoque por fases minimizó el riesgo de interrupciones y nos dio tiempo para supervisar el sistema a través de CloudWatch y las métricas avanzadas de cola de Buildkite. Ajustamos el sistema y acumulamos conocimientos en todo el equipo a lo largo del camino:
- Queríamos limitar el aumento del gasto resultante de duplicar la cantidad de colas y ASG. En cada fase del despliegue, ajustamos gradualmente los recuentos máximos de instancias disminuyendo el máximo para nuestros grupos de escalado automático (ASG) bajo demanda y aumentando el máximo para nuestros ASG de instancias spot. En otras palabras, estábamos sobreaprovisionando temporalmente el sistema, por lo que redujimos dónde se producía el sobreaprovisionamiento a medida que las necesidades de cómputo se trasladaban a las colas de instancias spot.
- Antes y durante el despliegue de las instancias spot en las PR preliminares, creamos un nuevo panel, añadimos alarmas automatizadas para las tasas de interrupción de spot y los tiempos largos de cola de trabajos de Buildkite, y redactamos manuales de guardia para gestionar el sistema. Necesitábamos que quien estuviera de guardia pudiera manejar las limitaciones de capacidad de spot, lo cual se podía solucionar ajustando la distribución porcentual del ASG entre spot y bajo demanda o añadiendo capacidad base bajo demanda. Normalmente elegíamos la última opción y descubrimos que funcionaba bien en la práctica para nuestra situación. Finalmente, dejamos de ver limitaciones de capacidad al añadir más tipos de instancia a la mezcla, como se describió anteriormente.
- Tras el despliegue en todas las PR y debido a las tasas de interrupción de spot que observamos, tomamos la decisión de implementar puntos de control de pruebas comenzando a nivel de archivo con metadatos de Buildkite como almacén de datos de puntos de control. Consideramos que las métricas eran lo suficientemente aceptables como para no volver a limitar el despliegue solo a las PR preliminares. Tras esa implementación, vimos mejoras en nuestras métricas, lo que permitió el despliegue fluido de las instancias spot en la cola de fusión. Luego realizamos un seguimiento con puntos de control a nivel de suite o de prueba, dependiendo del ejecutor, y pasamos a Redis para almacenar los resultados de las pruebas y manejar el aumento en el volumen de datos.
Este enfoque metódico para adoptar instancias de spot y gestionar sus interrupciones nos permitió lograr un ahorro de costes considerable sin comprometer la estabilidad ni la fiabilidad de nuestra infraestructura crítica de CI.
Exención de tipos de recursos de AWS Config
Para reducir aún más los costes, optimizamos nuestra configuración de AWS Config, que generaba gastos innecesarios debido al gran volumen de instancias EC2 de corta duración. AWS Config rastrea los cambios en los recursos de AWS, algo fundamental para la seguridad y el cumplimiento normativo. Sin embargo, para nuestra infraestructura de CI, creamos miles de instancias EC2 temporales cada día, lo que generaba una cantidad masiva de datos de seguimiento y costes asociados. Con el aumento en el número de instancias tras implementar las instancias de spot, también vimos crecer los costes de Config. Necesitábamos una forma de filtrar lo que se registraba sin crear brechas de seguridad. Afortunadamente, estos ajustes fueron bastante sencillos.
Abordamos este problema excluyendo selectivamente ciertos tipos de recursos EC2 del registro de AWS Config.
Ciertos tipos de recursos, como los volúmenes EC2, no eran críticos para nuestra monitorización de seguridad, así que creamos excepciones detalladas para excluirlos. Añadimos las excepciones, revisamos el Cost Explorer al día siguiente y realizamos ajustes adicionales hasta notar una reducción significativa de costes. Para compensar el hecho de que algunas reglas de cumplimiento no pueden funcionar sin estos datos, hemos optado por consultar periódicamente el Cost Optimization Hub.
Como resultado, eliminamos costes innecesarios sin comprometer nuestra postura de seguridad general.
Reducción de nuestros volúmenes EBS
Redujimos significativamente nuestros costes de CI ajustando el tamaño de nuestros volúmenes EBS, que anteriormente estaban sobredimensionados. Esta fue un área de ahorro potencial sorprendentemente grande, ya que muchas de nuestras instancias EC2 tenían volúmenes adjuntos innecesariamente grandes. Al analizar nuestros patrones de uso y métricas a través de los registros posteriores a los trabajos, identificamos oportunidades para reducir el tamaño de los volúmenes sin afectar al rendimiento.
Para nuestras instancias EC2 con almacenamiento local, optimizamos el tamaño del volumen para que coincidiera con el tamaño de nuestra AMI base, más un pequeño margen.
- Aquí fuimos precavidos: elegimos el tamaño mínimo de volumen EBS y añadimos un poco de espacio extra "por si acaso".
- También nos encontramos con problemas de agotamiento de inodos en el sistema de archivos ext4 predeterminado debido a la gran cantidad de archivos pequeños, algo típico en los directorios `node_modules`. Para resolverlo, cambiamos al sistema de archivos XFS para nuestros SSD, ya que gestiona mejor un gran número de inodos y, por lo general, ofrece un mejor rendimiento para nuestras cargas de trabajo.
Para nuestras otras instancias EC2, realizamos un análisis detallado y descubrimos que los discos adjuntos estaban significativamente sobredimensionados.
- Las métricas mostraron que muchos volúmenes podían reducirse aproximadamente a la mitad. Adoptamos un enfoque cauteloso y recortamos todos los volúmenes, asegurándonos de monitorizar el uso posteriormente.
- También optimizamos nuestro extenso sistema de caché de `node_modules`, mejorando su gestión del agotamiento de disco. Esta optimización implicó refinar nuestras políticas de limpieza para asegurar una gestión eficiente del espacio, eliminando de forma iterativa entradas de caché antiguas y borrando volúmenes de Docker antiguos cuya limpieza no era necesaria anteriormente.
Al abordar estos problemas, redujimos significativamente los costes de los volúmenes EBS manteniendo el rendimiento general de nuestro sistema.
¿Qué sigue?
Nuestro viaje de optimización de costes de CI no termina aquí. Hemos identificado varias áreas interesantes para seguir mejorando y con potencial para obtener ganancias de eficiencia aún mayores.
Adopción de Graviton: Evaluamos las instancias AWS Graviton y observamos beneficios prometedores en cuanto a coste-rendimiento. Sin embargo, encontramos algunos problemas de incompatibilidad con partes de nuestra infraestructura de CI y tuvimos que cerrar el proyecto antes de poder solucionarlos todos. Planeamos retomar las instancias Graviton más adelante este año. Estamos seguros de que esto permitirá nuevas reducciones de costes sin sacrificar el rendimiento.
Gestión del ciclo de vida de S3: Tenemos buckets de S3 que almacenan datos que no han dejado de crecer. Simplemente borrar todos los datos antiguos no es viable debido a cómo gestionamos los activos y las instantáneas del sitio, ya que no hay un prefijo común que podamos usar para aplicar reglas de ciclo de vida. Deberíamos poder mejorar nuestros scripts de copia de activos e instantáneas para usar S3 Object Lock en modo de gobernanza sobre estos objetos y luego activar las reglas de ciclo de vida, lo que nos permitiría ahorrar decenas de miles de dólares al año.
Al abordar estos próximos pasos, nuestro objetivo es seguir refinando nuestra infraestructura de CI, reduciendo costes y optimizando nuestros recursos.
Conclusión
Como resultado directo de estos esfuerzos de optimización, hemos logrado una reducción significativa del 33% en los costes mensuales amortizados de CI al comparar el gasto de finales del cuarto trimestre del año pasado con el de finales del primer trimestre de este año. Para desglosar un poco más la reducción, vimos una disminución del 42,7% en el gasto de instancias EC2, del 89,6% en el gasto de Config y del 42,4% en otros gastos de EC2. Ya estamos viendo estos ahorros reflejados en nuestros presupuestos y esperamos que la reducción crezca aún más en el segundo trimestre a medida que se note el impacto total de nuestros cambios más recientes.
Pero estas cifras representan mucho más que un simple ahorro de costes. Para los ingenieros de Webflow, esto significa una infraestructura de integración continua más rápida y fiable, ya que mi equipo reinvierte lo ahorrado en otras mejoras. Supone pasar menos tiempo esperando a que las compilaciones y pruebas terminen, al poder escalar horizontalmente más que antes, y dedicar más tiempo a crear funciones y resolver problemas complejos. Con estas optimizaciones, hemos sentado las bases para el crecimiento y la innovación futuros sin el lastre de unos costes excesivos. El impacto positivo de estos cambios se notará en nuestro día a día, permitiéndonos ofrecer un software de mayor calidad con más eficiencia. Estamos entusiasmados con el impulso logrado y el potencial que esto supone para nuestro equipo y nuestros usuarios.
¡Estamos contratando!
Buscamos talento en producto e ingeniería para que se una a nuestra misión de poner superpoderes de desarrollo al alcance de todos.
