Azure Spring Apps integrado con zonas de aterrizaje

Esta arquitectura de referencia implementa la arquitectura de línea de base de Azure Spring Apps en las zonas de aterrizaje de Azure.

En este escenario, la organización espera que la carga de trabajo use recursos federados administrados por equipos centrales (plataforma). Los ejemplos de gestión centralizada incluyen redes para la conectividad local, administración de acceso a identidades y directivas. En esta guía se asume que la organización ha adoptado zonas de aterrizaje de Azure para aplicar una gobernanza coherente y ahorrar costos en varias cargas de trabajo.

Las opciones de diseño tomadas en esta arquitectura se tratan en las áreas clave de diseño técnico para este acelerador. Para más información, consulte Acelerador de zona de aterrizaje de Azure Spring Apps.

Architecture

En este diagrama se muestra la arquitectura de este enfoque:

Los usos habituales de esta arquitectura incluyen:

• Aplicaciones privadas: aplicaciones internas implementadas en entornos de nube híbrida.
• Aplicaciones públicas: aplicaciones orientadas al exterior.

Estos casos de uso son similares, excepto en lo que refiere a la configuración de seguridad y las reglas de tráfico de red.

Componentes

En las secciones siguientes se describen los componentes de esta arquitectura. Los componentes se dividen según las responsabilidades de propiedad para ayudarle a identificar qué compartir con los equipos de plataforma de la organización. Para obtener documentación del producto sobre los servicios de Azure, consulte la sección de Recursos relacionados.

Recursos que son propiedad del equipo de la aplicación

El equipo es responsable de crear y mantener estos recursos.

• Azure Spring Apps Estándar hospeda las aplicaciones de Java Spring Boot en Azure.

• Azure Application Gateway Estándar v2 es el proxy inverso que enruta el tráfico web entrante a Azure Spring Apps. Este SKU ha integrado Azure Web Application Firewall que inspecciona el tráfico en busca de vulnerabilidades de Open Web Application Security Project (OWASP).

• Azure Virtual Machines actúa como un jumpbox para las operaciones de administración.

• Azure Database for MySQL almacena los datos de la aplicación.

• Azure Key Vault almacena los secretos y la configuración, como una cadena de conexión a la base de datos.

• Log Analytics es una característica de Azure Monitor que también se conoce como Azure Monitor Logs. Log Analytics es el receptor de supervisión que almacena los registros y las métricas de la aplicación y los servicios de Azure.

• Azure Application Insights se usa como herramienta de administración de rendimiento de aplicaciones (APM) para recopilar todos los datos de supervisión de aplicaciones y almacenarlos directamente en Log Analytics.

Recursos que son propiedad del equipo de la plataforma

En esta arquitectura se supone que ya existen estos recursos. Los equipos centrales de la organización poseen y mantienen estos recursos. La aplicación depende de estos servicios para reducir la sobrecarga operativa y optimizar el costo.

• Azure Firewall inspecciona y restringe el tráfico de salida.

• Azure Bastion proporciona acceso seguro al jumpbox de administración.

• Azure ExpressRoute proporciona la conectividad privada desde el entorno local a la infraestructura de Azure.

• Azure DNS proporciona la resolución de nombres entre locales.

• Azure VPN Gateway conecta la aplicación con equipos remotos en la red local.

Aspectos que tener en cuenta sobre la aplicación

En la implementación de referencia se incluye una aplicación de ejemplo que ilustra una aplicación de microservicios típica hospedada en una instancia de Azure Spring Apps. En las secciones siguientes se proporcionan detalles sobre la aplicación hospedada. Para más información, consulte Ejemplo de almacén de PetClinic.

Detección de servicios

En un patrón de microservicios, se debe admitir la funcionalidad del registro de servicios para enrutar las solicitudes de usuario y la comunicación entre servicios.

Los servicios deben poder comunicarse con otros servicios. Cuando se generan nuevas instancias, se agregan al registro para que se puedan detectar dinámicamente. En esta arquitectura, el registro de servicios administrado de Spring Cloud (OSS) está habilitado para Azure Spring Apps. El servicio mantiene un registro de las instancias de aplicaciones activas, permite el equilibrio de carga del lado cliente y desacopla los proveedores de servicios de los clientes sin depender de un Servicio de nombres de dominio (DNS).

