Semana 4 ‐ Diseño del experimento - lmaero/MISW-4501-ABCJobs-Grupo1 GitHub Wiki
| Titulo del experimento | Latencia en múltiples zonas geográficas |
|---|---|
| Propósito del experimento | Validar la latencia máxima esperada (300ms) definida en la historia de arquitectura ABC-31, relacionada con la retroalimentación de la respuesta a una prueba presentada por uno o varios aspirantes en simultáneo. Para ejecutar el experimento se desplegará la solución en una única zona AWS definida en Estados Unidos, y se ejecutarán las pruebas desde 3 locaciones geográficas distintas (Colombia, Chile y México). Las pruebas a ejecutar son las siguientes: - 30 usuarios envían la prueba al mismo tiempo. Esta prueba se relaciona con la HU ABC-73 - 100 usuarios envían la prueba al mismo tiempo. Esta prueba se relaciona con la HU ABC-74. |
| Resultados esperados | Independientemente de la zona geográfica desde donde se generen las peticiones, y su distancia a la zona de despliegue, dado que usamos los patrones fachada (API Gateway), responsabilidad única (Evaluator) y a su vez utilizamos el estilo N-Niveles para los diferentes módulos con el fin de reducir el acoplamiento, se espera que la latencia sea menor a 300ms. |
| Recursos requeridos | AWS Free Tier (RDS, EC2, ECR), Postman, JMeter, Express (Node.js), JsonWebToken (JWT) |
| Elementos de arquitectura involucrados | Vista funcional, modelo de componentes. Componentes involucrados en el flujo de evaluador: API Gateway, Authorizer (Authentication and Authorization), Candidate Management, Evaluator, y Database (DB) |
| Esfuerzo estimado | 192 horas. 96 horas para el planteamiento y diseño del experimento. 96 horas para el desarrollo, ejecución y análisis de los resultados. (12h/semanales/miembro) para un equipo de 4 miembros. |
| Punto de sensibilidad | La comunicación entre el componente Candidate Management y el componente Evaluator frente a la alta tasa de solicitudes en simultáneo. La ejecución del algoritmo de evaluación respecto de las consultas a base datos en búsqueda de la respuesta correcta a las preguntas enviadas por el(los) aspirante(s) |
| Historia de arquitectura asociada |
ABC-31: Como aspirante, cuando presento una prueba, dado que el sistema opera normalmente, quiero que la retroalimentación de la pregunta sea devuelta en menos de 0.3 segundos ABC-73: Como administrador del sistema, cuando múltiples usuarios están enviando una prueba, dado que el sistema opera normalmente, quiero el sistema soporte un mínimo de 30 usuarios ABC-74: Como administrador del sistema, cuando múltiples usuarios están enviando una prueba, dado que el sistema opera con alto tráfico, quiero el sistema soporte hasta 100 usuarios ABC-72: Como aspirante cuando presento una prueba dado que el sistema opera normalmente, quiero que la siguiente pregunta (adaptada) sea devuelta en menos de 0.5 segundos |
| Nivel de incertidumbre | Muy bajo Bajo Medio ➡️Alto Muy alto |
| Estilo | Análisis (Atributos de calidad que favorece y desfavorece) |
|---|---|
| N-Niveles | Favorece la alta cohesión, el bajo acoplamiento y la facilidad de modificación, delegando responsabilidades definidas a cada módulo, por ejemplo el nivel de presentación solo es accesible por el cliente y a su vez éste nivel solo puede acceder al API expuesta por el Gateway. Adicionalmente la seguridad limita el acceso de los niveles superiores a los niveles inferiores. A su vez, al modularizar los niveles, los componentes pueden ser reutilizados en distintas partes de la aplicación o incluso en otros proyectos. Atributos de calidad como la latencia se ven desfavorecidos puesto que la velocidad de las operaciones mediante interfaces definidas entre los niveles puede disminuir. El rendimiento del sistema puede verse afectado debido a que se introducen interfaces de comunicación adicionales. |
| Táctica | Descripción |
|---|---|
| Detección de fallas - Monitor | Se utilizará la táctica de monitoreo para hacer una observación constante y registrar métricas respecto del sistema de autenticación como punto de entrada general de la aplicación. Esto permitirá detectar fallas tempranas de disponibilidad de la misma. |
| Acceso a los recursos - Dar prioridad a los eventos | Se utilizará la táctica de dar prioridad a eventos al identificar el tipo de usuario respondiendo una de las pruebas para poder asignar una prioridad con base al atributo seleccionado como prioritario. |
| Acceso a los recursos - Limitar tiempo de ejecución | Se utilizará la táctica de limitar el tiempo de ejecución en el componente Evaluator para poder asignar un tiempo determinado para el response de los eventos. |
| Incremento de recursos - Mantener múltiples copias de la información | Se utilizará la táctica de mantener múltiples copias de la información en el caso de que se identifique que el sistema está siendo degradado debido por el componente DB. |
| Táctica | Descripción |
|---|---|
| Single Responsability | Se implementa el patrón de single responsability al extraer la funcionalidad de evaluar pruebas del componente Candidate Management y asignar esa responsabilidad al componente Evaluator, el cual será el encargado de realizar las validaciones a las pruebas asignadas a un usuario. Por último, el componente Candidate Management tiene como una de sus responsabilidad principales el llevar a cabo la priorización de eventos recibidos para poder cumplir con la latencia esperada. |
| Facade | Se utiliza el patron de diseño facade para proveer una interfaz unica (API Gateway) que sirve como intermediador para la comunicación con los subsistemas de autenticación, lógica de negocio y persistencia. En este caso, se crearon tres 'Routers': 'CandidateRouter', 'ProjectRouter' y 'CompanyRouter', que se encargan de administrar los diferentes componentes del sistema relacionados con los candidatos, los proyectos y las compañías, respectivamente. Esto se llevó a cabo debido a que se busca introducir un único punto de entrada al sistema mediante el cual los clientes se van a comunicar con los subsistemas mediante diferentes peticiones realizadas exclusivamente al API Gateway. El patrón Facade sirve como punto de protección a los subsistemas o componentes al reducir el numero de objetos con los cuales el cliente tiene que lidiar, por lo cual facilita la interacción con el sistema. Por último promueve un bajo acoplamiento entre el subsistema y los clientes que realizan las peticiones, promoviendo de esta forma una baja latencia en el sistema. |
| Abierto y Cerrado | El patrón de abierto y cerrado se utilizó al implementar el API Gateway, esto debido a que los componentes de la lógica de negocio puede ser cambiados por nuevas implementaciones o pueden llegar a ser a ser reemplazados por nuevos componentes en el dado caso de que la lógica de negocio así lo requiera. Sin embargo la funcionalidad expuesta a los clientes no cambia debido a que las API no se modifican, cumpliendo de esta forma que el componente esté abierto a las extensiones pero cerrado a las modificaciones. |
| Singleton | Se utiliza el patrón de singleton para mantener un solo componente de DB asociado a un solo nodo de ejecución para poder garantizar la consistencia y coherencia de los datos del sistema, si el sistema necesita escalar para poder evitar una degradación en los tiempos de respuesta, el patrón seguirá siendo de vital importancia debido a que se mantendrá una única instancia por nodo de ejecución. Este patrón también es utilizado en el componente Monitor, debido a que se mantiene una sola instancia del componente que puede ser replicada a multiples nodos de ejecución en caso de que se necesite un escalamiento en el sistema y de esta forma aumentar el atributo de observabilidad para poder monitorear algún otro componente. |
| Componente | Propósito y comportamiento esperado | Tecnologia asociada |
|---|---|---|
| API Gateway | Recibir de manera centralizada y servir como unico punto de entrada para las peticiones originadas por los clientes. Se espera que no tenga cambios en su comportamiento puesto que es un componente mediador, en contraste a los componentes que resuelven la problematica del sistema. |
Express (JavaScript) |
| Authorizer (Authentication and Authorization) | Autenticar y autorizar las peticiones realizadas por parte del cliente, actuando como un middleware previo al acceso a la logica de negocio. Se espera que introduzca una latencia insignificante por el uso del algoritmo de validacion del token enviado por el cliente. |
Express (JavaScript) and JWT |
| Candidate Management | Valida el perfil del usuario y determina si tiene pruebas disponibles a ser evaluadas y posteriormente envia al componente evaluador en caso de ser necesario. Se espera que las consultas que realice a la base de datos sean de un grado de complejidad bajo e introduzca la menor cantidad de latencia posible. |
Express (JavaScript) |
| Evaluator | Realizar consultas a la base de datos para contrastar las respuestas de las pruebas enviadas por los aspirante. Adicionalmente, asignar un puntaje basado en la dificultad de la pregunta, ponderando y retornando el resultado de la prueba. Se espera que este componente sea el que aumenta en mayor medida la latencia, dada la complejidad de la consulta y el tiempo de ejecucion del algoritmo de evaluacion. |
Express (JavaScript) |
| Database (DB) | Recibir consultas por parte del nivel de logica de negocio y retornar la informacion con base en la consulta realizada. Se espera que en base al diseno de la consulta introduzca o no una cantidad considerable o minima de latencia. |
PostgreSQL (AWS RDS) |
| Conector | Comportamiento deseado en el experimento | Tecnología asociada |
|---|---|---|
| API (Gateway) | Recibir las peticiones enviadas por parte del cliente a través de internet a endpoints públicamente expuestos. Se desea que el API esté disponible en todas las zonas geográficas desde donde se ejecutarán las pruebas. | Express (Node.js), AWS |
| Middleware (Auth Systems) | Recibir las peticiones desde el API Gateway y validar, autenticar y/o autorizar los datos de identidad del client para permitir o denegar el acceso a los recursos ofrecidos por el nivel de lógica de negocio | Express (Node.js), Docker containers, AWS (EC2) |
| Candidate API | Recibir la carga paga del token validado por el middleware de autenticación y perfilar el usuario y los datos enviados para determinar si se debe enviar la información al componente Evaluator. | Express (Node.js), Docker containers, AWS (EC2) |
| Database Services | Recibir las consultas emitidas por parte de los componentes Candidate API y Evaluator, para recuperar información relacionada con las pruebas y/o respuestas presentadas por los aspirantes. | AWS (RDS) |
| Tecnología | Justificación |
|---|---|
| Express (Node.js) | Framework del ecosistema JavaScript para desarrollar los distintos módulos y/o componentes involucrados en el experimento |
| JWT | Librería para generación y validación de sesiones (autenticación y autorización), que además permite la inclusión de una carga paga con insumo para las peticiones. Ofrece una capa de seguridad al cifrar los datos del usuario que se intenta autenticar. |
| AWS (RDS, ECR, EC2) | Ecosistema de servicios de Amazon que permite crear por demanda y hacer uso de infraestructura como servicio, para desplegar aplicaciones en la nube. |
| Docker Containers | Tecnología de contenerización de aplicaciones, manteniendo un ambiente de ejecución consistente y portable entre máquinas físicas con configuraciones variadas. |
| Postman y JMeter | Herramientas para probar servicios o APIs que no disponen de una interfaz gráfica. JMeter usada principalmente para pruebas de carga, y Postman para crear colecciones de peticiones HTTP, ejecutarlas, documentarlas, etc. |
| Integrante | Tareas a realizar | Esfuerzo estimado |
|---|---|---|
| Alonso Daniel Cantu Trejo | Realizar la implementación del microservicio de autenticación Preparar y ejecutar las pruebas en JMeter |
12 horas/semana, un total de 48 horas distribuidas en semanas 4, 5, 6 y 7 |
| Camilo Andres Galvez Vidal | Crear el evaluador con el respectivo algoritmo Crear colección de pruebas en Postman |
12 horas/semana, un total de 48 horas distribuidas en semanas 4, 5, 6 y 7 |
| Diego Fernando Eslava Lozano | Realizar la implementación del microservicio de candidate management Generar los datos para alimentar el banco de preguntas y respuestas en base de datos |
12 horas/semana, un total de 48 horas distribuidas en semanas 4, 5, 6 y 7 |
| Luis Miguel Guzman Perez | Desplegar la infraestructura requerida en AWS Contenerizar los microservicios |
12 horas/semana, un total de 48 horas distribuidas en semanas 4, 5, 6 y 7 |