IIC2173 - Entrega 1 - Levantando clusters hechos por estudiantes de arquitectura de sistemas de software
Esta segunda parte del proyecto sirve para que conozcan e implementen herramientas para tener escalabilidad y performance en sus aplicaciones. Para esto, cada grupo debe escoger una E0 de los integrantes de su grupo y trabajar desde ahí o implementar una nueva que cumpla con los requisitos de la E0 (poco recomendado). Eventualmente pueden complementar su solución entre los conocimientos aprendidos por todos los integrantes durante esa primera entrega.
La entrega tiene por objetivo separar el frontend del backend del chat. Para esto se implementará una Content Delivery Network (CDN) y se desacomplarán los servicios utilizando endpoints mediante HTTP.
Debe ser entregada a más tardar a las 23:59 del domingo 11 de Octubre. Las condiciones de entrega están explicadas más abajo. De ser entregada el día lunes 12 de Octubre se obtendrá nota máxima 6.0.
Para esta entrega, deberan hacer una demo de 10-15 minutos acerca de lo que hicieron en la entrega y que al menos un tercio del grupo exponga sobre la solución. Se les pedirá mostrar su trabajo en la consola del servicio cloud y pruebas de usabilidad. Se les avisarán las fechas disponibles (es la semana entre entregas) y algunas pruebas obligatorias que deben hacer para evaluar la correctitud de su solución.
Deben subir el código de su solución (hasta donde aplique) en el repositorio que se les asignará vía github classroom a cada grupo. Deben inscribirse en el siguiente link
https://classroom.github.com/g/9f2h5kYm
Primero entra un miembro a crear el grupo y luego los demás pueden entrar a ese grupo. Ojo con que entren al grupo correcto, puesto que es difícil cambiarlos. Si se crean dos grupos con el mismo nombre, habra una penalizacion al grupo que se creo después. También deben entregar el archivo .pem asociado al servidor EC2 para revisarla. Alternativamente pueden indicarnos para su disponibilidad para incorporarnos (ayudantes) a su lista de "authorized_keys".
Además, para poder facilitar la corrección deben realizar un README.md que señale:
- Consideraciones generales
- Método de acceso al servidor con archivo .pem y ssh (no publicar estas credenciales en el repositorio).
- Logrado o no logrado y comentarios si son necesarios para cada aspecto a evaluar en la Parte mínima y en la Parte variable.
- De realizar un tercer requisito variable también explicitar en el readme.
Pueden sobreescribir este README sin problemas o cambiarle el nombre.
Esta entrega consiste en dos partes, la parte mínima (que todos deben lograr) que vale 50% de la nota final y una parte variable que también vale 50%. Sobre la parte variable, tendrán 3 opciones para trabajar, de las que deberán escoger 2. Cada una de las que escojan para evaluar vale 25% de la nota final, y realizar una tercera parte puede dar hasta 3 décimas.
-
RF1: (3p) Se debe poder enviar mensajes y se debe registrar su timestamp. Estos mensajes deben aparecer en otro usuario, ya sea en tiempo real o refrescando la página. El no cumplir este requisito completamente limita la nota a 3.9
-
RF2: (5p) Se deben exponer endpoints HTTP que realicen el procesamiento y cómputo del chat para permitir desacoplar la aplicación. El no cumplir este requisito completamente limita la nota a 3.9
-
RF3: (7p) Establecer un AutoScalingGroup con una AMI de su instancia EC2 para lograr autoescalado direccionado desde un ELB (Elastic Load Balancer).
- (4p) Debe estar implementado el Load Balancer
- (3p) Se debe añadir al header del request información sobre cuál instancia fue utilizada para manejar el request. Se debe señalar en el Readme cuál fue el header agregado.
-
RF4: (2p) El servidor debe tener un nombre de dominio de primer nivel (tech, me, tk, ml, ga, com, cl, etc).
-
RF4: (3p) El dominio debe estar asegurado por SSL con Let's Encrypt. No se pide auto renew. Tambien pueden usar el servicio de certificados de AWS para el ELB
- (2p) Debe tener SSL.
- (1p) Debe redirigir HTTP a HTTPS.
- RF5: (3p) Utilizar un CDN para exponer los assets de su frontend. (ej. archivos estáticos, el mismo frontend, etc.). Para esto recomendamos fuertemente usar cloudfront en combinacion con S3.
-
RF6: (7p) Realizar una aplicación para el frontend que permita ejecutar llamados a los endpoints HTTP del backend.
- (3p) Debe hacer llamados al servidor correctamente.
- Elegir
$1$ de los siguientes. No debe ser una aplicación compleja en diseño. No pueden usar una aplicacion que haga rendering via template de los sitios web. Debe ser una app que funcione via endpoints REST- (4p) Hacer una aplicación móvil (ej. Flutter, ReactNative)
- (4p) Hacer una aplicación web (ej. ReactJS, Vue, Svelte)
Deben completar al menos 2 de los 3 requisitos
Para esta sección variable la idea es implementar una capa de Caché para almacenar información y reducir la carga en el sistema. Para almacenar información para la aplicación recomendamos el uso de Redis, así como recomendamos Memcached para fragmentos de HTML o respuestas de cara al cliente.
- RF1: (4p) Levantar la infraestructura necesaria de caché. Se puede montar en otra máquina o usando el servicios administrado por AWS. Se debe indicar como funciona en local y en producción.
- RF2: (6p) Utilizar la herramienta seleccionada de caché para almacenar las información para al menos 2 casos de uso. Por ejemplo las salas y sus últimos mensajes o credenciales de acceso (login).
- Restricción Por cada caso de uso debe utilizar alguna configuración distinta (reglas de entrada FIFO/LIFO, estructura de datos o bien el uso de reglas de expiración)
- RF3: (5p) Documentar y explicar la selección de la tecnología y su implementación en el sistema. Responder a preguntas como: "¿por qué se usó el FIFO/LRU o almacenar un hash/list/array?" para cada caso de uso implementado.
Para esta sección de delegación de trabajo recomendamos el uso de "Functions as a Service" como el servicio administrado de AWS, Lambda Functions, o bien el uso de más herramientas como AWS SQS y AWS SNS.
Se pide implementar al menos 3 casos de uso con distinto tipo de integración.
1.- Mediante una llamada web (AWS API Gateway) 2.- Mediante código incluyendo la librería (sdk) 3.- Como evento a partir de una regla del AutoScalingGroup 4.- Mediante Eventbridge para eventos externos (NewRelic, Auth0 u otro) 5.- Cuando se esté haciendo un despliegue mediante CodeCommit 6.- Cuando se cree/modifique un documento a S3
Alternativamente pueden integrar más servicios para realizar tareas más lentas de la siguiente forma: 1.- Al crear un mensaje se registra en una cola (SQS) que llama a una función en lambda (directamente o a través de SNS) 2.- En Lambda se analiza ciertos criterios (si es positivo o negativo, si tiene "garabatos" o palabras prohibidas en el chat) y con este resultado se "taggea" el comentario. Si se crean en "tópics" distintos se consideran como 2 casos de uso (por el uso de distintas herramientas).
Seguir el siguiente tutorial cuenta como 3 (https://read.acloud.guru/perform-sentiment-analysis-with-amazon-comprehend-triggered-by-aws-lambda-7363db23651f o https://medium.com/@manojf/sentiment-analysis-with-aws-comprehend-ai-ml-series-454c80a6114). No es necesaro que entiendan a cabalidad como funciona el código de estas funciones, pero sí que comprendan el flujo de la información y cómo es que se ejecuta.
Se deben documentar las decisiones tomadas.
- RF: (5p) Por cada uno de los 3 tipos de integración.
- (3p) Por la implementación.
- (2p) Por la documentación.
El objetivo de esta sección es implementar la capacidad de enviar actualizaciones hacia otros servicios. Servicios recomendados a utilizar: SNS, Sockets (front), AWS Pinpoint entre otras.
- RF1: (5p) Cuando se escriben mensajes en un chat/sala que el usuario está viendo, se debe reflejar dicha acción sin que éste deba refrescar su aplicación.
- RF2: (5p) Independientemente si el usuario está conectado o no, si es nombrado con @ o # se le debe enviar una notificación (al menos crear un servicio que diga que lo hace, servicio que imprime "se está enviando un correo")
- RF3: (5p) Debe documentar los mecanismos utilizados para cada uno de los puntos anteriores indicando sus limitaciones/restricciones.
Si su grupo implementó varias funcionalidades como comandos en los chats, es posible utilizar dichas funciones en Lambdas y manejarlas en paralelo utilizando SQS y SNS en conjunto. Pueden aprovechar su desarrollo para implementar las secciones variables 2 y 3 en conjunto.