Patrón Reliable Web App para Java

En este artículo se proporcionan instrucciones para implementar el patrón Reliable Web App. Este patrón describe cómo modificar (plataforma) las aplicaciones web para la migración a la nube. Proporciona instrucciones de configuración, código y arquitectura prescriptivas que se alinean con los principios de Azure Well-Architected Framework.

¿Por qué el patrón Reliable Web App para Java?

El patrón Reliable Web App es un conjunto de principios y técnicas de implementación que definen cómo debe replatar las aplicaciones web al migrarlas a la nube. Se centra en las actualizaciones de código mínimas que debe realizar para que se realicen correctamente en la nube. En las instrucciones siguientes se usa una implementación de referencia como ejemplo. Sigue el recorrido de la plataforma de la empresa ficticia Contoso Fiber para proporcionar contexto empresarial para su recorrido. Antes de implementar el patrón Reliable Web App para Java, Contoso Fiber tenía un sistema de administración de cuentas de cliente (CAMS) local monolítico que usaba el marco de Spring Boot.

Cómo implementar el patrón Reliable Web App

En este artículo se incluyen instrucciones de arquitectura, código y configuración para implementar el patrón Reliable Web App. Use los vínculos siguientes para ir a las instrucciones específicas que necesita:

• contexto empresarial. Alinear esta guía con su contexto empresarial y aprender a definir objetivos inmediatos y a largo plazo que impulsan decisiones de replatación.
• guía de arquitectura de . Aprenda a seleccionar los servicios en la nube adecuados y diseñar una arquitectura que cumpla sus requisitos empresariales.
• guía de código. Implementar tres patrones de diseño para mejorar la confiabilidad y la eficacia del rendimiento de la aplicación web en la nube: los patrones Retry, Circuit Breaker y Cache-Aside.
• guía de configuración de . Configure la autenticación y autorización, las identidades administradas, los entornos con derechos, la infraestructura como código y la supervisión.

Contexto empresarial

El primer paso para replanificar una aplicación web es definir sus objetivos empresariales. Debe establecer objetivos inmediatos, como objetivos de nivel de servicio (SLO) y objetivos de optimización de costos, así como objetivos futuros para la aplicación web. Estos objetivos influyen en la elección de servicios en la nube y en la arquitectura de la aplicación web en la nube. Defina un SLO de destino para la aplicación web (por ejemplo, 99.9% tiempo de actividad). Calcule el SLA compuesto para todos los servicios que afectan a la disponibilidad de su aplicación web.

Por ejemplo, Contoso Fiber quería expandir su aplicación web CAMS local para llegar a otras regiones. Para hacer frente al aumento de la demanda de la aplicación web, establecieron los siguientes objetivos:

• Aplique cambios de código de bajo costo y de alto valor.
• Alcance un SLO de 99,9%.
• Adoptar prácticas de DevOps.
• Cree entornos optimizados para costos.
• Mejorar la confiabilidad y la seguridad.

Contoso Fiber determinó que su infraestructura local no era una solución rentable para escalar la aplicación. Decidieron que migrar su aplicación web CAMS a Azure era la manera más rentable de lograr sus objetivos inmediatos y futuros.

Guía de arquitectura

El Reliable Web App fiable tiene algunos elementos arquitectónicos esenciales. Necesita DNS para administrar la resolución de puntos de conexión, un firewall de aplicaciones web para bloquear el tráfico HTTP malintencionado y un equilibrador de carga para enrutar y ayudar a proteger las solicitudes de usuario entrantes. La plataforma de aplicaciones hospeda el código de la aplicación web y realiza llamadas a todos los servicios back-end a través de puntos de conexión privados en una red virtual. Una herramienta de supervisión del rendimiento de la aplicación captura métricas y registros para ayudarle a comprender la aplicación web.

Figura 1. Elementos arquitectónicos esenciales del patrón Reliable Web App.

Diseño de la arquitectura

Diseñe la infraestructura para admitir las métricas de recuperación , como el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO). El RTO afecta a la disponibilidad y debe ser compatible con su SLO. Determine un RPO y configure redundancia de datos para satisfacer el RPO.

• Elija la fiabilidad de la infraestructura. Determine cuántas zonas de disponibilidad y regiones necesita para cumplir los requisitos de disponibilidad. Añada zonas y regiones de disponibilidad hasta que el SLA compuesto cumpla su SLO. El patrón Reliable Web App admite varias regiones para una configuración activo-activo o activo-pasivo. Por ejemplo, la implementación de referencia utiliza una configuración activa-pasiva para cumplir un SLO del 99,9 %.

  En el caso de una aplicación web de varias regiones, configure el equilibrador de carga para enrutar el tráfico a la segunda región para admitir una configuración activa-activa o activa-pasiva, en función de la necesidad empresarial. Las dos regiones requieren los mismos servicios, salvo que una región tiene una red virtual de concentrador que conecta las regiones. Adopte una topología de red radial para centralizar y compartir recursos, como un firewall de red. Si tiene máquinas virtuales, agregue un host bastión a la red virtual del centro para administrarlas con seguridad mejorada. (Véase la figura 2.)

  

  Ilustración 2. El patrón de Reliable Web App con una segunda región y una topología radial.

