Modèle d’application web fiable pour Java

Azure App Service

Azure Front Door

Cet article fournit des conseils pour l’implémentation du modèle Reliable Web App. Ce modèle décrit comment modifier (replatformer) des applications web pour la migration cloud. Il fournit des conseils d’architecture, de code et de configuration préscriptifs alignés sur les principes des Azure Well-Architected Framework.

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

Le modèle Reliable Web App est un ensemble de principes et de techniques d’implémentation qui définissent la façon dont vous devez reformer les applications web lorsque vous les migrez vers le cloud. Il se concentre sur les mises à jour minimales du code que vous devez effectuer pour réussir dans le cloud. Les instructions suivantes utilisent une implémentation de référence comme exemple dans l’ensemble. Il suit le parcours replatforme de la société fictive Contoso Fibre pour fournir un contexte métier pour votre parcours. Avant d’implémenter le modèle Reliable Web App pour Java, Contoso Fibre disposait d’un système de gestion de compte client local (CAMS) monolithique qui utilisait l’infrastructure Spring Boot.

Conseil

Il existe une implémentation de référence (exemple) du modèle d’application web fiable. Il représente l’état final de l’implémentation Reliable Web App. Il s’agit d’une application web de niveau production qui présente toutes les mises à jour du code, de l’architecture et de la configuration dont il est question dans cet article. Déployez et utilisez l’implémentation de référence pour guider votre implémentation du modèle d’application web fiable.

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

Cet article inclut des instructions d’architecture, de code et de configuration pour l’implémentation du modèle Reliable Web App. Utilisez les liens suivants pour accéder aux conseils spécifiques dont vous avez besoin :

• contexte métier. Aligner ces conseils sur votre contexte métier et apprendre à définir des objectifs immédiats et à long terme qui favorisent la replatformation des décisions.
• 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émenter trois modèles de conception pour améliorer la fiabilité et l’efficacité des performances de votre application web dans le cloud : les modèles Nouvelle tentative, Disjoncteur et Cache-Aside.
• conseils de configuration . Configurer l’authentification et l’autorisation, les identités managées, les environnements avec droits, 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 définir des objectifs immédiats, tels que des objectifs de niveau de service (SLO) et des cibles 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, 99,9% temps d’activité). Calculez le contrat SLA composite pour tous les services qui affectent la disponibilité de votre application web.

Par exemple, Contoso Fibre souhaitait développer son application web CAMS locale pour atteindre d’autres régions. Pour répondre à la demande croissante de l'application web, elle s'est fixé les objectifs suivants :

