Modèle d’application web fiable pour Java

Cet article fournit des conseils sur l’implémentation du modèle d’application web fiable. Ce modèle explique comment modifier (replatforming) des applications web pour la migration cloud. Il fournit des conseils normatifs en matière d’architecture, de code et de configuration, alignés sur les principes de Well-Architected Framework.

Pourquoi un modèle d’application web fiable pour Java ?

Le modèle d’application web fiable est un ensemble de principes et de techniques d’implémentation qui définissent la façon dont vous devez créer une nouvelle plateforme d’applications web lors de la migration vers le cloud. Il met l'accent sur les mises à jour minimales du code que vous devez effectuer pour tirer une expérience positive du cloud. Les conseils suivants utilisent l’implémentation de référence comme exemple tout au long du processus et suivent le parcours de replatforming de la société fictive, Contoso Fiber, pour fournir un contexte métier pour votre parcours. Avant d’implémenter le modèle d’application web fiable pour Java, Contoso Fiber disposait d’un système Customer Account Management System monolithique et local qui utilisait l’infrastructure Spring Boot.

Comment implémenter le modèle d’application web fiable

Cet article inclut l’architecture, le code et les instructions de configuration pour implémenter le modèle d’application web fiable. Utilisez les liens suivants pour accéder aux conseils spécifiques dont vous avez besoin :

• Contexte métier : alignez ces conseils sur votre contexte métier et apprenez à définir des objectifs immédiats et à long terme qui orientent les décisions de création de nouvelles plateformes.
• Conseils sur l’architecture : découvrez comment sélectionner les services cloud appropriés et concevoir une architecture qui répond aux besoins de votre entreprise.
• Conseils sur le code : implémentez trois modèles de conception pour améliorer la fiabilité et l’efficacité des performances de votre application web dans le cloud : nouvelles tentatives, disjoncteur et modèles cache-aside
• Conseils sur la configuration : configurez l’authentification et l’autorisation, les identités managées, les environnements bien dimensionnés, l’infrastructure en tant que code et la surveillance.

Le contexte métier

La première étape du replatforming d’une application web consiste à définir vos objectifs métier. Vous devez fixer des objectifs immédiats, tels que des objectifs de niveau de service et d’optimisation des coûts, ainsi que des objectifs futurs pour votre application web. Ces objectifs influencent votre choix de services cloud et l’architecture de votre application web dans le cloud. Définissez un SLO cible pour votre application web, par exemple un temps de disponibilité de 99,9 %. Calculez le contrat SLA composite pour tous les services qui affectent la disponibilité de votre application web.

Par exemple, Contoso Fiber souhaitait étendre son application web CAMS (Customer Account Management System) locale à d’autres régions. Pour répondre à la demande croissante de l'application web, elle s'est fixé les objectifs suivants :

• Appliquer des modifications de code à faible coût et à forte valeur ajoutée
• Atteindre un objectif de niveau de service (SLO) de 99,9 %
• Adopter des pratiques DevOps
• Créer des environnements à coût optimisé
• Améliorer la fiabilité et la sécurité

Contoso Fiber a déterminé que son infrastructure locale n'était pas une solution rentable pour mettre à l’échelle l’application. La société a donc décidé que la migration de son application web CAMS vers Azure était le moyen le plus rentable d'atteindre ses objectifs immédiats et futurs.

Conseils sur l’architecture

Le modèle d’application web fiable comporte quelques éléments architecturaux essentiels. Vous avez besoin d’un DNS pour gérer la résolution des points de terminaison, d’un pare-feu d’application web pour bloquer le trafic HTTP malveillant et d’un équilibreur de charge pour protéger et acheminer les demandes des utilisateurs entrantes. La plateforme d’application héberge votre code d’application web et effectue des appels à tous les services principaux via des points de terminaison privés dans un réseau virtuel. Un outil de surveillance des performances de l’application capture des métriques et des journaux pour comprendre votre application web.

Figure 1. Éléments architecturaux essentiels du modèle d’application web fiable.

Concevoir l’architecture

Concevez votre infrastructure pour prendre en charge vos métriques de récupération, notamment l’objectif de délai de récupération (RTO) et l’objectif de point de récupération (RPO). Le RTO affecte la disponibilité et doit prendre en charge votre SLO. Déterminez un objectif de point de récupération (RPO) et configurez la redondance des données pour satisfaire le RPO.