• Elija una topología de red. Elija la topología de red adecuada para los requisitos web y de red. Si tiene previsto usar varias redes virtuales, use una topología de red de concentrador y radio . Proporciona ventajas de costo, administración y seguridad y opciones de conectividad híbrida a redes locales y virtuales.

Elija los servicios Azure adecuados

Al mover una aplicación web a la nube, debe elegir los servicios de Azure que cumplan los requisitos empresariales y alinearse con las características de la aplicación web local. Esta alineación ayuda a minimizar el esfuerzo de replatación. Por ejemplo, utilice servicios que le permitan mantener el mismo motor de base de datos y sean compatibles con el middleware y los marcos existentes. Las siguientes secciones proporcionan orientación para seleccionar los servicios Azure adecuados para su aplicación web.

Por ejemplo, antes de moverse a la nube, la aplicación web CAMS de Contoso Fiber era una aplicación web monolítica de Java local. Es una aplicación Spring Boot con una base de datos PostgreSQL. La aplicación web es una aplicación de soporte técnico a la línea de negocio. Está orientada a los empleados. Los empleados de Contoso Fiber utilizan la aplicación para gestionar los casos de asistencia de sus clientes. La aplicación web sufría los problemas habituales de escalabilidad e implementación de características. Este punto de partida, sus objetivos empresariales y el SLO impulsaron su elección de servicios.

• Plataforma de aplicaciones: Utilice Azure App Service como plataforma de aplicaciones. Contoso Fiber eligió Azure App Service como plataforma de aplicaciones por los siguientes motivos:

  • Progresión natural. Contoso Fiber implementó un archivo de Spring Boot jar en su servidor local y quería minimizar la cantidad de rediseño para ese modelo de implementación. App Service proporciona una sólida compatibilidad con la ejecución de aplicaciones de Spring Boot y era una progresión natural para que Contoso Fiber usara App Service. Azure Container Apps también es una alternativa atractiva para esta aplicación. Para más información, consulte ¿Qué es Azure Container Apps? y Java en Azure Container Apps.
  • Acuerdo de Nivel de Servicio alto. App Service proporciona un Acuerdo de Nivel de Servicio elevado que cumple los requisitos del entorno de producción.
  • Sobrecarga de administración reducida. App Service es una solución de hospedaje totalmente administrada.
  • Funcionalidad de contenedorización. App Service funciona con registros de imágenes de contenedor privados, como Azure Container Registry. Contoso Fiber puede utilizar estos registros para contenerizar la aplicación web en el futuro.
  • Escalabilidad automática. La aplicación web puede escalar verticalmente, reducir y reducir verticalmente rápidamente en función del tráfico del usuario.

• administración de identidades: Utilice Microsoft Entra ID como solución de administración de identidades y accesos. Contoso Fiber eligió Microsoft Entra ID por las siguientes razones:

  • Autenticación y autorización. La aplicación debe autenticar y autorizar a los empleados del centro de llamadas.
  • Escalabilidad. Microsoft Entra ID se escala para admitir escenarios más grandes.
  • Control de identidad de usuario. Los empleados del centro de llamadas pueden usar sus identidades empresariales existentes.
  • Compatibilidad con el protocolo de autorización. Microsoft Entra ID admite OAuth 2.0 para identidades administradas.

• Base de datos: Utilice un servicio que le permita mantener el mismo motor de base de datos. Use el árbol de decisión del almacén de datos para guiar la selección. Contoso Fiber eligió Azure Database for PostgreSQL y el modelo de implementación de servidor flexible por los siguientes motivos:

  • Fiabilidad. El modelo de implementación de servidor flexible admite alta disponibilidad con redundancia de zona en varias zonas de disponibilidad. Esta configuración mantiene un servidor en espera en caliente en una zona de disponibilidad diferente dentro de la misma región de Azure. La configuración replica los datos de forma sincrónica en el servidor en espera.
  • Replicación entre regiones. Azure Database for PostgreSQL proporciona una característica de réplica de lectura que permite replicar datos de forma asincrónica en una base de datos de réplica de solo lectura en otra región.
  • Rendimiento. Azure Database for PostgreSQL proporciona un rendimiento predecible y un ajuste inteligente que mejora el rendimiento de la base de datos mediante datos de uso reales.
  • Sobrecarga de administración reducida. Es un servicio de Azure totalmente administrado que reduce las obligaciones de administración.
  • Compatibilidad con la migración. Admite la migración de bases de datos desde bases de datos postgreSQL de servidor único local. Contoso puede usar la herramienta de migración para simplificar el proceso de migración.
  • Coherencia con configuraciones locales. Admite diferentes versiones de la comunidad de PostgreSQL, incluida la versión que Contoso Fiber usa actualmente.
  • Resistencia. La implementación de servidor flexible crea automáticamente copias de seguridad de servidor y las almacena en el almacenamiento con redundancia de zona (ZRS) dentro de la misma región. Contoso puede restaurar su base de datos a cualquier momento dado que se encuentra dentro del período de retención de copia de seguridad. La capacidad de copia de seguridad y restauración crea un RPO (cantidad aceptable de pérdida de datos) mejor que el que Contoso Fiber podría crear en el entorno local.

