Saltar al contenido
← proyectosdata

cloud-cost-predictor

123.000 VMs reales. 5,9 M$/mes recuperables. Una recomendación por máquina.

123.363VMs analizadas5,9 M$ahorro mensual identificado98,1%cobertura de intervalo CPU

El problema

El sobreaprovisionamiento cloud es un problema de incentivos: quien pide los recursos no es quien paga la factura, y apagar algo en producción siempre tiene más coste político que económico. El resultado es capacidad ociosa que nadie reclama. La complicación técnica es doble: detectar el desperdicio no basta — hay que decir exactamente qué hacer con cada máquina, y hacerlo con suficiente margen de confianza para que el equipo de infraestructura actúe. Y hay que hacerlo sin matar VMs que consumen poca CPU pero mucha memoria.

Los datos

Dataset público SAP Cloud Infrastructure (CC BY 4.0, Harvard Dataverse) con 123.363 máquinas virtuales reales y 30 días de telemetría: CPU y memoria por VM, percentiles y estadísticos de resumen. Los costes se calculan con precios reales de AWS EC2 on-demand (us-east-1) obtenidos de la Bulk Pricing API, lo que permite expresar el desperdicio en dólares por máquina, no solo en porcentaje.

Enfoque

  • Regresión cuantílica con XGBoost: seis modelos producen percentil 10 / mediana / percentil 95 para CPU y memoria por separado — el intervalo de confianza es parte del output
  • Función de pérdida asimétrica (3×): penaliza más subestimar el uso que sobreestimarlo; un falso positivo (apagar algo ocupado) cuesta mucho más que un falso negativo
  • VIF para limpieza de multicolinealidad: de las métricas disponibles se conservan solo 5 features por modelo tras eliminar las correlacionadas
  • Doble modelo CPU + memoria: la recomendación final es la más conservadora de las dos — una VM con CPU baja pero memoria alta no se toca
  • Spike detection: 7.822 VMs con z-score ≥ 2,5 en los últimos 7 días se redirigen a revisión manual independientemente de la predicción
  • Pitch deck interactivo con navegación por teclado, gráficos Plotly en vivo y animaciones de entrada — desplegado como página estática

Herramientas

python
xgboost
plotly

Resultado

5,9 M$/mes de desperdicio identificado: 502 VMs para apagar, 20.174 para redimensionar, 18.619 para revisar. El modelo CPU cubre el 98,1% de los casos reales dentro del intervalo predicho; el de memoria, el 87,6%. El 68% de la flota se mantiene intacta — conservadurismo deliberado.

Próximos pasos

El siguiente paso natural es orquestar el pipeline con Apache Airflow (refresco nocturno) y gestionar las transformaciones con dbt. Para el modelo de memoria, conseguir series temporales diarias —en lugar de solo estadísticos de resumen— permitiría detectar tendencias y estacionalidad, mejorando la cobertura desde el 87,6% actual. La validación temporal cruzada (por mes, no por fila) es también pendiente para blindar contra overfitting.