• Choisir la fiabilité de l’infrastructure. Déterminez le nombre de zones de disponibilité et de régions dont vous avez besoin pour répondre à vos besoins en la matière. Ajoutez des zones de disponibilité et des régions jusqu’à ce que le contrat SLA composite corresponde à votre SLO. Le modèle d’application web fiable prend en charge plusieurs régions pour une configuration active-active ou active-passive. Par exemple, l’implémentation de référence utilise une configuration active-passive pour satisfaire un SLO de 99,9 %.

  Pour une application web multirégion, configurez votre équilibreur de charge pour acheminer le trafic vers la deuxième région afin de prendre en charge une configuration active-active ou active-passive en fonction des besoins de votre entreprise. Les deux régions ont besoin des mêmes services, sauf que l’une d’entre elles dispose d’un réseau virtuel de type « hub » qui les relie. Adoptez une topologie de réseau hub-and-spoke pour centraliser et partager des ressources, comme un pare-feu réseau. Si vous avez des machines virtuelles, ajoutez un hôte bastion au réseau virtuel de type hub pour les gérer en toute sécurité (voir la figure 2).

  

  Figure 2 : Le modèle d’application web fiable avec une deuxième région et une topologie hub-and-spoke.

• Choisir une topologie de réseau. Choisissez la topologie de réseau adaptée à vos exigences web et de mise en réseau. Si vous envisagez d’avoir plusieurs réseaux virtuels, utilisez une topologie de réseau hub-and-spoke. Elle offre des avantages en termes de coût, de gestion et de sécurité grâce aux options de connectivité hybride aux réseaux locaux et virtuels.

Choisir les services Azure appropriés

Lorsque vous migrez une application web vers le cloud, vous devez sélectionner des services Azure qui répondent à vos exigences métier et s'alignent sur les fonctionnalités actuelles de l'application web locale. Cet alignement permet de réduire l'effort de replatforming. Par exemple, optez pour des services qui vous permettent de conserver le même moteur de base de données et de prendre en charge les middleware et frameworks existants. Les sections suivantes fournissent des conseils pour sélectionner les services Azure appropriés pour votre application web.

Par exemple, avant la migration vers le cloud, l’application web CAMS de Contoso Fiber était une application web Java monolithique locale. Il s’agit d’une application Spring Boot avec une base de données PostgreSQL. L’application web est une application d’assistance métier. Il est accessible aux employés. Les employés de Contoso Fiber utilisent l'application pour traiter les demandes d'assistance de leurs clients. L'application web souffrait de problèmes courants en matière d'évolutivité et de déploiement de fonctionnalités. Ce point de départ, les objectifs de l'entreprise et le SLO ont guidé le choix des services.

• Plateforme d’application : utilisez Azure App Service comme plateforme d’application. Contoso Fiber a choisi Azure App Service comme plateforme d’application pour les raisons suivantes :

  • Progression naturelle : Contoso Fiber a déployé un fichier jar Spring Boot sur son serveur local et souhaitait réduire la quantité de restructuration de ce modèle de déploiement. App Service fournit une prise en charge robuste de l’exécution d’applications Spring Boot, et il était dans la suite logique pour Contoso Fiber d'utiliser App Service. Azure Container Apps est également une alternative intéressante pour cette application. Pour plus d’informations, consultez Qu’est-ce qu’Azure Spring Apps et Vue d’ensemble de Java sur Azure Container Apps.
  • SLA élevé : il dispose d’un contrat SLA élevé qui répond aux exigences de l’environnement de production.
  • Charge de gestion réduite : il s’agit d’une solution d’hébergement entièrement managée.
  • Fonctionnalité de conteneurisation : App Service fonctionne avec des registres d’images de conteneur privés comme Azure Container Registry. Contoso Fiber peut utiliser ces registres pour conteneuriser l’application web à l’avenir.
  • Mise à l’échelle automatique : l’application web peut rapidement effectuer un scale-up, un scale-down, un scale-in et un scale-out en fonction du trafic utilisateur.

• Gestion des identités : utilisez Microsoft Entra ID comme solution de gestion des identités et des accès. Contoso Fiber a choisi Microsoft Entra ID pour les raisons suivantes :

  • Authentification et autorisation : L’application doit authentifier et autoriser les employés du centre d’appels.
  • Évolutivité : Il est mis à l’échelle pour prendre en charge des scénarios plus grands.
  • Contrôle d’identité utilisateur : Les employés du centre d’appels peuvent utiliser leurs identités d’entreprise existantes.
  • Prise en charge du protocole d’autorisation : Il prend en charge OAuth 2.0 pour les identités managées.

