Diagrama de arquitectura de tres niveles: presentación, aplicación y datos

La arquitectura de tres niveles es la forma que la mayoría de las aplicaciones web todavía tienen por dentro: algo que sirve la interfaz de usuario, algo que ejecuta la lógica de negocio y algo que guarda los datos. Es antigua, es aburrida y es el punto de partida correcto para la mayoría de los sistemas, porque cada nivel puede escalar y protegerse por separado.

Este artículo explica los tres niveles, muestra cómo se trasladan a una red en la nube con subredes y grupos de seguridad, y dibuja un despliegue típico en AWS repartido en dos zonas de disponibilidad. La misma estructura sirve en cualquier nube.

Los tres niveles

La regla que lo convierte en una arquitectura y no solo en tres cajas: cada nivel solo habla con su vecino. El navegador nunca llega a la base de datos y el nivel de presentación nunca ejecuta SQL.

AWS describe el patrón en su descripción general de la arquitectura de tres niveles, incluidas variantes serverless en las que las funciones sustituyen a los servidores de aplicación.

Llevar los niveles a la red

Los niveles se convierten en fronteras reales cuando viven en subredes distintas con rutas distintas:

• Las subredes públicas contienen solo lo que debe ser accesible desde Internet: el balanceador de carga y las pasarelas NAT.
• Las subredes privadas de aplicación contienen los servidores de aplicación. Pueden salir a Internet a través de NAT para actualizaciones y API, pero nada puede llegar a ellos desde fuera salvo a través del balanceador.
• Las subredes privadas de datos contienen bases de datos y cachés, sin ninguna ruta a Internet.

Después, los grupos de seguridad solo permiten el tráfico del vecino: la base de datos acepta el puerto 5432 únicamente desde el grupo de seguridad del nivel de aplicación, no desde un rango de IP. Hacer referencia a grupos en lugar de a direcciones mantiene las reglas correctas a medida que las instancias van y vienen.

Alta disponibilidad entre zonas

Ejecuta cada nivel en al menos dos zonas de disponibilidad:

• El balanceador de carga abarca varias zonas por diseño.
• Los servidores de aplicación se ejecutan en un grupo de autoescalado con instancias en cada zona. Si una zona falla, las demás asumen el tráfico y el grupo repone la capacidad.
• La base de datos se ejecuta con un standby síncrono en otra zona. Con Amazon RDS Multi-AZ, la conmutación al standby es automática y el nombre del endpoint no cambia.

Mantén el nivel de aplicación sin estado para que cualquier instancia pueda atender cualquier petición: las sesiones van a una caché compartida o a la base de datos, los archivos subidos al almacenamiento de objetos, y nada importante vive en el disco de una instancia. Pruébalo terminando un servidor de aplicación al azar en horario laboral; si los usuarios lo notan, todavía queda estado escondido en las instancias.

Escalar cada nivel

Los niveles escalan de forma distinta, y esa es la razón para mantenerlos separados:

• Presentación: una CDN absorbe la mayor parte del tráfico estático. Las cabeceras de caché deciden cuánto.
• Aplicación: añade instancias. Escala según el número de peticiones o la CPU, y mantén rápido el arranque de las instancias.
• Datos: el más difícil. Escala verticalmente primero, añade réplicas de lectura para cargas dominadas por lecturas, una caché para las claves calientes y deja el sharding como último recurso.

Una petición a través de los niveles

Sigue a un usuario que carga su historial de pedidos:

1. El DNS devuelve la dirección de la CDN. El navegador pide la página; el HTML, los scripts y las imágenes vienen de la caché de la CDN o del bucket estático que hay detrás.
2. La página llama a GET /api/orders. La CDN reenvía las rutas dinámicas al balanceador, que termina TLS y elige un servidor de aplicación sano en cualquiera de las dos zonas.
3. El servidor de aplicación lee la sesión de la caché, comprueba que el usuario ha iniciado sesión y consulta los pedidos en la base de datos primaria.
4. La respuesta vuelve a través del balanceador y de la CDN, que no la guarda en caché porque la respuesta es privada.

Cada salto cruza una sola frontera de nivel, y cada frontera tiene exactamente un punto de entrada permitido. Eso es lo que hace que el diseño sea fácil de entender y de proteger.

Costes y dimensionamiento

