Implementación de Azure Spring Apps en varias regiones

Esta arquitectura de referencia describe un enfoque para ejecutar varias instancias de Azure Spring Apps en regiones con una configuración activa/activa.

Este diseño se basa en la arquitectura de línea de base de Azure Spring Apps. La línea de base implementa una aplicación de Java Spring Boot en varias zonas de disponibilidad dentro de una sola región. Las diferentes zonas distribuyen la carga de trabajo de la aplicación entre ubicaciones independientes para que la carga de trabajo pueda tolerar errores locales dentro de la región de Azure.

Pero si toda la región experimenta una interrupción, la línea de base deja de estar disponible para el usuario. La intención de este diseño es generar alta disponibilidad que soporte una interrupción regional.

La arquitectura es útil para cumplir estos objetivos:

• Aumentar la resistencia general y el objetivo de nivel de servicio (SLO) de la aplicación.
• Habilitar un alcance global para la aplicación.
• Acercar la carga de trabajo al usuario final y hacer que la latencia sea lo más baja posible.
• Usar una región secundaria como sitio de conmutación por error para la región primaria y elegir un diseño activo/pasivo.

Para aumentar la resistencia y la confiabilidad de la aplicación, puede implementarla en varias regiones. Para este diseño, necesita un enrutador global que equilibre la carga de las solicitudes en las aplicaciones entre regiones. El enrutador global en esta arquitectura también aborda otros objetivos.

El mayor desafío con una configuración en varias regiones es replicar los datos de la aplicación entre varias regiones. Esta incidencia no es un problema con la configuración de varias zonas. Estas zonas de disponibilidad de Azure se conectan mediante una red de alto rendimiento que cuenta con una latencia de ida y vuelta inferior a 2 milisegundos. Este periodo de latencia es suficiente para la mayoría de aplicaciones.

Architecture

En este diagrama se muestra la arquitectura de este enfoque:

Componentes

Los componentes de esta arquitectura son los mismos que los de la arquitectura de línea de base. En esta lista solo se resaltan los cambios realizados en la arquitectura de línea de base. Para obtener documentación del producto sobre los servicios de Azure, consulte la sección de Recursos relacionados.

• Azure Front Door actúa como equilibrador de carga global. Este servicio se usa debido a su capacidad para ofrecer una mayor disponibilidad con una menor latencia, mayor escala y almacenamiento en caché en el borde.

Flujo de trabajo

La arquitectura de referencia implementa este flujo de trabajo:

1. El usuario envía una solicitud al nombre de host HTTP de la aplicación, por ejemplo www.contoso.com. Azure DNS resuelve la solicitud de este nombre de host en Azure Front Door.

2. Azure Front Door usa varias configuraciones de equilibrio de carga para reenviar las solicitudes entrantes al punto de conexión público de Azure Application Gateway de cada región. Las instancias de Application Gateway se configuran con el mismo nombre de dominio personalizado y el mismo nombre de certificado TLS que Azure Front Door.

3. Application Gateway con Azure Web Application Firewall integrado inspecciona la solicitud. Web Application Firewall permite solicitudes entrantes solo desde el perfil de Azure Front Door especificado.

4. Application Gateway reenvía el tráfico permitido a la dirección IP del equilibrador de carga en la instancia de Spring Apps aprovisionada.

5. El equilibrador de carga interno solo enruta el tráfico de Application Gateway a los servicios back-end. Estos servicios se hospedan en la instancia de Spring Apps dentro de una red virtual de cada región.

6. Como parte del procesamiento de la solicitud, la aplicación se comunica con otros servicios de Azure dentro de la red virtual. Algunos ejemplos incluyen la aplicación que se comunica con Azure Key Vault para secretos y la base de datos para almacenar el estado.

Distribución global

Si está diseñando un sistema con alta disponibilidad, puede configurar esta arquitectura en un modo activo/activo, activo/pasivo con espera activa o activo/pasivo con espera pasiva.

La elección depende de los requisitos de disponibilidad de su aplicación. Esta arquitectura usa la implementación activa/activa en dos regiones porque la organización de muestra quiere una presencia global con un Acuerdo de Nivel de Servicio de tiempo de actividad alto. Si ejecuta aplicaciones críticas y quiere una mayor disponibilidad, debe usar más de dos regiones.

Activo-activo

En el modo activo/activo, todas las regiones procesan solicitudes simultáneamente. El mayor reto con el modo activo/activo es mantener la sincronización de datos entre regiones. Este modo es un enfoque costoso porque se paga dos veces por casi todos los componentes.