• Base de données : utilisez un service qui vous permet de conserver le même moteur de base de données. Utilisez l’arbre de décision de magasin de données. Contoso Fiber a choisi Azure Database pour PostgreSQL et l’option de serveur flexible pour les raisons suivantes :

  • Fiabilité : le modèle de déploiement de serveur flexible prend en charge la haute disponibilité redondante interzone sur plusieurs zones de disponibilité. Cette configuration maintient un serveur de secours actif dans une autre zone de disponibilité au sein de la même région Azure. La configuration réplique les données de manière synchrone sur le serveur de secours.
  • Réplication entre régions : il dispose d’une fonctionnalité de lecture réplica qui vous permet de répliquer de manière asynchrone des données vers une base de données réplica en lecture seule dans une autre région.
  • Performances : il fournit des performances prévisibles et un réglage intelligent pour améliorer les performances de votre base de données en utilisant des données d’utilisation réelles.
  • Charge de gestion réduite : il s’agit d’un service Azure entièrement managé qui réduit les obligations de gestion.
  • Prise en charge de la migration : il prend en charge la migration de bases de données à partir de bases de données PostgreSQL à serveur unique locaux. La société peut utiliser l'outil de migration pour simplifier le processus.
  • Cohérence avec les configurations locales : il prend en charge différentes versions communautaires de PostgreSQL, y compris la version que Contoso Fiber utilise actuellement.
  • Résilience. Le déploiement de serveur flexible crée automatiquement des sauvegardes de serveur et les conserve en utilisant un stockage redondant interzone (ZRS) dans la même région. Contoso Fiber peut restaurer sa base de données à n’importe quel instant dans le passé s’inscrivant dans la période de rétention des sauvegardes. La fonctionnalité de sauvegarde et de restauration offre un meilleur RPO (quantité acceptable de perte de données) que Contoso Fiber pourrait créer localement.

• Surveillance des performances des applications : utilisez Application Insights pour analyser les données de télémétrie sur votre application. Contoso Fiber a choisi d’utiliser Application Insights pour les raisons suivantes :

  • Intégration à Azure Monitor : Il offre la meilleure intégration à Azure Monitor.
  • Détection d’anomalies : Il détecte automatiquement les anomalies de performances.
  • Résolution des problèmes : Il vous aide à diagnostiquer les problèmes dans l’application en cours d’exécution.
  • Surveillance : Il collecte des informations sur la façon dont les utilisateurs utilisent l’application et vous permet de suivre facilement les événements personnalisés.
  • Manque de visibilité : La solution locale ne comportait pas de solution de surveillance des performances des applications. Application Insights offre une intégration facile à la plateforme et au code de l’application.

• Cache : choisissez si vous souhaitez ajouter du cache à votre architecture d’application web. Azure Cache pour Redis est la solution de cache principale d’Azure. Il s'agit d'un magasin de données managé en mémoire basé sur le logiciel Redis. Contoso Fiber a ajouté Azure Cache pour Redis pour les raisons suivantes :

  • Vitesse et volume : il offre un débit de données élevé et des lectures à faible latence pour les données couramment sollicitées et à variation lente.
  • Prise en charge diversifiée : il s’agit d’un emplacement de cache unifié que toutes les instances de l’application web peuvent utiliser.
  • Magasin de données externe. Les serveurs d’applications locaux ont effectué la mise en cache locale de la machine virtuelle. Cette configuration n’a pas déchargé les données très fréquentées et n’a pas pu invalider les données.
  • Sessions non persistantes : le cache permet à l’application web d’externaliser l’état de session et d’utiliser des sessions non persistantes. La plupart des applications web Java exécutées localement utilisent la mise en cache côté client en mémoire. En mémoire, la mise en cache côté client n’est pas correctement mise à l’échelle et augmente l’empreinte mémoire sur l’hôte. En utilisant Azure Cache pour Redis, Contoso Fiber dispose d’un service de cache évolutif entièrement managé pour améliorer la scalabilité et les performances de ses applications. Contoso Fiber utilisait une infrastructure d’abstraction de cache (Spring Cache) et n'a eu besoin que de changements de configuration minimes pour remplacer le fournisseur de cache. Cela leur a permis de passer d’un fournisseur Ehcache au fournisseur Redis.

• Équilibreur de charge : les applications web qui utilisent des solutions PaaS doivent utiliser Azure Front Door, Azure Application Gateway ou les deux en fonction de l’architecture et des exigences des applications web. Utilisez l’arbre de décision de l’équilibreur de charge pour choisir l’équilibreur de charge approprié. Contoso Fiber avait besoin d’un équilibreur de charge de couche 7 capable d’acheminer le trafic entre plusieurs régions. Contoso Fiber avait besoin d’une application web multirégion pour respecter le SLO de 99,9 %. Contoso Fiber a choisi Azure Front Door pour les raisons suivantes :

  • Équilibrage de charge global : Il s’agit d’un équilibreur de charge de couche 7 capable d'acheminer le trafic entre plusieurs régions.
  • Pare-feu d’applications web : Il s’intègre en mode natif à Azure Web Application Firewall.
  • Flexibilité du routage : Il permet à l’équipe de l’application de configurer les besoins d’entrée pour prendre en charge les modifications futures de l’application.
  • Accélération du trafic : Il utilise anycast pour atteindre le point de présence Azure le plus proche et trouver l’itinéraire le plus rapide vers l’application web.
  • Domaines personnalisés : Il prend en charge les noms de domaine personnalisés avec la validation de domaine flexible.
  • Sondes d’intégrité : L’application a besoin d’une surveillance intelligente à l’aide de sondes d’intégrité. Azure Front Door utilise alors les réponses fournies par la sonde pour identifier la « meilleure » origine vers lesquels acheminer les requêtes de vos clients.
  • Prise en charge de la surveillance : Il prend en charge des rapports intégrés avec un tableau de bord tout-en-un pour Front Door et pour les modèles de sécurité. Vous pouvez configurer des alertes qui s’intègrent à Azure Monitor. Il permet à l’application de journaliser chaque requête et les sondes d’intégrité ayant échoué.
  • Protection DDoS : Il dispose d’une protection DDoS de couche 3 à 4 intégrée.
  • Réseau de distribution de contenu : il permet à Contoso Fiber d’utiliser un réseau de distribution de contenu. Le réseau de diffusion de contenu assure l'accélération du site.

