Una arquitectura compleja usando AWS

No podía cerrar mayo sin publicar una entrada. No he tenido el suficiente tiempo pues he estado dedicada a varios proyectos, y claro a estudiar, pues estoy preparándome para certificarme como Amazon architect. Así que, decidí en honor a la mejor clase que he recibido hasta ahora, y también como un buen ejercicio para repasar, publicar hoy una arquitectura en Amazon Web Services usando tres capas y compartirles un poco de cómo he aprendido que todo esto se relaciona.

Vamos a suponer que tengo un requerimiento, la creación de un sitio web con un carrito de compras para clientes que desean comprar licores y pinturas. Este es un sitio web que permite no solo la búsqueda de productos, sino su compra y despacho, funciona únicamente para clientes finales personas naturales o B2C si así queremos llamarlo.

Se espera que el sitio de comercio electrónico reciba visitas de distintas latitudes en el mundo, se espera que sea rápido en su rendimiento y seguro (como todos los requerimientos de los usuarios jajajaja). Además se solicita que este disponible 99.999% del tiempo y que maneje estrategias que permitan que esto suceda, al final son productos que se adquieren 7x24.

Ahora vamos a suponer que ya soy una arquitecta Amazon certificada y que debo de definir la arquitectura a usar para esta aplicación. Algo que ha funcionado para mí es empezar pensando en la estructura más sencilla de la solución y luego ir haciéndola robusta hasta que considero que cumplirá los requerimientos de mi cliente final. Así que iniciaré cumpliendo con el primer requisito, un sitio web que permita tener un carrito de compras:

Arquitectura número uno:

A.  En esta arquitectura consideraré entonces un EC2 instance o en otras palabras un servidor en donde desplegará mi sitio web transaccional. (Si fuera solo estático podría considerar un bucket de S3 pero no es el caso). Este servidor, según las métricas entregadas por el cliente puede ser de la familia M3, no necesito más. (las familias definen entre otras cosas la capacidad del servidor, memoria, espacio, I/O, etc).

B. Debo tener almacenamiento para poder tener cuentas de clientes que compran, así que agregare una base de datos, en este caso usare RDS que es el servicio de bases de datos relacionales de AWS. Además he decidido desplegar una base de datos en Aurora, motor propio de AWS que ya por su propia cuenta maneja temas como réplicas, disponibilidad, entre otros. (Un poco más caro pero el mantenimiento, crecimiento será más sencillo).

C. En términos de seguridad quiero que solo mi servidor EC2 sea accesible desde internet, por lo que mi instancia de Aurora la creó dentro de una subnet privada y creo permisos de acceso únicamente a el servidor en donde alojo mi sitio web. Además agregó RUTA 53, esto no es más que un DNS para los servicios de AWS. Finalmente asignó a este servidor web una ip elástica para que en caso de cambiar la ip publica no tener problemas de direccionamiento. Al final mi arquitectura se vería mas o menos así:

2. Mi segunda arquitectura ya será un poco más completa pues aunque ya tengo un sitio web, aun tengo requerimientos de seguridad, disponibilidad, cantidad de transacciones y rendimiento que debo cumplir.

Primero para la alta disponibilidad y tolerancia a fallos definitivamente NO puedo tener un solo servidor EC2 instance ,y cómo a diferencia de aurora, la alta disponibilidad no está por defecto, debo configurarla. Para esto necesito entonces agregar un balanceador de cargas que entre otras cosas incluye un health check, este me permitirá asegurar disponibilidad y saber si alguna instancia está “muerta”, además para tener acceso desde distintas regiones desplegare estas instancias en MutliAZ ósea en distintas zonas de disponibilidad o distintos data center en distintos lugares del mundo si así queremos llamarlo.

Si tengo los servidores y las peticiones distribuidas tengo que lidiar con un nuevo “requerimiento”. Si un cliente lanza una petición por ejemplo y crea un carrito de compras, quiero asegurarme que este quede disponible la próxima vez que el cliente entre, y que pueda visualizarse si su nueva petición ya no viaja al mismo servidor (Si quisiera que viajará al mismo servidor puede configurar stickiness pero esto no me gusta para el nivel de disponibilidad porque qué pasa si justo esta instancia se cae) así que mejor colocare un elasticache, en donde almacenar el carrito de compras de todos los clientes que visiten el sitio.

Voy a eliminar la elastic ip, pues ya no es un solo servidor, mejor configurar un alias en el Route53 que me direccione al balanceador de cargas, que además por seguridad será el único desplegado en una subnet publica, ahora tanto mis máquinas EC2 como mi capa de RDS estarán en subnets privadas solo accesibles desde el balanceador o entre ellas.  

Finalmente, incluiré read replicas para Aurora, esto con el fin de que todo lo que el sitio requiera en términos de lecturas así como toda la reportería que implementará próximamente apunte a estos servicios y así no generar problemas de disponibilidad.

Mi arquitectura final se vería mas o menos así:

Como todas las arquitecturas existen miles de opciones distintas de cumplir los requerimientos de mi cliente, pero esta seria mi solución final a plantear. Al final de este ejercicio y de lo todo lo que he estudiado he llegado a la conclusión que AWS me permite realmente por primera vez relacional atributos de calidad, conceptos de arquitectura de software con el despliegue final de las soluciones. Definitivamente Cloud es él cómo!!!