• Supervisión del rendimiento de las aplicaciones: Utilice Application Insights para analizar la telemetría de su aplicación. Contoso Fiber eligió utilizar Application Insights por las siguientes razones:

  • Integración con Azure Monitor. Proporciona la mejor integración con Azure Monitor.
  • Detección de anomalías. Detecta automáticamente anomalías de rendimiento.
  • Solución de problemas. Le ayuda a diagnosticar problemas en la aplicación en ejecución.
  • Monitorización. Recopila información sobre cómo los usuarios usan la aplicación y le permite realizar un seguimiento sencillo de los eventos personalizados.
  • Brecha de visibilidad. La solución local no tenía una solución de supervisión del rendimiento de la aplicación. Application Insights proporciona una integración sencilla con la plataforma y el código de la aplicación.

• Caché: Elija si desea agregar una caché a la arquitectura de la aplicación web. azure Cache for Redis es la solución principal de azure cache. Se trata de un almacén de datos en memoria administrado basado en el software de Redis. Contoso Fiber agregó Azure Cache for Redis por los siguientes motivos:

  • Velocidad y volumen. Proporciona un rendimiento de datos alto y lecturas de baja latencia para los datos a los que se accede con frecuencia y cambian lentamente.
  • Compatibilidad diversa. Es una ubicación de caché unificada que todas las instancias de la aplicación web pueden usar.
  • Almacén de datos externo. Los servidores de aplicaciones locales realizaron el almacenamiento en caché local de la máquina virtual. Esta configuración no ha descargado datos muy frecuentes y no ha podido invalidar los datos.
  • Sesiones no sticky. La memoria caché permite que la aplicación web externalice el estado de sesión y use sesiones no auxiliares. La mayoría de las aplicaciones web de Java que se ejecutan en el entorno local usan el almacenamiento en caché del lado cliente en memoria. El almacenamiento en caché del lado cliente en memoria no se escala bien y aumenta la superficie de memoria en el host. Con Azure Cache for Redis, Contoso Fiber tiene un servicio de caché totalmente administrado y escalable para mejorar la escalabilidad y el rendimiento de sus aplicaciones. Contoso usaba un marco de abstracción de caché (Spring Cache) y solo necesitaba cambios mínimos de configuración para intercambiar el proveedor de caché. Les permitió cambiar de un proveedor de Ehcache al proveedor de Redis.

• Equilibrador de carga: Las aplicaciones web que usan soluciones de plataforma como servicio (PaaS) deben usar Azure Front Door, Azure Application Gateway o ambos, en función de la arquitectura y los requisitos de la aplicación web. Utilice el árbol de decisión del equilibrador de carga para elegir el equilibrador de carga adecuado. Contoso Fiber necesitaba un equilibrador de carga de nivel 7 que pudiera enrutar el tráfico entre varias regiones y una aplicación web de varias regiones para satisfacer el SLO de 99,9%. Contoso eligió Azure Front Door por los siguientes motivos:

  • Equilibrio de carga global. Es un equilibrador de carga de nivel 7 que puede enrutar el tráfico entre varias regiones.
  • Firewall de aplicaciones web. Se integra de forma nativa con Azure Web Application Firewall.
  • Flexibilidad de enrutamiento. Permite que el equipo de la aplicación configure las necesidades de entrada para admitir cambios futuros en la aplicación.
  • Aceleración del tráfico. Usa anycast para llegar al punto de presencia de Azure más cercano y encontrar la ruta más rápida a la aplicación web.
  • Dominios personalizados. Admite nombres de dominio personalizados con validación de dominio flexible.
  • Pruebas de salud. La aplicación necesita una supervisión inteligente del sondeo de estado. Azure Front Door usa las respuestas del sondeo para determinar el mejor origen para enrutar las solicitudes de los clientes.
  • Compatibilidad con la supervisión. Azure Front Door admite informes integrados con un panel todo en uno para los patrones de seguridad y Azure Front Door. Puede configurar alertas que se integren con Azure Monitor. Azure Front Door permite que la aplicación registre cada solicitud y los sondeos de estado con errores.
  • Protección contra DDoS. Tiene protección contra DDoS de capa 3-4 integrada.
  • Red de entrega de contenido. Coloca Contoso Fiber para usar una red de entrega de contenido. La red de entrega de contenido proporciona aceleración del sitio.

• Firewall de aplicaciones web: Utiliza Azure Web Application Firewall para proporcionar protección centralizada contra exploits y vulnerabilidades web comunes. Contoso Fiber utilizó Azure Web Application Firewall por los siguientes motivos:

  • Protección global. Proporciona una protección mejorada de aplicaciones web globales sin sacrificar el rendimiento.
  • Protección de botnet. El equipo puede supervisar y configurar las opciones para abordar los problemas de seguridad relacionados con las redes de bot.
  • Paridad con el entorno local. La solución local se ejecutó detrás de un firewall de aplicaciones web administrado por TI.
  • Facilidad de uso. Web Application Firewall se integra con Azure Front Door.

