Pequeño repaso arquitecturil:
Me gustaría repasar algunos conceptos primero:
¿Qué es una Zona de Disponibilidad aka (AZ: Availability Zone)?
Una AZ en AWS es un centro de datos (o un grupo de centros de datos) físicamente separado e independiente dentro de una Región. Las regiones de AWS cuentan con múltiples AZs, con un mínimo de 3 por región.
Cada AZ dispone de electricidad, refrigeración y redes independientes, lo que garantiza alta disponibilidad y tolerancia a fallos.
¿Puede una subnet formar parte de distintas AZs?
No, por defecto, cada subnet o subred, tiene que estar vinculada a una zona de disponibilidad, no se puede expandir una misma subnet entre varias AZs a la vez.
Si se desea, se pueden desplegar varias subnets (por servicio) y asignarlas a distintas AZs.
¿Por qué se debe de usar distintas subnets en distintas AZs?
Al diseñar arquitecturas que son altamente disponibles, es una buena práctica distribuir las cargas de trabajo segmentando los distintos servicios en diferentes subnets y desplegar estas subnets en distintas AZs para así garantizar la resiliencia.
Por ejemplo:
Una base de datos debería ubicarse dentro una subnet en una AZ. Si se quiere hacer una arquitectura multi-AZ, habría que utilizar más subnets y desplegar los servicios de las DB, dentro de estas subredes, en otras AZs.
Si a nuestro ejemplo añadimos un frontend, este debería de estar desplegado en una subnet distinta a la de la base de datos.
Además tendría que estar desplegado en diferentes AZs, en distintas subnets si se quisiera hacer una arquitectura resiliente multi-AZ.
Siguiendo este principio, mejoramos la seguridad, aumentamos la escalabilidad y aprovechamos las capacidades de resiliencia de AWS.
Subnets públicas vs privadas
- Subnet pública: tiene una ruta directa a Internet.
Ejemplo: Un servidor web se ubica en la subnet pública y está expuesto directamente a Internet. El servidor tiene IP Pública y privada
- Subnet privada: No tiene una ruta directa a Internet.
Ejemplo: Una base de datos se ubica en una subnet privada y no necesita estar expuesta a Internet. La base de datos solo tiene IP Privada
- Es posible permitir que los recursos dentro de una subnet privada se comuniquen con Internet sin que haya acceso desde fuera manteniendo la IP Privada. Para ello, hay que desplegar algunos servicios de red adicionales.
Hace unos meses, un amigo me lanzó un reto, el de diseñar la arquitectura de una aplicación. Podría ser la que quisiera...
Le empecé a dar un par de vueltas para ver cómo se podría arquitecturizar. Lo que empezó como un pequeño proyecto terminó escalando bastante, y esa es la razón por la que estás leyendo este artículo.
¿Cómo crearías un dashboard de ping?
¡Gracias Batman!, Exacto, ¡la P*** red!
No se puede empezar a construir la aplicación sin considerar primero la red. Para hacer esto, me miré ante el espejo y y me pregunté cómo sería la arquitectura a nivel de red:
Quiero crear un dashboard de ping resiliente en múltiples AZs,
con servicios expuestos tanto en subnets públicas como privadas.
En el futuro, quiero extender algunas partes de la aplicación a
diferentes regiones para expandir las mediciones.
Una vez entendido cómo iba a ser la estructura a nivel de red, es hora de entrar a la de la aplicación:
El dashboard de ping contará con un servidor web accesible desde
Internet en una subnet pública, el cual mostrará datos de
latencia obtenidos desde varias máquinas virtuales ubicadas en
subnets privadas y utilizadas como sondas (probes).
Funcionamiento de la aplicación:
Las sondas realizarán mediciones de ping a un objetivo específico
(una URL o una dirección IP) que será enviado por el servidor
web.
Se registrará el tiempo de respuesta desde AWS hasta el destino
indicado.
Los datos de latencia serán almacenados en una base de datos.
El servidor web consultará la base de datos y expondrá la
información a los usuarios finales en un dashboard accesible
desde la subnet pública.
Con este diseño, garantizamos resiliencia, escalabilidad y la posibilidad de expansión a otras regiones en el futuro.
Estructura del VPC (Virtual Private Cloud // La red)
He seleccionado la región eu-south-2 (España) y la red IPv4 10.0.0.0/24.
Dado que no necesito tantas IPs (una /24 contiene 256 IPs), quiero segmentar esta red en subnets más pequeñas y distribuir los servicios en diferentes AZs.
Hora del Subnetting!.
Voy a dividir la /24 en /28, lo que nos dará 16 subnets de 16 hosts cada una (11 utilizables, ya que AWS reserva 5)
Asignación de subnets por AZ
AZ A → Rango: 10.0.0.0/28 - 10.0.0.64/28
10.0.0.0/28
10.0.0.16/28
10.0.0.32/28
10.0.0.48/28
10.0.0.64/28
AZ B → Rango: 10.0.0.80/28 - 10.0.0.144/28
10.0.0.80/28
10.0.0.96/28
10.0.0.112/28
10.0.0.128/28
10.0.0.144/28
AZ C → Rango: 10.0.0.160/28 - 10.0.0.240/28
10.0.0.160/28
10.0.0.176/28
10.0.0.192/28
10.0.0.208/28
10.0.0.224/28
10.0.0.240/28
Basándonos en los requerimientos, necesitamos:
Una base de datos en una subnet privada
Una sonda en una subnet privada
Un servidor web en una subnet pública
Lo que vendría a ser 3 redes por AZ de la lista de arriba
¿Por qué no colocar todo en la misma subnet?
Por seguridad. Cada componente debe estar aislado para minimizar el impacto en caso de brecha de seguridad.
La segmentación en subnets, combinada con reglas de firewall, restringe el acceso de red entre servicios.
Dibujo de nuestra arquitectura
Elementos de red esenciales
Internet Gateway
Necesario para que el servidor web tenga acceso a Internet.
Se despliega a nivel del VPC, no llega a estar ubicado en una subnet.
NAT Gateway
Permite que las instancias en subnets privadas accedan a
Internet sin exponerse directamente.
Se despliega en una subnet pública y funciona en combinación
con el Internet Gateway.
Se ha colocado un NAT Gateway por AZ (esto lo podremos
optimizar en siguientes iteraciones).
Con el cómputo nos hemos topado: EC2
Selección de instancias
Probes (sondas) → t3.micro
Servidores web → t3.micro
Load Balancer → Network Load Balancer (NLB)
En lugar de un solo servidor web, usaremos dos, bajo un NLB, para redistribuir el tráfico entre AZs.
¿Por qué no tres servidores web?
Los servidores webs están incluidos dentro de un
AutoScaling Group (ASG) que se expande entre
las distintas AZs.
Si el NLB detecta fallos en los healthchecks de
la aplicación, el ASG redepliega la instancia en la
misma, o en otra Zona de disponibilidad.
Si una AZ falla, el NLB dejará de enrutar tráfico
a la AZ caída y el ASG reubicará la carga en otra AZ
y el NLB apuntará a esta nueva instancia
Las sondas no son críticas, pero la aplicación sí
lo es, es por eso que podemos permitirnos fallos al
nivel de las sondas.
El NLB usará una Elastic IP.
Añadiendo la base de Datos
Se ha seleccionado RDS Multi-AZ (MySQL) con:
Nodo principal
Réplicas en standby
Si la DB primaria falla, se activa automáticamente
una réplica para hacer el failover.
Instancia utilizada: db.t3.micro
Expansión a otras regiones
Siguiendo el mismo principio, podemos expandir la solución a Frankfurt:
Nueva VPC (10.1.0.0/24)
Subnets públicas y privadas
Probes en cada AZ
NAT Gateway en cada AZ
Internet Gateway
VPC Peering para interconectar ambas regiones
Medidas de Seguridad
Session Manager
Eliminamos puertos abiertos desde el exterior para reducir
la superficie de ataque. Nos conectaremos a las instancias,
de manera segura, a través de la interfaz web usando
session manager.
Security Groups (SGs) por servicio
SG del Servidor Web: Acepta tráfico solo desde el NLB.
SG del NLB: Acepta tráfico de Internet.
SG de la Base de Datos: Solo acepta tráfico del Servidor
Web y las Probes.
SG de las Sondas: Permite tráfico ICMP desde
cualquier origen (0.0.0.0/0).
Costes Aproximados por mes
8 instancias EC2 t3.micro (encendidas 24h // On Demand)
= 8 x 8.32 USD = 66.56 USD
2 Internet Gateway = GRATIS
6 NAT Gateways (1 GB de tráfico mensual)
= 6 x 35.09 USD = 210.54 USD
VPC Peering entre España y Alemania - Cada sonda genera
aproximadamente 6 MB por día = 180 MB por mes x 6 sondas ≈ 1GB de
tráfico = 0.04 USD
Network Load Balancer ≈ 20 USD
Elastic IP = 3.65 USD por IP
RDS Multi-AZ (db.t3.micro) = 77.13 USD
Total: 377.92 USD - Factura mensual
Huella de Carbono estimada
40 KgCO₂eq (Entre EC2 y el RDS)
Vamos a echarle mano a la red:
Podemos eliminar los NAT Gateways que no son indispensables, reduciendo drásticamente los costes. Se puede colocar un solo NAT Gateway en una AZ, permitiendo el acceso a Internet de las instancias en otras zonas de disponibilidad.
Si este NAT Gateway fallase por cualquier motivo, ninguna instancia dentro de las subredes privadas podrá acceder a Internet hasta que AWS lo recree.
- Dado que el NAT Gateway es un servicio administrado por AWS, si falla, se volverá a desplegar automáticamente, pero el proceso puede tardar hasta 15 minutos.
Una buena estrategia sería crear una función de failover automatizada (usando AWS Lambda) que verifique el estado del Nat Gateway actual y actualice las rutas hacia el otro disponible si comienza a fallar.
- He mantenido dos NAT Gateways en España para garantizar alta disponibilidad.
- En Alemania he dejado solo uno, ya que no es crítico.
- Si el NAT Gateway fallase en este caso, habría que esperar a que se vuelva a desplegar.
Vamos a por las Bases de datos:
Al eliminar la arquitectura Multi-AZ, ahorraremos más dinero al final del mes. Pero, ¿qué sacrificamos?
- Usando la RDS en modo single-AZ, perdemos el SLA del 99.95%.
- Cambia el paradigma para recuperar la base de datos si existe algun fallo.
- Para los fallos "recuperables" como problemas en la instancia RDS, el RTO (Recovery Time Objective) será inferior a 30 minutos (esto puede variar según el tamaño de la instancia).
- Para los fallos no recuperables, como fallos en el volumen de datos EBS:
- El RTO dependerá del tiempo necesario para iniciar una nueva instancia de RDS y aplicar todos los cambios desde la última copia de seguridad.
- Este proceso debe iniciarse manualmente o automatizarse con un script en Lambda.
- Los fallos en la Zona de Disponibilidad requieren una recuperación manual o automatizada mediante restauración en un punto en el tiempo en otra AZ.
Vamos a por las instancias EC2:
Vamos a cambiar el enfoque en nuestra aplicación
- Nos hemos cargado el load balancer y la instancia EC2 del servidor web en la AZ B. La IP del NLB ahora la tiene el servidor web.
¿Cuál es la desventaja de hacer esto?
- Amazon supervisa la salud del hardware que contiene la aplicación, pero no vigila si la aplicación está funcionando o no, como lo hacía el Load Balancer.
- Para poder supervisar si la aplicación está levantada y funciona correctamente, tendríamos que usar los health checks de Route53 y funciones de lambda para detectar posibles fallos y automáticamente borrar esa instancia y así poder degradarla y para que el Autoscaling Group la recree de nuevo.
Pero hay una cosita más... 🤔
¿Qué pasaría si el servidor web automatizase el proceso de encendido de las sondas bajo petición de un usuario a través de la aplicación o en intervalos de tiempo para tomar mediciones y luego las apagase automáticamente?
Podriamos reducir mucho dinero con este scheduler...
Costes aproximados por mes
Probes: 6 instancias EC2 t3.micro (Operando 1 hora
por día) = 6 VMs x 0.34 USD (30 horas en el mes)
= 2.04 USD
Servidor Web: 1 instancia EC2 t3.micro (Operando 24h
al día) = 8.32 USD
2 Internet Gateways: GRATIS
3 NAT Gateways (2 GB de tráfico mensual) = 105.42 USD
VPC Peering entre España y Alemania:
Cada probe genera 6 MB por día → 180 MB/mes
por probe → 1GB de tráfico total = 0.04 USD
Elastic IP: 3.65 USD por IP
RDS Single-AZ (t3.micro): 50.66 USD
Total: 170.13 USD - Factura mensual // 2.22 veces menos
Huella de carbono estimada
8.991 KgCO₂eq (Entre EC2 y RDS) // 4.45 veces menos
Tercera iteración: Sujétame el cubata
Usemos ARM:
Cambiando el tipo de instancia de x86 a ARM Graviton, reduciremos costes, mejoraremos la eficiencia eléctrica y térmica y reduciremos aproximadamente en un 40% la huella de carbono.
Las instancias t3.micro y db.t3.micro se han cambiado a la familia t4g.micro
Nota: En algunos casos, el uso de arquitectura ARM requiere la recompilación de la aplicación. Antes de hacer el cambio y migrar, hay que asegurarse de que es compatible.
¿Qué le habéis hecho a la red?
Es posible bajar la factura a nivel de red, haciendo unos simples cambios, pasando del servicio gestionado del NAT gateway, a NAT instances. (Que son instancias EC2 configuradas para enrutar el tráfico hacia el exterior)
Como comentaba, estamos pasando de un servicio gestionado a construirlo nosotros mismos, puede que esto no sea la mejor opción, ni sea la más eficiente, pero creo que merece la pena mostrar esta posibilidad.
Ventajas:
- Ahorro de costes
- En combinación con Route53 y un AutoScaling group, podemos crear failover automático, creando un sistema resiliente
Desventajas:
- El máximo throughput es de 5Gbps, tendríamos que monitorear este parámetro para asegurarnos de que no llegamos al límite y empezamos a tirar paquetes. En comparación, los NAT Gateways pueden llegar hasta 100Gbps sin despeinarse.
- Este diseño implica utilizar una Elastic IP por NAT Instance
- No escala por defecto, es necesario gestión manual del servicio.
Este es el tutorial de AWS sobre cómo configurarlo.
En nuestro caso, si la NAT instance fallase en España o Alemania, el tiempo de caída, sería el tiempo que se necesite en volver a desplegarse la instancia de EC2. Este es el sacrificio que tengo que hacer para ahorrar costes.
Costes aproximados por mes
Sondas: 6 instancias EC2 t4g.micro (Funcionando 1
hora al día) = 6 VMs x 0.28 USD (30 horas al mes)
= 1.68 USD
Servidor web: 1 instancia EC2 t4g.micro (Funcionando
24h al día) = 6.72 USD
Instancias NAT: 2 instancias EC2 t4g.micro (Funcionando
24h al día) = 13.44 USD
2 Internet Gateway = GRATIS
VPC Peering entre España y Alemania - Cada sonda
generará aproximadamente 6 MB por día = 180 MB
al mes x 6 sondas = 1GB de tráfico = 0.04 USD
Elastic IP = 3.65 USD por IP x 3 (2 Instancias NAT
+ Servidor Web) = 10.95 USD
RDS Single-AZ (db.t4g.micro) = 49.20 USD
Total: 8*2.03 USD - Factura mensual // 4.6 veces menos*
Huella de carbono estimada
5.293 KgCO₂eq (Entre EC2 y RDS) // 7.56 veces menos
Conclusión
Esta es la arquitectura más optimizada en cuanto a recursos, siendo la más eficiente y barata. No ha sido nada fácil de visualizar, pero todo empezó a coger forma cuando empecé a dibujar el problema con papel y boli ;)
Este ha sido mi aproximación ante este problema, pero seguro que hay muchos más. ¿Qué hubieras hecho diferente?
Te leo en los comentarios
Top comments (0)