• Web application firewall : il utilise Azure Web Application Firewall pour protéger de manière centralisée contre les vulnérabilités et les attaques web courantes. Contoso Fiber a utilisé Azure Web Application Firewall pour les raisons suivantes :

  • Protection globale : Il offre une protection globale améliorée des applications web sans sacrifier les performances.
  • Protection contre les botnets : l’équipe peut surveiller et configurer des paramètres pour résoudre les problèmes de sécurité liés aux botnets.
  • Parité avec l’environnement local : La solution locale était exécutée derrière un pare-feu d’applications Web géré par le service informatique.
  • Facilité d’utilisation : Web Application Firewall s’intègre à Azure Front Door.

• Gestionnaire de secrets : il utilise Azure Key Vault si vous gérez des secrets dans Azure. Contoso Fiber a utilisé Key Vault pour les raisons suivantes :

  • Chiffrement : Il prend en charge le chiffrement au repos et en transit.
  • Prise en charge des identités managées : les services d’application peuvent utiliser des identités managées pour accéder au magasin de secrets.
  • Surveillance et journalisation : Il facilite l’accès à l’audit et génère des alertes lorsque les secrets stockés sont modifiés.
  • Intégration : Il fournit une intégration native avec le magasin de configuration Azure (App Configuration) et la plateforme d’hébergement web (App Service).

• Sécurité des points de terminaison : il utilise Azure Private Link pour accéder à des solutions de plateforme en tant que service via un point de terminaison privé sur votre réseau virtuel. Le trafic entre votre réseau virtuel et le service transite par le réseau principal de Microsoft. Contoso Fiber a choisi Liaison privée pour les raisons suivantes :

  • Communication de sécurité améliorée : Il permet à l’application d’accéder en privé aux services sur la plateforme Azure et réduit l’empreinte réseau des magasins de données pour aider à se protéger contre les fuites de données.
  • Effort minimal : Les points de terminaison privés prennent en charge la plateforme d’application web et la plateforme de base de données que l’application web utilise. Les deux plateformes reflètent les configurations locales existantes pour un minimum de modifications.

• Sécurité du réseau : il utilise Pare-feu Azure pour contrôler le trafic entrant et sortant au niveau du réseau. Il utilise Azure Bastion pour se connecter de manière sécurisée aux machines virtuelles sans exposer de ports RDP/SSH. Contoso Fiber a adopté une topologie de réseau hub-and-spoke et souhaitait placer les services de sécurité réseau partagés dans le hub. Le pare-feu Azure renforce la sécurité réseau en inspectant tout le trafic sortant des spokes. Contoso Fiber avait besoin d’Azure Bastion pour sécuriser les déploiements à partir d’un hôte de saut dans le sous-réseau DevOps.

Conseils sur le code

Pour réussir la migration d’une application web vers le cloud, vous devez mettre à jour le code de votre application web avec le modèle Nouvelle tentative, le modèle Disjoncteur et le modèle de conception Cache-Aside.

Figure 3. Rôle des modèles de conception.

Chaque modèle de conception offre des avantages en matière de charge de travail qui sont conformes à un ou plusieurs piliers de Well-Architected Framework. Voici une vue d’ensemble des modèles que vous devez implémenter :

1. Modèle Nouvelle tentative : : le modèle Nouvelle tentative permet de gérer les défaillances transitoires en relançant les opérations susceptibles d’échouer de manière intermittente. Implémentez ce modèle sur tous les appels sortants vers d’autres services Azure.

2. Modèle disjoncteur : le modèle Disjoncteur empêche une application de renouveler des opérations qui ne sont pas temporaires. Implémentez ce modèle sur tous les appels sortants vers d’autres services Azure.

3. Modèle Cache-Aside : le modèle Cache-Aside ajoute et récupère à partir d’un cache plus fréquemment qu’un magasin de données. Implémentez ce modèle sur les demandes adressées à la base de données.

Implémenter le modèle Nouvelle tentative

Ajoutez le modèle Nouvelle tentative à votre code d’application pour résoudre les interruptions de service temporaires. Ces interruptions sont appelées erreurs temporaires. Les erreurs temporaires se résolvent généralement en quelques secondes. Le modèle Nouvelle tentative vous permet de renvoyer des demandes ayant échoué. Il vous permet également de configurer les délais de demande et le nombre de tentatives avant l’échec.

