Diseño de una arquitectura distribuida geográficamente
Azure es un sistema global. Al diseñar una arquitectura que esté presente en más de una región de Azure, podemos compilar una aplicación que sea resistente incluso a desastres en toda la región.
Su portal de seguimiento de envíos es escalable porque se ha creado con una variedad de recursos de Azure que se pueden escalar. Además, es resistente a muchos errores porque sus componentes pueden tener varias instancias. Aun así, a la junta directiva de su empresa le preocupa que un desastre a gran escala pueda provocar una interrupción porque el portal se encuentra por completo en la región de Azure Este de EE. UU. Usted quiere proponer una arquitectura modificada que pueda conmutar por error a una segunda región en caso de que se produzca un error en la del Este de EE. UU.
Aquí aprenderemos a ajustar la arquitectura de nuestra aplicación para admitir una aplicación distribuida geográficamente. También veremos por qué esta arquitectura es útil para las aplicaciones críticas para la empresa.
Arquitectura de la aplicación web original
Echemos un vistazo a cómo se usan en la solución el diseño arquitectónico y los componentes del portal de seguimiento. Una vez que entendamos cómo se usan todos los elementos, podremos investigar cómo admitir cada uno de ellos en escenarios de redundancia geográfica.
El diseño del portal de seguimiento se basa en la arquitectura de referencia que se muestra en este diagrama.
Observe la forma en que la aplicación usa un único grupo de recursos de Azure. Este grupo de recursos nos permite agrupar y administrar todos los recursos de manera lógica y simplifica la administración. Decidimos implementar este grupo de recursos en la región Este de EE. UU. Aunque el grupo de recursos no nos limita a usar la misma región de Azure para los recursos incluidos, hemos decidido usar la región Este de EE. UU. para todos los recursos implementados en nuestra aplicación.
Nuestra aplicación usa tres categorías de recursos de Azure. Veamos cada categoría y qué recursos se emplean.
Componentes de red
El portal de seguimiento usa los siguientes servicios de red.
| Servicio | Descripción |
|---|---|
| DNS de Azure | Hemos configurado Azure DNS para que hospede nuestros registros DNS en Azure. Azure DNS nos permite administrar los registros DNS con las credenciales de Azure en Azure Portal. |
| Application Gateway | Hemos configurado el equilibrador de carga de Application Gateway para equilibrar el tráfico entre varias instancias del front-end web. Este servicio se localiza en una región de Azure. |
| Azure CDN | Hemos configurado Azure CDN para maximizar la entrega de contenido estático no seguro, como gráficos para el contenido del sitio web. Este servicio global almacena en caché el contenido estático en puntos de presencia por todo el mundo. |
Componentes de aplicación
El portal de seguimiento usa los siguientes servicios para admitir los requisitos de código, caché y almacenamiento intermedio.
| Servicio | Descripción |
|---|---|
| Microsoft Entra ID | Los usuarios acceden al portal de seguimiento mediante cuentas de Microsoft Entra. El directorio y la cuenta se replican automáticamente de forma global. |
| Azure App Service | El portal de seguimiento usa dos servicios de Azure App Service. El primero ejecuta un conjunto de páginas web dinámicas y el segundo, una API web. |
| Aplicaciones de Azure Functions | El portal de seguimiento usa aplicaciones de Azure Functions para ejecutar todas las tareas en segundo plano. Algunas de estas tareas se ejecutan según una programación periódica, mientras que otras operan en los mensajes de una cola. |
| Colas de Azure Storage | El portal de seguimiento usa colas de Azure Storage con aplicaciones de funciones de Azure. El portal de seguimiento coloca los mensajes generados en la cola desde donde las aplicaciones de Functions procesan estos mensajes. |
| Redis Cache | El portal de seguimiento usa Redis Cache entre el servicio de aplicación de front-end y los sistemas de almacenamiento de datos para maximizar el rendimiento de las consultas. |
| Azure Blob Storage | El contenido estático, como los gráficos y los archivos de vídeo, se conservan como objetos binarios grandes (blobs) en una cuenta de Azure Storage y se entregan a través de Azure CDN. |
| Azure Search | Hemos habilitado Azure Search en el portal de seguimiento. Azure Search nos permite realizar búsquedas en todo el contenido y proporcionar sugerencias de búsqueda y resultados de búsqueda aproximados a nuestros usuarios. |
Componentes de almacenamiento de datos
El portal de seguimiento usa los siguientes servicios de almacenamiento persistente.
| Servicio | Descripción |
|---|---|
| Azure SQL Database | Almacenamiento de datos relacionales, como detalles de los pedidos y los clientes en Azure SQL Database. |
| Cosmos DB | Almacenamiento de datos semiestructurados, incluido nuestro catálogo de productos en Cosmos DB. |
Problemas con la arquitectura original
La arquitectura existente para el portal de seguimiento está diseñada para permitir la escalabilidad y la disponibilidad.
Por ejemplo, si la demanda es alta y las respuestas a las solicitudes web de usuario son lentas, puede considerar la posibilidad de agregar más instancias de la aplicación web de front-end en App Service. En este caso, Application Gateway puede enrutar las solicitudes a estas instancias recién creadas.
Aun así, hay escenarios en los que nuestro diseño arquitectónico se enfrenta a desafíos o, incluso, genera errores. Veamos cada escenario para entender mejor el impacto en el portal de seguimiento.
Errores regionales
Algunos eventos importantes podrían interrumpir toda una región de Azure. Los centros de datos de Azure están diseñados para ser muy resistentes, pero un evento meteorológico masivo, como un huracán o una inundación, podría interrumpir el servicio de la región.
Estos eventos son poco habituales y muchas empresas creen que pueden asumir el riesgo. Pero las consecuencias de que un error regional deshabilite el portal de seguimiento son muy peligrosas, por lo que el equipo ejecutivo de la empresa ha decidido eliminar este riesgo.
Acuerdos de Nivel de Servicio
La mayoría de los servicios de Azure ofrecen un Acuerdo de Nivel de Servicio o una garantía de tiempo de actividad. Cuando diseñamos una arquitectura de aplicación que consta de varios servicios de Azure, calculamos el Acuerdo de Nivel de Servicio global de la aplicación como una composición de los demás acuerdos del servicio.
Para calcular este Acuerdo de Nivel de Servicio, se multiplican los acuerdos de los servicios de los componentes. Por ejemplo, supongamos que nuestra aplicación consta de Azure App Service (SLA del 99,95 %) y de Microsoft Entra ID (SLA del 99,9 %). El Acuerdo de Nivel de Servicio final calculado es del 99,85 %.
Si este porcentaje de tiempo de actividad no es suficiente para la aplicación, podemos disponer que la aplicación conmute por error en otra región.
Componentes globales, regionales y configurables
En nuestro diseño, algunos componentes son globales de forma predeterminada y no son vulnerables a un error regional.
Algunos componentes se limitan a una sola región, como Application Gateway. Para estos tipos de componentes debemos seleccionar un servicio alternativo.
Algunos componentes se pueden configurar para que admitan varias regiones. Por ejemplo, podemos usar la opción de almacenamiento con redundancia geográfica (GRS) en la cuenta de Azure Storage que almacena contenido estático. GRS replica los blobs en otra región.
En esta tabla se muestra qué componentes son globales, regionales y configurables.
| Componente | Compatibilidad con varias regiones | Comentarios |
|---|---|---|
| Azure DNS | Global | No es preciso realizar cambios. |
| Application Gateway | Regional | Cada instancia de Application Gateway se encuentra en una sola región. |
| Azure CDN | Global | No es necesario realizar ningún cambio. El contenido se almacena en la caché global de forma predeterminada. |
| Microsoft Entra ID | Global | No es preciso realizar cambios. |
| Azure App Service | Regional | Cada instancia de la aplicación se encuentra en una sola región. |
| Aplicaciones de Azure Functions | Regional | Cada instancia de la aplicación de funciones se encuentra en una sola región. |
| Colas de Azure Storage | Configurable | Puede optar por replicar una cuenta de almacenamiento de Azure en varias regiones. |
| Azure Redis Cache | Regional | Cada instancia de la caché se encuentra en una sola región. |
| Azure Blob Storage | Configurable | Puede optar por replicar una cuenta de almacenamiento de Azure en varias regiones. |
| Azure Search | Regional | Cada instancia del servicio de búsqueda se encuentra en una sola región. |
| Azure SQL Database | Configurable | Puede usar la replicación geográfica para sincronizar datos en varias regiones. |
| Azure Cosmos DB | Configurable | Puede usar la replicación geográfica para sincronizar datos en varias regiones. |
Arquitectura distribuida propuesta
Tras investigar un poco, propone la arquitectura de este diagrama.
En este diseño, hay una región activa (Este de EE. UU.) y una región en espera (Oeste de EE. UU.). La región Este de EE. UU. controla todas las solicitudes que realizan los componentes en circunstancias normales. Si un desastre provoca un error regional, la aplicación conmuta por error a la región Oeste de EE. UU.
Vamos de forma general cómo ha modificado la arquitectura original. Exploraremos estos cambios con más detalle en unidades posteriores.
Redes
Azure DNS y Azure CDN son sistemas globales de forma predeterminada y ya son resistentes a errores regionales, por ello los dejaremos tal cual.
Al crear una instancia de Azure Application Gateway, asignaremos el servicio a una sola región. Para quitar esta vulnerabilidad, reemplazaremos este servicio por Azure Front Door. Front Door puede sondear varios servicios de App Service y controlar la conmutación por error del servicio de la región Este de EE. UU. a la región Oeste de EE. UU.
Servicios de aplicación
Microsoft Entra ID es un sistema global y no necesita ninguna modificación.
Las cuentas de Azure Storage se pueden configurar para replicar contenido en varias regiones. Usaremos una de las opciones de almacenamiento con redundancia geográfica para cambiar la configuración.
Los demás componentes son regionales, entre los que se incluyen App Service, las aplicaciones de Functions, Redis Cache y Azure Search. Crearemos instancias duplicadas de estos componentes en la región Oeste de EE. UU. en nuestro nuevo diseño arquitectónico. En este diseño, la nueva región puede asumir el control cuando se produce una conmutación por error.
Almacenamiento de datos
Azure SQL Database y Azure Cosmos DB admiten la replicación geográfica de datos en otras regiones. Configuraremos estos servicios para replicar los datos del Este de EE. UU. en los servicios equivalentes del Oeste de EE. UU.
Pares regionales
Una región de Azure es un área con una sola zona geográfica que contiene uno o varios centros de datos de Azure. Todas las regiones se emparejan con otras regiones de la misma zona geográfica. En estos pares, las actualizaciones y el mantenimiento planeado se realizan en una sola región de cada vez. Si hay un error que afecta a varias regiones, se da prioridad a al menos una región de cada par para una recuperación rápida.
Se recomienda colocar una arquitectura de dos regiones para la aplicación en las dos regiones de un par regional. Por ejemplo, el Este de EE. UU. se empareja con el Oeste de EE. UU. En nuestro diseño propuesto se usa Este de EE. UU. para la región activa y Oeste de EE. UU. para la región en espera.