El nivel de datos suele dominar la factura y es el más difícil de reducir después, así que dimensiónalo a partir de mediciones, no de suposiciones. El nivel de aplicación es el más fácil de ajustar: empieza pequeño, escala según la carga real y deja que el autoescalado se ocupe de los picos. Las pasarelas NAT y el tráfico entre zonas son las partidas que sorprenden; mantén el tráfico más hablador dentro de una zona cuando puedas y usa endpoints de VPC para el almacenamiento de objetos, para que los servidores de aplicación no paguen NAT por cada subida.

El diagrama de arquitectura

Cómo leerlo:

• Arriba: los usuarios resuelven el DNS y se conectan a la CDN, que sirve archivos estáticos desde un bucket y reenvía las peticiones dinámicas.
• Nivel de presentación: el application load balancer es el único componente en las subredes públicas.
• Nivel de aplicación: los servidores de aplicación de las zonas A y B están en subredes privadas y solo reciben tráfico del balanceador.
• Nivel de datos: la base de datos primaria de la zona A se replica de forma síncrona en un standby de la zona B; los servidores de aplicación también usan una caché de sesiones. Este nivel no tiene ruta a Internet.
• El bloque Markdown enumera las reglas de los grupos de seguridad, que son las que hacen cumplir de verdad los niveles.

Errores comunes

• Bases de datos en subredes públicas, «temporalmente», para hacer una consulta rápida desde un portátil. Usa en su lugar un bastión o una herramienta de sesiones gestionada.
• Grupos de seguridad que permiten un rango CIDR completo entre niveles en lugar de hacer referencia al grupo del vecino.
• Estado en los servidores de aplicación: sesiones en memoria, archivos subidos en el disco local. El autoescalado y la conmutación por error pierden entonces datos.
• Una sola zona de disponibilidad para la base de datos para ahorrar dinero, con el nivel de aplicación repartido en tres.
• Prescindir de la CDN y servir cada imagen desde los servidores de aplicación.
• Ninguna ruta de health check en los servidores de aplicación, de modo que el balanceador sigue enviando tráfico a instancias que no llegan a la base de datos.

Cuando tres niveles no bastan

Tres niveles describen una aplicación. Cuando un sistema crece hasta tener varios servicios, cada servicio suele conservar su propia forma de tres niveles y el diagrama sube un nivel para mostrar cómo hablan los servicios entre sí. El diagrama de arquitectura de microservicios cubre ese paso. Para los detalles de red, consulta el diagrama de VPC de AWS, y para más de una región, el diagrama de arquitectura multirregión en AWS.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Añade una Persona del pack Modelo C4, un DNS del pack Red, y una CDN y un nodo Almacenamiento de objetos del pack Nube.
3. Añade una VPC del pack Red y, dentro, tres nodos Marco del pack Básico, uno por nivel.
4. Añade un Balanceador de carga en la nube al nivel de presentación, dos nodos Instancia de cómputo al nivel de aplicación, y dos nodos Base de datos administrada más Redis del pack Datos al nivel de datos.
5. Conecta cada nivel solo con su vecino y añade un bloque Markdown del pack Básico con las reglas de los grupos de seguridad. Si tu infraestructura ya existe en Terraform, la herramienta de Terraform a diagrama te da un primer borrador.

El ejemplo usa 15 nodos de diagrama, dentro del plan Free.

Preguntas frecuentes

¿Cuáles son los tres niveles de una arquitectura de tres niveles? Presentación (la interfaz de usuario y el punto de entrada), aplicación (lógica de negocio y API) y datos (bases de datos, cachés y almacenamiento).

¿Está obsoleta la arquitectura de tres niveles? No. Es la forma predeterminada de las aplicaciones web. Los microservicios y los sistemas serverless siguen conteniendo las mismas tres responsabilidades, a menudo por servicio.

¿Qué diferencia hay entre la arquitectura de tres niveles y la de tres capas? Las capas son una división lógica dentro del código; los niveles son una división física entre máquinas o servicios separados, con fronteras de red entre ellos.

¿Debe estar la base de datos en una subred pública? No. Mantenla en subredes privadas sin ruta a Internet, accesible solo desde el grupo de seguridad del nivel de aplicación.

¿Cómo hago que una aplicación de tres niveles tenga alta disponibilidad? Ejecuta cada nivel en al menos dos zonas de disponibilidad, mantén sin estado los servidores de aplicación y usa una base de datos con standby automático en otra zona.

Empieza gratis — un puesto, sin tarjeta de crédito.