Resultados Experimento 1 ‐ Latencia del perfilamiento mediante Cache‐Aside - JuanHerreraP/Proyecto-MISO-Solventa-Grupo-11 GitHub Wiki
1. Resumen del experimento
El experimento busca validar el efecto del patrón Cache-Aside sobre la latencia del proceso de perfilamiento de riesgo de Solventa.
La decisión arquitectónica consiste en consultar primero Amazon ElastiCache Redis antes de realizar nuevas llamadas a Open Finance y Open Data. Cuando existe un perfil vigente en caché, este puede ser reutilizado y se evita realizar nuevamente las consultas externas.
Para observar el efecto de esta decisión se evaluaron dos comportamientos:
| Escenario | Propósito dentro del experimento |
|---|---|
| Cache Hit | Evaluar el comportamiento del sistema cuando Cache-Aside puede reutilizar un perfil previamente almacenado en Redis. |
| Cache Miss | Servir como escenario de referencia para observar el impacto de tener que consultar Open Finance y Open Data cuando el perfil todavía no existe en caché. |
El escenario de calidad evaluado corresponde a EC02 - Latencia, cuyos criterios son:
| Métrica | Criterio de aceptación |
|---|---|
| p95 | ≤ 400 ms |
| p99 | ≤ 800 ms |
Experimento asociado: Experimento 1 - Validación de latencia del perfilamiento mediante Cache-Aside
2. Hipótesis de diseño
| Elemento | Hipótesis de diseño |
|---|---|
| Punto de sensibilidad | Uso del perfil almacenado en ElastiCache Redis antes de realizar nuevas consultas a Open Finance y Open Data. |
| Hipótesis de diseño | Si Solventa utiliza el patrón Cache-Aside con ElastiCache Redis para reutilizar perfiles de riesgo vigentes, entonces el proceso de perfilamiento podrá cumplir EC02, manteniendo p95 ≤ 400 ms y p99 ≤ 800 ms, al disminuir las consultas que dependen directamente de los proveedores externos. |
| Historia de arquitectura asociada | EC02 - Latencia: perfilamiento y personalización dentro del recorrido de compra del seguro de vida hipotecario. |
| Nivel de incertidumbre | Alto. La arquitectura contempla el uso de caché para reducir la dependencia de los proveedores externos, pero aún no se cuenta con resultados experimentales que demuestren que esta decisión permite alcanzar los percentiles definidos en EC02. |
3. Ambiente de ejecución
Para realizar el experimento se desplegaron los componentes requeridos en AWS. Los servicios de dominio y los proveedores simulados fueron ejecutados mediante Amazon ECS Fargate, mientras que Amazon ElastiCache Redis fue utilizado para almacenar temporalmente los perfiles de riesgo.
La generación de carga se realizó desde un equipo externo mediante k6, enviando solicitudes al servicio de Cotización y Precio desplegado en AWS.
| Elemento | Configuración utilizada |
|---|---|
| Plataforma de ejecución | Amazon ECS Fargate |
| Imagen de contenedores | Amazon ECR |
| Servicio de entrada | Cotización y Precio (Rating) |
| Servicio evaluado | Perfilamiento de Riesgo |
| Caché | Amazon ElastiCache Redis |
| Proveedores externos simulados | Open Finance Mock y Open Data Mock |
| Herramienta de carga | k6 |
| Usuarios virtuales por escenario | 5 VUs |
| Duración Cache Hit | 30 segundos |
| Duración Cache Miss | 30 segundos |
| Número de ejecuciones | 3 |
| Criterio EC02 | p95 ≤ 400 ms / p99 ≤ 800 ms |
Durante las ejecuciones también se realizaron validaciones funcionales para comprobar que las solicitudes fueran procesadas correctamente y que cada escenario correspondiera realmente al comportamiento esperado.
En Cache Hit se verificó que la respuesta indicara:
fuente_perfilamiento = cache
Mientras que en Cache Miss se comprobó:
fuente_perfilamiento = external_fetch
Esto permitió asegurar que la comparación se estaba realizando entre solicitudes atendidas desde Redis y solicitudes que realmente requerían consultar las fuentes externas.
4. Resultados obtenidos
El experimento fue ejecutado tres veces utilizando la misma configuración. La repetición de la prueba permitió observar si el comportamiento se mantenía entre diferentes ejecuciones y evitar basar las conclusiones en una única muestra.
4.1 Resultados por ejecución
| Ejecución | Escenario | Promedio | p95 | p99 | Errores HTTP |
|---|---|---|---|---|---|
| 1 | Cache Hit | 156,38 ms | 185,05 ms | 214,34 ms | 0 % |
| 1 | Cache Miss | 374,10 ms | 415,68 ms | 511,42 ms | 0 % |
| 2 | Cache Hit | 171,36 ms | 204,35 ms | 411,72 ms | 0 % |
| 2 | Cache Miss | 372,55 ms | 412,14 ms | 512,52 ms | 0 % |
| 3 | Cache Hit | 161,18 ms | 181,60 ms | 208,04 ms | 0 % |
| 3 | Cache Miss | 427,92 ms | 614,02 ms | 1.020 ms | 0 % |
4.2 Comparación frente a EC02
El siguiente resumen presenta los resultados considerando Cache Hit como el escenario principal para evaluar el efecto de Cache-Aside y Cache Miss como referencia del comportamiento cuando todavía es necesario consultar los proveedores externos.
| Escenario evaluado | Propósito | p95 observado | p99 observado | Interpretación |
|---|---|---|---|---|
| Cache Hit - Ejecución 1 | Perfil reutilizado desde Redis | 185,05 ms | 214,34 ms | Cumple EC02 |
| Cache Hit - Ejecución 2 | Perfil reutilizado desde Redis | 204,35 ms | 411,72 ms | Cumple EC02 |
| Cache Hit - Ejecución 3 | Perfil reutilizado desde Redis | 181,60 ms | 208,04 ms | Cumple EC02 |
| Cache Miss - Ejecución 1 | Referencia con consultas externas | 415,68 ms | 511,42 ms | Mayor latencia por consultas externas |
| Cache Miss - Ejecución 2 | Referencia con consultas externas | 412,14 ms | 512,52 ms | Mayor latencia por consultas externas |
| Cache Miss - Ejecución 3 | Referencia con consultas externas | 614,02 ms | 1.020 ms | Se evidencia mayor sensibilidad a proveedores externos |
En las tres ejecuciones, Cache Hit mantuvo tanto el p95 como el p99 dentro de los límites establecidos por EC02.
Cache Miss presentó tiempos mayores en todas las ejecuciones, lo que permite observar el impacto que tienen las consultas externas cuando todavía no existe un perfil reutilizable en Redis.
4.3 Resumen consolidado
| Indicador | Cache Hit | Cache Miss - Referencia |
|---|---|---|
| Rango p95 observado | 181,60 - 204,35 ms | 412,14 - 614,02 ms |
| Rango p99 observado | 208,04 - 411,72 ms | 511,42 - 1.020 ms |
| Ejecuciones con p95 dentro de EC02 | 3 de 3 | 0 de 3 |
| Ejecuciones con p99 dentro de EC02 | 3 de 3 | 2 de 3 |
| Errores HTTP | 0 % | 0 % |
| Comportamiento observado | Cumplimiento consistente de EC02 | Mayor latencia al depender de fuentes externas |
Los resultados consolidados se presentan utilizando rangos y número de ejecuciones que cumplen los criterios. No se calcula un único percentil mediante el promedio de los percentiles de las tres ejecuciones, ya que cada ejecución corresponde a una muestra independiente.
4.4 Volumen de pruebas
Considerando las tres ejecuciones realizadas, se obtuvieron los siguientes valores:
| Indicador | Resultado |
|---|---|
| Solicitudes HTTP procesadas | 3.914 |
| Iteraciones completadas | 3.911 |
| Checks ejecutados | 7.825 |
| Checks exitosos | 100 % |
| Solicitudes HTTP fallidas | 0 % |
El 100 % de los checks configurados en k6 fueron satisfactorios. Esto confirma que las solicitudes de Cache Hit fueron atendidas efectivamente desde Redis y que las solicitudes de Cache Miss utilizaron el flujo que consulta las fuentes externas.
También se mantuvo una tasa de errores HTTP del 0 % durante las tres ejecuciones.
5. Análisis de resultados
Los resultados muestran una diferencia consistente entre las solicitudes atendidas utilizando información previamente almacenada en Redis y aquellas que requieren consultar Open Finance y Open Data.
Cuando se presenta un Cache Hit, el p95 se mantuvo entre 181,60 ms y 204,35 ms en las tres ejecuciones. Estos valores se encuentran considerablemente por debajo del límite de 400 ms definido en EC02. De igual forma, el p99 se mantuvo entre 208,04 ms y 411,72 ms, también dentro del límite de 800 ms.
Este comportamiento muestra que, cuando Cache-Aside puede reutilizar un perfil existente, se reduce de manera importante el tiempo necesario para completar la operación de perfilamiento.
El escenario de Cache Miss fue utilizado como referencia para observar qué ocurre cuando el perfil todavía no existe en Redis. En este caso el servicio debe consultar Open Finance y Open Data, procesar sus respuestas, construir el perfil y posteriormente almacenarlo en caché. Bajo estas condiciones se obtuvieron valores de p95 entre 412,14 ms y 614,02 ms, superiores a los observados cuando la información ya se encontraba disponible en Redis.
La diferencia entre ambos escenarios permite observar directamente el efecto de la decisión arquitectónica. Cache-Aside evita repetir las consultas externas para perfiles vigentes y permite que solicitudes posteriores sean atendidas en tiempos significativamente menores.
La tercera ejecución también mostró una mayor variabilidad en Cache Miss, alcanzando un p99 de 1.020 ms. Este resultado refuerza la identificación de las consultas externas como un punto sensible dentro del proceso, ya que sus tiempos pueden afectar directamente la latencia total cuando la información no puede ser obtenida desde la caché.
6. Resultado de la hipótesis
La evidencia obtenida soporta la principal premisa de la hipótesis de diseño: reutilizar perfiles de riesgo mediante Cache-Aside disminuye la dependencia de Open Finance y Open Data y reduce la latencia del proceso de perfilamiento.
En las tres ejecuciones realizadas, las solicitudes atendidas mediante Cache Hit cumplieron tanto el p95 como el p99 establecidos por EC02. Al compararlas con las solicitudes de Cache Miss se observó un incremento claro en los tiempos de respuesta cuando fue necesario consultar las fuentes externas.
Sin embargo, los resultados también muestran que Cache-Aside no elimina la sensibilidad existente durante la creación inicial o renovación de un perfil. Cuando ocurre un Cache Miss, el tiempo total sigue dependiendo del comportamiento de Open Finance y Open Data. Por esta razón, el experimento soporta el beneficio de la decisión arquitectónica, pero también deja identificado el flujo de Cache Miss como un aspecto que debe continuar siendo analizado y optimizado.
7. Conclusión
El experimento permitió evidenciar que el patrón Cache-Aside aporta un beneficio claro sobre la latencia del proceso de perfilamiento. Cuando existe un perfil vigente almacenado en ElastiCache Redis, las solicitudes cumplen de forma consistente los valores de p95 y p99 definidos en EC02. En las tres ejecuciones realizadas, el p95 del escenario Cache Hit permaneció aproximadamente entre 182 y 204 ms, muy por debajo del límite de 400 ms.
La comparación con Cache Miss permitió identificar el origen de este beneficio. Cuando no existe información disponible en Redis, el sistema debe consultar Open Finance y Open Data y los tiempos de respuesta aumentan de forma considerable. Por lo tanto, Cache Miss no se interpreta como un experimento independiente que deba demostrar el beneficio del patrón, sino como el escenario de referencia que permite observar el impacto de las consultas externas que Cache-Aside busca reducir.
A partir de los resultados obtenidos se mantiene Cache-Aside como decisión arquitectónica para Solventa. La evidencia muestra que la reutilización de perfiles vigentes permite disminuir la latencia y cumplir EC02 en el camino atendido desde caché. Al mismo tiempo, se identifica como aspecto de mejora el comportamiento de las solicitudes que generan Cache Miss, especialmente por la dependencia de los tiempos de respuesta de Open Finance y Open Data.
8. Resultado final del experimento
El experimento aporta evidencia favorable para mantener el patrón Cache-Aside con Amazon ElastiCache Redis dentro de la arquitectura de Solventa. En las tres ejecuciones realizadas, el escenario Cache Hit cumplió los límites establecidos por EC02 y presentó tiempos considerablemente menores que el escenario en el que fue necesario consultar los proveedores externos.
El escenario Cache Miss permitió identificar y cuantificar la sensibilidad que Cache-Aside busca mitigar. Los resultados muestran que la dependencia de Open Finance y Open Data incrementa la latencia del proceso, mientras que la reutilización de perfiles almacenados permite evitar dichas consultas y responder en tiempos menores.
Como resultado del experimento se mantiene la decisión de utilizar Cache-Aside y se documenta el flujo de Cache Miss como un punto de sensibilidad que deberá ser considerado en futuras optimizaciones de la arquitectura.