El camino de Luft hacia la elasticidad - Parte 2: Auto-Scaling con historial de consultas
(engineering.ab180.co)Compartimos la experiencia de implementar un autoscaler basado en costos que aprovecha el historial de consultas para mejorar la elasticidad de Luft, una base de datos desarrollada internamente.
- En un trabajo previo se migró a una arquitectura de Shared Storage, pero para obtener beneficios reales era necesario contar con un sistema de auto-scaling eficiente.
- Se dejó atrás Kubernetes y se adoptó un enfoque de clúster self-managed usando AWS SDK, además de implementar un método para reanudar instancias detenidas, reduciendo el tiempo de scaling a alrededor de 10 segundos.
- En lugar del enfoque tradicional de auto-scaling basado en métricas rezagadas como uso de CPU/memoria, se desarrolló un modelo de predicción de costos utilizando el historial de consultas.
- Mediante la normalización de consultas (
canonicalization) se identifican consultas similares, y al implementar una función de costo que usa el historial de las consultas se logró una predicción precisa de recursos. - Al asignar recursos solo cuando son necesarios, sin overprovisioning, se redujo el costo de las instancias en aproximadamente 40% y se construyó un sistema elástico capaz de manejar incluso consultas pesadas.
Aún no hay comentarios.