Activo/pasivo con espera activa.

En un modo activo/activo con espera activa, la región secundaria no recibe ninguna solicitud de Azure Front Door, siempre que la región primaria esté activa. Asegúrese de replicar correctamente los datos de la aplicación desde la región primaria a la secundaria. Si se produce un error en la región primaria, es necesario cambiar los roles de las bases de datos de back-end y conmutar por error todo el tráfico por Azure Front Door a la región secundaria.

En el modo activo/pasivo, se espera que la conmutación por error tarde un poco, lo que facilita la sincronización de todos los datos. Pero el modo activo/pasivo con espera activa es tan costoso como trabajar con el modo activo/activo.

Activo/pasivo con espera pasiva

En modo activo/pasivo con espera pasiva, la región primaria tiene todos los recursos y atiende el tráfico. La región secundaria puede tener menos componentes o componentes con menos recursos de proceso. Las opciones tecnológicas dependen del tiempo de inactividad aceptable según los requisitos empresariales. La extensión de la configuración de la región secundaria también afecta a los costos. Asegúrese de que al menos los datos de la aplicación estén presentes en la región secundaria.

Como se mencionó, el modo activo/pasivo incluye la conmutación por error que tarda un poco, por lo que es más fácil mantener sincronizados todos los datos. El modo activo/pasivo con espera pasiva es el enfoque más rentable porque no se implementan todos los recursos en ambas regiones.

Si toda la configuración de la solución usa plantillas, puede implementar fácilmente una región secundaria con espera pasiva al crear los recursos según sea necesario. Puede usar plantillas de Terraform, Bicep o Azure Resource Manager y automatizar la configuración de la infraestructura en una canalización de integración continua o implementación continua (CI/CD). Debe probar periódicamente la configuración mediante la recreación de la región secundaria para asegurarse de que las plantillas se pueden implementar en caso de emergencia.

Se recomienda el patrón de sellos de implementación porque se pueden implementar varias copias independientes de una aplicación o componente desde una sola plantilla a varias regiones.

Comparación de modo

En esta tabla se resume el esfuerzo necesario para sincronizar los datos de cada modo y se compara el costo.

Enrutamiento entre regiones

Esta arquitectura de referencia usa nodos geográficos en los que cualquier región puede atender cualquier solicitud.

Azure Front Door se configura con un enrutamiento igual entre las dos regiones de implementación. Azure Front Door también proporciona otros métodos de enrutamiento de tráfico al origen. Si quiere enrutar los clientes a su origen más cercano, el enrutamiento basado en latencia es la opción más lógica. Si diseña una solución activa o pasiva, el enrutamiento basado en prioridad es más adecuado.

El ejemplo de arquitectura de referencia usa una regla de equilibrio de carga equitativa entre las dos regiones. Azure Front Door está configurado con:

• Un dominio personalizado y un certificado de seguridad de la capa de transporte (TLS) con el mismo nombre que el nombre de host de la aplicación, como www.contoso.com.

• Un origen por región donde se implementa la aplicación, donde cada origen es una instancia de Azure Application Gateway.

Diseño del grupo de recursos

Use grupos de recursos de Azure para administrar los recursos implementados en cada región como una sola colección. Considere la posibilidad de colocar la región primaria, la región secundaria y Azure Front Door en grupos de recursos independientes, tal como se muestra en este diagrama:

En el diagrama se muestra esta configuración de grupos de recursos:

• Azure Front Door se implementa en el grupo de recursos Application-shared.
• Todos los recursos hospedados en la región Oeste de Europa (weu) se implementan en el grupo de recursos Application-weu.
• Los recursos hospedados en la región Este de EE. UU. (eus) se hospedan en el grupo de recursos Application-eus.
• Los recursos hospedados en la región Este de Japón (jae) se hospedan en el grupo de recursos Application-jae.

Los recursos en el mismo grupo de recursos comparten el mismo ciclo de vida y se pueden crear y eliminar fácilmente juntos. Cada región tiene su propio conjunto de recursos en un grupo de recursos dedicado que sigue una convención de nomenclatura basada en el nombre de la región. Azure Front Door se encuentra en su propio grupo de recursos ya que debe existir incluso si se agregan o quitan otras regiones.

Configuración de proxy inverso

Azure Front Door hace un equilibrio de carga global entre regiones. Este proxy inverso ayuda a distribuir el tráfico si implementa una carga de trabajo en varias regiones. Como alternativa, puede usar Azure Traffic Manager. Traffic Manager es un servicio de equilibrio de carga de tráfico basado en DNS que solo equilibra la carga en el dominio