Utilisez Resilience4j, une bibliothèque légère et de tolérance de panne, pour implémenter le modèle Nouvelle tentative dans Java. Par exemple, l’implémentation de référence ajoute le modèle Nouvelle tentative en décorant la méthode listServicePlans du contrôleur de plan de service avec des annotations Nouvelle tentative. En cas d'échec de l'appel initial, le code renouvelle l'appel à une liste des plans de service de la base de données. L’implémentation de référence configure la stratégie de nouvelles tentatives, y compris le nombre maximal de nouvelles tentatives, la durée d’attente et les exceptions à retenter. La stratégie de nouvelles tentatives est configurée dans 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";
    }

Implémenter le modèle Disjoncteur

Utilisez le modèle Disjoncteur pour gérer les interruptions de service qui ne sont pas des erreurs temporaires. Le modèle Disjoncteur empêche une application d'essayer continuellement d'accéder à un service qui ne répond pas. Il libère l’application et évite de gaspiller les cycles de processeur afin que l’application conserve son intégrité de performance pour les utilisateurs finaux.

Utilisez la documentation relative à Spring Circuit Breaker et Resilience4j pour implémenter le modèle Disjoncteur. Par exemple, l’implémentation de référence implémente le modèle Disjoncteur en décorant les méthodes avec l’attribut Disjoncteur.

Implémenter le modèle Cache-Aside

Ajoutez le modèle Cache-Aside à votre application web pour améliorer la gestion des données en mémoire. Ce modèle confie à l'application la responsabilité de traiter les requêtes de données et d'assurer la cohérence entre le cache et un stockage persistant, tel qu'une base de données. Il permet de diminuer les temps de réponse, d’améliorer le débit et de réduire la nécessité d’une mise à l’échelle plus importante. Il réduit également la charge sur le magasin de données principal, ce qui améliore la fiabilité et l’optimisation des coûts. Pour implémenter le modèle Cache-Aside, suivez les recommandations ci-dessous :

• Configurer l’application pour utiliser le cache. Pour activer la mise en cache, ajoutez le package spring-boot-starter-cache en tant que dépendance dans votre fichier pom.xml. Ce package fournit des configurations par défaut pour le cache Redis.

• Mettez en cache les données les plus nécessaires. Appliquez le modèle Cache-Aside sur les données les plus nécessaires pour augmenter son efficacité. Utilisez Azure Monitor pour effectuer le suivi du processeur, de la mémoire et du stockage de la base de données. Ces métriques vous aident à déterminer si vous pouvez utiliser une référence SKU de base de données plus petite après avoir appliqué le modèle Cache-Aside. Pour mettre en cache des données spécifiques dans votre code, ajoutez l’annotation @Cacheable. Cette annotation indique à Spring les méthodes dont les résultats doivent être mis en cache.

• Conservez les données du cache à jour. Planifiez des mises à jour régulières du cache pour le synchroniser avec les dernières modifications de la base de données. Déterminez la fréquence d’actualisation optimale en fonction de la volatilité des données et des besoins des utilisateurs. Cette pratique garantit que l'application utilise le modèle Cache-Aside pour fournir à la fois un accès rapide et des informations à jour. Les paramètres de cache par défaut peuvent ne pas convenir à votre application web. Vous pouvez personnaliser ces paramètres dans le fichier application.properties ou les variables d’environnement. Par exemple, vous pouvez modifier la valeur spring.cache.redis.time-to-live (exprimée en millisecondes) pour contrôler la durée pendant laquelle les données doivent rester dans le cache avant d’être supprimées.

• Garantir la cohérence des données. Implémentez des mécanismes pour mettre immédiatement à jour le cache après une opération d'écriture dans la base de données. Pour garantir la cohérence du cache, utilisez des mises à jour basées sur les événements ou des classes de gestion de données dédiées. La synchronisation cohérente du cache avec les modifications de la base de données est au cœur du modèle Cache-Aside.

Conseils sur la configuration

Les sections suivantes contiennent des conseils sur l’implémentation des mises à jour des configurations. Chaque section s’aligne sur un ou plusieurs piliers de Well-Architected Framework.

Configurer l’authentification et l’autorisation de l’utilisateur

Lorsque vous migrez des applications web vers Azure, configurez les mécanismes d’authentification et d’autorisation des utilisateurs. Suivez ces recommandations :