La instancia de Azure Spring Apps implementa el patrón de enrutamiento de puerta de enlace, que proporciona un único punto de entrada para el tráfico externo. La puerta de enlace enruta las solicitudes entrantes a las instancias de servicio activas que se encuentran en el registro. En este diseño, el patrón se implementa con una implementación de código abierto de Spring Cloud Gateway. Ofrece un conjunto de características que incluye autenticación y autorización, características de resistencia y limitación de frecuencia.

Servidor de configuración

En el caso de los microservicios, los datos de configuración se deben separar del código. En esta arquitectura, Config Server en Azure Spring Apps permite la administración de recursos mediante un repositorio conectable que admite el almacenamiento local y los repositorios de Git.

Redundancia

Puede usar zonas de disponibilidad al crear una instancia de Azure Spring Apps.

Con esta característica, Azure Spring Apps distribuye automáticamente los recursos fundamentales en secciones lógicas de la infraestructura subyacente de Azure. Esta distribución proporciona un mayor nivel de disponibilidad para protegerse contra errores de hardware o eventos de mantenimiento planificados.

La redundancia de zona garantiza que los nodos de máquina virtual (VM) subyacentes se distribuyan uniformemente entre todas las zonas de disponibilidad. Pero la redundancia de zona no garantiza la distribución uniforme de las instancias de aplicación. Si se produce un error en una instancia de aplicación porque su zona deja de funcionar, Azure Spring Apps crea una nueva instancia para esta aplicación en un nodo de otras zonas de disponibilidad.

Si habilita su propio recurso en Azure Spring Apps, como un sistema de almacenamiento persistente, habilite la redundancia de zona para el recurso. Para más información, consulte Cómo habilitar su propio almacenamiento persistente en Azure Spring Apps.

Las zonas de disponibilidad no se admiten en todas las regiones. Para ver qué regiones admiten zonas de disponibilidad, consulte Regiones de Azure con compatibilidad con zonas de disponibilidad.

Escalabilidad

Azure Spring Apps proporciona funcionalidades de escalado automático de forma predeterminada, lo que habilita a las aplicaciones escalar según los umbrales de las métricas o durante un período de tiempo específico. El escalado automático se recomienda cuando las aplicaciones deben escalar vertical u horizontalmente en respuesta al cambio de la demanda.

Azure Spring Apps también admite el escalado manual de las aplicaciones mediante el ajuste de la CPU, la memoria o los GB por instancia, y los recuentos de instancias de las aplicaciones. Este tipo de escalado es adecuado para una actividad de escalado de una sola vez que quizá quiera para aplicaciones determinadas. Ajuste los valores para satisfacer las necesidades de escalado de la aplicación y asegúrese de que la configuración se encuentre dentro de los límites máximos de cada atributo.

Consideraciones sobre redes

En este diseño, la carga de trabajo depende de los recursos que pertenecen al equipo de la plataforma para acceder a los recursos locales, controlar el tráfico de salida, etc. Para más información, consulte Topología de red y conectividad para el acelerador de zona de aterrizaje de Azure Spring Apps.

Topología de red

El equipo de la plataforma determina la topología de red. En esta arquitectura se asume una topología en estrella tipo hub-and-spoke.

Red virtual de concentrador

La suscripción de conectividad contiene una red virtual de centro que toda la organización comparte. La red contiene recursos de red propiedad del equipo de la plataforma y que este mantiene. Estos recursos del equipo de plataforma están en el ámbito de esta arquitectura:

• Azure Firewall controla el tráfico de salida a Internet.
• Azure Bastion asegura el acceso al jumpbox de administración.

Red virtual de radios

La zona de aterrizaje de la aplicación tiene al menos una red virtual aprovisionada previamente que está emparejada con la red del centro de conectividad. Usted posee los recursos de esta red, como el equilibrador de carga que enruta y protege las conexiones HTTP/s entrantes a Azure Spring Apps desde Internet.

La red virtual y los emparejamientos aprovisionados previamente deben ser capaces de admitir el crecimiento esperado de la carga de trabajo. Calcule el tamaño de la red virtual y evalúe los requisitos con el equipo de la plataforma de forma periódica. Para información, consulte Requisitos de red virtual.

Inserción y subred de red virtual

Azure Spring Apps se implementa en la red mediante el proceso de inyección de red virtual. Este proceso aísla la aplicación de Internet, sistemas en redes privadas, otros servicios de Azure e incluso el runtime del servicio. El tráfico entrante y saliente de la aplicación se permite o deniega en función de las reglas de la red.