• Appliquez des modifications de code à faible coût et à valeur élevée.
• Atteignez un SLO de 99,9%.
• Adoptez les pratiques DevOps.
• Créez des environnements optimisés pour les coûts.
• Améliorez 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. Ils ont décidé que la migration de leur application web CAMS vers Azure était le moyen le plus rentable d’atteindre leurs 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 de DNS pour gérer la résolution des points de terminaison, un pare-feu d’applications web pour bloquer le trafic HTTP malveillant et un équilibreur de charge pour acheminer et protéger les demandes des utilisateurs entrants. 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 des applications capture les métriques et les journaux pour vous aider à 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 , comme votre objectif de délai de récupération (RTO) et votre objectif de point de récupération (RPO). Le RTO affecte la disponibilité et doit prendre en charge votre SLO. Déterminez un RPO et configurez redondance des données pour répondre au 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 matière de disponibilité. 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 pour prendre en charge une configuration active-active ou active-passive, en fonction des besoins de votre entreprise. Les deux régions nécessitent les mêmes services, sauf qu’une région possède un réseau virtuel hub qui connecte les régions. 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 hub pour les gérer avec une sécurité renforcée. (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’utiliser plusieurs réseaux virtuels, utilisez une topologie de réseau hub-and-spoke . Il offre des avantages en matière de coût, de gestion et de sécurité et des options de connectivité hybride aux réseaux locaux et virtuels.

Choisir les services Azure appropriés

Lorsque vous déplacez une application web vers le cloud, vous devez choisir des services Azure qui répondent à vos besoins métier et s’aligner sur les fonctionnalités de l’application web locale. Cet alignement permet de réduire l’effort de reformation. 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 son déplacement 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 Fibre a choisi Azure App Service comme plateforme d’application pour les raisons suivantes :

  • Progression naturelle. Contoso Fibre a déployé un fichier Spring Boot jar sur son serveur local et a voulu réduire la quantité de réarchitecture pour 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 Présentation d’Azure Container Apps et Java sur Azure Container Apps.
  • Contrat SLA élevé. App Service fournit un contrat SLA élevé qui répond aux exigences de l’environnement de production.
  • Réduction de la surcharge de gestion. App Service est une solution d’hébergement entièrement managée.
  • Fonctionnalité de conteneurisation. App Service fonctionne avec des registres d’images 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-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.
  • Scalabilité. Microsoft Entra ID est mis à l’échelle pour prendre en charge des scénarios plus volumineux.
  • 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. Microsoft Entra ID 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 magasin de données pour guider votre sélection. Contoso Fibre a choisi Azure Database pour PostgreSQL et le modèle de déploiement 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 interrégion. Azure Database pour PostgreSQL fournit une fonctionnalité de réplica en lecture 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.
  • Rendement. Azure Database pour PostgreSQL fournit des performances prévisibles et un réglage intelligent qui améliore les performances de votre base de données à l’aide de données d’utilisation réelles.
  • Réduction de la surcharge de gestion. Il s’agit d’un service Azure entièrement géré qui réduit les obligations de gestion.
  • Prise en charge de la migration. Il prend en charge la migration de base de données à partir de bases de données PostgreSQL à serveur unique local. Contoso peut utiliser l’outil de migration pour simplifier le processus de migration.
  • Cohérence avec les configurations locales. Il prend en charge différentes versions de la communauté de PostgreSQL, y compris la version utilisée actuellement par Contoso Fiber.
  • Résilience. Le déploiement de serveur flexible crée automatiquement des sauvegardes de serveur et les stocke dans le stockage redondant interzone (ZRS) dans la même région. Contoso peut restaurer sa base de données à n’importe quel point dans le temps qui se trouve dans la période de rétention de sauvegarde. 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 des anomalies. Il détecte automatiquement les anomalies de performances.
  • Dépannage. 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.
  • Écart de visibilité. La solution locale n’a pas de solution de supervision des performances des applications. Application Insights offre une intégration facile à la plateforme et au code de l’application.

• Cache : Choisir d’ajouter un cache à votre architecture d’application web. cache Azure pour Redis est la solution de cache Azure principale. Il s’agit d’un magasin de données en mémoire géré basé sur le logiciel Redis. Contoso Fibre a ajouté le cache Azure pour Redis pour les raisons suivantes :

  • Vitesse et volume. Il fournit 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 rouges. Le cache permet à l’application web de externaliser l’état de session et d’utiliser des sessions non rouges. La plupart des applications web Java qui s’exécutent localement utilisent la mise en cache côté client en mémoire. La mise en cache côté client en mémoire n’est pas correctement mise à l’échelle et augmente l’empreinte mémoire sur l’hôte. Avec Azure Cache pour Redis, Contoso Fibre dispose d’un service de cache entièrement managé et évolutif pour améliorer la scalabilité et les performances de leurs applications. Contoso utilise une infrastructure d’abstraction de cache (Spring Cache) et ne nécessite que des modifications de configuration minimales pour échanger 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 (Platform as a Service) doivent utiliser Azure Front Door, Azure Application Gateway ou les deux, en fonction de l’architecture et des exigences de l’application web. Utilisez l’arbre de décision de l’équilibreur de charge pour choisir l’équilibreur de charge approprié. Contoso Fibre avait besoin d’un équilibreur de charge de couche 7 qui pouvait acheminer le trafic entre plusieurs régions et une application web multirégion pour répondre au SLO de 99,9%. Contoso a choisi Azure Front Door pour les raisons suivantes :

  • Équilibrage de charge global. Il s’agit d’un équilibreur de charge de couche 7 qui peut acheminer le trafic entre plusieurs régions.
  • Pare-feu d’applications web. Il s’intègre en mode natif avec le pare-feu d’applications web Azure.
  • Flexibilité du routage. Elle permet à l’équipe d’application de configurer les besoins d’entrée pour prendre en charge les modifications futures dans 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 une validation de domaine flexible.
  • Sondes de santé. L’application a besoin d’une surveillance intelligente des 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. Azure Front Door prend en charge les rapports intégrés avec un tableau de bord tout-en-un pour les modèles de sécurité et Azure Front Door. Vous pouvez configurer des alertes qui s’intègrent à Azure Monitor. Azure Front Door permet à l’application de consigner chaque requête et les sondes d’intégrité ayant échoué.
  • Protection DDoS. Il dispose d’une protection DDoS intégrée de couche 3 à 4.
  • Réseau de distribution de contenu. Il positionne Contoso Fibre pour 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 améliorée des applications web globales sans sacrifier les performances.
  • Protection botnet. L’équipe peut surveiller et configurer les paramètres pour répondre aux problèmes de sécurité liés aux botnets.
  • Parité avec local. La solution locale s’est exécutée derrière un pare-feu d’applications web géré par l’informatique.
  • Facilité d’utilisation. Le pare-feu d’applications web 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. Key Vault facilite l’accès à l’audit et génère des alertes lorsque les secrets stockés changent.
  • Intégration. Key Vault fournit une intégration native au magasin de configuration Azure (Azure App Configuration) et à la plateforme d’hébergement web (App Service).

• Sécurité du point de terminaison : Utilisez Azure Private Link pour accéder aux solutions PaaS sur un point de terminaison privé dans 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 améliorée en matière de sécurité. 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 vous 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, de sorte qu’une modification minimale est requise.

• Sécurité du réseau : il utilise Pare-feu Azure pour contrôler le trafic entrant et sortant au niveau du réseau. Utilisez Azure Bastion pour vous connecter à des machines virtuelles avec une sécurité renforcée, sans exposer les ports RDP/SSH. Contoso Fibre a adopté une topologie de réseau hub-and-spoke et voulait 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 Fibre a besoin d’Azure Bastion pour des déploiements de sécurité améliorés à partir d’un hôte de rebond dans le sous-réseau DevOps.

Conseils sur le code

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

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

Chaque modèle de conception offre des avantages de conception de charge de travail qui s’alignent sur un ou plusieurs piliers de l’infrastructure Well-Architected. Voici une vue d’ensemble des modèles que vous devez implémenter :

1. Modèle de nouvelle tentative. Le modèle Nouvelle tentative gère les échecs temporaires en retenant des opérations susceptibles d’échouer par intermittence. 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 réessayer 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 charge les données à la demande dans un cache à partir d’un magasin de données. Implémentez ce modèle sur les demandes adressées à la base de données.

Modèle de conception	Fiabilité (RE)	Sécurité (SE)	Optimisation des coûts (CO)	Excellence opérationnelle (OE)	Efficacité des performances (PE)	Prise en charge des principes de WAF
Modèle Nouvelle tentative	✔					RE :07
Modèle Disjoncteur	✔				✔	RE :03 RE :07 PE :07 PE :11
Modèle Cache-Aside	✔				✔	RE :05 PE :08 PE :12

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 le délai entre les nouvelles tentatives et le nombre de tentatives à effectuer avant l’échec de concédage.

Utilisez Resilience4j, une bibliothèque de tolérance de panne légère, pour implémenter le modèle Nouvelle tentative en Java. 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 Retry. 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. La stratégie de nouvelle tentative pour l’implémentation de référence inclut les tentatives maximales, 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 empêche la perte de cycles du processeur afin que l’application conserve son intégrité des performances pour les utilisateurs finaux.

Utilisez Spring Cloud Circuit Breaker et Resilience4j pour implémenter le modèle Disjoncteur. 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. Le modèle affecte à l’application la responsabilité de gérer les demandes de données et de garantir la cohérence entre le cache et le stockage persistant, comme 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. Elle 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 à haut besoin pour améliorer 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 spécifie à Spring quelles méthodes doivent avoir leurs résultats 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. Utilisez la volatilité des données et l’utilisateur doit déterminer le taux d’actualisation optimal. Cette pratique garantit que l’application utilise le modèle Cache-Aside pour fournir un accès rapide et des informations actuelles. 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 (exprimée en millisecondes) pour contrôler la spring.cache.redis.time-to-live durée pendant laquelle les données doivent rester dans le cache avant de les supprimer.

• 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 fournissent des conseils sur l’implémentation des mises à jour de configuration. Chaque section s’aligne sur un ou plusieurs piliers de Well-Architected Framework.

Paramétrage	Fiabilité (RE)	Sécurité (SE)	Optimisation des coûts (CO)	Excellence opérationnelle (OE)	Efficacité des performances (PE)	Prise en charge des principes de WAF
Configurer l’authentification et l’autorisation de l’utilisateur		✔		✔		SE :05 OE :10
Implémentation d’identités managées		✔		✔		SE :05 OE :10
Dimensionnement des environnements Rightsize			✔			CO :05 CO :06
Implémenter la mise à l’échelle automatique	✔		✔		✔	RE :06 CO :12 PE :05
Automatiser le déploiement de ressources				✔		OE :05
Implémenter la supervision			✔	✔	✔	OE :07 PE :04

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.

  Spring Boot Starter pour Microsoft Entra ID simplifie ce processus. Il utilise Spring Security et Spring Boot pour garantir une configuration facile. Il fournit différents flux d’authentification, gestion automatique des jetons, stratégies d’autorisation personnalisables et fonctionnalités d’intégration avec les composants Spring Cloud. Ce service permet une intégration simple de Microsoft Entra ID et OAuth 2.0 aux applications Spring Boot sans configuration manuelle de bibliothèque ou de paramètres.

  L’implémentation de référence utilise la plateforme d’identités Microsoft (MICROSOFT Entra ID) comme 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 active 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éez une inscription d’application. Microsoft Entra ID nécessite d'inscrire une application dans le locataire principal. L’inscription de l’application permet de s’assurer que les utilisateurs qui accèdent à l’application web ont des identités dans le locataire principal. L’implémentation de référence utilise Terraform pour créer une inscription d’application Microsoft Entra ID avec 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 le contrôle d’accès en fonction du rôle (RBAC) pour attribuer des privilèges minimum 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 ont accès uniquement aux ressources et actions nécessaires. Configurez Spring Security pour utiliser Spring Boot Starter pour Microsoft Entra ID. Cette bibliothèque permet l’intégration à l’ID Microsoft Entra 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.

  L’implémentation de référence crée des rôles d’application qui reflètent les types de rôles d’utilisateur dans le 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 dans CAMS, citons le gestionnaire de comptes, le représentant de support de niveau 1 (L1) et le représentant du service de champ. 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 montre comment configurer l’ID SecurityFilterChain Microsoft Entra pour l’authentification et l’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 protéger contre les accès et violations non autorisés. Par exemple, vous pouvez utiliser signatures d’accès partagé (SAP) pour limiter l’accès à une période donnée. Utilisez la SAP de délégation d’utilisateur pour optimiser la sécurité lorsque vous accordez 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éfinit les ressources Azure auxquelles les identités peuvent accéder, ce qu’elles peuvent faire avec ces ressources et les zones auxquelles elles 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. Lorsque vous utilisez l’accès juste-à-temps, les identités utilisateur reçoivent des autorisations temporaires pour effectuer des tâches privilégiées.

Implémentation d’identités managées

Utilisez 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 avoir à gérer les informations d’identification. Pour simplifier la migration, vous pouvez continuer à utiliser des solutions d’authentification locales pour les systèmes hybrides et hérités, mais vous devez les transférer vers des 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 approche 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 RBAC Azure pour accorder uniquement des autorisations critiques pour les 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.

• Fournissez une sécurité pour 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.

Dimensionnement des environnements Rightsize

Utilisez des niveaux de performances (SKU) des services Azure qui répondent aux besoins de chaque environnement sans les dépasser. Pour rightsiser vos environnements, suivez ces recommandations :

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

• Environnements de production à optimisation des coûts. 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.

• environnements de préproduction d’optimisation du coût.environnements de préproduction devez utiliser des ressources à moindre coût et tirer parti des remises telles que tarification Azure Dev/Test. Dans ces environnements, vous devez désactiver les services qui ne sont pas nécessaires. En même temps, assurez-vous que environnements de préproduction sont suffisamment similaires aux environnements de production pour éviter d’introduire des risques. Le maintien de cet équilibre garantit que les tests restent efficaces sans entraîner de coûts inutiles.

• Utilisez l’infrastructure en tant que code (IaC) pour définir des références SKU. 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 spécifie la référence SKU à déployer. Un paramètre d’environnement spécifie que le modèle Terraform doit déployer 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 permet de garantir qu’une application web reste résiliente, réactive et capable de gérer efficacement les 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 afin que votre application puisse gérer des charges variables.

• Affiner les déclencheurs de mise à l’échelle. Utilisez l’utilisation du processeur comme déclencheur de mise à l’échelle initial si vous n’êtes pas familiarisé avec les exigences de mise à l’échelle de votre application. Affinez vos déclencheurs de mise à l’échelle pour inclure d’autres métriques telles que la RAM, le débit 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 que la capacité maximale soit atteinte. 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 infrastructure en tant que code à l’aide de pipelines d’intégration et de livraison continue (CI/CD). Azure fournit des 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. Utilisez 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 des frameworks fictifs. Pour les tests impliquant des points de terminaison externes, utilisez des frameworks fictifs. 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é. Utilisez des tests de sécurité d’application statiques (SAST) pour rechercher des failles de sécurité et des 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 pour ces analyses sont faciles à intégrer à 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 d’autoinstrumentation dans Azure Application Insights pour collecter des de télémétrie d’application, telles que le débit de requête, la durée moyenne des requêtes, les erreurs et la surveillance des dépendances. Vous n’avez pas besoin de modifier le code pour utiliser cette télémétrie. Spring Boot inscrit plusieurs métriques principales dans Application Insights, comme la machine virtuelle Java (JVM), le processeur, Tomcat et d’autres. Application Insights collecte automatiquement à partir de frameworks de journalisation tels que Log4j et Logback.

  L’implémentation de référence utilise Application Insights, qui est activée via Terraform dans la configuration d’App app_settings Service :

  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. 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 stockent 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 configure les paramètres de diagnostic du service d’application :

  # 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 via une migration simulée d’une application Java locale vers Azure, mettant en évidence les modifications nécessaires pendant la phase d’adoption initiale. Cet exemple utilise une application web CAMS pour la société fictive Contoso Fibre. Contoso Fibre a défini les objectifs suivants pour l’application web :

• Implémentez des modifications de code à faible coût et à valeur élevée.
• Obtenez un SLO de 99,9%.
• Adoptez les pratiques DevOps.
• Créez des environnements optimisés pour les coûts.
• Améliorez la fiabilité et la sécurité.

Contoso Fiber constate que son infrastructure locale ne permettait pas d’atteindre ces objectifs de manière rentable. Ils ont décidé que la migration de leur application web CAMS vers Azure était le moyen le plus rentable d’atteindre leurs objectifs immédiats et futurs. L’architecture suivante représente l’état final de l’implémentation du modèle Reliable Web App de Contoso Fiber.

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

Implémentation de référence

Cet article fournit des conseils pour l’implémentation du modèle Reliable Web App. Ce modèle décrit comment modifier (replatformer) des applications web pour la migration cloud. Il fournit des conseils d’architecture, de code et de configuration préscriptifs alignés sur les principes des Azure Well-Architected Framework.

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

Le modèle Reliable Web App est un ensemble de principes et de techniques d’implémentation qui définissent la façon dont vous devez reformer les applications web lorsque vous les migrez vers le cloud. Il se concentre sur les mises à jour minimales du code que vous devez effectuer pour réussir dans le cloud. Les instructions suivantes utilisent une implémentation de référence comme exemple dans l’ensemble. Il suit le parcours replatforme de la société fictive Contoso Fibre pour fournir un contexte métier pour votre parcours. Avant d’implémenter le modèle Reliable Web App pour Java, Contoso Fibre disposait d’un système de gestion de compte client local (CAMS) monolithique qui utilisait l’infrastructure Spring Boot.

Conseil

Il existe une implémentation de référence (exemple) du modèle d’application web fiable. Il représente l’état final de l’implémentation Reliable Web App. Il s’agit d’une application web de niveau production qui présente toutes les mises à jour du code, de l’architecture et de la configuration dont il est question dans cet article. Déployez et utilisez l’implémentation de référence pour guider votre implémentation du modèle d’application web fiable.

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

Cet article inclut des instructions d’architecture, de code et de configuration pour l’implémentation du modèle Reliable Web App. Utilisez les liens suivants pour accéder aux conseils spécifiques dont vous avez besoin :

• contexte métier. Aligner ces conseils sur votre contexte métier et apprendre à définir des objectifs immédiats et à long terme qui favorisent la replatformation des décisions.
• 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émenter trois modèles de conception pour améliorer la fiabilité et l’efficacité des performances de votre application web dans le cloud : les modèles Nouvelle tentative, Disjoncteur et Cache-Aside.
• conseils de configuration . Configurer l’authentification et l’autorisation, les identités managées, les environnements avec droits, 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 définir des objectifs immédiats, tels que des objectifs de niveau de service (SLO) et des cibles 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, 99,9% temps d’activité). Calculez le contrat SLA composite pour tous les services qui affectent la disponibilité de votre application web.