• Utilisez une plateforme d’identité. Utilisez la plateforme Microsoft Identity pour configurer l’authentification de l’application web. Cette plateforme prend en charge les applications qui utilisent un seul annuaire Microsoft Entra, plusieurs répertoires Microsoft Entra provenant de différentes organisations, ainsi que des identités Microsoft ou des comptes sociaux.

  Le Spring Boot Starter pour Microsoft Entra ID simplifie ce processus, en utilisant Spring Security et Spring Boot pour faciliter la configuration. Il offre des flux d’authentification variés, une gestion automatique des jetons et des stratégies d’autorisation personnalisables, ainsi que des fonctionnalités d’intégration avec les composants Spring Cloud. Ainsi, l'intégration de Microsoft Entra ID et d'OAuth 2.0 dans les applications Spring Boot est directe, sans configuration manuelle de la bibliothèque ou des paramètres.

  Par exemple, l’implémentation de référence utilise la plateforme d’identité Microsoft (Microsoft Entra ID) en tant que fournisseur d’identité pour l’application web. Il utilise l’octroi de code d’autorisation OAuth 2.0 pour connecter un utilisateur avec un compte Microsoft Entra. L’extrait de code XML suivant définit les deux dépendances requises du flux d’octroi de code d’autorisation OAuth 2.0. La dépendance com.azure.spring: spring-cloud-azure-starter-active-directory active l’authentification et l’autorisation Microsoft Entra dans une application Spring Boot. La dépendance org.springframework.boot: spring-boot-starter-oauth2-client prend en charge l’authentification et l’autorisation OAuth 2.0 dans une application 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>
  

• Créer une inscription d’application. Microsoft Entra ID nécessite d'inscrire une application dans le locataire principal. L’inscription de l’application garantit que les utilisateurs qui ont accès à l’application web possèdent des identités dans le locataire principal. Par exemple, l’implémentation de référence utilise Terraform pour créer une inscription d’application Microsoft Entra ID, ainsi qu’un rôle gestionnaire de comptes spécifique à l’application.

  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"
    }
  }
  

• Appliquez l’autorisation dans l’application. Utilisez des contrôles d’accès en fonction du rôle (RBAC) pour attribuer des privilèges moindres aux rôles d’application. Définissez des rôles spécifiques pour les différentes actions des utilisateurs afin d’éviter les chevauchements et de garantir la clarté. Mappez les utilisateurs aux rôles appropriés et assurez-vous qu’ils n’ont accès qu’aux ressources et aux actions nécessaires. Configurez Spring Security pour utiliser Spring Boot Starter pour Microsoft Entra ID. Cette bibliothèque permet l’intégration à Microsoft Entra ID et vous permet de vous assurer que les utilisateurs sont authentifiés en toute sécurité. La configuration et l’activation de la bibliothèque d’authentification Microsoft (MSAL) permettent d’accéder à d’autres fonctionnalités de sécurité. Ces fonctionnalités incluent la mise en cache des jetons et l’actualisation automatique des jetons.

  Par exemple, l’implémentation de référence crée des rôles d’application reflétant les types de rôles d’utilisateur du système de gestion des comptes de Contoso Fiber. Les rôles sont finalement traduits en autorisations pendant l’autorisation. Parmi les exemples de rôles spécifiques à l’application CAMS, citons le gestionnaire de comptes, le conseiller du support de niveau 1 (L1) et le représentant Field Service. Le rôle Gestionnaire de comptes dispose des autorisations nécessaires pour ajouter de nouveaux utilisateurs et clients à l'application. Un représentant Field Service peut créer des tickets de support. L’attribut PreAuthorize limite l’accès à des rôles spécifiques.

      @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";
      }
      ...
  

  Pour procéder à l’intégration avec Microsoft Entra ID, l’implémentation de référence utilise le flux d’octroi du code d’autorisation OAuth 2.0. Ce flux permet aux utilisateurs de se connecter avec un compte Microsoft. L’extrait de code suivant vous montre comment configurer SecurityFilterChain de manière à utiliser Microsoft Entra à des fins d’authentification et d’autorisation.

  @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();
      }
  }
  ...
  

• Préférez l’accès temporaire au stockage. Utilisez des autorisations temporaires pour vous protéger contre les accès non autorisés et les violations, telles que les signatures d’accès partagé (SAP). Utilisez des SAP de délégation d’utilisateur pour optimiser la sécurité lors de l’octroi d’un accès temporaire. Il s’agit de la seule SAP qui utilise les informations d’identification Microsoft Entra ID et ne nécessite pas de clé de compte de stockage permanente.

• Appliquez l’autorisation dans Azure. Utilisez Azure RBAC pour attribuer des privilèges moindres aux identités utilisateur. Azure RBAC détermine les ressources Azure auxquelles les identités ont accès, ce que ces utilisateurs peuvent en faire ainsi que les zones auxquelles ils ont accès.

• Évitez les autorisations permanentes avec élévation de privilèges. Utilisez Microsoft Entra Privileged Identity Management pour accorder un accès juste-à-temps pour les opérations privilégiées. Par exemple, les développeurs ont souvent besoin d’un accès au niveau administrateur pour créer/supprimer des bases de données, modifier des schémas de table et modifier les autorisations utilisateur. Avec l’accès juste-à-temps, les identités utilisateurs reçoivent des autorisations temporaires pour effectuer des tâches privilégiées.

