Antes de comenzar
Inspeccionarás demanda real agregada con SQL real (DuckDB-Wasm), formularás una hipótesis sobre picos y SLA, configurarás una política de autoescalado y observarás instancias requeridas frente a activas. Cerrarás comparando proveedores con una restricción de cumplimiento obligatoria.
Producirás una evidencia de aprendizaje con tu hipótesis, tu política de escalado y tu decisión de proveedor justificada. Tiempo orientativo: 30–40 minutos.
¿Cómo debería escalar la infraestructura ante una demanda cambiante, equilibrando capacidad, SLA, costo y restricciones del proveedor?
- Contexto
- Finanzas de NexoRetail 360 pregunta por qué la nube cuesta lo que cuesta, y por qué no simplemente eligieron "la más barata".
- Problema
- Tu trabajo es dimensionar el autoescalado para una campaña de 24 horas y recomendar un proveedor con una decisión multicriterio, no solo por precio: algunos datos son regulados y exigen un cumplimiento mínimo que ninguna diferencia de costo puede compensar.
- Misión
- Configurar una política de capacidad (mínimo, máximo, margen de seguridad), ejecutar el escalado sobre demanda real, y comparar proveedores en costo, latencia, cumplimiento y soporte de forma ponderada.
- Decisión esperada
- Recomendar un proveedor para este escenario y justificar si pesó más el costo, la restricción de cumplimiento, o ambos.
Objetivos de la sesión
- Aplicar una política de autoescalado con mínimos, máximos y margen de seguridad.
- Detectar violaciones de SLA causadas por límites de capacidad, no solo por demanda.
- Comparar proveedores en costo, latencia, cumplimiento y soporte de forma ponderada.
- Reconocer cuándo una restricción obligatoria (cumplimiento regulatorio) debe primar sobre el costo.
Autoescalado, SLA y decisión multicriterio
Un autoescalado agrega la demanda por hora y calcula cuántas instancias requeridas hacen falta para cubrirla con un margen de seguridad. Las instancias activas son las que realmente corren, limitadas por una política de mínimo y máximo — cuando quedan por debajo de las requeridas, el SLA se viola. Sub-dimensionar (sub-aprovisionar) arriesga el servicio; sobre-dimensionar (sobre-aprovisionar) cuesta de más sin mejorar nada. La elección de proveedor añade una restricción obligatoria: ningún puntaje de costo compensa no cumplir un mínimo regulatorio.
Importante: en este laboratorio, la demanda agregada por hora en la sección "Laboratorio de datos" es REAL — DuckDB-Wasm la calcula con SQL genuino sobre un dataset incluido, un archivo local o datos sintéticos. La política de autoescalado, el cálculo de SLA y los precios/puntajes de proveedor son un MODELO DIDÁCTICO: los costos son valores ficticios, no tarifas comerciales reales.
Ver los conceptos en detalle qué son, por qué importan, qué observarás
- Demanda
- Qué es: solicitudes por minuto durante una hora del día. Por qué importa: es la entrada del modelo de autoescalado. Observarás: el gráfico de barras "Demanda de NexoRetail 360", real si importaste datos, sintética si no.
- Agregación por hora
- Qué es: la consulta SQL real que agrupa el dataset de demanda en 24 valores, uno por hora. Por qué importa: convierte datos crudos en la serie que consume el modelo de escalado. Observarás: el botón "Agregar por hora" del Laboratorio de datos.
- Capacidad por instancia
- Qué es: cuántas solicitudes por minuto atiende una sola instancia. Por qué importa: junto al margen, determina cuántas instancias hacen falta. Observarás: subir "Capacidad / instancia" reduce las instancias requeridas por hora.
- Instancias requeridas vs. activas
- Qué es: requeridas = lo que la demanda pide; activas = lo que la política de mínimo/máximo realmente deja correr. Por qué importa: cuando activas < requeridas, el SLA se viola. Observarás: la columna "Requeridas" vs. "Activas" en el detalle horario.
- Política de escalado
- Qué es: los límites mínimo y máximo de instancias que el sistema respeta siempre. Por qué importa: un máximo demasiado bajo genera violaciones aunque haya presupuesto. Observarás: subir "Máximo" reduce las "Horas con SLA violado".
- Margen de seguridad
- Qué es: un porcentaje extra de capacidad que se suma a la demanda observada antes de calcular instancias requeridas. Por qué importa: absorbe picos no vistos en el histórico. Observarás: subir "Margen de seguridad" sube las instancias requeridas incluso con la misma demanda.
- SLA
- Qué es: el compromiso de que la capacidad activa cubra la demanda observada. Por qué importa: es la métrica que el negocio realmente percibe. Observarás: "Horas con SLA violado" en el resultado del autoescalado.
- Sub-aprovisionamiento / sobre-aprovisionamiento
- Qué es: tener menos capacidad de la necesaria (arriesga el SLA) o más de la necesaria (cuesta de más sin beneficio). Por qué importa: ambos son errores de ingeniería, en direcciones opuestas. Observarás: "Uso promedio" muy bajo sugiere sobre-aprovisionamiento; violaciones de SLA sugieren sub-aprovisionamiento.
- Restricción obligatoria de proveedor
- Qué es: un mínimo de cumplimiento regulatorio que, si no se alcanza, descalifica al proveedor sin importar su puntaje. Por qué importa: evita que el costo, por sí solo, elija un proveedor inadecuado para datos regulados. Observarás: activa "Los datos incluyen información regulada" y compara el ganador antes y después.
Pasos del laboratorio
- Inspecciona la demanda real disponible.
- Formula tu hipótesis de proveedor ganador y de efecto de la restricción de cumplimiento.
- Agrega los datos por hora con SQL real.
- Configura la política de capacidad (mínimo, máximo, margen).
- Ejecuta el escalado de 24 horas.
- Observa instancias requeridas frente a activas y las horas con SLA violado.
- Analiza el uso promedio (sub- o sobre-aprovisionamiento).
- Compara proveedores, activando la restricción de cumplimiento si aplica.
- Decide qué proveedor recomendar.
- Genera tu evidencia justificando la decisión.
Hipótesis
Una hipótesis es tu predicción antes de observar los resultados. Regístrala ahora: una vez bloqueada, no podrás cambiarla, solo reformularla después de ver el resultado.
Completa las dos preguntas y pulsa «Registrar hipótesis y comenzar» para desbloquear la simulación de 24 horas.
Mientras configuras el autoescalado
- Demanda por hora — real (si importaste datos) o sintética.
- Capacidad configurada por instancia, mínimo y máximo.
- Instancias requeridas vs. activas hora a hora.
- Horas con SLA violado y uso promedio.
- Proveedor recomendado y si cumple la restricción de cumplimiento.
Laboratorio de datos: demanda real (DuckDB-Wasm)
DuckDB-Wasm agrega REALMENTE una serie de demanda por hora con SQL. La política de autoescalado (mínimos, máximos, margen, SLA) la sigue calculando el modelo JS de esta misma sección — DuckDB no simula autoescalado, solo agrega la demanda que ese modelo usa como entrada.
Los datos que selecciones o generes aquí se procesan en este navegador y no se envían al servidor del curso ni a ninguna API externa.
Inicializando motor local de datos…
Genera un dataset reproducible: la misma semilla produce siempre el mismo dataset.
Fuente: —
Filas (consulta real): —
Esquema
Agregación real (SQL)
Consulta ejecutada localmente mediante DuckDB-Wasm — datos reales, no inventados por JavaScript.
Demanda de NexoRetail 360
Cada barra representa solicitudes por minuto durante una hora del día (modelo didáctico, salvo que hayas importado demanda real en el Laboratorio de datos).
Antes de simular: ¿qué crees que pasará con el SLA si subes la intensidad de campaña sin subir el máximo de instancias?
Resultado del autoescalado
Simula 24 horas para ver un resumen basado en tus resultados reales.
Aquí verás la relación entre tu política de capacidad y las horas con SLA violado.
Aquí verás qué ajuste de capacidad o costo implicaría este resultado.
Comparador multicloud
Detalle horario
¿Qué proveedor recomendarías para este escenario?
Cierre conceptual
Lo que descubriste: cómo una política de escalado y una restricción obligatoria de cumplimiento cambian tanto el resultado técnico como la elección de proveedor.
Concepto para recordar: el proveedor más barato no siempre es viable si no cumple una restricción obligatoria.
Conexión con la próxima semana: en la Semana 8 usaremos datos históricos y un modelo predictivo para anticipar la demanda en vez de reaccionar a ella.
Genera tu evidencia
Esta evidencia resume tu hipótesis, tu política de escalado y tu decisión de proveedor. Puedes utilizarla para discusión, entrega o reflexión posterior.
Continuidad curricular
Antes: en la Semana 6 elegimos arquitectura y seguridad en la nube.
Después: en la Semana 8 usaremos datos históricos y un modelo predictivo para anticipar la demanda y apoyar decisiones proactivas de capacidad.