• Gestor de secretos: Utilice Azure Key Vault si tiene secretos que administrar en Azure. Contoso Fiber utilizó Key Vault por las siguientes razones:

  • Encriptación. Admite el cifrado en reposo y en tránsito.
  • Compatibilidad con identidades administradas. Los servicios de aplicación pueden usar identidades administradas para acceder al almacén de secretos.
  • Supervisión y registro. Key Vault facilita el acceso de auditoría y genera alertas cuando cambian los secretos almacenados.
  • Integración. Key Vault proporciona integración nativa con el almacén de configuración de Azure (Azure App Configuration) y la plataforma de hospedaje web (App Service).

• Seguridad de los puntos de conexión: Use Azure Private Link para acceder a las soluciones de PaaS a través de un punto de conexión privado en la red virtual. El tráfico entre la red virtual y el servicio viaja por la red troncal de Microsoft. Contoso Fiber eligió Vínculo Privado por los siguientes motivos:

  • Comunicación de seguridad mejorada. Permite que la aplicación acceda de forma privada a los servicios en la plataforma Azure y reduce la superficie de red de los almacenes de datos para ayudar a protegerse contra la pérdida de datos.
  • Esfuerzo mínimo. Los puntos de conexión privados admiten la plataforma de aplicaciones web y la plataforma de base de datos que usa la aplicación web. Ambas plataformas reflejan las configuraciones locales existentes, por lo que se requiere un cambio mínimo.

• Seguridad de red: Utilice Azure Firewall para controlar el tráfico entrante y saliente a nivel de red. Use azure Bastion para conectarse a máquinas virtuales con seguridad mejorada, sin exponer puertos RDP/SSH. Contoso Fiber adoptó una topología de red en estrella tipo hub-and-spoke y quería poner los servicios de seguridad de red compartidos en el centro. Azure Firewall mejora la seguridad inspeccionando todo el tráfico saliente desde los radios para aumentar la seguridad de red. Contoso Fiber necesitaba Azure Bastion para implementaciones de seguridad mejorada desde un host de salto en la subred de DevOps.

Guía de código

Para mover correctamente una aplicación web a la nube, debe actualizar el código de la aplicación web con el patrón Reintento, el patrón Circuit Breaker y el patrón Cache-Aside.

Figura 3. Roles de los patrones de diseño.

Cada patrón de diseño proporciona ventajas de diseño de carga de trabajo que se alinean con uno o varios pilares de Well-Architected Framework. A continuación, te ofrecemos una visión general de los patrones que deberías implementar:

1. Patrón de reintento. El patrón Retry controla los errores transitorios mediante las operaciones de reintento que podrían producir un error intermitente. Implemente este patrón en todas las llamadas salientes a otros servicios de Azure.

2. Patrón circuit Breaker. El patrón Circuit Breaker impide que una aplicación vuelva a intentar las operaciones que no son transitorias. Implemente este patrón en todas las llamadas salientes a otros servicios de Azure.

3. Cache-Aside patrón. El patrón Cache-Aside carga datos a petición en una memoria caché desde un almacén de datos. Implemente este patrón en las solicitudes a la base de datos.

Implementar el patrón Retry

Añada el patrón Reintentar al código de su aplicación para hacer frente a las interrupciones temporales del servicio. Estas interrupciones se denominan fallos transitorios. Los fallos transitorios suelen resolverse en cuestión de segundos. El patrón Retry permite reenviar solicitudes con errores. También le permite configurar el retraso entre reintentos y el número de intentos que se deben realizar antes de conceder un error.

Use Resilience4j, una biblioteca ligera de tolerancia a errores, para implementar el patrón Retry en Java. La implementación de referencia agrega el patrón Retry mediante la decoración del método listServicePlans del controlador de plan de servicio con anotaciones de reintento. El código reintenta la llamada a una lista de planes de servicio de la base de datos si se produce un error en la llamada inicial. La directiva de reintento para la implementación de referencia incluye los intentos máximos, la duración de espera y las excepciones que se deben reintentar. La directiva de reintentos está configurada en application.properties.

    @GetMapping("/list")
    @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
    @CircuitBreaker(name = SERVICE_PLAN)
    @Retry(name = SERVICE_PLAN)
    public String listServicePlans(Model model) {
        List<serviceplandto> servicePlans = planService.getServicePlans();
        model.addAttribute("servicePlans", servicePlans);
        return "pages/plans/list";
    }

Implementación del patrón de interruptor

Utilice el patrón Circuit Breaker para administrar las interrupciones del servicio que no sean fallos transitorios. El patrón Circuit Breaker impide que una aplicación intente acceder continuamente a un servicio que no responde. Libera la aplicación y ayuda a evitar la pérdida de ciclos de CPU para que la aplicación conserve su integridad de rendimiento para los usuarios finales.

