Resultados experimento 1 - galoryzen/equipo8-pfinal GitHub Wiki
Resultado del Experimento 1
Título del experimento
Validación de latencia de búsqueda de hospedaje con patrón cache-aside (Redis) bajo carga pico y determinación del umbral de quiebre del SLA
Tabla de Contenidos
- Resultado del Experimento 1
- Título del experimento
- Tabla de Contenidos
- 1. Objetivo del experimento
- 2. Hipótesis
- 3. Metodología
- 4. Resultados
- 5. Análisis de los resultados
- 6. Conclusiones
- 7. Impacto en la arquitectura propuesta
- 8. Evidencias
1. Objetivo del experimento
Validar que la táctica de redundancia de información (cache-aside con Redis) permite al Catalog Service cumplir el SLA de latencia p95 ≤ 800ms para búsquedas de hospedaje bajo carga pico esperada (100 usuarios concurrentes), y determinar el umbral de carga y hit ratio por debajo del cual el SLA se quiebra bajo condiciones de stress test (300 usuarios concurrentes).
2. Hipótesis
La táctica arquitectónica redundancia de información implementada mediante el patrón cache-aside con Redis es suficiente para cumplir el SLA de p95 ≤ 800ms bajo carga pico esperada (100 usuarios concurrentes) en todos los escenarios de hit ratio (HOT, MIXED, COLD). Sin embargo, bajo carga extrema (300 usuarios concurrentes), se espera que el SLA se quiebre en algunos escenarios, particularmente en el baseline (sin caché) y posiblemente en el escenario COLD (bajo hit ratio), permitiendo identificar el umbral de quiebre y validar la efectividad del caché para mitigar este riesgo.
El punto de sensibilidad identificado es el cache hit ratio combinado con el nivel de carga: bajo alta carga y bajo hit ratio, la mayoría de búsquedas golpearán directamente a PostgreSQL, aumentando la latencia y potencialmente quebrando el SLA. El experimento busca determinar estos umbrales.
3. Metodología
3.1 Infraestructura
El experimento se ejecutó sobre la infraestructura desplegada en AWS:
| Componente | Configuración |
|---|---|
| Catalog Service | ECS Fargate |
| PostgreSQL | Amazon RDS |
| Redis | Amazon ElastiCache Redis |
| Load Balancer | AWS ALB |
| Service Discovery | Cloud Map DNS (VPC interna) |
3.2 Generador de carga
Se utilizó Locust ejecutado desde una máquina local contra el ALB público. Cada usuario simulado:
- Envía un
GET /api/catalog/searchcon parámetros de búsqueda (ciudad, fechas, capacidad) - Espera un think time aleatorio de 1-3 segundos (simula comportamiento real)
- Repite durante toda la duración del escenario
Configuración de carga:
- Usuarios concurrentes: 100 (carga pico esperada) y 300 (carga extrema)
- Spawn rate: 10 usuarios/segundo (100 usuarios) y 30 usuarios/segundo (300 usuarios)
- Duración: 5 minutos por escenario
- TTL del caché: 90 segundos (1.5 minutos) para escenarios con caché, 0 segundos (desactivado) para baseline
3.3 Escenarios de carga
Se diseñaron 8 escenarios para evaluar el comportamiento bajo dos niveles de carga y diferentes configuraciones de caché:
Escenarios con 100 usuarios (carga pico esperada):
| Escenario | Descripción | Hit Ratio Esperado | TTL |
|---|---|---|---|
| Baseline (TTL=0) | Cache desactivado, todos los requests van directo a PostgreSQL. Escenario MIXED sin caché. | 0% | 0s |
| COLD (TTL=90) | Todos los usuarios buscan combinaciones únicas de ciudad/fechas/capacidad (baja repetición) | Bajo (<30%) | 90s |
| MIXED (TTL=90) | 80% de usuarios buscan queries HOT (repetidas), 20% buscan queries COLD (variadas) | Medio-Alto (~70%) | 90s |
| HOT (TTL=90) | Todos los usuarios buscan las mismas combinaciones de ciudad/fechas/capacidad (alta repetición) | Muy alto (>90%) | 90s |
Escenarios con 300 usuarios (carga extrema - stress test):
| Escenario | Descripción | Hit Ratio Esperado | TTL |
|---|---|---|---|
| Baseline (TTL=0) | Cache desactivado, todos los requests van directo a PostgreSQL. Escenario MIXED sin caché. | 0% | 0s |
| COLD (TTL=90) | Todos los usuarios buscan combinaciones únicas de ciudad/fechas/capacidad (baja repetición) | Bajo (<30%) | 90s |
| MIXED (TTL=90) | 80% de usuarios buscan queries HOT (repetidas), 20% buscan queries COLD (variadas) | Medio-Alto (~70%) | 90s |
| HOT (TTL=90) | Todos los usuarios buscan las mismas combinaciones de ciudad/fechas/capacidad (alta repetición) | Muy alto (>90%) | 90s |
3.4 Clasificación de respuestas
| Código | Significado | Clasificación |
|---|---|---|
| 200 | Búsqueda exitosa | Éxito |
| 502 | Error interno del servicio | Fallo de infraestructura |
| 500 | Error de procesamiento | Fallo de infraestructura |
4. Resultados
4.1 Tabla resumen general
| Escenario | Usuarios | Requests | Fallos | Tasa de error | RPS | p50 | p95 | Max | Cumple SLA |
|---|---|---|---|---|---|---|---|---|---|
| Baseline 100 | 100 | 18,227 | 0 | 0.00% | 60.95 | 100ms | 130ms | 550ms | Sí |
| COLD 100 | 100 | 18,257 | 0 | 0.00% | 61.07 | 100ms | 130ms | 490ms | Sí |
| MIXED 100 | 100 | 18,298 | 0 | 0.00% | 61.24 | 100ms | 130ms | 670ms | Sí |
| HOT 100 | 100 | 18,311 | 0 | 0.00% | 61.29 | 100ms | 130ms | 420ms | Sí |
| Baseline 300 | 300 | 52,639 | 7 | 0.01% | 175.83 | 110ms | 430ms | 3,700ms | Promedio sí, picos no |
| COLD 300 | 300 | 54,385 | 0 | 0.00% | 181.55 | 100ms | 200ms | 1,900ms | Promedio sí, picos exceden |
| MIXED 300 | 300 | 54,691 | 1 | 0.00% | 182.77 | 100ms | 140ms | 1,300ms | Promedio sí, picos en límite |
| HOT 300 | 300 | 54,764 | 1 | 0.00% | 182.96 | 100ms | 140ms | 1,700ms | Sí |
4.2 Resultados - Carga pico esperada (100 usuarios)
4.2.1 Comparación baseline vs cache (100 usuarios)
| Métrica | Baseline (TTL 0) | COLD (TTL 90) | MIXED (TTL 90) | HOT (TTL 90) |
|---|---|---|---|---|
| p50 | 100ms | 100ms | 100ms | 100ms |
| p95 | 130ms | 130ms | 130ms | 130ms |
| RPS | 60.95 | 61.07 | 61.24 | 61.29 |
| Tasa de error | 0.00% | 0.00% | 0.00% | 0.00% |
4.2.2 Impacto del hit ratio (100 usuarios)
| Escenario | Hit Ratio Medido | p95 | Cumple SLA | Margen |
|---|---|---|---|---|
| HOT | 99.89% | 130ms | Sí | 6.15x |
| MIXED | 84.38% | 130ms | Sí | 6.15x |
| COLD | 57.31% | 130ms | Sí | 6.15x |
| Baseline | 0% | 130ms | Sí | 6.15x |
4.3 Resultados - Carga extrema (300 usuarios)
4.3.1 Comparativa baseline vs cache (300 usuarios)
| Métrica | Baseline (TTL 0) | COLD (TTL 90) | MIXED (TTL 90) | HOT (TTL 90) |
|---|---|---|---|---|
| p50 | 110ms | 100ms | 100ms | 100ms |
| p95 | 430ms | 200ms | 140ms | 140ms |
| RPS | 175.83 | 181.55 | 182.77 | 182.96 |
| Tasa de error | 0.01% | 0.00% | 0.00% | 0.00% |
4.3.2 Impacto del hit ratio (300 usuarios)
| Escenario | Hit Ratio Medido | p95 | Cumple SLA | Margen |
|---|---|---|---|---|
| HOT | 99.92% | 140ms | Sí | 5.7x |
| MIXED | 89.04% | 140ms | Promedio sí, picos en límite | 5.7x (promedio) |
| COLD | 80.42% | 200ms | Promedio sí, picos exceden | 4.0x (promedio) |
| Baseline | 0% | 430ms | Promedio sí, picos no | 1.86x (promedio) |
4.3.3 Identificación del quiebre del SLA
| Escenario | p95 Promedio | p95 Máximo Observado | Excede SLA (800ms) | Factor de exceso | Observaciones |
|---|---|---|---|---|---|
| Baseline 300 | 430ms | ~3,600ms | Sí (picos) | 4.5x | Promedio cumple, pero picos temporales exceden SLA |
| COLD 300 | 200ms | ~1,650ms | Sí (picos) | 2.1x | Promedio cumple, pero picos temporales exceden SLA |
| MIXED 300 | 140ms | ~800ms | En límite | 1.0x | Promedio cumple, picos temporales justo en límite del SLA |
| HOT 300 | 140ms | ~1,600ms (cache warming) | No | - | Pico inicial de cache warming, luego estabilizado < 300ms |
4.4 Desglose de errores
| Escenario | Tipo de error | Cantidad | Porcentaje |
|---|---|---|---|
| Baseline 100 | Sin errores | 0 | 0.00% |
| COLD 100 | Sin errores | 0 | 0.00% |
| MIXED 100 | Sin errores | 0 | 0.00% |
| HOT 100 | Sin errores | 0 | 0.00% |
| Baseline 300 | 502 Bad Gateway | 7 | 0.01% |
| COLD 300 | Sin errores | 0 | 0.00% |
| MIXED 300 | 502 Bad Gateway | 1 | 0.00% |
| HOT 300 | 502 Bad Gateway | 1 | 0.00% |
Análisis de errores:
Los errores observados son todos de tipo 502 Bad Gateway y son esporádicos (0.00-0.01% de tasa de error), atribuibles a condiciones transitorias de la infraestructura o timeouts durante períodos de alta contención. No están relacionados con la lógica del caché sino con condiciones de infraestructura bajo carga extrema.
5. Análisis de los resultados
5.1 Comportamiento bajo carga pico esperada (100 usuarios)
5.1.1 Escenario Baseline (TTL=0) - 100 usuarios
Resultados: 18,227 requests, 60.95 RPS, p95 = 130ms (cumple SLA con margen 6.15x), hit ratio 0%. El sistema muestra comportamiento estable con picos ocasionales hasta ~380ms, todos por debajo del SLA. PostgreSQL puede manejar ~60 RPS sin degradación significativa.
5.1.2 Escenario HOT (TTL=90) - 100 usuarios
Resultados: 18,311 requests, 61.29 RPS, p95 = 130ms (idéntico al baseline), hit ratio 99.89%. Pico inicial de cache warming (~250ms) transitorio. Reducción del 99.89% en carga de PostgreSQL. Picos temporales menores que baseline (hasta ~200ms vs ~380ms).
5.1.3 Escenario MIXED (TTL=90) - 100 usuarios
Resultados: 18,298 requests, 61.24 RPS, p95 = 130ms (idéntico a baseline y HOT), hit ratio 84.38% (80% queries HOT, 20% COLD). Reducción del 84.38% en carga de PostgreSQL. El 20% de queries COLD no degrada significativamente el p95 agregado.
5.1.4 Escenario COLD (TTL=90) - 100 usuarios
Resultados: 18,257 requests, 61.07 RPS, p95 = 130ms (idéntico a todos los escenarios), hit ratio 57.31%. Hallazgo crítico: bajo carga pico esperada (100 usuarios), el hit ratio no afecta el p95, incluso cuando varía de 0% a 99.89%. Reducción del 57.31% en carga de PostgreSQL. Variabilidad temporal mayor (picos hasta ~290ms).
5.2 Comportamiento bajo carga extrema (300 usuarios)
5.2.1 Escenario Baseline (TTL=0) - 300 usuarios
Resultados: 52,639 requests, 175.83 RPS, p95 promedio = 430ms (cumple SLA), p95 máximo = ~3,600ms (excede SLA por 4.5x), hit ratio 0%. Degradación no lineal: +231% en p95 al aumentar carga 3x. Picos temporales indican contención severa en PostgreSQL. 7 fallos 502 Bad Gateway (0.01%).
5.2.2 Escenario HOT (TTL=90) - 300 usuarios
Resultados: 54,764 requests, 182.96 RPS, p95 promedio = 140ms (cumple SLA con margen 5.7x), p95 máximo = ~1,600ms (cache warming transitorio), hit ratio 99.92%. Después del cache warming, p95 se estabiliza < 300ms, nunca excediendo el SLA. Mejora del 67.4% vs baseline. Reducción del 99.92% en carga de PostgreSQL.
5.2.3 Escenario MIXED (TTL=90) - 300 usuarios
Resultados: 54,691 requests, 182.77 RPS, p95 promedio = 140ms (cumple SLA con margen 5.7x), p95 máximo = ~800ms (justo en límite del SLA), hit ratio 89.04% (80% queries HOT, 20% COLD). Picos periódicos en límite debido al 20% de queries COLD. Mejora del 67.4% vs baseline. Reducción del 89.04% en carga de PostgreSQL.
5.2.4 Escenario COLD (TTL=90) - 300 usuarios
Resultados: 54,385 requests, 181.55 RPS, p95 promedio = 200ms (cumple SLA con margen 4.0x), p95 máximo = ~1,650ms (excede SLA por 2.1x), hit ratio 80.42%. Identifica umbral de quiebre: con hit ratio < 89% bajo carga extrema, picos temporales exceden el SLA. Mejora del 53.5% vs baseline. Reducción del 80.42% en carga de PostgreSQL.
5.3 Análisis comparativo y umbral de quiebre
Escalabilidad: Todos los escenarios muestran escalabilidad casi lineal del RPS (2.9-3.0x) al aumentar carga 3x. La degradación de p95 varía dramáticamente: Baseline +231%, COLD +54%, MIXED/HOT +8%.
Impacto del hit ratio:
- 100 usuarios (~60 RPS): El hit ratio no afecta p95 (todos 130ms), independientemente del valor (0% a 99.89%).
- 300 usuarios (~180 RPS): El hit ratio tiene impacto dramático:
- Baseline (0%): p95 = 430ms, picos ~3,600ms (4.5x límite) → SLA quebrado
- COLD (80.42%): p95 = 200ms, picos ~1,650ms (2.1x límite) → SLA quebrado
- MIXED (89.04%): p95 = 140ms, picos ~800ms (1.0x límite) → SLA en límite
- HOT (99.92%): p95 = 140ms, estable < 300ms después de cache warming → SLA cumplido
Umbral de quiebre identificado: El SLA se quiebra cuando se cumplen ambas condiciones: carga ≥ 300 usuarios (~180 RPS) y hit ratio < 89%. Se requiere hit ratio ≥ 89% para mantener picos en el límite del SLA o por debajo bajo carga extrema.
6. Conclusiones
6.1 Validación de la hipótesis bajo carga pico esperada
Todos los escenarios (Baseline, COLD, MIXED, HOT) cumplen el SLA de p95 ≤ 800ms con amplio margen (6.15x), independientemente del hit ratio (0% a 99.89%). Bajo carga pico esperada (100 usuarios, ~60 RPS), el SLA se cumple independientemente del hit ratio, incluso sin caché. PostgreSQL puede manejar ~60 RPS manteniendo p95 en 130ms. El caché proporciona beneficios (reducción de carga en PostgreSQL 57-99%) pero no es crítico para cumplir el SLA.
6.2 Identificación del punto de quiebre del SLA
Umbral identificado: El SLA se quiebra cuando se cumplen ambas condiciones: carga ≥ 300 usuarios (~180 RPS) y hit ratio < 89%.
| Escenario | Hit Ratio | p95 Promedio | p95 Máximo | Estado SLA |
|---|---|---|---|---|
| Baseline 300 | 0% | 430ms | ~3,600ms | Quebrado (4.5x límite) |
| COLD 300 | 80.42% | 200ms | ~1,650ms | Quebrado (2.1x límite) |
| MIXED 300 | 89.04% | 140ms | ~800ms | En límite (1.0x límite) |
| HOT 300 | 99.92% | 140ms | ~1,600ms (cache warming) | Cumple (estable < 300ms) |
Mecanismo: Alta carga + bajo hit ratio genera contención en PostgreSQL, manifestándose como picos temporales que exceden el SLA. Se requiere hit ratio ≥ 89% para mantener picos en el límite o por debajo bajo carga extrema.
6.3 Efectividad de la táctica cache-aside
Bajo carga extrema (300 usuarios), el caché es crítico: Baseline muestra picos de 3,600ms (4.5x límite), mientras HOT mantiene p95 estable < 300ms después de cache warming. Mejora del 67.4% en p95 promedio (430ms → 140ms). El caché elimina la variabilidad temporal observada en el baseline.
7. Impacto en la arquitectura propuesta
No se requieren cambios fundamentales en la arquitectura. Las tácticas evaluadas (cache-aside con Redis, TTL 1-2 minutos, async con connection pooling) son adecuadas para la escala de operación esperada. Sin embargo, los hallazgos del experimento generan recomendaciones operacionales importantes.
8. Evidencias
Se pueden encontrar todos los archivos de resultados aquí: https://drive.google.com/file/d/1LEPxiuWgbmvE9gubvfElv9OUlzKCJqpd/view?usp=sharing