Azure Front Door tiene redes de entrega de contenido integradas (CDN) que entregan contenido de la red perimetral global de Microsoft con puntos de presencia (POP) distribuidos en todo el mundo.

La solución actual usa dos servidores proxy inversos para mantener la coherencia con la arquitectura de línea de base. Azure Front Door es el enrutador global. Application Gateway actúa como equilibrador de carga por región. En la mayoría de casos, esta configuración no es necesaria. Puede quitar Application Gateway si cumple los requisitos siguientes:

• Como Azure Web Application Firewall está conectado a Application Gateway, debe conectar Azure Web Application Firewall al servicio Azure Front Door en su lugar.
• Necesita un modo de asegurarse de que las llamadas entrantes solo se originen en la instancia de Azure Front Door. Puede agregar la comprobación X-Azure-FDID header y la comprobación de intervalos IP de Azure Front Door en la aplicación Spring Cloud Gateway. Para más información, consulte Uso de Azure Front Door como proxy inverso con Spring Cloud Gateway.

Para obtener información sobre diferentes escenarios de proxy inverso, cómo configurarlos y sus consideraciones de seguridad, vea Exposición de Azure Spring Apps mediante un proxy inverso.

Base de datos de back-end

Para la implementación en varias regiones, debe tener una estrategia de replicación de datos. Cuando la aplicación está disponible entre regiones, los datos se deben sincronizar para que los usuarios no vean datos obsoletos.

La arquitectura actual usa una base de datos MySQL para la base de datos back-end, pero esta configuración no aborda la sincronización de datos. Al elegir una tecnología de base de datos, compruebe cómo replicar y sincronizar mejor los datos entre regiones. Una opción es Azure SQL Database, que tiene una característica de replicación geográfica activa que proporciona una base de datos secundaria sincronizada de forma continua y legible para una base de datos principal.

La característica se puede usar en estos escenarios:

• Si la región secundaria es una espera pasiva que no recibe solicitudes activas
• Para hacer una conmutación por error si se produce un error en la región primaria
• Para configurar bases de datos primarias y secundarias con conexiones de vínculo privado a sus respectivas regiones mediante emparejamiento de red virtual entre las dos regiones.

Otro enfoque consiste en usar Azure Cosmos DB. Este servicio puede distribuir datos de manera global mediante la replicación transparente de los datos en todas las regiones de la cuenta de Azure Cosmos DB. También puede configurar Azure Cosmos DB con varias regiones de escritura. Para más información, consulte Patrones de nodo geográfico.

Implementación automatizada

Automatice la implementación de la infraestructura y las implementaciones de código de aplicación tanto como sea posible.

La automatización de implementaciones de infraestructura garantiza que esta está configurada de manera idéntica, lo que ayuda a evitar el desfase en la configuración, por ejemplo entre regiones. La automatización de la infraestructura también puede probar las operaciones de conmutación por error.

Para la implementación de aplicaciones, asegúrese de que los sistemas de implementación tengan como destino las diferentes regiones en las que deban implementarse. También puede usar varias regiones en una estrategia de implementación azul-verde o controlada. Con estas estrategias de implementación, implementará versiones nuevas de aplicaciones en una región para hacer pruebas. Después, si el resultado es correcto, lo hará en otras regiones.

Rendimiento y escalabilidad

Esta arquitectura es más adecuada que una arquitectura de línea de base a la hora de satisfacer las demandas de la aplicación ya que distribuye la carga entre regiones. Si configura Azure Front Door para enrutar las solicitudes según la latencia, los usuarios obtienen tiempos de respuesta mejores, ya que las solicitudes se enrutan a las regiones más cercanas a ellas.

En función de la configuración de la base de datos, es posible que se produzca una latencia adicional cuando los datos deban sincronizarse entre regiones. Puede superar esta latencia usando Azure Cosmos DB con un nivel de coherencia más relajado.

Esta arquitectura de referencia tiene varios componentes que se pueden escalar automáticamente en función de métricas:

• Azure Front Door puede escalar automáticamente en función de la demanda. Puede usar otras características de Azure Front Door como la aceleración del tráfico y las capacidades de almacenamiento en caché para acercar los recursos a los usuarios finales.
• Application Gateway admite el escalado automático. Para más información, consulte Escalado de Application Gateway v2 y WAF v2.
• Azure Spring Apps también admite el escalado automático. Para más información, consulte Configuración de la escalabilidad automática para aplicaciones.

Consideraciones sobre el costo