Use Spring Cloud Circuit Breaker y Resilience4j para implementar el patrón Circuit Breaker. La implementación de referencia implementa el patrón Circuit Breaker mediante la decoración de métodos con el atributo Circuit Breaker.

Implementación del patrón Cache-Aside

Añada el patrón Cache-Aside a su aplicación web para mejorar la administración de datos en memoria. El patrón asigna a la aplicación la responsabilidad de controlar las solicitudes de datos y garantizar la coherencia entre la caché y el almacenamiento persistente, como una base de datos. Acorta los tiempos de respuesta y mejora el rendimiento, además de reducir la necesidad de aumentar la escala. También reduce la carga en el almacén de datos principal, lo que mejora la confiabilidad y la optimización de costos. Para implementar el patrón Cache-Aside, siga estas recomendaciones:

• Configure la aplicación para utilizar una caché. Para habilitar el almacenamiento en caché, agregue el paquete spring-boot-starter-cache como una dependencia en el archivo pom.xml. Este paquete proporciona configuraciones predeterminadas para la caché Redis.

• Almacenamiento en caché de datos de alta necesidad. Aplique el patrón de Cache-Aside en datos de alta necesidad para mejorar su eficacia. Use Azure Monitor para realizar un seguimiento de la CPU, la memoria y el almacenamiento de la base de datos. Estas métricas le ayudan a determinar si puede usar una SKU de base de datos más pequeña después de aplicar el patrón de Cache-Aside. Para almacenar en caché datos específicos en su código, añada la anotación @Cacheable. Esta anotación especifica a Spring qué métodos deben tener sus resultados almacenados en caché.

• Mantenga actualizados los datos de la memoria caché. Programe actualizaciones de caché periódicas para sincronizarse con los cambios más recientes en la base de datos. Use la volatilidad de los datos y las necesidades del usuario para determinar la velocidad de actualización óptima. Esta práctica garantiza que la aplicación use el patrón Cache-Aside para proporcionar acceso rápido e información actual. La configuración predeterminada de la caché puede no adaptarse a su aplicación web. Puede personalizar estos ajustes en el archivo application.properties o en las variables de entorno. Por ejemplo, puede modificar el spring.cache.redis.time-to-live valor (expresado en milisegundos) para controlar cuánto tiempo deben permanecer los datos en la memoria caché antes de quitarlos.

• Aseguramiento de la coherencia de los datos. Implemente mecanismos para actualizar la memoria caché inmediatamente después de cualquier operación de escritura en la base de datos. Use actualizaciones controladas por eventos o clases de administración de datos dedicadas para garantizar la coherencia de la memoria caché. La sincronización coherente de la memoria caché con modificaciones de la base de datos es fundamental para el patrón Cache-Aside.

Guía de configuración

En las secciones siguientes se proporcionan instrucciones sobre la implementación de las actualizaciones de configuración. Cada sección se ajusta a uno o varios pilares del marco de trabajo bien diseñado.

Configure la autenticación y la autorización

Cuando migre aplicaciones web a Azure, configure mecanismos de autenticación y autorización de usuarios. Siga estas recomendaciones:

• Utilice una plataforma de identidad. Utilice la plataforma Microsoft Identity para configurar la autenticación de aplicaciones web. Esta plataforma admite aplicaciones que usan un único directorio de Microsoft Entra, varios directorios de Microsoft Entra de diferentes organizaciones e identidades de Microsoft o cuentas sociales.

  Spring Boot Starter para microsoft Entra ID simplifica este proceso. Usa Spring Security y Spring Boot para garantizar una configuración sencilla. Proporciona varios flujos de autenticación, administración automática de tokens, directivas de autorización personalizables y funcionalidades de integración con componentes de Spring Cloud. Este servicio permite la integración directa de Microsoft Entra ID y OAuth 2.0 en aplicaciones de Spring Boot sin la configuración manual de la biblioteca o la configuración.

  La implementación de referencia usa la plataforma de identidad de Microsoft (Id. de Entra de Microsoft) como proveedor de identidades para la aplicación web. Utiliza la concesión de código de autorización OAuth 2.0 para iniciar sesión en un usuario con una cuenta de Microsoft Entra. El siguiente fragmento XML define las dos dependencias necesarias del flujo de concesión de código de autorización de OAuth 2.0. La dependencia com.azure.spring: spring-cloud-azure-starter-active-directory habilita la autenticación y autorización de Microsoft Entra en una aplicación de Spring Boot. La dependencia org.springframework.boot: spring-boot-starter-oauth2-client habilita la autenticación y autorización de OAuth 2.0 en una aplicación de Spring Boot.

  <dependency>
      <groupid>com.azure.spring</groupid>
      <artifactid>spring-cloud-azure-starter-active-directory</artifactid>
  </dependency>
  <dependency>
      <groupid>org.springframework.boot</groupid>
      <artifactid>spring-boot-starter-oauth2-client</artifactid>
  </dependency>
  