Implémentation d’identités managées

Utilisez des identités managées pour tous les services Azure qui les prennent en charge. Une identité managée permet aux ressources Azure (identités de charge de travail) de s’authentifier et d’interagir avec d’autres services Azure sans gérer les informations d’identification. Les systèmes hybrides et hérités peuvent conserver des solutions d’authentification locales pour simplifier la migration, mais doivent passer aux identités managées dès que possible. Pour implémenter des identités managées, suivez ces recommandations :

• Choisir le type d’identité managée approprié. Préférez les identités managées affectées par l’utilisateur lorsque deux ressources Azure ou plus ont besoin du même ensemble d’autorisations. Cette configuration est plus efficace que la création d’identités managées affectées par le système pour chacune de ces ressources et l’attribution des mêmes autorisations à toutes ces ressources. Sinon, utilisez des identités managées affectées par le système.

• Configurer les moindres privilèges. Utilisez Azure RBAC pour accorder uniquement les autorisations indispensables aux opérations, telles que les actions CRUD dans les bases de données ou l’accès aux secrets. Les autorisations des identités de charge de travail sont persistantes, de sorte que vous ne pouvez pas octroyer des autorisations ponctuelles ou à court terme aux identités de charge de travail. Si Azure RBAC ne couvre pas un scénario spécifique, utilisez des politiques d’accès au niveau du service Azure en plus d’Azure RBAC.

• Sécuriser les secrets restants. Stockez les secrets restants dans Azure Key Vault. Chargez des secrets à partir de Key Vault au démarrage de l’application plutôt qu'à chaque requête HTTP. Les accès très fréquents dans le cadre de requêtes HTTP peuvent dépasser les limites de transaction Key Vault. Stockez les configurations d’application dans Azure App Configuration.

Environnements de taille appropriée

Utilisez les niveaux de performances (SKU) des services Azure qui répondent aux besoins de chaque environnement sans excès. Pour dimensionner correctement vos environnements, suivez ces recommandations :

• Estimer les coûts. Utilisez la Calculatrice de prix Azure pour estimer le coût de chaque environnement.

• Optimiser les coûts des environnements de production. Les environnements de production ont besoin de références SKU qui répondent aux contrats de niveau de service (SLA), aux fonctionnalités et à la mise à l’échelle nécessaires pour la production. Contrôlez en permanence l’utilisation des ressources et ajustez les références SKU pour les aligner sur les besoins réels en matière de performances.

• Optimiser les coûts des environnements de préproduction. Les environnements de préproduction doivent utiliser des ressources à moindre coût, désactiver les services inutiles et appliquer des remises telles que la Tarification Dev/Test Azure. Assurez-vous que les environnements de préproduction sont suffisamment similaires à ceux de production pour éviter d’introduire des risques. Cet équilibre permet de garantir l’efficacité des tests sans engendrer de coûts inutiles.

• Définissez des références SKU à l’aide de l’infrastructure en tant que code (IaC). Implémentez l’IaC pour sélectionner et déployer dynamiquement les références SKU appropriées en fonction de l’environnement. Cette approche améliore la cohérence et simplifie la gestion.

Par exemple, l’implémentation de référence a un paramètre facultatif qui déploie différentes références SKU. Un paramètre d’environnement indique au modèle Terraform de sélectionner des références SKU de développement.

azd env set APP_ENVIRONMENT prod

Implémenter la mise à l’échelle automatique

La mise à l’échelle automatique garantit la résilience, la réactivité et la capacité d’une application web à gérer efficacement des charges de travail dynamiques. Pour implémenter la mise à l’échelle automatique, suivez ces recommandations :

• Automatiser le scale-out. Utilisez la mise à l’échelle automatique Azure pour automatiser la mise à l’échelle horizontale dans les environnements de production. Configurez des règles de mise à l’échelle automatique pour effectuer un scale-out en fonction des métriques de performances clés, pour votre application puisse gérer des charges variables.

• Affiner les déclencheurs de mise à l’échelle. Si vous ne connaissez pas bien les exigences de votre application en matière de mise à l’échelle, commencez par l’utilisation du processeur comme premier déclencheur de mise à l’échelle. Affinez vos déclencheurs de mise à l’échelle pour inclure d’autres mesures telles que la mémoire vive, le débit du réseau et les E/S de disque. L’objectif est d’adapter le comportement de votre application web pour améliorer les performances.

• Fournissez une mise en mémoire tampon de scale-out. Définissez vos seuils de mise à l’échelle pour qu’ils se déclenchent avant d’atteindre la capacité maximale. Par exemple, configurez la mise à l’échelle pour qu’elle se produise à 85 % de l’utilisation du processeur plutôt que d’attendre qu’elle atteigne 100 %. Cette approche proactive permet de maintenir les performances et d’éviter les goulots d’étranglement potentiels.

Automatiser le déploiement de ressources

