Cluster 24/7, costos -60%: qué hicimos diferente

La pregunta correcta en el momento correcto

‍

Este no es un blog sobre Kubernetes. Es sobre hacerse la pregunta correcta en el momento correcto.

‍

Nico, Cloud Engineer en Renaiss, se preguntó: "¿Por qué este cluster sigue corriendo 24/7?" Y esa simple pregunta terminó ahorrándole a Autoptic aproximadamente un 60% en costos operativos de su cluster de Kubernetes en AWS. Pero como en toda buena historia de infraestructura, el camino entre la pregunta y la solución tuvo sus vueltas. Acá te contamos qué pasó, qué se rompió (o casi se rompe), y qué aprendió Nico en el proceso.

‍

El problema: cuando "siempre estuvo así" deja de tener sentido

‍

Autoptic tenía un cluster de Kubernetes corriendo 24/7 en AWS (EKS). Al principio, tenía todo el sentido del mundo. "Estaba bueno para tener idea de cómo funcionaba el sistema del cliente constantemente", cuenta Nico. Cuando estás empezando con un cliente nuevo, querés ver todo: cómo se comporta el sistema en distintos momentos del día, qué patrones de uso tiene, dónde aparecen los cuellos de botella.

‍

Pero el tiempo pasó. El cluster creció. Lo que había empezado como un ambiente de pruebas con pocos servicios ahora corría una gran variedad de recursos. Y seguía prendido 24 horas al día, 7 días a la semana. "Con el rápido crecimiento se notaba que en algún momento iba a haber que hacer algo con respecto a los gastos", explica Nico.

‍

El problema era evidente: ya no había información relevante que justificara mantener todo corriendo constantemente.

‍

El impacto: cuando el problema es interno pero igual duele

‍

A diferencia de muchos incidentes de infraestructura, este no afectaba directamente a los usuarios finales. Todo funcionaba perfectamente desde su perspectiva. El impacto era interno: costos operativos que crecían sin necesidad. Recursos de AWS que se consumían fuera de horarios laborales, cuando nadie realmente los necesitaba.

‍

"Es interno, con respecto a usuarios nada", aclara Nico. "Pero en servicios y negocio aportó ahorros significativos." Además, estaba la oportunidad de mejorar la arquitectura. La solución anterior era simple: un nodo grande corriendo todo el tiempo. Pasar a varios nodos administrados por Karpenter iba a dar "un pantallazo de cómo es una solución más 'real'", más preparada para escalar y adaptarse a demanda real.

‍

La solución: Karpenter

‍

La idea era clara: implementar una manera inteligente de eliminar recursos fuera de horarios laborales. Nico implementó Karpenter dentro del cluster con jobs que escalan y desescalan recursos según horarios. Básicamente, pasar de "un nodo grande siempre activo" a "varios nodos que Karpenter administra según demanda real".

‍

"Implementamos Karpenter dentro del cluster con jobs que corren tanto para escalar como para desescalar recursos fuera de horarios laborales", explica. Karpenter es un auto-scaler de código abierto diseñado específicamente para Kubernetes en AWS. A diferencia de otras soluciones, Karpenter puede tomar decisiones más granulares sobre qué tipo de instancias usar y cuándo, optimizando costos y performance al mismo tiempo.

‍

El resultado fue contundente: aproximadamente 60% de reducción en los costos de operación del cluster de Autoptic. Pero como todo en infraestructura, la solución trajo sus propios desafíos y aprendizajes.

‍

Lo que se rompió (o casi)

‍

"¿Se rompió algo después?", le preguntamos a Nico. "Por suerte no", responde. "Pero hay un problema bastante común con Karpenter que es importante conocer." El problema es casi filosófico en su ironía: Karpenter corre un controlador que maneja los nodos de tu cluster. Y ese controlador también corre dentro de tu cluster.

‍

"En el caso de que Karpenter elimine el nodo donde está el controlador por alguna razón, es como que Karpenter se auto-elimina y tu cluster va a quedar como está", explica Nico. Es el equivalente en infraestructura de cortarte la rama del árbol sobre la que estás sentado. El sistema que decide qué nodos eliminar puede, en teoría, eliminarse a sí mismo. ¿Le pasó a Nico? No. Pero saber que puede pasar cambia cómo diseñás e implementás la solución. Como dice Werner Vogels, CTO de AWS: "En el mundo del desarrollo, todo se rompe todo el tiempo." La diferencia está en estar preparado.

‍

El aprendizaje: implementar de a partes, siempre

‍

Si hay algo que Nico se llevó de este proyecto, es una filosofía de implementación que ahora aplica en todo. "Aprendí a implementar cosas de a partes que vayan funcionando, en vez de armar todo de una", cuenta. "Una vez que tenés partes andando, es más fácil ver qué se rompe cuando vas agregando algo nuevo." Además: probar en escala más chica antes de implementar. No arrancar con todo el cluster en producción. Empezar con un ambiente controlado, verificar que funcione, y después escalar.

‍

La decisión constante: ¿que funcione o que quede perfecto?

‍

Le preguntamos a Nico si en algún momento tuvo que decidir entre "que quede perfecto" vs "que funcione". "Sí", responde sin dudar. "Como se iban implementando de a partes, fue más que nada hacer cosas que funcionen hasta que quede bien." Esa tensión entre velocidad y perfección es constante en infraestructura. Y la respuesta de Nico es pragmática: primero que funcione, después que quede perfecto. Pero siempre con la mirada puesta en mejorar. Porque en infraestructura cloud, las cosas se rompen. La diferencia está en estar preparado, implementar de a partes, y aprender en el camino.

‍

¿Querés optimizar tu infraestructura cloud?

‍

En Renaiss ayudamos a empresas a resolver problemas reales de negocio a través de tecnología. Desde optimización de costos hasta arquitectura cloud escalable.

‍

Si tenés un cluster corriendo 24/7 y te preguntás si realmente tiene sentido, hablemos. Podemos hacer una evaluación de tu infraestructura actual y encontrar oportunidades de optimización.

‍