Creación de un Pipeline de Datos y API con Caché Inteligente

Objetivo General del Proyecto

Desarrollar una solución integral de backend que demuestre la capacidad de migrar datos a gran escala, exponerlos a través de una API segura y optimizada, y desplegarla en un entorno de nube productivo. El proyecto culmina con la implementación de un sistema de monitoreo y una estrategia de caché con invalidación automática.

---

Fase 1: Preparación y Migración de Datos

Selección del Dataset

• Se eligió un Dataset en Kaggle sobre Animes, con exactamente 20,238 registros.
• El Dataset consta de 12 columnas, se han elegido 6 columnas con la información más relevante: title, type, year, score, episodes, genres.

Migración de Datos con Azure Data Factory

• Se ha usado el servicio Azure Data Factory como Orquestador para realizar un proceso ETL que extrae columnas de datos de un .csv hacia una base de datos Azure SQL.
• En Azure Data Factory debe hacer conexión con los servicios de almacenamiento que se usarán para el ETL.

Conexión con los servicios de almacenamiento desde Azure Data Factory:

Creación del los Dataset relacionadas a los servicios de almacenamiento:

Pipeline completado:

Servicios creados para el pipeline de datos:

---

Fase 2: Desarrollo de API y Autenticación

Tecnología

• Se ha usado FastAPI para la creación de la API REST

A continuación se muestran las librerías/dependencias utilizadas en el proyecto FastAPI:

python3 -m venv env-api
pip install fastapi
pip install uvicorn

pip install dotenv
pip install pyodbc

pip install pyrebase
pip install firebase-admin
pip install firebase

Autenticación y Autorización con Firebase

• Se ha implementado Firebase para la gestión de registro e inicio de sesión de los usuarios en la aplicación.
• Se ha implementado JWT con un tiempo de vida para autorizaciones y autenticaciones de los usuarios a ciertos Endpoint de la API.

Endpoint Signup

• Las pruebas en estas capturas de pantalla fueron hechas en ambiente de desarrollo.

Enviando datos de registro desde Postman:

Usuario registrado en la base de datos:

Usuario registrado en Firebase:

Endpoint Signin

• Las pruebas en estas capturas de pantalla fueron hechas en ambiente de desarrollo.

Respuesta del Login del usuario:

Endpoint para obtener toda la lista de datos

• Las pruebas en estas capturas de pantalla fueron hechas en ambiente de desarrollo.

Tiempo de respuesta al traer toda la lista de animes:

Endpoint de lista de animes con un filtro:

---

Fase 3: Monitoreo del Rendimiento

Configuración de Application Insights

Creación del servicio Application Insights en el grupo de recursos:

Librerías/Dependencias necesarias para la herramienta de telemetría en la API:

pip install azure-monitor-opentelemetry
pip install opentelemetry-instrumentation-fastapi

Logs generados por la herramienta Telemetry (demostración de implementación correcta):

Pruebas de Carga

• Se han múltiples peticiones al Endpoint que lista todos los animes sin usar filtros.
• Estas capturas corresponden a pruebas de la aplicación en ambiente de desarrollo.

Gráficas de repsuesta del servidor, peticiones al servidor, fallos y disponibilidad:

Tiempo promedio de respuesta de la aplicación:

---

Fase 4: Implementación de Caché con Redis

Integración con Redis

Librería utilizada para la implementación de Redis Caché en la API:

pip install redis

Persistencia en Caché y Reto de las Llaves Dinámicas:

• Las siguientes capturas corresponden a pruebas en ambiente de desarrollo.

En las siguientes capturas se ha hecho una consulta y la cache debería tener data guardada.

Verificando que la caché está limpia:

Haciendo una Query para almacenar data en la Caché (21.01 segundos):

• En la prueba anterior se tarda un tiempo considerable por la lectura de caché, obtención de datos de la DB y la escritura en la caché.

Volviendo a consultar la data de la caché:

Haciendo nuevamente la Query, y esto debe buscar data en la caché y tardar menos tiempo:

2.61 segundos

2.26 segundos:

Haciendo un Query con filtro de type (18.77 segundos):

Consultando que la Key y la Data ya existe en la Cache:

Volviento a hacer la consulta

1.90 segundos:

6.96 segundos:

---

Fase 5: Invalidación de Caché

Endpoint de Creación

• Al crear un nuevo registro en la tabla de la base de datos, los Keys de la Caché Redis relacionados con la data insertada deben ser eliminados.

Creando un nuevo anime, insertando el Type:

En la caché deberián estar borrado la key de all

Insertando en la DB con el type guardado en la cache y volviendo a verificar en la cache:

Vuelvo a hacer una consulta con el filtro type, se tarda 4.24 segundos porque ya no existe data en la cache, entonces hace la consulta y vuelve a escribir en la cache:

Obteniendo data de la cache:

Lógica de Invalidación

Intentando crear con un usuario no Admin:

Verificación del Flujo

Verificando la caché:

Realizando petición de todos los animes de la DB (7.53 segundos):

Verificando la cache:

Obteniendo data de la cache (2.51 segundos):

Obteniendo data con filtro de type (3.72 segundos):

Verificando inserción en la cache:

Obteniendo data de la caché (1.48 segundos):

Métricas de la API usando Application Insigths

Métricas con los tiempos de respuesta de la API:

Sin la cache, los tiempos de respuesta estában en una media de 18 segundos:

En este ejemplo leyó de la caché:

---

Fase 6: Despliegue en la Nube con Docker

Containerización

Creación de imagen Docker:

Contenedor del proyecto en ejecución:

Release en la Nube

Creación del ACR y Webapp de Azure:

Publicando Imagen en el ACR:

az login
az acr login --name {acranimeprojectdev}

docker tag anime-api:latest acranimeprojectdev.azurecr.io/api-anime:0.0.1

Vinculando ACR con la Webapp

Pruebas en Producción

Probando REDIS en el proyecto desplegado

1.24 segundos:

878 milisegundos

Guardando información en Redis desde el proyecto Desplegado