El aislamiento se consigue mediante instancias subredes. Es responsable de asignar subredes en la red virtual de tipo hub-and-spoke. Azure Spring Apps requiere dos subredes dedicadas para el runtime del servicio y para las aplicaciones Spring Boot de Java.

Las subredes deben estar dedicadas a una sola instancia de Azure Spring Apps. Varias instancias no pueden compartir las mismas subredes.

El tamaño mínimo de cada subred es /28. El tamaño real depende del número de instancias de aplicación que pueda admitir Azure Spring Apps. Para más información, consulte Uso de intervalos de subred más pequeños.

Controles de red

Azure Application Gateway con Web Application Firewall restringe el tráfico entrante a la red virtual de tipo hub-and-spoke desde Internet. Las reglas de Web Application Firewall permiten o deniegan conexiones HTTP/s.

El tráfico de la red se controla mediante grupos de seguridad de red (NSG) en las subredes. Los grupos de seguridad de red filtran el tráfico según las direcciones IP y los puertos configurados. En este diseño, los grupos de seguridad de red se colocan en todas las subredes. La subred de Azure Bastion permite el tráfico HTTPS desde Internet, los servicios de puerta de enlace, los equilibradores de carga y la red virtual. Solo se permite la comunicación RDP y SSH a las redes virtuales desde la subred.

Los vínculos privados se usan para controlar la conectividad entre Azure Spring Apps y otros servicios de Azure, como el acceso al almacén de claves y a la base de datos. Los puntos de conexión privados se colocan en una subred independiente.

Los registros del DNS del host de la aplicación deben almacenarse en Azure DNS privado para garantizar la disponibilidad continua durante un error geográfico.

Aunque la suscripción de conectividad tiene zonas DNS privadas, cree sus propias zonas de Azure DNS privadas para admitir los servicios a los que acceden los puntos de conexión privados.

El tráfico saliente de la red virtual debe estar restringido para evitar ataques de filtración de datos. Este tráfico se enruta mediante la instancia centralizada de Azure Firewall (próximo salto) que permite o deniega el flujo mediante un nombre de dominio completo (FQDN).

Administración de identidades y acceso

La implementación de identidad de la carga de trabajo debe alinearse con los procedimientos recomendados de la organización para asegurar que la aplicación no infrinja los límites de seguridad o gobernanza de la organización. Para más información, consulte Administración de identidades y accesos para el acelerador de zona de aterrizaje de Azure Spring Apps.

Se recomienda Microsoft Entra ID para autenticar los usuarios y los servicios que interactúan con la instancia de Azure Spring Apps.

El enfoque recomendado es habilitar las identidades administradas de Microsoft Entra para los recursos de Azure para que la aplicación permita que la aplicación se autentique automáticamente en otros servicios. En esta arquitectura, las identidades administradas asignadas por el sistema se usan para facilitar la administración.

En el caso de la autorización, use el control de acceso basado en roles (RBAC) de Azure. Para ello, aplique el principio de privilegios mínimos al conceder permisos.

Consideraciones sobre supervisión

La plataforma de zona de aterrizaje de Azure proporciona recursos de observabilidad compartidos como parte de las suscripciones de administración. Sin embargo, se recomienda aprovisionar sus propios recursos de supervisión para simplificar la administración general de la carga de trabajo. Para más información, consulte Supervisar operaciones para el acelerador de zonas de aterrizaje de Azure Spring Apps.

La arquitectura crea estos recursos:

• Azure Application Insights es la solución de APM y se encuentra totalmente integrado en el servicio mediante un agente de Java. Este agente proporciona visibilidad en todas las aplicaciones y dependencias implementadas sin necesidad de código adicional.
• El área de trabajo de Azure Log Analytics es el receptor unificado para todos los registros y las métricas recopilados de los servicios de Azure y la aplicación.

Configure la instancia de Azure Spring Apps para enviar los registros de diagnóstico desde la aplicación al área de trabajo aprovisionada de Log Analytics. Para más información, consulte Supervisión de aplicaciones de un extremo a otro.

Recopile los registros y las métricas de los servicios de Azure. Los diagnósticos de arranque están habilitados para el jumpbox, por lo que puede capturar eventos como arranque de la máquina virtual.

Configure los valores de los diagnóstico para enviar los registros de recursos para todos los demás recursos de Azure a un área de trabajo de Log Analytics. Los registros de recursos no se recopilan hasta que se enrutan a un destino. Cada recurso de Azure requiere su propia configuración de diagnóstico.