Par exemple, Contoso Fibre souhaitait développer son application web CAMS locale pour atteindre d’autres régions. Pour répondre à la demande croissante de l'application web, elle s'est fixé les objectifs suivants :

• Appliquez des modifications de code à faible coût et à valeur élevée.
• Atteignez un SLO de 99,9%.
• Adoptez les pratiques DevOps.
• Créez des environnements optimisés pour les coûts.
• Améliorez 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. Ils ont décidé que la migration de leur application web CAMS vers Azure était le moyen le plus rentable d’atteindre leurs 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 de DNS pour gérer la résolution des points de terminaison, un pare-feu d’applications web pour bloquer le trafic HTTP malveillant et un équilibreur de charge pour acheminer et protéger les demandes des utilisateurs entrants. 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 des applications capture les métriques et les journaux pour vous aider à 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 , comme votre objectif de délai de récupération (RTO) et votre objectif de point de récupération (RPO). Le RTO affecte la disponibilité et doit prendre en charge votre SLO. Déterminez un RPO et configurez redondance des données pour répondre au 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 matière de disponibilité. 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 pour prendre en charge une configuration active-active ou active-passive, en fonction des besoins de votre entreprise. Les deux régions nécessitent les mêmes services, sauf qu’une région possède un réseau virtuel hub qui connecte les régions. 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 hub pour les gérer avec une sécurité renforcée. (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’utiliser plusieurs réseaux virtuels, utilisez une topologie de réseau hub-and-spoke . Il offre des avantages en matière de coût, de gestion et de sécurité et des options de connectivité hybride aux réseaux locaux et virtuels.

Choisir les services Azure appropriés

Lorsque vous déplacez une application web vers le cloud, vous devez choisir des services Azure qui répondent à vos besoins métier et s’aligner sur les fonctionnalités de l’application web locale. Cet alignement permet de réduire l’effort de reformation. 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 son déplacement 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 Fibre a choisi Azure App Service comme plateforme d’application pour les raisons suivantes :

  • Progression naturelle. Contoso Fibre a déployé un fichier Spring Boot jar sur son serveur local et a voulu réduire la quantité de réarchitecture pour 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 Présentation d’Azure Container Apps et Java sur Azure Container Apps.
  • Contrat SLA élevé. App Service fournit un contrat SLA élevé qui répond aux exigences de l’environnement de production.
  • Réduction de la surcharge de gestion. App Service est une solution d’hébergement entièrement managée.
  • Fonctionnalité de conteneurisation. App Service fonctionne avec des registres d’images 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-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.
  • Scalabilité. Microsoft Entra ID est mis à l’échelle pour prendre en charge des scénarios plus volumineux.
  • 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. Microsoft Entra ID 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 magasin de données pour guider votre sélection. Contoso Fibre a choisi Azure Database pour PostgreSQL et le modèle de déploiement 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 interrégion. Azure Database pour PostgreSQL fournit une fonctionnalité de réplica en lecture 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.
  • Rendement. Azure Database pour PostgreSQL fournit des performances prévisibles et un réglage intelligent qui améliore les performances de votre base de données à l’aide de données d’utilisation réelles.
  • Réduction de la surcharge de gestion. Il s’agit d’un service Azure entièrement géré qui réduit les obligations de gestion.
  • Prise en charge de la migration. Il prend en charge la migration de base de données à partir de bases de données PostgreSQL à serveur unique local. Contoso peut utiliser l’outil de migration pour simplifier le processus de migration.
  • Cohérence avec les configurations locales. Il prend en charge différentes versions de la communauté de PostgreSQL, y compris la version utilisée actuellement par Contoso Fiber.
  • Résilience. Le déploiement de serveur flexible crée automatiquement des sauvegardes de serveur et les stocke dans le stockage redondant interzone (ZRS) dans la même région. Contoso peut restaurer sa base de données à n’importe quel point dans le temps qui se trouve dans la période de rétention de sauvegarde. 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 des anomalies. Il détecte automatiquement les anomalies de performances.
  • Dépannage. 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.
  • Écart de visibilité. La solution locale n’a pas de solution de supervision des performances des applications. Application Insights offre une intégration facile à la plateforme et au code de l’application.

• Cache : Choisir d’ajouter un cache à votre architecture d’application web. cache Azure pour Redis est la solution de cache Azure principale. Il s’agit d’un magasin de données en mémoire géré basé sur le logiciel Redis. Contoso Fibre a ajouté le cache Azure pour Redis pour les raisons suivantes :

  • Vitesse et volume. Il fournit 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 rouges. Le cache permet à l’application web de externaliser l’état de session et d’utiliser des sessions non rouges. La plupart des applications web Java qui s’exécutent localement utilisent la mise en cache côté client en mémoire. La mise en cache côté client en mémoire n’est pas correctement mise à l’échelle et augmente l’empreinte mémoire sur l’hôte. Avec Azure Cache pour Redis, Contoso Fibre dispose d’un service de cache entièrement managé et évolutif pour améliorer la scalabilité et les performances de leurs applications. Contoso utilise une infrastructure d’abstraction de cache (Spring Cache) et ne nécessite que des modifications de configuration minimales pour échanger 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 (Platform as a Service) doivent utiliser Azure Front Door, Azure Application Gateway ou les deux, en fonction de l’architecture et des exigences de l’application web. Utilisez l’arbre de décision de l’équilibreur de charge pour choisir l’équilibreur de charge approprié. Contoso Fibre avait besoin d’un équilibreur de charge de couche 7 qui pouvait acheminer le trafic entre plusieurs régions et une application web multirégion pour répondre au SLO de 99,9%. Contoso a choisi Azure Front Door pour les raisons suivantes :

  • Équilibrage de charge global. Il s’agit d’un équilibreur de charge de couche 7 qui peut acheminer le trafic entre plusieurs régions.
  • Pare-feu d’applications web. Il s’intègre en mode natif avec le pare-feu d’applications web Azure.
  • Flexibilité du routage. Elle permet à l’équipe d’application de configurer les besoins d’entrée pour prendre en charge les modifications futures dans 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 une validation de domaine flexible.
  • Sondes de santé. L’application a besoin d’une surveillance intelligente des 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. Azure Front Door prend en charge les rapports intégrés avec un tableau de bord tout-en-un pour les modèles de sécurité et Azure Front Door. Vous pouvez configurer des alertes qui s’intègrent à Azure Monitor. Azure Front Door permet à l’application de consigner chaque requête et les sondes d’intégrité ayant échoué.
  • Protection DDoS. Il dispose d’une protection DDoS intégrée de couche 3 à 4.
  • Réseau de distribution de contenu. Il positionne Contoso Fibre pour 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 améliorée des applications web globales sans sacrifier les performances.
  • Protection botnet. L’équipe peut surveiller et configurer les paramètres pour répondre aux problèmes de sécurité liés aux botnets.
  • Parité avec local. La solution locale s’est exécutée derrière un pare-feu d’applications web géré par l’informatique.
  • Facilité d’utilisation. Le pare-feu d’applications web 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. Key Vault facilite l’accès à l’audit et génère des alertes lorsque les secrets stockés changent.
  • Intégration. Key Vault fournit une intégration native au magasin de configuration Azure (Azure App Configuration) et à la plateforme d’hébergement web (App Service).

• Sécurité du point de terminaison : Utilisez Azure Private Link pour accéder aux solutions PaaS sur un point de terminaison privé dans 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 améliorée en matière de sécurité. 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 vous 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, de sorte qu’une modification minimale est requise.

• Sécurité du réseau : il utilise Pare-feu Azure pour contrôler le trafic entrant et sortant au niveau du réseau. Utilisez Azure Bastion pour vous connecter à des machines virtuelles avec une sécurité renforcée, sans exposer les ports RDP/SSH. Contoso Fibre a adopté une topologie de réseau hub-and-spoke et voulait 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 Fibre a besoin d’Azure Bastion pour des déploiements de sécurité améliorés à partir d’un hôte de rebond dans le sous-réseau DevOps.

Conseils sur le code

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

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

Chaque modèle de conception offre des avantages de conception de charge de travail qui s’alignent sur un ou plusieurs piliers de l’infrastructure Well-Architected. Voici une vue d’ensemble des modèles que vous devez implémenter :

1. Modèle de nouvelle tentative. Le modèle Nouvelle tentative gère les échecs temporaires en retenant des opérations susceptibles d’échouer par intermittence. 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 réessayer 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 charge les données à la demande dans un cache à partir d’un magasin de données. Implémentez ce modèle sur les demandes adressées à la base de données.

Modèle de conception	Fiabilité (RE)	Sécurité (SE)	Optimisation des coûts (CO)	Excellence opérationnelle (OE)	Efficacité des performances (PE)	Prise en charge des principes de WAF
Modèle Nouvelle tentative	✔					RE :07
Modèle Disjoncteur	✔				✔	RE :03 RE :07 PE :07 PE :11
Modèle Cache-Aside	✔				✔	RE :05 PE :08 PE :12

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 le délai entre les nouvelles tentatives et le nombre de tentatives à effectuer avant l’échec de concédage.

Utilisez Resilience4j, une bibliothèque de tolérance de panne légère, pour implémenter le modèle Nouvelle tentative en Java. 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 Retry. 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. La stratégie de nouvelle tentative pour l’implémentation de référence inclut les tentatives maximales, 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 empêche la perte de cycles du processeur afin que l’application conserve son intégrité des performances pour les utilisateurs finaux.

Utilisez Spring Cloud Circuit Breaker et Resilience4j pour implémenter le modèle Disjoncteur. 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. Le modèle affecte à l’application la responsabilité de gérer les demandes de données et de garantir la cohérence entre le cache et le stockage persistant, comme 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. Elle 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 à haut besoin pour améliorer 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 spécifie à Spring quelles méthodes doivent avoir leurs résultats 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. Utilisez la volatilité des données et l’utilisateur doit déterminer le taux d’actualisation optimal. Cette pratique garantit que l’application utilise le modèle Cache-Aside pour fournir un accès rapide et des informations actuelles. 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 (exprimée en millisecondes) pour contrôler la spring.cache.redis.time-to-live durée pendant laquelle les données doivent rester dans le cache avant de les supprimer.

• 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 fournissent des conseils sur l’implémentation des mises à jour de configuration. Chaque section s’aligne sur un ou plusieurs piliers de Well-Architected Framework.

Paramétrage	Fiabilité (RE)	Sécurité (SE)	Optimisation des coûts (CO)	Excellence opérationnelle (OE)	Efficacité des performances (PE)	Prise en charge des principes de WAF
Configurer l’authentification et l’autorisation de l’utilisateur		✔		✔		SE :05 OE :10
Implémentation d’identités managées		✔		✔		SE :05 OE :10
Dimensionnement des environnements Rightsize			✔			CO :05 CO :06
Implémenter la mise à l’échelle automatique	✔		✔		✔	RE :06 CO :12 PE :05
Automatiser le déploiement de ressources				✔		OE :05
Implémenter la supervision			✔	✔	✔	OE :07 PE :04

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.

  Spring Boot Starter pour Microsoft Entra ID simplifie ce processus. Il utilise Spring Security et Spring Boot pour garantir une configuration facile. Il fournit différents flux d’authentification, gestion automatique des jetons, stratégies d’autorisation personnalisables et fonctionnalités d’intégration avec les composants Spring Cloud. Ce service permet une intégration simple de Microsoft Entra ID et OAuth 2.0 aux applications Spring Boot sans configuration manuelle de bibliothèque ou de paramètres.

  L’implémentation de référence utilise la plateforme d’identités Microsoft (MICROSOFT Entra ID) comme 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 active 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éez une inscription d’application. Microsoft Entra ID nécessite d'inscrire une application dans le locataire principal. L’inscription de l’application permet de s’assurer que les utilisateurs qui accèdent à l’application web ont des identités dans le locataire principal. L’implémentation de référence utilise Terraform pour créer une inscription d’application Microsoft Entra ID avec 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 le contrôle d’accès en fonction du rôle (RBAC) pour attribuer des privilèges minimum 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 ont accès uniquement aux ressources et actions nécessaires. Configurez Spring Security pour utiliser Spring Boot Starter pour Microsoft Entra ID. Cette bibliothèque permet l’intégration à l’ID Microsoft Entra 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.

  L’implémentation de référence crée des rôles d’application qui reflètent les types de rôles d’utilisateur dans le 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 dans CAMS, citons le gestionnaire de comptes, le représentant de support de niveau 1 (L1) et le représentant du service de champ. 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 montre comment configurer l’ID SecurityFilterChain Microsoft Entra pour l’authentification et l’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 protéger contre les accès et violations non autorisés. Par exemple, vous pouvez utiliser signatures d’accès partagé (SAP) pour limiter l’accès à une période donnée. Utilisez la SAP de délégation d’utilisateur pour optimiser la sécurité lorsque vous accordez 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éfinit les ressources Azure auxquelles les identités peuvent accéder, ce qu’elles peuvent faire avec ces ressources et les zones auxquelles elles 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. Lorsque vous utilisez l’accès juste-à-temps, les identités utilisateur reçoivent des autorisations temporaires pour effectuer des tâches privilégiées.

Implémentation d’identités managées

Utilisez 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 avoir à gérer les informations d’identification. Pour simplifier la migration, vous pouvez continuer à utiliser des solutions d’authentification locales pour les systèmes hybrides et hérités, mais vous devez les transférer vers des 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 approche 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 RBAC Azure pour accorder uniquement des autorisations critiques pour les 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.

• Fournissez une sécurité pour 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.

Dimensionnement des environnements Rightsize

Utilisez des niveaux de performances (SKU) des services Azure qui répondent aux besoins de chaque environnement sans les dépasser. Pour rightsiser vos environnements, suivez ces recommandations :

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

• Environnements de production à optimisation des coûts. 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.

• environnements de préproduction d’optimisation du coût.environnements de préproduction devez utiliser des ressources à moindre coût et tirer parti des remises telles que tarification Azure Dev/Test. Dans ces environnements, vous devez désactiver les services qui ne sont pas nécessaires. En même temps, assurez-vous que environnements de préproduction sont suffisamment similaires aux environnements de production pour éviter d’introduire des risques. Le maintien de cet équilibre garantit que les tests restent efficaces sans entraîner de coûts inutiles.

• Utilisez l’infrastructure en tant que code (IaC) pour définir des références SKU. 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 spécifie la référence SKU à déployer. Un paramètre d’environnement spécifie que le modèle Terraform doit déployer 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 permet de garantir qu’une application web reste résiliente, réactive et capable de gérer efficacement les 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 afin que votre application puisse gérer des charges variables.

• Affiner les déclencheurs de mise à l’échelle. Utilisez l’utilisation du processeur comme déclencheur de mise à l’échelle initial si vous n’êtes pas familiarisé avec les exigences de mise à l’échelle de votre application. Affinez vos déclencheurs de mise à l’échelle pour inclure d’autres métriques telles que la RAM, le débit 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 que la capacité maximale soit atteinte. 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 infrastructure en tant que code à l’aide de pipelines d’intégration et de livraison continue (CI/CD). Azure fournit des 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. Utilisez 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 des frameworks fictifs. Pour les tests impliquant des points de terminaison externes, utilisez des frameworks fictifs. 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é. Utilisez des tests de sécurité d’application statiques (SAST) pour rechercher des failles de sécurité et des 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 pour ces analyses sont faciles à intégrer à 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 d’autoinstrumentation dans Azure Application Insights pour collecter des de télémétrie d’application, telles que le débit de requête, la durée moyenne des requêtes, les erreurs et la surveillance des dépendances. Vous n’avez pas besoin de modifier le code pour utiliser cette télémétrie. Spring Boot inscrit plusieurs métriques principales dans Application Insights, comme la machine virtuelle Java (JVM), le processeur, Tomcat et d’autres. Application Insights collecte automatiquement à partir de frameworks de journalisation tels que Log4j et Logback.

  L’implémentation de référence utilise Application Insights, qui est activée via Terraform dans la configuration d’App app_settings Service :

  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. 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 stockent 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 configure les paramètres de diagnostic du service d’application :

  # 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 via une migration simulée d’une application Java locale vers Azure, mettant en évidence les modifications nécessaires pendant la phase d’adoption initiale. Cet exemple utilise une application web CAMS pour la société fictive Contoso Fibre. Contoso Fibre a défini les objectifs suivants pour l’application web :

• Implémentez des modifications de code à faible coût et à valeur élevée.
• Obtenez un SLO de 99,9%.
• Adoptez les pratiques DevOps.
• Créez des environnements optimisés pour les coûts.
• Améliorez la fiabilité et la sécurité.

Contoso Fiber constate que son infrastructure locale ne permettait pas d’atteindre ces objectifs de manière rentable. Ils ont décidé que la migration de leur application web CAMS vers Azure était le moyen le plus rentable d’atteindre leurs objectifs immédiats et futurs. L’architecture suivante représente l’état final de l’implémentation du modèle Reliable Web App de Contoso Fiber.

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

Implémentation de référence