DisenoExperi2 - shiomar-salazar/MISW-PF-Grupo1-Backend GitHub Wiki

Diseño de Experimento #2: Latencia

Titulo del Experimiento: Reduccion de Latencia en el Registro de Usuarios Simultaneos

Proposito del Experimento

Con este experimento se espera poder comprobar que las siguientes tácticas de aquitectura:

  • Escalamiento Horizontal de servicios criticos como forma de aumentar los recursos disponibles y alcanzar los niveles de desempeño esperado.
  • Efecto negativo que se tiene cuando se aplica la táctica de retiro de la operacion sobre los servicios de registro de usuario durante diferentes picos de actividad en el sistema, para poder mitigarlos mediante la aplicacion de otras tácticas .

Pero mas alla de la comprobacion de las tácticas antes mecionadas, queremos:

  • Determinar que parametros de Configuracion necesarios para obtener los niveles de desempeño que nos permita manejar el registro simultaneo de 1000 usuarios como tope superior.
  • Determinar que parametros de Configuracion necesarios para obtener los niveles de desempeño que nos permita manejar el registro simultaneo de 50 usuarios como tope inferior.

Resultados Esperados:

Con el experimento se espera poder comprobar los siguientes comportamientos:

  • El establecimiento de parametros base en temas de instancias de Escalamiento Horizontal que nos sirvan como punto de partida al momento del desarrollo del proyecto final nos ayude reducir el riesgo, la incertidumbre y el consumo de recursos .
  • Determinar si es necesaria la aplicacion de nuevas tacticas dado el efecto negativo de la Táctica de Retiro de la Operacion ante la indisponibilidad del servico de registro de usuarios.

Recursos Requeridos:

Como elementos de Software necesitaremos:

  • Google Gloud Platform.
  • Python
  • Docker
  • JMeter

Elementos de Arquitectura Involucrados

Elementos de Arquitectura Punto de Sensibilidad
Ingress Load Balancer Garantizar que el sistema puedo procesar las peticiones de registro de usuario de al menos 1000 nuevos usuarios concurrentes con un tiempo de respuesta menor a 3 segundos por cada peticion.
Microservicio de Gestor de Usarios
Configuracion de Servicio de Gestor de Usarios
Configuracion de Servicio de Gestor de Entrenamientos
Configuracion de Servicio de Gestor Plan Nutricional

Esfuerzo Estimado

Se estiman 18 horas de esfuerzo para la ejecucion de este experimento distrinbuidos en las siguientes actividades:

  • Creación de los microservicios Mockup para el Gestor de Usuarios.
  • Creación de los microservicios Mockup para el Gestor de Entrenamientos.
  • Creación de los microservicios Mockup para el Gestor Plan Nutricional.
  • Creacion de la Configuracion DockerFiles como pre-requisito de los Kubernetes.
  • Creacion de la Configuracion de Kubernetes para el despliegue del experimento.
  • Creacion de los parametros de Prueba en JMeter para la comprobacion de Hipotesis.

Hipotesis de Diseño 1

Punto de Sensibilidad Historia de Arquitectura asociada Nivel de Incentidumbre
Garantizar que el sistema pueda procesar las peticiones de registro de usuario de al menos 1000 nuevos usuarios concurrentes con un tiempo de respuesta menor a 3 segundos por cada peticion. Como usuario, cuando envíe el formulario para registrarme en la aplicación dado que el sistema opera normalmente, quiero obtener una notificación de que la operación fue exitosa y también la clasificación en el grupo de riesgo y recomendación de los planes para iniciar un entrenamiento adecuado, basado en mis características fisiológicas, historial deportivo y lugar de residencia. Esto debe suceder en menos de 3 segundos. Media

Estilos de Arquitectura asociados al experimento

Estilo de Arquitectura de Microservicios, esto con el fin de validar la decision de estilo de arquitectura y validar si la misma nos ayuda a cumplir con lo esperado en el proyecto.

