Patrón Reliable Web App para Java

Este artículo proporciona orientación sobre la implementación del patrón Reliable Web App. Este patrón describe cómo modificar (replanificar) aplicaciones web para la migración a la nube. Ofrece orientación prescriptiva sobre arquitectura, código y configuración en consonancia con los principios del Marco de trabajo bien diseñado.

¿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 el modo en que se deben replanificar las aplicaciones web al migrar a la nube. Se centra en las actualizaciones mínimas de código que hay que hacer para tener éxito en la nube. La siguiente guía utiliza la implementación de referencia como ejemplo y sigue el viaje de replataforma de la empresa ficticia, Contoso Fiber, para proporcionar contexto empresarial para su viaje. Antes de implementar el patrón Reliable Web App para Java, Contoso Fiber tenía un sistema de administración de cuentas de clientes (CAMS) monolítico y local que utilizaba el marco Spring Boot.

Cómo implementar el patrón Reliable Web App

Este artículo incluye orientación sobre arquitectura, código y configuración para implantar el patrón Reliable Web App. Utilice los siguientes enlaces para navegar hasta la orientación específica que necesita:

• Contexto empresarial: Alinee esta orientación con su contexto empresarial y aprenda a definir objetivos inmediatos y a largo plazo que impulsen las decisiones de replanificación.
• Orientación sobre arquitectura: Aprenda a seleccionar los servicios en la nube adecuados y a diseñar una arquitectura que satisfaga sus requisitos empresariales.
• Guía de código: Implemente tres patrones de diseño para mejorar la fiabilidad y la eficiencia del rendimiento de su aplicación web en la nube: Los patrones Retry, Circuit-Breaker y Cache-Aside.
• Guía de configuración: Configure la autenticación y la 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 y objetivos de optimización de costes, así como objetivos futuros para su 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 objetivo de SLO para su aplicación web, como un tiempo de actividad del 99,9 %. Calcule el SLA compuesto para todos los servicios que afectan a la disponibilidad de su aplicación web.

Por ejemplo, Contoso Fiber quería ampliar su aplicación web local del sistema de administración de cuentas de clientes (CAMS) para llegar a otras regiones. Para hacer frente al aumento de la demanda de la aplicación web, establecieron los siguientes objetivos:

• Aplicar cambios de bajo costo y alto valor
• Alcanzar un objetivo de nivel de servicio (SLO) del 99,9 %
• Adoptar las prácticas de DevOps
• Crear entornos con costes optimizados
• Mejorar la confiabilidad y la seguridad

Contoso Fiber determinó que su infraestructura local no era una solución rentable para escalar la aplicación. Así que decidieron que migrar su aplicación web CAMS a Azure era la manera más rentable de alcanzar 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 malicioso y un equilibrador de carga para proteger y enrutar las solicitudes entrantes de los usuarios. La plataforma de aplicaciones aloja el código de su aplicación web y realiza llamadas a todos los servicios backend 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 comprender su aplicación web.

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

Diseño de la arquitectura

Diseñe su infraestructura para soportar sus 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 objetivo de punto de recuperación (RPO) y configure la redundancia de datos para cumplir el RPO.