Utilisez l’automatisation pour déployer et mettre à jour des ressources et du code Azure dans tous les environnements. Suivez ces recommandations :

• Utilisez l’infrastructure en tant que code (IaC). Déployez l’infrastructure en tant que code via des pipelines d’intégration continue et de livraison continue (CI/CD). Azure dispose de modèles prédéfinis Bicep, ARM (JSON) et Terraform pour chaque ressource Azure.

• Utilisez un pipeline d’intégration continue/de déploiement continu (CI/CD). Utilisez un pipeline CI/CD pour déployer le code depuis le contrôle source vers vos différents environnements, tels que les tests, la préproduction et la production. Utilisez Azure Pipelines si vous utilisez Azure DevOps ou GitHub Actions pour les projets GitHub.

• Intégrez des tests unitaires. Octroyez la priorité à l’exécution et à la réussite de tous les tests unitaires au sein de votre pipeline avant tout déploiement vers App Services. Intégrez des outils de qualité et de couverture du code tels que SonarQube pour une couverture complète des tests.

• Adoptez le framework de simulation. Pour les tests impliquant des points de terminaison externes, utilisez des frameworks de simulation. Ces frameworks vous permettent de créer des points de terminaison simulés. Ils évitent d’avoir à configurer des points de terminaison externes réels et permettent de garantir des conditions de test uniformes dans les environnements.

• Effectuez des analyses de sécurité. Procédez à des tests statiques de sécurité des applications (SAST) pour détecter les failles de sécurité et les erreurs de codage dans votre code source. En outre, il convient de procéder à une analyse de composition logicielle (SCA) afin d'examiner les bibliothèques et composants tiers à la recherche de risques de sécurité. Les outils permettant ces analyses peuvent être facilement intégrés à GitHub et Azure DevOps.

Configuration de l’analyse

Implémentez la surveillance des applications et des plateformes pour améliorer l’excellence opérationnelle et l’efficacité des performances de votre application web. Pour implémenter la surveillance, suivez ces recommandations :

• Collecter les données de télémétrie des applications. Utilisez l’autoinstrumentation dans Azure Application Insights pour collecter des données de télémétrie des applications, telles que le débit de la requête, la durée moyenne des requêtes, les erreurs et la surveillance des dépendances, sans modification du code. Spring Boot enregistre plusieurs indicateurs de performance de base dans Application Insights, telles que la machine virtuelle Java (JVM), le processeur, Tomcat et d’autres. Application Insights collecte automatiquement à partir d’infrastructures de journalisation tels que Log4j et Logback. Par exemple, l’implémentation de référence utilise Application Insights activé via Terraform dans le cadre de la configuration app_settings d’App Service. (voir le code suivant).

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

  Pour plus d’informations, consultez l’article suivant :

  • Configurer Azure Monitor Application Insights pour Spring Boot
  • Azure Monitor Application Insights pour Java
  • Activer Azure Monitor OpenTelemetry pour les applications Java
  • Utilisation d’Azure Monitor Application Insights avec Spring Boot

• Créer des métriques d’application personnalisées. Implémenter l’instrumentation basée sur le code pour capturer la télémétrie des applications personnalisées en ajoutant le SDK Application Insights et en utilisant son API.

• Surveiller la plateforme. Activez les diagnostics pour tous les services pris en charge et envoyez des diagnostics à la même destination que les journaux d’activité de l’application pour la corrélation. Les services Azure créent automatiquement des journaux de plateforme, mais les stocke uniquement lorsque vous activez les diagnostics. Activez les paramètres de diagnostic pour chaque service qui prend en charge les diagnostics. L’implémentation de référence utilise Terraform pour activer les diagnostics Azure sur tous les services pris en charge. Le code Terraform suivant permet de configurer les paramètres de diagnostic pour 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
    }
  }
  

Déployer l’implémentation de référence

L’implémentation de référence guide les développeurs à travers une simulation de migration d’une application Java sur site vers Azure, en mettant en évidence les changements nécessaires au cours de la phase d’adoption initiale. Cet exemple utilise une application web CAMS (Customer Account Management System) pour la société fictive Contoso Fiber. Contoso Fiber a défini les objectifs suivants pour son application web :

• Implémenter des modifications de code à faible coût et à forte valeur ajoutée
• Atteindre un objectif de niveau de service (SLO) de 99,9 %
• Adopter des pratiques DevOps
• Créer des environnements à coût optimisé
• Améliorer la fiabilité et la sécurité

Contoso Fiber constate que son infrastructure locale ne permettait pas d’atteindre ces objectifs de manière rentable. La société a donc décidé que la migration de son application web CAMS vers Azure était le moyen le plus rentable d’atteindre ses objectifs immédiats et futurs. L’architecture suivante représente l’état final de l’implémentation du modèle d’application web fiable de Contoso Fiber.

Figure 4 : Architecture de l’implémentation de référence. Téléchargez un fichier Visio de cette architecture.