• Cree un registro de aplicación. Microsoft Entra ID requiere un registro de aplicación en el inquilino principal. El registro de la aplicación ayuda a garantizar que los usuarios que obtienen acceso a la aplicación web tengan identidades en el inquilino principal. La implementación de referencia usa Terraform para crear un registro de aplicación de Id. de Microsoft Entra junto con un rol de administrador de cuentas específico de la aplicación:

  resource "azuread_application" "app_registration" {
    display_name     = "${azurecaf_name.app_service.result}-app"
    owners           = [data.azuread_client_config.current.object_id]
    sign_in_audience = "AzureADMyOrg"  # single tenant
  
    app_role {
      allowed_member_types = ["User"]
      description          = "Account Managers"
      display_name         = "Account Manager"
      enabled              = true
      id                   = random_uuid.account_manager_role_id.result
      value                = "AccountManager"
    }
  }
  

• Haga cumplir la autorización en la aplicación. Use el control de acceso basado en rol (RBAC) para asignar privilegios mínimos a los roles de aplicación. Defina roles específicos para diferentes acciones de usuario para evitar solapamientos y garantizar la claridad. Asigne usuarios a los roles adecuados y asegúrese de que solo tienen acceso a los recursos y acciones necesarios. Configure Spring Security para utilizar Spring Boot Starter para Microsoft Entra ID. Esta biblioteca permite la integración con el identificador de Entra de Microsoft y le ayuda a garantizar que los usuarios se autentican de forma segura. La configuración y habilitación de la biblioteca de autenticación de Microsoft (MSAL) proporciona acceso a más características de seguridad. Estas características incluyen el almacenamiento en caché de tokens y la actualización automática de tokens.

  La implementación de referencia crea roles de aplicación que reflejan los tipos de roles de usuario en el sistema de administración de cuentas de Contoso Fiber. Los roles se traducen a permisos durante la autorización. Entre los ejemplos de roles específicos de la aplicación en CAMS se incluyen el Administrador de cuentas, el Representante de soporte técnico de Nivel Uno (L1) y el Representante de Field Service. El rol Administrador de cuentas tiene permisos para agregar nuevos usuarios y clientes de la aplicación. Un representante de Field Service puede crear incidencias de soporte técnico. El atributo PreAuthorize restringe el acceso a roles específicos.

      @GetMapping("/new")
      @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
      public String newAccount(Model model) {
          if (model.getAttribute("account") == null) {
              List<ServicePlan> servicePlans = accountService.findAllServicePlans();
              ServicePlan defaultServicePlan = servicePlans.stream().filter(sp -> sp.getIsDefault() == true).findFirst().orElse(null);
              NewAccountRequest accountFormData = new NewAccountRequest();
              accountFormData.setSelectedServicePlanId(defaultServicePlan.getId());
              model.addAttribute("account", accountFormData);
              model.addAttribute("servicePlans", servicePlans);
          }
          model.addAttribute("servicePlans", accountService.findAllServicePlans());
          return "pages/account/new";
      }
      ...
  

  Para integrarse con Microsoft Entra ID, la implementación de referencia usa el flujo de concesión de código de autorización de OAuth 2.0. Este flujo permite a un usuario iniciar sesión con una cuenta Microsoft. En el fragmento de código siguiente se muestra cómo configurar el SecurityFilterChain para usar microsoft Entra ID para la autenticación y la autorización.

  @Configuration(proxyBeanMethods = false)
  @EnableWebSecurity
  @EnableMethodSecurity
  public class AadOAuth2LoginSecurityConfig {
      @Bean
      SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
          http.apply(AadWebApplicationHttpSecurityConfigurer.aadWebApplication())
              .and()
                  .authorizeHttpRequests()
              .requestMatchers(EndpointRequest.to("health")).permitAll()
              .anyRequest().authenticated()
              .and()
                  .logout(logout -> logout
                              .deleteCookies("JSESSIONID", "XSRF-TOKEN")
                              .clearAuthentication(true)
                              .invalidateHttpSession(true));
          return http.build();
      }
  }
  ...
  

• Prefiera el acceso temporal al almacenamiento. Use permisos temporales para proteger contra el acceso no autorizado y las infracciones. Por ejemplo, puede usar firmas de acceso compartido (SAS) para limitar el acceso a un período de tiempo. Use saS de delegación de usuarios para maximizar la seguridad al conceder acceso temporal. Es el único SAS que utiliza credenciales de Microsoft Entra ID y no requiere una clave de cuenta de almacenamiento permanente.

• Aplique la autorización en Azure. Utilice Azure RBAC para asignar los mínimos privilegios a las identidades de usuario. RBAC de Azure define los recursos de Azure a los que pueden acceder las identidades, lo que pueden hacer con esos recursos y las áreas a las que tienen acceso.

• Evite los permisos elevados permanentes. Use Microsoft Entra Privileged Identity Management para conceder acceso Just-In-Time para las operaciones con privilegios. Por ejemplo, los desarrolladores a menudo necesitan acceso de nivel de administrador para crear/eliminar bases de datos, modificar esquemas de tablas y cambiar permisos de usuario. Cuando se usa el acceso Just-In-Time, las identidades de usuario reciben permisos temporales para realizar tareas con privilegios.

