Ejercicio: Expansión del diseño a varias regiones
Contoso Shoes necesita una manera de soportar las interrupciones regionales. Quieren implementar la marca actual en una topología activa-activa, de estado compartido y de varias regiones. La arquitectura debe diseñarse para redirigir el tráfico a una región en caso de que se produzca un error en otra.
Estado actual y problema
Una sola región ha sido suficiente para la aplicación. Sin embargo, hace poco se produjo una interrupción regional que afectó a las redes y que hizo que el sistema se desconectase a ojos de los usuarios finales. El escalado horizontal en la región o incluso la implementación de una nueva marca en esa región no habría servido para recuperar la aplicación del estado de error.
Un registrador existente mantiene el registro DNS para api.contososhoes.com. El registro DNS se resuelve en el punto de conexión de App Services de back-end (apicontososhoes.azurewebsites.net) con un período de vida de 2 días. Cuando la solución se implementa en varias regiones, el registro DNS se debe migrar.
Especificación
- Amplíe la arquitectura para que funcione en una topología activa-activa y de varias regiones.
- Modifique el modelo de marca de implementación que permite agregar y quitar regiones de forma dinámica según sea necesario, en vez de una lista de recursos codificados de forma rígida entre dos regiones.
- Si se produce un error regional, el tráfico debe enrutarse a la región que no tenga errores sin impacto reseñable alguno en los clientes que ya están en esa región sin errores.
- Los clientes no deben anclarse a una región.
- Los clientes no deben tener que cambiar las direcciones URL para establecer contacto con la API. El registro DNS debe migrarse al enrutador global.
Enfoque recomendado
Para empezar con el diseño, recomendamos hacer lo siguiente.
1: Topología de varias regiones
La arquitectura se debe distribuir entre dos o más regiones de Azure para protegerse de interrupciones regionales. Tenga en cuenta estos factores al elegir una región:
- La región debe ser capaz de soportar interrupciones del centro de datos en esa región.
- Los servicios y las funciones de Azure que se usan en la arquitectura deben admitirse en la región.
- La región y los recursos implementados en la región deben estar próximos a los usuarios finales y a los sistemas dependientes para minimizar la latencia de red.
Analicemos un escenario de error. Imaginemos que la Región 1 obtiene el 75 % del tráfico y que la Región 2 que hemos agregado obtiene el resto. Ambas escalan adecuadamente para controlar esa carga. Hay una interrupción regional en la Región 1 y ahora todo el tráfico se enruta a la Región 2. ¿Puede hacer que esa transición sea fluida? ¿Tiene cabida la Región 2 para ese aumento de la carga de tráfico?
Compruebe su progreso: Distribución global
2: Enrutamiento global
Agregue un equilibrador de carga global para enrutar a los clientes de forma transparente a cualquier región de trabajo. El equilibrador de carga debe usar las comprobaciones de estado que agregamos en el ejercicio anterior para determinar si una marca es correcta. ¿Se le ocurren formas de atender solicitudes frecuentes y similares que puedan tramitarse sin llegar al back-end?
- Elija un servicio de Azure nativo que se integre con la arquitectura existente y que sea capaz de conmutar por error rápidamente.
- Asegúrese de que la ruta de acceso de entrada de red tiene controles para denegar el tráfico no autorizado.
- Minimice la latencia de red atendiendo a los usuarios finales desde una memoria caché perimetral.
- Migre el registro DNS existente sin afectar a los clientes existentes.
- Disponga de una manera automatizada de indicar un error regional para asegurarse de que el tráfico no se enruta a la región con el error. Asimismo, reciba una notificación cuando la región vuelva a estar disponible para que el equilibrador de carga pueda reanudar el enrutamiento a esa región.
Compruebe su progreso: Enrutamiento del tráfico global
3: Cambios de la marca de implementación
El estado ideal es una configuración activa-activa que no requiera ninguna conmutación por error manual y que permita que las solicitudes de cliente puedan atenderse desde cualquier región. Piense en lo que esto supone para la arquitectura. Por ejemplo, ¿hay algún estado almacenado en la marca regional?
Algunos servicios de la arquitectura actual tienen funcionalidades de replicación geográfica. Considere la posibilidad de separar los servicios en marcas distintas. Una marca que contiene recursos globales. La otra marca regional que comparte recursos con la marca global. Uno de los factores decisivos debería ser el ciclo de vida de esos recursos. ¿Cuál es la duración esperada del recurso en relación con otros recursos de la arquitectura? ¿El recurso debe sobrevivir o compartir la duración con todo el sistema o la región, o debería ser temporal?
Explore las características de confiabilidad de los servicios de Azure empleados en la arquitectura. Puede empezar con estas características y seguir ahondando para aumentar la confiabilidad al máximo.
| Servicio de Azure | Característica |
|---|---|
| Azure Cosmos DB | Escritura multirregional |
| Azure Container Registry | Replicación geográfica |
| Plan de Azure App Service | Compatibilidad de zonas de disponibilidad |
Compruebe su progreso: Plataforma de la aplicación | Plataforma de datos
Comprobar el trabajo
Estas son las opciones de diseño de aplicación y datos de una arquitectura similar. ¿Cubre el diseño todos los aspectos?
- ¿Qué otra región de Azure ha seleccionado para incluirla en la topología de varias regiones, y por qué?
- ¿Ha habilitado dos o más zonas de disponibilidad de Azure en cada región de Azure para protegerse de posibles interrupciones del centro de datos?
- ¿Ha incluido Web Application Firewall para controlar el tráfico de entrada? ¿Qué reglas de enrutamiento ha puesto en marcha, y por qué?
- ¿Cómo admite el equilibrador de carga el registro DNS existente?
- ¿Cómo ha usado la API de comprobación de estado del ejercicio anterior?
- ¿Ha protegido la aplicación de ataques DDoS, especialmente para impedir que algún cliente malintencionado omita el equilibrador de carga y llegue a alguna instancia regional?
- ¿Cómo ha abordado la migración de DNS?
- ¿Ha realizado algún cambio de SKU en el componente existente para admitir la topología de varias regiones?
- ¿Qué servicios de Azure ha dejado como singletons? ¿Cómo ha justificado la elección de cada servicio? ¿Ha realizado algún cambio de configuración?
- ¿Registra los recursos? ¿Cree que esto afectará a su capacidad de inspeccionar los registros del sistema general?