• Elija la fiabilidad de la infraestructura. Determine cuántas zonas y regiones de disponibilidad necesita para satisfacer sus necesidades 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 %.

  Para una aplicación web multirregión, configure su equilibrador de carga para enrutar el tráfico a la segunda región con el fin de admitir una configuración activa-activa o activa-pasiva en función de sus necesidades empresariales. Las dos regiones requieren los mismos servicios, excepto que una de las regiones tiene una red virtual concentradora 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, añada un host bastión a la red virtual hub para administrarlas de forma segura (consulte 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 disponer de varias redes virtuales, utilice una topología de red radial. Proporciona ventajas de coste, administración y seguridad con opciones de conectividad híbrida a redes locales y virtuales.

Elija los servicios Azure adecuados

Al trasladar una aplicación web a la nube, debe seleccionar los servicios de Azure que satisfagan sus requisitos empresariales y se ajusten a las funciones actuales de la aplicación web local. La alineación ayuda a minimizar el esfuerzo de cambio de plataforma. 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 pasar a la nube, la aplicación web CAMS de Contoso Fiber era una aplicación web Java monolítica 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 Spring Boot jar en su servidor local y quería minimizar la cantidad de rearquitectura 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 obtener más información, consulte ¿Qué es Azure Spring Apps? y Visión general de Java en Azure Container Apps.
  • SLA alto: Tiene un SLA alto que cumple los requisitos para el entorno de producción.
  • Gastos de administración reducidos: Es una solución de hosting totalmente administrada.
  • Capacidad de contenerización: App Service funciona con registros privados de imágenes de contenedores como Azure Container Registry. Contoso Fiber puede utilizar estos registros para contenerizar la aplicación web en el futuro.
  • Autoescalado: La aplicación web puede escalarse rápidamente hacia arriba, abajo, dentro y fuera en función del tráfico de usuarios.

• 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.
  • Escalable: 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: Admite OAuth 2.0 para identidades administradas.

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

  • Fiabilidad: El modelo de implementación de servidor flexible admite alta disponibilidad redundante por zonas 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: Cuenta con una función de réplica de lectura que permite replicar datos de forma asíncrona a una base de datos de réplica de solo lectura en otra región.
  • Rendimiento: Proporciona un rendimiento predecible y un ajuste inteligente para mejorar el rendimiento de su base de datos mediante el uso de datos de uso real.
  • Gastos de administración reducidos: Es un servicio Azure totalmente administrado que reduce las obligaciones de administración.
  • Soporte de migración: Admite la migración de bases de datos desde bases de datos PostgreSQL locales de un solo servidor. Pueden usar la herramienta de migración para simplificar el proceso de migración.
  • Consistencia con configuraciones locales: Admite diferentes versiones comunitarias de PostgreSQL, incluida la versión que Contoso Fiber utiliza actualmente.
  • Resistencia. La implementación del servidor flexible crea automáticamente copias de seguridad del servidor y las almacena en el almacenamiento con redundancia de zona (ZRS) dentro de la misma región. Se puede restaurar su base de datos a cualquier momento dado dentro de su 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 las anomalías de rendimiento.
  • Solución de problemas: Ayuda a diagnosticar problemas de la aplicación en ejecución.
  • Supervisión: Recopila información sobre cómo los usuarios usan la aplicación y permite realizar un seguimiento sencillo de los eventos personalizados.
  • Brecha de visibilidad: La solución local no contaba con una solución de supervisión del rendimiento de las aplicaciones. Application Insights proporciona una integración sencilla con la plataforma y el código de la aplicación.

• Caché: Elija si desea añadir caché a la arquitectura de su aplicación web. Azure Cache for Redis es la solución de caché principal de Azure. Es un almacén de datos en memoria administrado basado en el software Redis. Contoso Fiber ha añadido Azure Cache for Redis por los siguientes motivos:

  • Velocidad y volumen: Tiene un rendimiento de datos alto y lecturas de baja latencia para los datos a los que se accede con frecuencia y que cambian poco.
  • Amplia compatibilidad: Se trata de una ubicación de caché unificada para que todas las instancias de la aplicación web la puedan 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 permanentes: La caché permite a la aplicación web externalizar el estado de la sesión y utilizar sesiones no pegajosas. La mayoría de las aplicaciones web de Java que se ejecutan de forma local usan el almacenamiento en caché del lado cliente en la memoria. El almacenamiento en caché del lado cliente en la memoria no se escala bien y aumenta la superficie de memoria en el host. Mediante el uso de Azure Cache for Redis, Contoso Fiber tiene un servicio de caché escalable y totalmente administrado para mejorar la escalabilidad y el rendimiento de sus aplicaciones. Contoso Fiber usaba un marco de abstracción de caché (Spring Cache) y solo necesitaba cambios mínimos de configuración para cambiar el proveedor de caché. Les permitió cambiar de un proveedor de Ehcache al proveedor de Redis.

• Equilibrador de carga: Las aplicaciones web que utilizan soluciones PaaS deben utilizar 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 capa 7 que pudiera enrutar el tráfico a través de varias regiones. Contoso Fiber necesitaba una aplicación web multirregión para cumplir el SLO del 99,9 %. Contoso Fiber eligió Azure Front Door por los siguientes motivos:

  • Equilibrio de carga global: Es un equilibrador de carga de capa 7 que puede enrutar el tráfico a través de 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 los cambios futuros en la aplicación.
  • Aceleración de tráfico: Usa cualquier difusión 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.
  • Sondeos de estado: 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: Análisis de informes integrados con un panel todo en uno que integre los patrones de Front Door y de seguridad. Puede configurar alertas que se integren con Azure Monitor. 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: Posiciona a Contoso Fiber para usar una red de entrega de contenidos. 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 mejor protección global de aplicaciones web sin sacrificar el rendimiento.
  • Protección contra botnets: El equipo puede supervisar y configurar los ajustes para abordar las preocupaciones de seguridad relacionadas con las redes de bots.
  • Paridad con el entorno local: La solución local se ejecutaba detrás de un firewall de aplicaciones web administrado por el departamento de 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:

  • Cifrado: Admite cifrado de datos en reposo y en tránsito
  • Compatibilidad con identidades administradas: Los servicios de aplicaciones pueden utilizar identidades administradas para acceder al almacén de secretos.
  • Supervisión y registro: Facilita el acceso de auditoría y genera alertas cuando cambian los secretos almacenados.
  • Integración: Proporciona integración nativa con el almacén de configuración de Azure (App Configuration) y la plataforma de hospedaje web (App Service).

• Seguridad de punto de conexión: Utilice Azure Vínculo Privado para acceder a soluciones de plataforma como servicio a través de un punto de conexión privado en su 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 de la plataforma Azure y reduce la superficie de red de los almacenes de datos para ayudar a protegerse frente a 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 para que el cambio sea mínimo.

• Seguridad de red: Utilice Azure Firewall para controlar el tráfico entrante y saliente a nivel de red. Utilice Azure Bastion para conectarse a máquinas virtuales de forma segura sin exponer puertos RDP/SSH. Contoso Fiber adoptó una topología de red hub and spoke y quería poner servicios de seguridad de red compartidos en el hub. 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 realizar implementaciones seguras desde un host de salto en la subred DevOps.

Guía de código

Para trasladar con éxito una aplicación web a la nube, es necesario actualizar el código de la aplicación web con el patrón Retry, el patrón Circuit-Breaker y el patrón de diseño Cache-Aside.

Figura 3. Función de los patrones de diseño.

Cada patrón de diseño proporciona beneficios de diseño de carga de trabajo que se alinean con uno o más pilares del marco de trabajo bien diseñado. A continuación, te ofrecemos una visión general de los patrones que deberías implementar:

1. Patrón de reintento: El patrón de reintento administra los fallos transitorios reintentando las operaciones que pueden fallar de forma 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 evita que una aplicación reintente operaciones que no son transitorias. Implemente este patrón en todas las llamadas salientes a otros servicios de Azure.

3. Patrón Cache-Aside: El patrón Cache-Aside añade y recupera de una caché con más frecuencia que de 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 le permite reenviar peticiones fallidas. También permite configurar los retardos de las peticiones y el número de intentos antes de conceder el fallo.

Utilice Resilience4j, una biblioteca ligera de tolerancia a fallos, para implementar el patrón Retry en Java. Por ejemplo, la implementación de referencia añade el patrón de reintento decorando el método listServicePlans del controlador del plan de servicio con anotaciones Retry. 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 implementación de referencia configura la directiva de reintentos, incluidos los intentos máximos, la duración de la 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 evita el desperdicio de ciclos de CPU, de modo que la aplicación conserva su integridad de rendimiento para los usuarios finales.

Utilice la documentación de Spring Circuit Breaker y Resilience4j para implementar el patrón Circuit-Breaker. Por ejemplo, la implementación de referencia implementa el patrón Circuit Breaker decorando los 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 gestionar las solicitudes de datos y garantizar la coherencia entre la caché y un 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 primario, mejorando la fiabilidad y la optimización de costes. 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 Cache-Aside en datos de alta necesidad para amplificar 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 ayudarán a determinar si puede utilizar un SKU de base de datos más pequeño tras aplicar el patrón Cache-Aside. Para almacenar en caché datos específicos en su código, añada la anotación @Cacheable. Esta anotación indica a Spring qué métodos deben almacenar sus resultados 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. Determine la velocidad de actualización óptima en función de la volatilidad de los datos y las necesidades del usuario. Esta práctica garantiza que la aplicación use el patrón Cache-Aside para proporcionar acceso rápido y 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 valor spring.cache.redis.time-to-live (expresado en milisegundos) para controlar cuánto tiempo deben permanecer los datos en la caché antes de ser desalojados.

• 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

Las siguientes secciones ofrecen orientación sobre la aplicación de las actualizaciones de las configuraciones. 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.

  El Spring Boot Starter para Microsoft Entra ID agiliza este proceso, utilizando Spring Security y Spring Boot para una fácil configuración. Ofrece diversos flujos de autenticación, administración automática de tokens y directivas de autorización personalizables, junto con funcionalidades de integración con componentes de Spring Cloud. Esto permite una integración sencilla 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.

  Por ejemplo, la implementación de referencia utiliza la plataforma de identidad de Microsoft (Microsoft Entra ID) como proveedor de identidad 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 admite la autenticacióny autorizació 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>
  

• Crear un registro de aplicación. Microsoft Entra ID requiere un registro de aplicación en el inquilino principal. El registro de la aplicación garantiza que los usuarios que obtienen acceso a la aplicación web tienen identidades en el inquilino principal. Por ejemplo, la implementación de referencia utiliza Terraform para crear un registro de aplicación de Microsoft Entra ID junto con un rol de Administrador de Cuenta específico para 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. Utilice controles de acceso basados en roles (RBAC) para asignar los menores privilegios a los roles de la aplicación. Defina roles específicos para diferentes acciones de usuario para evitar solapamientos y garantizar la claridad. Asigne a los usuarios 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 Microsoft Entra ID y le ayuda a garantizar que los usuarios se autentiquen 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.

  Por ejemplo, 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 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. Utilice permisos temporales para protegerse contra el acceso no autorizado y las infracciones, como las firmas de acceso compartido (SAS). Utilice 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. Azure RBAC determina a qué recursos de Azure pueden acceder las identidades, qué pueden hacer con esos recursos y a qué áreas 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. Con el acceso Just-In-Time, las identidades de usuario reciben permisos temporales para realizar tareas privilegiadas.

Implementación de identidades administradas

Utilice identidades administradas para todos los servicios Azure que admitan identidades administradas. Una identidad administrada permite a los recursos de Azure (identidades de carga de trabajo) autenticarse e interactuar con otros servicios de Azure sin administrar credenciales. Los sistemas híbridos y heredados pueden mantener las soluciones de autenticación locales para simplificar la migración, pero deben realizar la transición a las 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. Esta configuración 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. Utilice Azure RBAC para conceder solo los permisos que son críticos para las operaciones, como las acciones CRUD en bases de datos o el 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.

• Proteja 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 de tamaño adecuado

Utilice los niveles de rendimiento (SKU) de los servicios Azure que satisfagan las necesidades de cada entorno sin excesos. Para dimensionar correctamente sus entornos, siga estas recomendaciones:

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

• Optimice los costes de los entornos de producción. 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.

• Optimice los costes de los entornos de preproducción. Los entornos de preproducción deben utilizar recursos de menor coste, desactivar servicios innecesarios y aplicar descuentos como los precios de Azure Dev/Test. Asegúrese de que los entornos de preproducción sean lo suficientemente similares a los de producción para evitar introducir riesgos. Este equilibrio garantiza que las pruebas sigan siendo eficaces sin incurrir en costes innecesarios.

• Defina SKU utilizando la infraestructura como código (IaC). 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 despliega diferentes SKU. Un parámetro de entorno indica a la plantilla de Terraform que seleccione las SKU de desarrollo.

azd env set APP_ENVIRONMENT prod

Implementación del escalado automático

El autoescalado garantiza que una aplicación web siga siendo resistente, receptiva y capaz de administrar 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 autoescalado para escalar en función de métricas de rendimiento clave, de modo que su aplicación pueda administrar cargas variables.

• Refine los desencadenadores de escalado. Comience con la utilización de la CPU como desencadenador de escalado inicial si no está familiarizado con los requisitos de escalado de su aplicación. Perfeccione sus 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. Configure los umbrales de desencadenador para que se activen 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. Implementar la infraestructura como código a través de pipeline de integración continua y entrega continua (CI/CD). Azure dispone de plantillas Bicep, ARM (JSON) y Terraform prediseñadas para cada recurso 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 está trabajando con Azure DevOps o GitHub Actions 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.

• Adopte un marco de simulación. Para las pruebas que implican punto de conexión externo, utilice marcos de simulación. 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 se integran fácilmente 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. Utilice la autoinstrumentación en Azure Application Insights para recopilar telemetría de aplicaciones, como rendimiento de solicitudes, duración media de solicitudes, errores y supervisión de dependencias, sin cambios en el código. Spring Boot registra numerosas métricas principales en Application Insights, como la máquina virtual Java (JVM), la CPU, Tomcat y otros. Application Insights recopila automáticamente de plataformas de registro como Log4j y Logback. Por ejemplo, la implementación de referencia utiliza Application Insights habilitado a través de Terraform como parte de la configuración app_settings del App Service. (consulte el código siguiente).

  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 diagnósticos para todos los servicios compatibles y envíe diagnósticos al mismo destino que los registros de aplicaciones para su correlación. Los servicios 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 de App Service.

  # 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, destacando los cambios necesarios durante la fase de adopción inicial. Este ejemplo utiliza una aplicación de aplicación web de sistema de administración de cuentas de clientes (CAMS) para la empresa ficticia Contoso Fiber. Contoso Fiber estableció los siguientes objetivos para su aplicación web:

• Implementar cambios de código de bajo coste y alto valor
• Alcanzar un objetivo de nivel de servicio (SLO) del 99,9 %
• Adoptar las prácticas de DevOps
• Crear entornos con costes optimizados
• Mejorar la fiabilidad 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 forma más rentable de alcanzar sus objetivos inmediatos y futuros. La siguiente arquitectura 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.