Implementación de identidades administradas

Use identidades administradas para todos los servicios de Azure que los admitan. Una identidad administrada permite que los recursos de Azure (identidades de carga de trabajo) se autentiquen e interactúen con otros servicios de Azure sin necesidad de administrar las credenciales. Para simplificar la migración, puede seguir usando soluciones de autenticación locales para sistemas híbridos y heredados, pero debe realizar la transición a identidades administradas lo antes posible. Para implantar identidades administradas, siga estas recomendaciones:

• Elija el tipo adecuado de identidad administrada. Prefiera las identidades administradas asignadas por usuario cuando tenga dos o más recursos Azure que necesiten el mismo conjunto de permisos. Este enfoque es más eficaz que crear identidades administradas asignadas por el sistema para cada uno de esos recursos y asignar los mismos permisos a todos ellos. De lo contrario, utilice identidades administradas asignadas por el sistema.

• Configure los privilegios mínimos. Use azure RBAC para conceder solo permisos críticos para las operaciones, como acciones CRUD en bases de datos o acceso a secretos. Los permisos de identidad de carga de trabajo son persistentes, por lo que no puede proporcionar permisos Just-In-Time o a corto plazo a las identidades de carga de trabajo. Si Azure RBAC no cubre un escenario específico, complemente Azure RBAC con políticas de acceso a nivel de servicio de Azure.

• Proporcione seguridad para los secretos restantes. Almacene los secretos restantes en Azure Key Vault. desde Key Vault al inicio de la aplicación en lugar de durante cada solicitud HTTP. El acceso de alta frecuencia dentro de las solicitudes HTTP puede superar los límites de transacción de Key Vault. Almacene las configuraciones de las aplicaciones en Azure App Configuration.

Entornos rightsize

Use los niveles de rendimiento (SKU) de los servicios de Azure que satisfagan las necesidades de cada entorno sin superarlos. Para aplicar derechos a los entornos, siga estas recomendaciones:

• Evaluar los costos. Utilice la calculadora de precios de Azure para estimar el coste de cada entorno.

• Entornos de producción optimizados para costos. Los entornos de producción necesitan SKU que cumplan los acuerdos de nivel de servicio (SLA), las características y la escala necesarias para producción. Supervise continuamente el uso de recursos y ajuste las SKU para alinearlas con las necesidades reales de rendimiento.

• entornos de preproducción de optimización de costos.entornos de preproducción deben usar recursos de menor costo y aprovechar los descuentos, como precios de desarrollo y pruebas de Azure. En estos entornos, debe deshabilitar los servicios que no son necesarios. Al mismo tiempo, asegúrese de que entornos de preproducción sean lo suficientemente similares a los entornos de producción para evitar la introducción de riesgos. Mantener este equilibrio garantiza que las pruebas permanezcan vigentes sin incurrir en costos innecesarios.

• Use la infraestructura como código (IaC) para definir SKU. Implemente IaC para seleccionar y implementar dinámicamente las SKU correctas en función del entorno. Este enfoque mejora la coherencia y simplifica la administración.

Por ejemplo, la implementación de referencia tiene un parámetro opcional que especifica la SKU que se va a implementar. Un parámetro de entorno especifica que la plantilla de Terraform debe implementar SKU de desarrollo:

azd env set APP_ENVIRONMENT prod

Implementación del escalado automático

El escalado automático ayuda a garantizar que una aplicación web siga siendo resistente, con capacidad de respuesta y capaz de controlar las cargas de trabajo dinámicas de forma eficaz. Para implementar el autoescalado, siga estas recomendaciones:

• Automatice la escalabilidad horizontal. Utilice Autoescala de Azure para automatizar el escalado horizontal en entornos de producción. Configure reglas de escalado automático para escalar horizontalmente en función de las métricas clave de rendimiento para que la aplicación pueda controlar cargas variables.

• Refine los desencadenadores de escalado. Use el uso de cpu como desencadenador de escalado inicial si no está familiarizado con los requisitos de escalado de la aplicación. Refinar los desencadenadores de escalado para incluir otras métricas como RAM, rendimiento de red y E/S de disco. El objetivo es adaptarse al comportamiento de su aplicación web para mejorar el rendimiento.

• Proporcione un búfer de escalabilidad horizontal. Establezca los umbrales de escalado para que se desencadenen antes de alcanzar la capacidad máxima. Por ejemplo, configure el escalado para que se produzca al 85 % de utilización de la CPU en lugar de esperar hasta que alcance el 100 %. Este enfoque proactivo ayuda a mantener el rendimiento y evitar posibles cuellos de botella.

Automatización de la implementación de recursos

Utilice la automatización para implementar y actualizar los recursos y el código de Azure en todos los entornos. Siga estas recomendaciones:

• Usar la infraestructura como código. Implemente infraestructura como código mediante canalizaciones de integración continua y entrega continua (CI/CD). Azure proporciona plantillas precompiladas Bicep, ARM (JSON) y Terraform para cada recurso de Azure.