Análisis (Atributos de calidad que favorece y desfavorece)

Atributos de calidad favorecidos Atributos de calidad desfavorecidos
Capacidad de procesamiento autónomo e independiente. Complejidad en el desarrollo, pruebas y puesta en producción es más complicada.
Se pueden trabajar tecnologías heterogéneas para su desarrollo. Consistencia eventual de los datos.
Facilidad al implementar escalamiento y reinicio de servicios fallidos. Complejidad Operacional.

Tácticas de Arquitectura

Tácticas de Arquitectura asociadas al experimento Descripción
Táctica de Retiro de la Operacion Si el servicio de Usuario deja de responder positivamente a los eventos enviados debe ser retirado de la operacion para su reinicio y posterior puesta en operacion nuevamente, esto con la finalidad de manejar los errores que se presenten durante la operacion normal del sistema.
Tactica de Aumento de Recursos Si las instancias del servicio de Usuario empieza tener una alta demanda, se espera poder realizar los proceso de escalamiento horizontal y aprovicionamiento de nuevas isntancias, aumentando asi los recursos computaciones de manera temporal, para poder atender los picos de carga al sistema.

Listado de componentes (Microservicios) involucrados en el experimento

Microservicio Propósito y comportamiento esperado Tecnología Asociada
Microservicio de Gestor de Usuarios Este microservicios se encargara de recibir las peticiones de registro de nuevos usuarios, realizar las validaciones de la informacion ingresada y persistirlos en base de datos, completando de esta manera el proceso de registro de un nuevo usuario. Python / Flask / Docker
Microservicio de Gestor de Plan Nutiricional Este microservicios se encargara proveer un plan nutricional basico para que los usuarios tengan como referencia al registrarse en la plataforma. Python / Flask / Docker
Microservicio de Gestor de Entrenamientos Este microservicios se encargara proveer un plan de entrenamiento basico para que los usuarios tengan como referencia al registrarse en la plataforma. Python / Flask / Docker
Ingress Load Balancer Este componente se encargara de monitoreal el estado de salud de los microservicios y aplicar las reglas de escalamiento horizontal establecidad, de igual forma ayudara a rediriguir el trafico de las peticiones hacia los microservicios pertinentes. Kuberentes

Listado de conectores involucrados en el experimento

Conector Comportamiento deseado en el experimento Tecnología Asociada
crear_usuario Este conector va a recibir la informacion de registro de los usuarios, y los recibira el Gestor de Usuarios para poder crear su perfil, con los datos validos. Rest-API
consultar_entrenamiento Este conector va a servir para regresar al Gestor de Usarios un plan de Entrenamiento basico segun los datos enviados. Rest-API
consultar_alimentacion Este conector va a servir para regresar al Gestor de Usarios un plan de nutricional segun los datos enviados. Rest-API

Tecnología asociada con el experimento

Tecnología asociada con el experimento Descripcion
Lenguajes de programación Python
Plataforma de despliegue Docker y Kubernetes
Bases de datos SQLite
Herramientas para ejecución de pruebas JMeter
Herramientas de análisis Excel
Librerías Nginx
Frameworks de desarrollo Flask
Proveedor de Nube Google Gloud Platform.

Distribución de actividades por integrante

Integrante Actividad Esfuerzo Asociado
Haiber Creacion de Microservicio de Gestor de Usuarios 3 horas
Jorge Creacion de Microservicio de Gestor de Entrenamientos 1.5 horas
Haiber Creacion de Microservicio de Gestor Plan Nutricional 1.5 horas
Jorge Creacion Configuracion DockerFile 1.5 horas
Haiber Creacion Configuracion de Kubernetes 1.5 horas
Jorge Preparacion de Ambiente de Prueba 2 horas
Haiber Creacion de Set de Pruebas 2 horas
Jorge Ejecucion de Pruebas 2 horas
Haiber Analisis de Datos 3 horas
⚠️ **GitHub.com Fallback** ⚠️