Diseño de una arquitectura de aplicación distribuida geográficamente
Cuando nuestros componentes de red enrutan solicitudes a varias regiones para mitigar los efectos de una interrupción regional, debemos diseñar servicios de aplicación que puedan responder a esas solicitudes en las regiones primaria y en espera.
Recuerde que configuraremos Azure Front Door con la asignación de back-end por prioridad. Asignaremos la región Este de EE. UU. como región primaria y la región Oeste de EE. UU. como región en espera. Cuando se produzca un error regional, las solicitudes se enrutarán a la instancia de App Service de la región en la que no se ha producido ningún error. Tenemos que configurar los recursos de cada región de modo que admitan estas conmutaciones por error para el acceso de usuario, el almacenamiento replicado y el código de aplicación.
Aquí se examinan los servicios de aplicación de nuestra solución y se determina si deben modificarse para funcionar en una arquitectura de varias regiones. En concreto, examinaremos Active Directory, el almacenamiento de contenido estático, las aplicaciones web, la API web, las colas, las funciones de Azure y las cachés de datos.
Microsoft Entra ID
En nuestro portal de seguimiento de envíos, los usuarios pueden seguir la entrega de sus compras mediante un número de seguimiento. Además, los usuarios habituales pueden registrarse para acceder a características avanzadas, como la puntualidad de la entrega y otras estadísticas. Hemos desarrollado el portal de seguimiento para almacenar cuentas de usuario en Microsoft Entra ID.
Microsoft Entra ID está diseñado como un sistema global de forma predeterminada. Como tal, no es vulnerable a errores regionales y no es necesario modificar este componente del sistema.
Azure Blob Storage
El contenido estático, como las imágenes y los vídeos, se almacena en cuentas de Azure Storage como objetos binarios grandes (blobs) y se sirve a los usuarios a través de Azure CDN.
En nuestro diseño original, la cuenta de almacenamiento se encuentra en una sola región porque decidimos usar el almacenamiento con redundancia local (LRS). Nuestros datos solo se replican dentro de un único centro de datos con LRS. Por tanto, la cuenta de almacenamiento no está disponible si se produce una interrupción regional en esta configuración. Cualquier contenido estático que la red CDN ya haya almacenado en caché seguirá estando disponible para los usuarios.
Lo mismo sucede con el almacenamiento con redundancia de zona (ZRS). Aunque los datos se replican en centros de datos diferentes en esta configuración, todos se encuentran en la misma región. Las interrupciones regionales también afectan a la cuenta de almacenamiento en esta configuración.
En nuestro diseño, dependemos en gran medida de que la configuración de la red CDN almacene en caché el contenido estático. Es posible que, durante una interrupción, un usuario solicite un archivo estático que todavía no está en la caché de la red CDN. Esta solicitud tendría como resultado un gráfico o un vídeo que no se pueden mostrar.
Para eliminar esta posibilidad, podemos replicar la cuenta de almacenamiento en varias regiones al elegir una opción de almacenamiento con redundancia geográfica. También existe una opción de replicación de solo lectura para evitar agregar contenido estático durante una interrupción regional.
Para habilitar la redundancia geográfica, podemos elegir entre dos opciones: almacenamiento con redundancia geográfica con acceso de lectura (RA-GRS) y almacenamiento con redundancia de zona geográfica con acceso de lectura (RA-GZRS). La decisión que tomemos dependerá del presupuesto y del porcentaje de tiempo de actividad que necesitemos.
Azure App Service y aplicaciones de Azure Functions
Nuestro portal de seguimiento de envíos implementa dos servicios de Azure App Service. El primero hospeda una aplicación web que implementa la interfaz web orientada al usuario, mientras que el segundo hospeda una API web que usan las aplicaciones móviles para realizar el seguimiento de los datos de los envíos. Todas las tareas en segundo plano se ejecutan como aplicaciones de Azure Functions.
En nuestro diseño original, cada instancia de Azure App Service se localiza en una única región de Azure. Vamos a crear un segundo servicio de App Service en la región secundaria (Oeste de EE. UU.) e implementaremos allí el proyecto web para admitir la nueva arquitectura de varias regiones. Configuraremos el modo de enrutamiento por prioridad de Azure Front Door de modo que se envíen las solicitudes a nuestra región secundaria cuando la primaria no esté disponible.
Para garantizar que la conmutación por error sea lo más fluida posible, asegúrese de que la aplicación web no almacena en memoria información de estado de sesión. Cambiaremos nuestro sitio web para asegurarnos de que no se produzca una pérdida de datos. Por ejemplo, si el código almacena en memoria una lista de los envíos de los usuarios, esta lista se perdería si se produjera una conmutación por error.
Cada solicitud web se controla sin afectar a las demás cuando no se almacena el estado de sesión. Si se produce una conmutación por error en medio de la sesión de un usuario, dicha conmutación debe ser transparente para el usuario.
Haremos un cambio similar en las aplicaciones de Azure Functions. Crearemos otra instancia de Azure Functions en la región secundaria e implementaremos en ella el mismo código personalizado que se ejecuta en la región primaria.
Importante
Cuando implemente una actualización en el código personalizado en el servicio de aplicaciones de Functions o en App Service, no olvide distribuirlo a todas las instancias de App Service. Si quiere automatizar este proceso, Azure DevOps tiene herramientas que pueden ayudarle.
Colas de Azure Storage
En nuestra arquitectura original de una sola región, usamos una cola en una cuenta de Azure Storage para administrar las comunicaciones entre App Service y la aplicación de función. Cuando la aplicación web o la API web necesitan ejecutar una tarea en segundo plano, coloca un mensaje con toda la información necesaria en la cola. La aplicación de funciones supervisa si hay nuevos mensajes en la cola y ejecuta la tarea en segundo plano mediante la ejecución de las consultas necesarias en los almacenes de datos.
Podemos administrar una gran demanda de solicitudes web de manera ordenada cuando usamos una cola de este modo. Cuando hay muchas tareas en segundo plano para ejecutar, podrían acumularse en la cola, pero no se quitan. Permanecen en ella hasta que se procesan. Las aplicaciones de funciones funcionan a través de la cola y reducen su tamaño cuando la demanda disminuye. Si la demanda persiste, aumentaremos el número de instancias de la aplicación de funciones.
En el caso de la versión de varias regiones del portal de seguimiento de envíos, debemos asegurarnos de que los elementos de la cola no se pierdan cuando se produzca la conmutación por error. Nuestra cola está definida en Azure Storage y se puede usar una opción de redundancia para la replicación geográfica.
Tenga en cuenta que no se puede usar una opción de redundancia de acceso de lectura, ya que la cola admite operaciones de lectura y escritura. App Service debe agregar elementos a la cola y la aplicación de funciones debe quitar de esta los elementos completados. Use en su lugar el almacenamiento con redundancia geográfica (GRS) o el almacenamiento con redundancia de zona geográfica (GZRS).
Azure Redis Cache
Para maximizar el rendimiento del almacenamiento de datos, usamos Azure Redis Cache. Redis almacena en caché todos los resultados de consulta generados en las aplicaciones a medida que solicitan datos de la base de datos. Las siguientes consultas de datos similares no necesitan una consulta de base de datos y se recuperan de Redis Cache.
Para la arquitectura de varias regiones, crearemos una instancia de Redis Cache en las regiones primaria y en espera. Tenga en cuenta que, cuando se produce una conmutación por error, es probable que la instancia de Redis Cache en la región en espera esté vacía. Esa caché vacía no producirá ningún error, pero el rendimiento podría reducirse temporalmente mientras los datos rellenan la nueva caché.