• Utilice un pipeline de integración continua y entrega continua (CI/CD). Utilice un pipeline CI/CD para implementar código desde el control de origen a los distintos entornos, como pruebas, preparación y producción. Use Azure Pipelines si trabaja con Azure DevOps. Use Acciones de GitHub para proyectos de GitHub.

• Integre las pruebas de unidades. Dé prioridad a la ejecución y superación de todas las pruebas unitarias dentro de su pipeline antes de cualquier implementación en App Services. Incorpore herramientas de cobertura y calidad del código como SonarQube para lograr una cobertura de pruebas exhaustiva.

• Adoptar marcos ficticios. Para realizar pruebas que impliquen puntos de conexión externos, use marcos ficticios. Estos marcos permiten crear puntos de conexión simulados. Eliminan la necesidad de configurar puntos de conexión externos reales y garantizar condiciones de prueba uniformes en entornos.

• Realice exámenes de seguridad. Use pruebas estáticas de seguridad de aplicaciones (SAST) para buscar errores de seguridad y errores de codificación en el código fuente. Además, realice análisis de composición de software (SCA) para examinar bibliotecas y componentes de terceros para detectar riesgos de seguridad. Las herramientas para estos análisis son fáciles de integrar en GitHub y Azure DevOps.

Configuración de la supervisión

Implemente la supervisión de aplicaciones y plataformas para mejorar la excelencia operativa y la eficacia del rendimiento de su aplicación web. Para implantar la supervisión, siga estas recomendaciones:

• Recopile telemetría de aplicaciones. Use de instrucciones automáticas en Azure Application Insights para recopilar datos de telemetría de de aplicaciones, como el rendimiento de las solicitudes, la duración media de la solicitud, los errores y la supervisión de dependencias. No es necesario cambiar ningún código para usar esta telemetría. Spring Boot registra varias métricas principales en Application Insights, como la máquina virtual Java (JVM), la CPU, Tomcat y otras. Application Insights recopila automáticamente los marcos de registro, como Log4j y Logback.

  La implementación de referencia usa Application Insights, que se habilita a través de Terraform en la configuración de app_settings App Service:

  app_settings = {
      APPLICATIONINSIGHTS_CONNECTION_STRING = var.app_insights_connection_string
      ApplicationInsightsAgent_EXTENSION_VERSION = "~3"
      ...
  }
  

  Para más información, vea:

  • Configuración de Application Insights de Azure Monitor para Spring Boot
  • Application Insights de Azure Monitor para Java
  • Habilitación de OpenTelemetry de Azure Monitor para aplicaciones Java
  • Configuración de Application Insights de Azure Monitor para Spring Boot

• Cree métricas de aplicación personalizadas. Implemente instrumentación basada en código para capturar telemetría de aplicaciones personalizada añadiendo el SDK de Application Insights y utilizando su API.

• Supervise la plataforma. Habilite los diagnósticos para todos los servicios admitidos. Envíe diagnósticos al mismo destino que los registros de aplicación para la correlación. Los servicios de Azure crean registros de plataforma automáticamente, pero solo los almacenan cuando se habilitan los diagnósticos. Habilite la configuración de diagnóstico para cada servicio que admita diagnósticos.

  La implementación de referencia usa Terraform para habilitar diagnósticos de Azure en todos los servicios admitidos. El siguiente código de Terraform configura las opciones de diagnóstico del servicio de aplicaciones:

  # Configure diagnostic settings for app service
  resource "azurerm_monitor_diagnostic_setting" "app_service_diagnostic" {
    name                           = "app-service-diagnostic-settings"
    target_resource_id             = azurerm_linux_web_app.application.id
    log_analytics_workspace_id     = var.log_analytics_workspace_id
    #log_analytics_destination_type = "AzureDiagnostics"
  
    enabled_log {
      category_group = "allLogs"
  
    }
  
    metric {
      category = "AllMetrics"
      enabled  = true
    }
  }
  

Realice la implementación de referencia

La implementación de referencia guía a los desarrolladores a través de una migración simulada de una aplicación java local a Azure, resaltando los cambios necesarios durante la fase de adopción inicial. En este ejemplo se usa una aplicación web CAMS para la empresa ficticia Contoso Fiber. Contoso Fiber establece los siguientes objetivos para la aplicación web:

• Implemente cambios de código de bajo costo y de alto valor.
• Lograr un SLO de 99,9%.
• Adoptar prácticas de DevOps.
• Cree entornos optimizados para costos.
• Mejorar la confiabilidad y la seguridad.

Contoso Fiber determinó que su infraestructura local no era una solución rentable para alcanzar estos objetivos. Decidieron que migrar su aplicación web CAMS a Azure era la manera más rentable de lograr sus objetivos inmediatos y futuros. La arquitectura siguiente representa el estado final de la implementación del patrón Reliable Web App de Contoso Fiber.

Figura 4. Arquitectura de la implementación de referencia. Arquitectura de la implementación de referencia. Descargue un archivo Visio de esta arquitectura.