En esta arquitectura de referencia se describe cómo ejecutar cargas de trabajo de Java Spring Boot en Azure Spring Apps. El diseño usa redundancia de zona para lograr una alta disponibilidad. Implemente este diseño para evitar que se produzca un error en una aplicación si hay una interrupción en todos los centros de datos de una zona.
Esta arquitectura le ayuda a:
- Aumenta la disponibilidad de la aplicación mediante una implementación en una sola zona.
- Aumentar la resistencia general y el objetivo de nivel de servicio (SLO) de la aplicación.
Esta solución presenta una estrategia de línea de base para la implementación de Azure Spring Apps. Para ver otras soluciones que se basan en esta arquitectura, consulte Implementación de Azure Spring Apps en varias regiones y Azure Spring Apps integrado con zonas de aterrizaje.
Sugerencia
Vea una implementación de ejemplo que ilustra algunas de las opciones de diseño de esta arquitectura. La implementación se puede considerar el primer paso hacia la producción.
Arquitectura
En este diagrama se muestra la arquitectura de este enfoque:
Descargue un archivo Visio de esta arquitectura.
Flujo de trabajo
Este flujo de trabajo corresponde al diagrama anterior:
El usuario accede a la aplicación mediante el nombre de host HTTP de la aplicación; por ejemplo,
www.contoso.com. Azure DNS se usa para resolver la solicitud de este nombre de host al punto de conexión público de Azure Application Gateway.Application Gateway se usa para inspeccionar la solicitud. También se use para reenviar el tráfico permitido a la dirección IP del equilibrador de carga en la instancia de Azure Spring Apps aprovisionada. Application Gateway se integra con Azure Web Application Firewall.
El equilibrador de carga interno se usa para enrutar el tráfico a los servicios de back-end.
Mientras se procesa la solicitud, la aplicación se comunica con otros servicios de Azure dentro de la red virtual. Por ejemplo, la aplicación puede recibir secretos de Azure Key Vault o el estado de almacenamiento de la base de datos.
Componentes
Estos servicios de Azure son los componentes de esta arquitectura:
La versión estándar de Azure Spring Apps se usa para hospedar una aplicación de Java Spring Boot de ejemplo que se implementa como microservicios.
La versión estándar v2 de Application Gateway se usa para administrar el tráfico a las aplicaciones. Actúa como un proxy inverso local en la región en que se ejecuta la aplicación.
Esta SKU tiene Web Application Firewall integrado para ayudar a proteger las aplicaciones web frente a vulnerabilidades. Web Application Firewall en Application Gateway supervisa las vulnerabilidades de seguridad de Open Web Application Security Project (OWASP).
Azure DNS se usa para resolver las solicitudes que se envían al nombre de host de la aplicación. Resuelve esas solicitudes en el punto de conexión público de Application Gateway. Las zonas privadas de Azure DNS se usan para resolver solicitudes a los puntos de conexión privados que acceden a los recursos de Azure Private Link con nombre.
Azure Database for MySQL se usa para almacenar el estado en una base de datos relacional de back-end.
Key Vault se usa para almacenar secretos y certificados de aplicación. Los microservicios que se ejecutan en Azure Spring Apps usan los secretos de aplicación. Azure Spring Apps y Application Gateway usan los certificados para la conservación del nombre de host.
Alternativas
Azure Database for MySQL no es la única opción para una base de datos. También puede usar:
Redundancia
Cree redundancia en la carga de trabajo para minimizar los puntos únicos de error. En esta arquitectura, se replican componentes entre zonas dentro de una región. En su arquitectura, asegúrese de usar zonas de disponibilidad para todos los componentes de la configuración.
Los servicios de Azure no se admiten en todas las regiones y no en todas las regiones se admiten las zonas. Antes de seleccionar una región, compruebe su compatibilidad regional y de zona.
Los servicios con redundancia de zona replican o distribuyen los recursos entre zonas automáticamente. Los servicios siempre disponibles siempre están disponibles en todas las zonas geográficas de Azure y son resistentes tanto a las interrupciones en toda la zona como a las interrupciones en toda la región.
En la tabla siguiente se muestran los tipos de resistencia de los servicios de esta arquitectura:
| Service | Resistencia |
|---|---|
| Azure DNS | Siempre está disponible |
| Application Gateway | Redundancia de zona |
| Azure Spring Apps | Redundancia de zona |
| Azure Database for MySQL | Redundancia de zona |
| Key Vault | Redundancia de zona |
| Azure Virtual Network | Redundancia de zona |
| Puntos de conexión privados de Azure | Redundancia de zona |
Azure Spring Apps admite la redundancia de zona. Con la redundancia de zona, toda la infraestructura subyacente del servicio se distribuye entre varias zonas de disponibilidad, lo que proporciona una mayor disponibilidad para la aplicación. Las aplicaciones se escalan horizontalmente sin cambios en el código. Una red de alto rendimiento conecta las zonas de disponibilidad de Azure. La conexión tiene una latencia de ida y vuelta de menos de 2 milisegundos (ms). No es necesario confiar en la replicación asincrónica para las cargas de trabajo de datos, lo que suele presentar desafíos de diseño.
Se configuran varias zonas de disponibilidad para Application Gateway, incluida la dirección IP pública que usa Application Gateway. Las direcciones IP públicas con una SKU estándar admiten las zonas de disponibilidad.
La arquitectura usa Azure Database for MySQL con la opción de implementación de servidor flexible para admitir la alta disponibilidad con conmutación automática por error. En función de los requisitos de latencia, elija alta disponibilidad con redundancia de zona o alta disponibilidad en la misma zona. Con una configuración de alta disponibilidad, la opción de servidor flexible aprovisiona y administra automáticamente una réplica en espera. Si se produce una interrupción, los datos confirmados no se pierden.
Key Vault tiene redundancia de zona automáticamente en cualquier región en la que estén disponibles las zonas de disponibilidad. La instancia de Key Vault que se usa en esta arquitectura se implementa para almacenar secretos para los servicios de back-end.
Escalabilidad
La escalabilidad indica la capacidad de la carga de trabajo para satisfacer eficazmente las demandas que los usuarios ponen en ella. Este enfoque de varias regiones es más adecuado para la escalabilidad que una implementación de una sola zona porque distribuye la carga entre zonas de disponibilidad.
Esta arquitectura tiene varios componentes que se pueden escalar automáticamente en función de métricas:
Application Gateway admite el escalado automático. Para más información, consulte Escalado de Application Gateway v2 y WAF v2.
Azure Spring Apps admite el escalado automático. Para más información, consulte Configuración de la escalabilidad automática para aplicaciones.
En función de la configuración de la base de datos, es posible que se produzca una latencia adicional cuando deba sincronizar datos entre zonas.
Seguridad de red
Proteja la aplicación contra el acceso no autorizado desde Internet, los sistemas de redes privadas, otros servicios de Azure y las dependencias acopladas estrechamente.
Virtual Network es la pieza básica de una red privada en Azure. Esta arquitectura usa una red virtual para la región de la implementación. Coloque componentes en subredes para crear un aislamiento adicional. Azure Spring Apps requiere una subred dedicada para el entorno de ejecución del servicio y una subred independiente para las aplicaciones de Spring Boot de Java.
Proteja las redes virtuales con Azure DDoS Protection. Combine la protección de denegación de servicio distribuido (DDoS) junto con los procedimientos recomendados de diseño de aplicaciones para proporcionar características mejoradas de mitigación para protegerse de los ataques DDoS.
El diseño de la arquitectura incorpora varias soluciones de plataforma como servicio (PaaS) que ayudan a procesar una solicitud de usuario. Coloque controles de red estrictos en esos servicios para garantizar que la aplicación no se vea afectada.
Conectividad privada
Use puntos de conexión privados o integración de red para proporcionar comunicación desde Azure Spring Apps a los servicios auxiliares, como Key Vault y Azure Database for MySQL.
Use puntos de conexión privados para controlar el acceso. Las interfaces de red usan direcciones IP privadas para transferir los servicios a la red virtual. Esta arquitectura usa servicios de Azure que configuran automáticamente los puntos de conexión privados.
Implemente Azure Spring Apps en la red a través del proceso de inyección de red virtual. Se accede a la aplicación mediante la dirección IP privada.
La base de datos sigue un modelo similar. El modo de implementación de servidor flexible de Azure Database for MySQL admite la integración de red virtual mediante una subred dedicada.
Otros servicios, como Key Vault, están conectados a la red virtual a través de Private Link. En Private Link, debe habilitar un punto de conexión privado para deshabilitar el acceso a la red pública. Para obtener más información, consulte Integración de Key Vault con Private Link.
Los puntos de conexión privados no requieren una subred dedicada, pero se recomienda colocarlos en una subred independiente. Las direcciones IP privadas a los puntos de conexión privados se asignan desde esa subred.
El punto de conexión privado y las conexiones integradas en la red usan una zona privada de Azure DNS.
Control el flujo de tráfico
Con esta arquitectura, las solicitudes entrantes solo se permiten a través del punto de conexión público expuesto por Application Gateway. Todavía se debe inspeccionar el tráfico para bloquear vulnerabilidades. Web Application Firewall en Application Gateway realiza un seguimiento de las vulnerabilidades de OWASP. El tráfico entrante se inspecciona en función de las reglas configuradas con una acción que se debe seguir.
La instancia de Azure Spring Apps tiene un equilibrador de carga interno que enruta y distribuye el tráfico a los servicios back-end. El equilibrador de carga está configurado para que solo acepte el tráfico de Application Gateway.
Es posible que la aplicación tenga que conectarse con otros puntos de conexión a través de la red pública de Internet. Para restringir ese flujo, considere colocar Azure Firewall en la ruta de acceso de salida.
Configuración de proxy inverso
La solución usa Application Gateway como un proxy inverso. Sin embargo, puede usar distintos proxys inversos delante de Azure Spring Apps. Puede combinar Application Gateway con Azure Front Door, o usar Azure Front Door en lugar de Application Gateway.
Para obtener información sobre los escenarios de proxy inverso, cómo configurarlos y sus consideraciones de seguridad, consulte Exposición de Azure Spring Apps mediante un proxy inverso.
Administración de identidades y acceso
Además de usar controles de red, refuerce la posición de seguridad mediante el uso de la identidad como perímetro.
La aplicación se debe autenticar cuando se conecta con los servicios de back-end, como si la aplicación recuperara secretos de Key Vault. En la aplicación, el enfoque recomendado es habilitar las Identidades administradas para recursos de Azure de Microsoft Entra. Este método de configuración asigna una identidad a la aplicación para que pueda obtener tokens de Microsoft Entra ID, lo que reduce la sobrecarga de administrar las credenciales.
Esta arquitectura usa identidades administradas asignadas por el sistema para varias interacciones.
Los servicios back-end deben permitir el acceso a la entidad de servicio asignada en la identidad administrada. El servicio debe definir directivas de acceso mínimo para determinadas acciones. En esta arquitectura, Key Vault se usa para conceder a la aplicación acceso a los secretos, certificados y claves.
Administración de secretos
Esta arquitectura almacena los secretos de aplicación y los certificados en un único almacén de claves. Los secretos de aplicación y los certificados para la conservación de nombres de host son diferentes, por lo que es posible que quiera almacenar los elementos en almacenes de claves separados. Este enfoque alternativo agrega otro almacén de claves a la arquitectura.
Supervisión
Azure Monitor es una solución de supervisión para recopilar, analizar y responder a los datos de supervisión de los entornos en la nube y locales.
Agregue instrumentación a la aplicación para emitir registros y métricas en el nivel de código. Considere habilitar el seguimiento distribuido para proporcionar observabilidad en los servicios dentro de la instancia de Azure Spring Apps. Use una herramienta de administración de rendimiento de aplicaciones (APM) para recopilar registros y datos de métricas. El agente de Java de Application Insights para Azure Monitor es una buena opción para la herramienta de APM.
Use diagnósticos de plataforma para obtener registros y métricas de todos los servicios de Azure, como Azure Database for MySQL. Integre todos los datos con los registros de Azure Monitor para proporcionar información completa sobre la aplicación y los servicios de plataforma.
El área de trabajo de Azure Log Analytics es el receptor de datos de supervisión que recopila registros y métricas de los recursos de Azure y Application Insights. Esta solución de registro proporciona visibilidad, lo que ayuda a los procesos de automatización a escalar los componentes en tiempo real. El análisis de datos de registro también puede revelar ineficacias en el código de aplicación que puede abordar para mejorar los costos y el rendimiento.
Para obtener instrucciones de supervisión específicas de Spring App, consulte Supervisión de aplicaciones de un extremo a otro y Supervisión con Dynatrace Java OneAgent.
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 la configuración de infraestructura sea idéntica, lo que ayuda a evitar el desfase en la configuración, posiblemente entre entornos. También puede usar la automatización de la infraestructura para probar las operaciones de conmutación por error.
Puede usar una estrategia de implementación azul-verde o controlada para sus aplicaciones.
Consideraciones
Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.
Las consideraciones siguientes proporcionan instrucciones para implementar los pilares del marco de buena arquitectura de Azure en el contexto de esta arquitectura.
Confiabilidad
La confiabilidad garantiza que tu aplicación puede cumplir los compromisos contraídos con los clientes. Para más información, consulte Resumen del pilar de fiabilidad.
Implemente las sugerencias siguientes para crear una aplicación más confiable:
Use una implementación azul-verde para facilitar la reversión a un estado correcto anterior si se producen problemas críticos.
Configure la escalabilidad automática para las aplicaciones para ayudar a la aplicación a mejorar el rendimiento cuando cambia la demanda.
Habilite el apagado correcto de la web de Spring Boot y configure la terminación correcta de Azure Spring Apps para detener forzadamente los procesos que se ejecutan en la instancia de la aplicación.
Seguridad
La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.
Implemente las siguientes sugerencias para crear una aplicación más segura:
Use soluciones de administración de identidad y acceso (IAM) maduras, como Microsoft Entra ID. Habilite la autenticación multifactor. Para más información, consulte:
Evite usar contraseñas siempre que sea posible. Para más información, consulte:
Para obtener recomendaciones sobre cómo proteger la aplicación de Azure Spring, consulte Línea de base de seguridad de Azure para Azure Spring Apps.
Optimización de costos
La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.
Para esta arquitectura, espere un costo mayor porque implementa componentes en varias zonas. En lugar de una instancia de Azure Spring Apps, ejecute dos o incluso tres instancias. Pero no hay ningún costo adicional por habilitar la redundancia de zona en el servicio. Para obtener más información, consulte Precios de Azure Spring Apps.
Tenga en cuenta estas opciones de implementación para abordar los costos:
Puede implementar diferentes aplicaciones y tipos de aplicación en una sola instancia de Azure Spring Apps. Cuando implementa varias aplicaciones, el costo de la infraestructura subyacente se comparte entre aplicaciones.
Azure Spring Apps admite el escalado automático de aplicaciones desencadenado por métricas o programaciones, lo que puede mejorar el uso y la rentabilidad.
También puede usar Application Insights en Azure Monitor para reducir los costos operativos. La supervisión continua puede ayudar a solucionar problemas más rápido y mejorar los costos y el rendimiento.
Elija el mejor plan de tarifa en función de sus requisitos:
Use la escalabilidad automática para que las aplicaciones se escalen y reduzcan verticalmente en función de la demanda.
Para obtener un costo estimado de los servicios para esta arquitectura, consulte la calculadora de precios de Azure. Esta estimación usa valores predeterminados razonables para una aplicación a pequeña escala. Puede actualizar la estimación en función de los valores de rendimiento esperados para la aplicación.
Excelencia operativa
La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para más información, consulte Introducción al pilar de excelencia operativa.
Además de las instrucciones de supervisión que se trataron anteriormente, implemente las siguientes sugerencias para ayudarle a implementar y supervisar la aplicación.
Automatice las implementaciones de aplicaciones mediante Azure DevOps o Acciones de GitHub.
Supervise las aplicaciones de Azure Spring Apps mediante registros, métricas y seguimiento.
Supervise las métricas en Azure Database for PostgreSQL mediante el servidor flexible.
Use Azure Managed Grafana para ver y analizar datos de telemetría de aplicaciones e infraestructuras en tiempo real.
Eficiencia del rendimiento
La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan ejercido sobre ella. Para más información, consulte Información general sobre el pilar de eficiencia del rendimiento.
Implemente las sugerencias siguientes para crear una aplicación más eficaz:
Escale las aplicaciones de forma manual o automática.
Implementación de este escenario
Para implementar esta arquitectura, siga las instrucciones paso a paso de Arquitectura de referencia de varias zonas de Azure Spring Apps. La implementación usa plantillas de Terraform.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
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
- Inicio rápido: Implementación de la primera aplicación web en Azure Spring Apps
- ¿Qué son las identidades administradas de recursos de Azure?
Recursos relacionados
- Azure Spring Apps integrado con zonas de aterrizaje
- Implementación de Azure Spring Apps en varias regiones
- Exposición de Azure Spring Apps mediante un proxy inverso
- Implementaciones azul/verde de alta disponibilidad para las aplicaciones
- Administración de identidades y acceso para Azure Spring Apps en zonas de aterrizaje