Diseno experimento para el requisito Disponibilidad S5 - JohannPaezU/MISW4501-MediSupply GitHub Wiki
| Título del experimento | Experimento de Disponibilidad |
|---|---|
| Propósito del experimento | El objetivo del experimento es validar que la arquitectura propuesta garantiza la disponibilidad de la información, asegurando que los usuarios puedan acceder a sus datos de manera oportuna y confiable al utilizar el servicio de consulta y gestión de pedidos. |
| Resultados esperados | Se espera que el servicio de consulta de pedidos mantenga una disponibilidad continua, la cual será verificada mediante un componente de monitoreo. Esto permitirá validar que la arquitectura implementada incorpora las medidas necesarias para garantizar el acceso confiable y permanente a la información de los pedidos. |
| Recursos requeridos | Python, FastAPI, Celery, Redis, SQLAlchemy, Pydantic, Uvicorn, Git, GitHub. |
| Elementos de arquitectura involucrados | • ASR involucrado: https://proyecto-final-grupo-009.atlassian.net/browse/SCRUM-88 • Modelo de componentes: https://github.com/JohannPaezU/MISW4501-MediSupply/wiki/Modelo-de-componentes-S4 • Modelo de datos: https://github.com/JohannPaezU/MISW4501-MediSupply/wiki/Modelo-de-datos-S4 |
| Esfuerzo estimado | Se espera realizar el experimento en 6 días con 2.5 horas/hombre por día. |
| Punto de sensibilidad | La decisión crítica a implementar consiste en el uso de colas de mensajería para gestionar peticiones de manera asíncrona, lo que permite desacoplar componentes y fortalecer la disponibilidad de los sistemas críticos. Adicionalmente, se integrará un servicio de monitoreo orientado a la detección temprana de fallas, con el fin de garantizar la continuidad operativa y minimizar interrupciones ante posibles incidentes. |
|---|---|
| Historia de arquitectura asociada | https://proyecto-final-grupo-009.atlassian.net/browse/SCRUM-88 |
| Nivel de incertidumbre | El nivel de incertidumbre se clasifica como medio, dado que podrían requerirse mecanismos de control adicionales como esquemas de votación o estrategias de retiro controlado de servicio (graceful degradation) para garantizar el nivel de alta disponibilidad definido en esta ASR. |
| Estilos de Arquitectura asociados al experimento | Análisis (Atributos de calidad que favorece y desfavorece) |
|---|---|
| Estilo de arquitectura de microservicios basado en mensajes. |
Favorece: ✓ Disponibilidad ✓ Desacoplamiento ✓ Alta cohesión Desfavorece: ✓ Latencia |
| Tácticas de Arquitectura asociadas al experimento | Descripción |
|---|---|
| Detección de fallas: Monitor | Se implementará un componente de monitoreo encargado de verificar de forma continua la comunicación con el servicio de consulta y gestión de pedidos, validando así su disponibilidad y asegurando la detección temprana de posibles fallos. |
| Microservicio | Propósito y comportamiento esperado | Tecnología Asociada |
|---|---|---|
| Gestor de Pedidos | El propósito de este componente es exponer los endpoints que permiten el acceso a la información relacionada con los pedidos de los usuarios, proporcionando una interfaz confiable y estandarizada para su consulta. | • Python • FastAPI • SQLAlchemy • Pydantic • Celery |
| Monitor | El propósito es ser un intermediario que envía los mensajes correspondientes a la cola de los receptores a través de la plataforma de mensajes y adicionalmente comprueba que los componentes están disponibles, esto también se hace a través de una cola. Se espera que en caso de fallos realice una notificación del servicio afectado. | • Python • FastAPI • Pydantic • Celery |
| Plataforma de Mensajes | Microservicio encargado de gestionar los mensajes de solicitud y respuesta desde los microservicios monitor y gestor de pedidos. | • Python • FastAPI • Pydantic • Celery |
| Conector | Comportamiento deseado en el experimento | Tecnología Asociada |
|---|---|---|
| Monitor - Cola de mensajes | Se espera que el monitor envíe una petición a la cola de mensajes y que el microservicio correspondiente la procese. | Redis Celery |
| Cola de mensajes - Gestor de Pedidos | Se espera que la cola le envíe al gestor de pedidos la peticion para que este la procese hacia el almacenamiento principal. | Python FastAPI |
| Gestor de Pedidos - Almacenamiento Principal | Se espera que la peticion recibida por el almacenamiento, la ejecute y envíe una actualizacion a algunos de los almecenamientos secundarios, para luego enviarle un estado al monitor. | Base de Datos SQLAlchemy |
| Tecnología asociada con el experimento | Justificación |
|---|---|
| Lenguajes de programación: Python | Es un lenguaje de programación conocido por su simplicidad y legibilidad. Es ideal para desarrollar prototipos rápidos y mantener un código limpio y estructurado. |
| Plataforma de despliegue | Equipo local (localhost). |
| Bases de datos: SQLite | Es una base de datos ligera y fácil de integrar, perfecta para proyectos pequeños o experimentos. Permite trabajar con bases de datos relacionales sin necesidad de un servidor de base de datos separado. |
| Herramientas de análisis | • Excel • Archivos de logs de ejecución de la consola. |
| Librerías: FastAPI, SQLAlchemy, Pydantic, Celery, Redis |
FastAPI: Es un framework web moderno y de alto rendimiento para crear APIs con Python. Proporciona validación automática de datos, documentación interactiva automática (Swagger), y es ideal para desarrollar APIs REST de manera rápida y eficiente. SQLAlchemy: Es una biblioteca de mapeo objeto-relacional (ORM) para Python que facilita la interacción con bases de datos relacionales desde Python de una manera más orientada a objetos. Simplifica el manejo de consultas SQL y la manipulación de datos en la base de datos. Pydantic: Es una biblioteca de validación de datos que utiliza type hints de Python. Se integra perfectamente con FastAPI para la validación automática de datos de entrada y salida. Celery: Es una librería para la ejecución de tareas asíncronas y en segundo plano. Permite programar trabajos periódicos (cron jobs) y distribuir tareas entre múltiples workers, lo que mejora la escalabilidad y el rendimiento de la aplicación. Redis: Es un sistema de almacenamiento en memoria clave-valor muy rápido. Generalmente se utiliza como message broker para Celery, manejando la cola de tareas. También puede usarse como caché para mejorar la velocidad de acceso a datos y reducir carga en la base de datos. |
| Frameworks de desarrollo | FastAPI: Es un framework web moderno, rápido y de alto rendimiento para crear APIs con Python. Incluye características como validación automática de datos, documentación interactiva automática, soporte nativo para async/await, y es ideal para desarrollar microservicios y APIs REST de manera eficiente. |
-
Preparación y Configuración del Ambiente (6h)
Instalación de dependencias, configuración del repositorio y puesta a punto del entorno de ejecución. -
Desarrollo de Microservicios (20h)
Construcción del Gestor de Pedidos, Monitor y Plataforma de Mensajes, asegurando comunicación asíncrona mediante colas. -
Integración de Componentes (10h)
Conexión de los microservicios y validación del flujo completo de peticiones con Redis y Celery. -
Pruebas (12h)
Pruebas para verificar la resiliencia ante fallos y la correcta detección de indisponibilidades. -
Monitoreo y Métricas (6h)
Configuración de logs, recolección de métricas y validación de detección temprana de fallos. -
Análisis de Resultados y Documentación (6h)
Consolidación de resultados, redacción del reporte final y conclusiones sobre la disponibilidad alcanzada.