Correlación de datos de varias áreas de trabajo

Los registros y las métricas generados por la carga de trabajo y sus componentes de infraestructura se guardan en el área de trabajo de Log Analytics de la carga de trabajo. Pero los registros y las métricas generados por los servicios centralizados como Active Directory y Azure Firewall se guardan en un área de trabajo central de Log Analytics administrada por los equipos de la plataforma. La correlación de datos de receptores distintos puede dar lugar a complejidades.

Considere un escenario de un flujo de usuario en el que la carga de trabajo tiene dependencias en los servicios centralizados. Parte de los datos se podrían recopilar por carga de trabajo y exportarse al área de trabajo central de Log Analytics donde se correlaciona con los registros de la plataforma.

Pero es posible que solo haya otras entradas en el área de trabajo de la carga de trabajo debido a problemas como el volumen de datos, la interoperabilidad de formato o las restricciones de seguridad. Las entradas de registro no correlacionadas que existen en dos o más áreas de trabajo para un único flujo de usuario pueden dificultar la solución de algunos problemas. Estas complejidades agregadas requieren que los equipos trabajen juntos para solucionar problemas de incidentes de aplicaciones.

Para ayudar con este tipo de colaboración, familiarícese con los procedimientos configurados por su organización. Cuando se produce un incidente de seguridad, es posible que se pida a los administradores de cargas de trabajo que revisen los registros de sus sistemas en busca de signos de actividad malintencionada o proporcionen copias de sus registros a los encargados de incidentes para su posterior análisis. Cuando los administradores de cargas de trabajo solucionan problemas de aplicaciones, es posible que necesiten ayuda de los administradores de la plataforma para correlacionar las entradas de los registros de redes empresariales, seguridad u otros servicios de plataforma.

Sondeos de estado

Azure Application Gateway usa los sondeos de estado para asegurar que el tráfico entrante se enruta a las instancias de back-end con capacidad de respuesta. Se recomiendan los sondeos de preparación, ejecución e inicio de Azure Spring Apps. Si se produce un error, estos sondeos pueden ayudar en la finalización correcta. Para más información, consulte Configuración de sondeos de estado.

Consideraciones de seguridad

Los equipos centralizados proporcionan controles de red e identidad como parte de la plataforma. Sin embargo, la carga de trabajo debe tener prestaciones de seguridad para reducir la superficie expuesta a ataques. Para más información, consulte Consideraciones de seguridad para el acelerador de zona de aterrizaje de Azure Spring Apps.

Datos en reposo

Los datos en reposo deben estar cifrados. La propia aplicación no tiene estado. Los datos se conservan en una base de datos externa, donde la arquitectura usa Azure Database for MySQL. Este servicio cifra los datos, incluidas las copias de seguridad y los archivos temporales creados durante la ejecución de consultas.

Datos en tránsito

Los datos en tránsito deben estar cifrados. El tráfico entre el explorador del usuario y Azure Application Gateway debe cifrarse para asegurar que los datos no han cambiando durante el tránsito. En esta arquitectura, Azure Application Gateway solo acepta el tráfico HTTPS y negocia el protocolo de enlace TLS. Esta comprobación se aplica mediante reglas del grupo de seguridad de red en la subred de Application Gateway. El certificado TLS se carga directamente durante la implementación.

El tráfico de Application Gateway a la instancia de Azure Spring Apps se vuelve a cifrar para asegurar que solo el tráfico seguro llega a la aplicación. El runtime de servicio de Azure Spring Apps recibe ese tráfico y actúa como el punto de terminación TLS. A partir de aquí, la comunicación entre servicios en la aplicación no está cifrada. Pero la comunicación con otros servicios de plataforma como servicio de Azure y el runtime de servicio ocurre mediante TLS.

Puede optar por implementar la comunicación TLS de un extremo a otro mediante Azure Spring Apps. Tenga en cuenta los inconvenientes. Puede haber un efecto negativo en la latencia y las operaciones.

Los datos en tránsito deben inspeccionarse para detectar vulnerabilidades. Web Application Firewall se integra con Application Gateway e inspecciona con más detenimiento las vulnerabilidades de OWASP que bloquean el tráfico. Puede configurar Web Application Firewall para detectar, supervisar y registrar las alertas de amenazas. O puede configurar el servicio para bloquear las intrusiones y los ataques detectados por las reglas.

Protección contra DDOS