Esta solución duplica de manera efectiva la estimación de costos de la arquitectura de línea de base.

Los principales impulsores de los costos asociados a la solución de varias regiones incluyen los siguientes:

• Las bases de datos principal y secundaria deben usar el mismo nivel de servicio; de lo contrario, es posible que la base de datos secundaria no se mantenga al día con los cambios de replicación.
• La intensidad del tráfico entre regiones aumenta los costos. El tráfico de red entre regiones de Azure incurre en cargos.

Para administrar estos costos, tenga en cuenta estas recomendaciones para la implementación:

• Use versiones reducidas de recursos como Azure Spring Apps y Application Gateway en la región en espera y escale verticalmente los recursos solo cuando el modo de espera se active.
• Si los escenarios empresariales lo permiten, cree una configuración activa/pasiva para ahorrar costos.
• Implemente una configuración de varias zonas en una sola región para satisfacer las necesidades empresariales de disponibilidad y resistencia. Esta opción puede ser más rentable porque solo paga por la mayoría de los recursos una vez.
• Elija la configuración alternativa, en la que solo se usa un proxy inverso para ayudar a ahorrar costos. No olvide que deberá aplicar una configuración adicional para que esta alternativa siga siendo segura.

Estimamos el costo de los servicios de esta arquitectura con la calculadora de precios de Azure mediante el uso de valores predeterminados razonables para una aplicación a pequeña escala. Puede actualizar esta estimación en función de los valores de rendimiento esperados para la aplicación.

Otras consideraciones

Las consideraciones de diseño para la arquitectura de línea de base de varias zonas también se aplican a la solución de varias regiones que se describe en este artículo. Revise estos puntos en el contexto de la arquitectura de varias regiones:

• Seguridad de red. Es importante controlar la comunicación en la red. Esta solución solo permite llamadas entrantes desde Azure Front Door, donde las llamadas se enrutan a Application Gateway en cada región. Desde Application Gateway, las llamadas se enrutan al servicio back-end de Azure Spring Apps. La comunicación de Azure Spring Apps con servicios auxiliares, como Key Vault, también se controla mediante puntos de conexión privados. Para más información, consulte Arquitectura de línea de base: Seguridad de red.

• Administración de identidades y acceso. Implemente un acceso más seguro mediante identidades administradas para conectarse entre distintos componentes. Un ejemplo es el uso de Azure Spring Apps de una identidad administrada para conectarse a Key Vault. Para más información, consulte Arquitectura de línea de base: administración de identidades y acceso.

• Supervisión. Puede agregar instrumentación y habilitar el seguimiento distribuido para recopilar datos de la aplicación. Combine ese origen de datos con diagnósticos de plataforma para obtener una visión completa de la aplicación. Para más información, consulte Arquitectura de línea de base: Supervisión.

• Administración de secretos. Esta solución en varias regiones almacena los secretos de aplicación y los certificados en un único almacén de claves. Para más información, consulte Arquitectura de línea de base: Administración de secretos.

Implementación de escenarios

Hay disponible una implementación para esta arquitectura de referencia en Arquitectura de referencia de varias regiones de Azure Spring Apps en GitHub. La implementación usa plantillas de Terraform.

Para implementar la arquitectura, siga las instrucciones paso a paso.

Colaboradores

Microsoft se encarga del mantenimiento de este contenido. El colaborador siguiente desarrolló el contenido original.

Autor principal:

• Gitte Vermeiren | Ingeniero de FastTrack for Azure

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

Para integrar esta carga de trabajo con servicios compartidos administrados por equipos centrales de su organización, impleméntela en una zona de aterrizaje de la aplicación de Azure.

Recursos relacionados

Para obtener documentación sobre los servicios y características de Azure usados en esta arquitectura, consulte estos artículos:

• Azure Spring Apps
• Azure Front Door
• Azure Application Gateway v2
• Azure Database for MySQL
• Azure Key Vault
• DNS de Azure
• Firewall de aplicaciones web de Azure
• Azure Private Link
• Identidades administradas para recursos de Azure de Microsoft Entra

Se recomiendan estas guías para comprender mejor las opciones de configuración implicadas en esta arquitectura:

• Exposición de Azure Spring Apps mediante un proxy inverso
• Implementación azul/verde de alta disponibilidad para aplicaciones
• Conservar el nombre de host HTTP original entre un proxy inverso y su aplicación web back-end

Esta arquitectura está diseñada de forma alineada con los pilares del Marco de buena arquitectura de Microsoft Azure. Se recomienda revisar los principios de diseño de cada pilar.