6. Arquitectura y desarrollo
6.3 Tecnologías
6.3.3 Infraestructura
Una de las principales decisiones que el equipo tomó fue decidir qué infraestructura construir para el alojamiento del sistema. Si bien los integrantes del equipo habían realizado el curso de “Arquitectura de Software En La Practica”, el nivel de exigencia necesario para albergar un proyecto de tal tamaño sobrepasaba cualquier conocimiento académico previo.
119 PaaS vs IaaS
Se dedicaron días para investigar diferentes alternativas para la correcta elección de las tecnologías que conformasen a la infraestructura del sistema. Luego de analizar factores como el costo, complejidad de uso y control de la plataforma el equipo termino decidiéndose por entre dos candidatos: Heroku y Amazon Web Services. Si bien ambos presentaban una inmensidad de beneficios a contemplar, la principal diferencia en ambos era conceptual; Heroku es catalogada como un Platform as a Service (PaaS por sus siglas en inglés), y AWS como un Infraestracture as a Service (IaaS por sus siglas en inglés).
Luego del análisis realizado que se encuentra en el Anexo 13.13, el equipo terminó optando por Amazon Web Services.
Amazon Web Services
Amazon Web Servies es un IaaS y fue elegido ya que sus costos son muy convenientes y al mismo tiempo brinda una escalabilidad única.
Elegir un IaaS tiene muchos beneficios, ya que el equipo es responsable de toda la infraestructura. En primer lugar, permite acceder a un sistema con costos económicos, más bajos en comparación con otros de los modelos propuestos por Cloud Computing [83].
Por otro lado, tener todo el sistema dentro de Amazon Web Services genera una gran ventaja, ya que todos los servicios de AWS están hechos para trabajar correctamente en conjunto.
Otra gran ventaja de este modelo es la flexibilidad y escalabilidad que permite. Bajo este modelo es muy sencillo escalar un sistema y se puesden elegir entre distintos servidores con distinta capacidad de cómputo para poder elegir el que se adapte más a la solución.
Además del escalado vertical tradicional, el cual es muy sencillo de manipular en AWS, entre los servicios de AWS encontramos los Elastic Load Balancers los cuales nos
120 permiten balancear la carga de la plataforma entre varias instancias de servidores de manera simple haciendo que el escalado horizontal no tenga límites.
Vale la pena mencionar que los servicios IaaS suelen tener una disponibilidad bastante superior a las provistas por otros modelos de Cloud Computing. En el caso de AWS, la disponibilidad es mayor al 99.99 %.
A continuación, se describen los servicios cloud utilizados:
Almacenamiento
El almacenamiento del sistema requirió de la utilización de dos servicios cloud de Amazon, según los requerimientos especificados.
En primer lugar, las bases de datos relacionales son implementaron utilizando el servicio de Amazon RDS (Relational Database System) [84]. Este servicio permite la escalabilidad de forma sencilla, ofrece alta disponibilidad y buena performance y seguridad. También permite realizar respaldos de la base de datos de forma automática y programada, y en caso de necesitar uno en un momento especifico, se lo puede hacer manualmente mediante snapshots. Esto significa una gran ventaja en caso de pérdidas de información.
Por cada base de datos necesaria se creó una instancia MySQL.
La elección de esta se debe a su facilidad de integración con Java Spring y experiencia del equipo. Además, brinda todos los beneficios de una base de datos relacional, tales como la integridad y facilidad de los datos, que son aspectos fundamentales para garantizar la seguridad de esta [85].
Por otro lado, la base de datos NoSQL se utilizó mediante Amazon DynamoDB. Esta es una base de datos no relacional y clave-valor completamente administrada que ofrece desempeños rápidos, alta disponibilidad, durabilidad e integridad de los datos y una escalabilidad optima. A su vez, también ofrece facilidad de integración para con Java Spring mediante la SDK provista por el servicio en tal lenguaje [73].
121 Se utilizó el servicio de S3 (Amazon Simple Storage Services) para el almacenamiento de imágenes [86]. Presenta un excelente rendimiento y permite realizar copias de seguridad de los archivos en cualquier momento. Algunas ventajas que presenta son su facilidad de eso, escalabilidad y seguridad.
Alojamiento
Para el alojamiento de los servidores del backend se utilizó el servicio de EC2 (Elastic Cloud Computing), mediante la creación de instancias con características físicas y de rendimientos apropiadas a las necesidades del proyecto [87]. Se crearon cuatro servidores para alojar a los componentes del backend y otro para la utilización de un repositorio privado de Nexus [88].
Para los servidores del backend se crearon instancias con el sistema operativo Linux Amazon 2 y dentro de estas se instaló la versión de Java Correto11. Las instancias se encuentran alojadas en la región de Us-East-1/Virginia. Si bien Amazon ofrece una instancia Free Tier, es decir gratuita, el equipo se vio en la necesidad de aumentar su capacidad y pasarse a un plan pago para cumplir con los requerimientos de un producto que pretendía estar en producción.
Una vez creados y configurados las instancias, el equipo implementó varias tácticas para mejorar la disponibilidad, performance y seguridad de su aplicación:
• Seguridad
Las instancias del backend se crearon dentro de una red virtual privada (VPC por sus siglas en inglés), lo que significa que sus accesos están restringidos por el alcance de red configurado. Además, estas fueron configuradas con reglas a nivel red (ACL) y a nivel de aplicación (security groups) que permitieron restringir o habilitar los accesos de entrada y salida hacia las instancias y exterior (internet).
122 De esta manera se aplicaron las tácticas de resistir ataques, así como limitar exposición y acceso. Por ejemplo, las instancias del backend fueron habilitados para servir a las peticiones que lleguen por el puerto 8080 mediante protocolo https.
Además, las instancias pueden ser únicamente accedidas mediante SSH y utilizando un par de llaves pública y privada, utilizando la táctica de encriptar. Los accesos a estas fueron restringidos a un único integrante del equipo para mitigar el riesgo a una filtración de seguridad, además de crear un usuario para el despliegue continuo con accesos de lectura limitados.
Ilustración 44 - Reglas de seguridad en AWS
123 Por otro lado, se utilizó el servicio de Amazon Certificate Manager (ACM por sus siglas en inglés) para la creación de certificados SSL y permitir una comunicación segura entre los componentes del backend y con el frontend [89].
• Disponibilidad
Los servicios utilizados para cumplir con una buena disponibilidad a nivel de infraestructura fueron varios. Por un lado, las instancias creadas fueron reagrupadas en determinadas subnets y módulos lógicos para luego poder ser utilizadas como un conjunto indiferente (escalabilidad horizontal). De esta manera, al configurar luego el balanceador de carga mediante el Elastic Load Balancer (ELB por sus siglas en inglés), se balanceó la carga de tráfico del internet y distribuyo en forma uniforme hacia las instancias. De esta manera se utilizaron las tácticas de disponibilidad de recuperación de fallas. Además, el balanceador de carga sirvió para asegurar la disponibilidad en los momentos de despliegue de las aplicaciones. Utilizando la táctica ping/echo el load balancer realiza peticiones de verificación de salud de la aplicación cada cinco segundos.
En caso de que alguna de las instancias no esté saludable, las peticiones siguientes no serán tomadas en cuenta por el balanceador para el ruteo de tráfico hacia esa instancia.
Ilustración 45 - Configuración de dominios en AWS
124
Ilustración 46 - Health check
Dominios
“Dado que existen muchas direcciones IP, los nombres de dominio se crean para formar una identidad única para cada sitio web. Sin un nombre de dominio, su dirección web se traducirá en números de IP. Imagínese la terrible experiencia de recordar una serie de números” [90].
Ilustración 47 - Health check logueado en DataDog
125 El equipo se vio en búsqueda de registrar un dominio para la aplicación web del sistema, así como también para la API de acceso público. Por este motivo, en primer lugar, se recurrió al gestor de dominios Freenom7, que ofrece el registro de dominios sin costo.
Una vez registrados, se utilizó el servicio de Route53 para la creación de una hosted zone y asociar el dominio al balanceador de carga de la aplicación. Luego se crearon los certificados de seguridad correspondientes para poder acceder a la aplicación de forma segura.
7 https://www.freenom.com/en/index.html?lang=en
Ilustración 48 - Certificado SSL
126