La denegación de servicio distribuido (DDoS) puede desactivar un sistema al sobrecargalo con solicitudes. La protección contra DDoS básica está habilitado al nivel de infraestructura para que todos los servicios de Azure se defiendan contra estos ataques. Considere la posibilidad de actualizar al servicio Azure DDoS Protection para aprovechar las características como la supervisión, las alertas y la capacidad de establecer umbrales para la aplicación. Para más información, consulte Preguntas más frecuentes sobre el servicio Azure DDoS Protection.

Administración de secretos

El enfoque de seguridad de Confianza cero de Microsoft requiere que los secretos, los certificados y las credenciales se conserven en un almacén seguro. El servicio recomendado es Azure Key Vault.

Hay maneras alternativas de almacenar los secretos en función del servicio y de la intención de Azure. La arquitectura implementa este enfoque:

• Los certificados se cargan durante la implementación.
• La conexión a MySQL se implementa mediante un conector de servicio.

Estrategias de optimización de costos

Debido a la naturaleza del diseño como sistema distribuido, la expansión de la infraestructura es una realidad. Esta realidad genera costos inesperados e incontrolables. Azure Spring Apps se ha creado con componentes que se escalan para ayudar a satisfacer la demanda y optimizar el costo. La base de esta arquitectura es Azure Kubernetes Service (AKS). El servicio está diseñado para reducir la complejidad y la sobrecarga operativa de la administración de Kubernetes e incluye las eficiencias en el costo operativo del clúster.

Puede implementar diferentes aplicaciones y tipos de aplicación en una sola instancia de Azure Spring Apps. El servicio admite el escalado automático de aplicaciones desencadenado por métricas o programaciones que pueden mejorar el uso y la rentabilidad.

También puede usar Application Insights y Azure Monitor para reducir los costos operativos. Con la visibilidad proporcionada por la solución de registro completa, puede implementar la automatización para escalar los componentes del sistema en tiempo real. También puede analizar los datos de registro para revelar ineficiencias en el código de la aplicación, que se pueden abordar para mejorar el costo y el rendimiento generales del sistema.

Implementación de escenarios

Hay disponible una implementación para esta arquitectura de referencia en Acelerador de zonas de aterrizaje de Azure Spring Apps en GitHub. La implementación usa plantillas de Terraform.

Los artefactos de este repositorio ofrecen una base que se puede personalizar para su entorno. La implementación crea una red de centro de conectividad con recursos compartidos como Azure Firewall con fines ilustrativos. Esta agrupación se puede asignar a suscripciones independientes de zonas de aterrizaje para mantener separadas las funciones de la carga de trabajo y la plataforma.

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

Soporte técnico de VMware con el nivel Enterprise

Si quiere que se administre la compatibilidad de VMware Tanzu® con las implementaciones activas, considere actualizar al nivel Enterprise de Azure Spring Apps. VMware Tanzu® Service Registry está integrado para Azure Spring Apps, lo que permite la detección y el registro de servicios.

Para el enrutamiento de puerta de enlace, puede cambiar a Spring Cloud Gateway para VMware. Ofrece un conjunto de características que incluye autenticación y autorización, características de resistencia y limitación de frecuencia.

En el nivel de servicio Enterprise, Application Configuration Service for Tanzu® permite la administración de recursos de ConfigMap nativos de Kubernetes que se rellenan a partir de las propiedades definidas en uno o varios repositorios de Git.

Hay otros servicios de VMware admitidos en este nivel. Para más información, consulte Nivel Enterprise en Azure Marketplace.

La implementación de referencia admite el SKU empresarial de Azure Spring Apps como opción de implementación. En esta opción, hay algunos cambios de arquitectura. Usa una instancia del servidor flexible de Azure Database for PostgreSQL implementado con integración con Microsoft Azure Virtual Network y Azure Cache for Redis con punto de conexión privado. La aplicación de ejemplo es la aplicación Fitness Store.

Pasos siguientes

• Revise las áreas de diseño del acelerador de zonas de aterrizaje de Azure Spring Apps.

Recursos relacionados

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

• Enterprise de Azure Spring Apps
• Azure Application Gateway v2
• Azure Database for MySQL
• Azure Key Vault
• Azure Virtual Network
• Tablas de ruta

Para otros escenarios de implementación, consulte estos artículos:

• Implementación de Azure Spring Apps en varias regiones
• Exposición de Azure Spring Apps mediante un proxy inverso