Arquitectura de despliegue en la nube: camino de la petición y resiliencia
Una arquitectura de despliegue en la nube en un lienzo interactivo: el borde, el balanceador de carga, la capa de aplicación con autoescalado, la capa de datos y la observabilidad que mantienen el servicio en pie.
Un despliegue en la nube convierte un solo servidor en un sistema resiliente: el tráfico entra por el borde de la red, un balanceador de carga lo reparte, una capa con autoescalado lo atiende, una capa de datos lo guarda y la monitorización mantiene honesta a toda la pila.
Arquitectura de despliegue en la nube: camino de la petición y resiliencia
El lienzo interactivo de FlowJam de esta explicación: cada carril, cada fila y cada flecha de arriba forma parte de un diagrama real de QueryChart que puedes abrir y editar.
Cómo leer este diagrama
- Lee primero la columna izquierda de arriba abajo: usuarios, CDN, balanceador de carga, instancias, caché y base de datos; ese es el camino de la petición.
- Después lee la columna derecha como la historia de la resiliencia: el autoescalado, las réplicas, las copias de seguridad y la monitorización que mantienen vivo el camino de la petición.
- La banda de observabilidad es la capa de sensores: va la última porque vigila todo lo que tiene encima.
El camino de la petición
«Los usuarios llegan al servicio por el borde de la red» abre el viaje, y «La CDN cachea el contenido estático cerca de los usuarios» es la primera línea de defensa: recursos estáticos servidos desde ubicaciones del borde cercanas al visitante. «El balanceador de carga reparte el tráfico» es la puerta de entrada a la capa de cómputo, y reenvía cada petición a una instancia sana. «Las instancias de la aplicación atienden las peticiones» y «Una caché en memoria acelera las lecturas repetidas» son el corazón que trabaja, con la caché manteniendo los datos calientes fuera de la base de datos.
La capa de datos
«La base de datos principal guarda la única fuente de verdad» es el único componente que no se puede reconstruir desde cero, y «Las réplicas y las copias de seguridad protegen los datos» es el plan de recuperación: las réplicas de lectura reparten la carga, y las copias a un punto en el tiempo y entre regiones cubren los desastres. El diagrama la separa en su propio carril porque la capa de datos falla de otra manera que las capas sin estado que tiene encima y necesita otro conjunto de controles.
Resiliencia y observabilidad
«Grupo de autoescalado de instancias de la aplicación» escala en horizontal según el tráfico, y «La monitorización y las alertas vigilan toda la pila» es la capa de sensores: métricas, logs y alertas en todas las capas, y el disparador de la autorreparación y del rollback. «El despliegue escala y se repara solo» es el estado final: no una arquitectura fija, sino una que se ajusta sola. Ese autoajuste es toda la diferencia entre un despliegue en la nube y un solo servidor.
Relaciones clave y conclusiones
- La resiliencia va por capas: CDN, balanceador de carga, autoescalado, caché, réplicas y monitorización; cada capa protege a la que tiene detrás.
- La capa de datos falla de otra manera y necesita sus propios controles: réplicas para la carga y copias de seguridad para la recuperación.
- El balanceador de carga es la puerta de entrada; el autoescalado decide cuántas puertas hay.
- La caché es prescindible: perderla ralentiza el sistema, no lo rompe.
- La monitorización es lo que cierra el bucle: una alerta dispara las decisiones de escalado, rollback y recuperación.
Cuándo usar este diagrama
- Enseñar la anatomía de un despliegue en la nube antes de que un equipo diseñe su primer entorno de producción.
- Revisar una arquitectura en busca de huecos de resiliencia: una capa sin redundancia es un punto único de fallo que el lienzo deja a la vista.
- Anclar una discusión sobre el coste de la nube: cada capa es una decisión sobre cuánto pagar por la redundancia.
Cómo funciona
Renombra las capas con tu stack
Sustituye las capas genéricas por tus servicios reales —tu proveedor de CDN, tu balanceador de carga, tu tipo de instancia, tu motor de base de datos— con una caja por capa.
Dibuja el flujo de tráfico
Anota en el camino de la petición los protocolos y puertos reales, y señala dónde termina TLS y dónde se toman las decisiones de enrutamiento.
Añade tus reglas de escalado
En la caja de autoescalado, anota la métrica y los umbrales que disparan el escalado en tu entorno, para que el diagrama refleje tu política.
Documenta el plan de recuperación
Añade una rama de la base de datos a la caja de copias de seguridad con tu RPO y tu RTO y el procedimiento real de restauración o de conmutación por error, terminando en un estado de recuperación explícito.
Preguntas frecuentes
¿Qué es una arquitectura de despliegue en la nube?
Es el diseño de cómo se ejecuta un servicio en la nube: el tráfico entra por el borde de la red (la CDN), un balanceador de carga lo reparte, un grupo de instancias con autoescalado lo atiende, una capa de datos lo guarda y la monitorización lo vigila todo. La propiedad que define esta arquitectura es la resiliencia: el fallo de un solo componente no tumba el servicio, porque cada capa es redundante y se ajusta sola.
¿Por qué se trata la capa de datos de forma distinta al resto?
Porque las capas sin estado —instancias, cachés— se pueden reconstruir o sustituir al instante, mientras que la base de datos guarda la única fuente de verdad, que no se puede recrear. Necesita sus propios controles: réplicas para repartir la carga de lectura, copias de seguridad a un punto en el tiempo y entre regiones para la recuperación, y un procedimiento definido de conmutación por error. El diagrama le da a la capa de datos su propio carril porque sus modos de fallo y sus controles son distintos de los de las capas que tiene encima.
¿Qué significa «autoescalado» y por qué importa?
El autoescalado añade o quita instancias de la aplicación automáticamente según la demanda medida, normalmente CPU, memoria o profundidad de la cola. Importa porque convierte la capacidad de una suposición en un bucle de control: el sistema compra más capacidad cuando está ocupado y la libera cuando no lo está, y sustituye una instancia caída sin intervención humana. Ese autoajuste es buena parte de lo que hace resiliente a un despliegue en la nube.
¿Cómo encajan la caché y la monitorización en la arquitectura?
La caché se sitúa entre la aplicación y la base de datos: los datos calientes se sirven desde memoria, así que la base de datos solo ve las peticiones que de verdad la necesitan. La monitorización es la capa de sensores en todas las capas —métricas, logs y alertas— y es lo que dispara los demás mecanismos de resiliencia: un pico de errores inicia el rollback, una subida de carga dispara el escalado, una instancia caída se sustituye. Sin monitorización, el resto de la arquitectura opera a ciegas.
Edita este diagrama en QueryChart (FlowJam)
Abre ese mismo lienzo de despliegue en la nube como tu propio diagrama, renombra las capas con tu stack y dibuja tus controles de resiliencia.