Especificación del experimento

Título del experimento	Prueba de carga con balanceador al sistema de apoyo de diagnostico de epilepsia refractaria
ASRs involucrados	Como médico, cuando consulto la historia clínica de un paciente, dado que el sistema funciona con normalidad, quiero que se muestre la información del paciente para evaluar su estado de salud y determinar el siguiente paso en su diagnostico. Esto debe suceder en menos de 1 segundo.
Propósito del experimento	Evaluar si el diseño planteado satisface el ASR involucrado.
Resultados esperados	Se obtenga la historia clínica de un paciente en menos de 1000 ms
Infraestructura computacional requerida	Balanceador de carga en GCP, instancias VM en GCP para ejecutar el servidor de la base de datos, Computador personal para hacer las peticiones.
Descripción del experimento	Usando JMeter se van a crear 50 solicitudes GET en un ramp up de 10 segundos, simulando una consulta de 5 historias clinicas por segundo. La base de datos esta cargada por 10000 historias clínicas usando Faker.
Plan de uso IAG	No Aplica

Elementos de arquitectura

• Diagrama de componentes

• Diagrama de despliegue

Estilos de arquitectura

• MTV (Model-Template-View): Django tiene este estilo incorporado, asi que al usarlo, lo acoplamos mejor a su arquitectura. Ademas, que se organiza el codigo de manera clara, organizada y permite que sea reutilizable.
• Capas: El estilo por capas en nuestro caso encaja bien para darle a cada parte de la aplicacion una responsabilidad especifica. Se usaron tres capas en la construccion de la aplicacion: Primero la de presentacion donde se incluyen los templates y las vistas de MTV, y muestra la informacion al usuario. Segundo, esta la capa de negocio donde se encarga de manejar las procesos internos y reglas de negocio. Por ultimo la capa de persistencia que se encarga de acceder a la base de datos para obtener las historias.

Tácticas/patrones de arquitectura

• Balanceador de Carga - Replicación: Lo utilizamos para distribuir el trafico de solicitudes entre instancias en Google Cloud, asi se evita la sobrecarga en un solo servidor y mejora las disponibilidad para la respuesta. Asi si un servidor se llena de solicitudes, el balanceador puede redirigir las peticiones a la instancia que menos carga tenga mediante Least-conn. Esto contribuye directamente al cumplimiento del ASR, ya que permite que la historia clínica del paciente sea entregada rápidamente al médico (en menos de 1 segundo), incluso bajo carga, asegurando la fluidez necesaria para la evaluación médica.

Tecnologías

• Google Cloud: Lo utilizamos porque permite crear y configurar fácilmente el balanceador de carga junto con las instancias de VM, y asi podemos gestionar el tráfico para las pruebas en el experimento.

• JMeter: Lo utilizamos para generar múltiples solicitudes concurrentes y evaluar el desempeño de la aplicacion, permitiéndonos medir el rendimiento bajo diferentes niveles de tráfico, ya que nos muestra directamente la latencia de las respuestas. En general la herramienta nos facilita las pruebas, ayudando con el análisis de los resultados en el experimento.

• Faker: Biblioteca utilizada para generar los 35000 datos de prueba y simular historias clínicas realistas.

• Django: Framework principal del sistema, lo utilizamos por su arquitectura MTV, que facilita la separación de responsabilidades entre presentación, lógica y acceso a datos. Nos provee herramientas que permitieron implementar rápidamente las funcionalidades requeridas.