Modèle d’application web fiable pour .NET

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 .NET ?

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 met l'accent sur les mises à jour minimales du code que vous devez effectuer pour tirer une expérience positive du cloud. Les instructions suivantes utilisent une implémentation de référence comme exemple dans l’ensemble. Les conseils suivent le parcours replatform de la société fictive Relecloud pour fournir un contexte d’entreprise pour votre parcours. Avant d’implémenter le modèle Reliable Web App pour .NET, Relecloud disposait d’une application web monolithique de ticketing local qui utilisait l’infrastructure ASP.NET.

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 un temps de disponibilité de 99,9 %. Calculez le contrat SLA composite pour tous les services qui affectent la disponibilité de votre application web.

Par exemple, Relecloud prévoit un chiffre de vente positif et anticipe une augmentation de la demande pour son application web de billetterie. Pour répondre à cette demande, ils ont défini les objectifs de l'application web :

• 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é.

L’infrastructure locale de Relecloud ne permettait pas d'atteindre ces objectifs de manière rentable. Ils ont décidé que la migration de leur application web 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 actuelles 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 de ticketing de Relecloud était une application monolithique locale ASP.NET. Il s’est exécuté sur deux machines virtuelles et a utilisé une base de données SQL Server. L’application web a souffert de problèmes courants liés à l’extensibilité et au 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. Relecloud a choisi App Service comme plateforme d’application pour les raisons suivantes :

  • Contrat de niveau de service élevé (SLA). Il a un contrat SLA élevé qui répond au SLO de l’environnement de production de 99,9%.
  • Réduction de la surcharge de gestion. Il s’agit d’une solution entièrement managée qui gère la mise à l’échelle, les vérifications d’intégrité et l’équilibrage de charge.
  • Prise en charge de .NET. Il prend en charge la version de .NET dans laquelle l’application est écrite.
  • Fonctionnalité de conteneurisation. L’application web peut converger sur le cloud sans conteneuriser, mais la plateforme d’application prend également en charge la conteneurisation sans modifier les services Azure.
  • Mise à l’échelle automatique. L’application web peut effectuer automatiquement un scale-in et un scale-out en fonction du trafic utilisateur et des paramètres de configuration. La plateforme prend également en charge le scale-up ou le scale-down pour répondre à différentes exigences d’hébergement.

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

  • Authentification et autorisation. L’application doit authentifier et autoriser les employés du centre d’appels.
  • Évolutif. 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. L’application web de Relecloud a utilisé SQL Server localement. Ils souhaitaient utiliser le schéma de base de données existant, les procédures stockées et les fonctions. Plusieurs produits SQL sont disponibles sur Azure, mais Relecloud a choisi Azure SQL Database pour les raisons suivantes :

  • Fiabilité. Le niveau usage général fournit un contrat SLA élevé et une redondance multirégion. Il peut prendre en charge une charge utilisateur élevée.
  • Réduction de la surcharge de gestion. SQL Database fournit une instance de base de données SQL managée.
  • Prise en charge de la migration. Il prend en charge la migration de base de données à partir de SQL Server local.
  • Cohérence avec les configurations locales. Il prend en charge les procédures stockées, les fonctions et les vues existantes.
  • Résilience. Il prend en charge les sauvegardes et la restauration à un point dans le temps.
  • Expertise et remaniement minimal. SQL Database permet à Relecloud de tirer parti de l’expertise existante et nécessite un travail minimal à adopter.

• surveillance des performances des applications : utiliser application Insights pour analyser les données de télémétrie pour votre application. Relecloud 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. La charge de l’application web de Relecloud est fortement asymétrique pour afficher les concerts et les détails du lieu. Relecloud a ajouté Azure Cache pour Redis pour les raisons suivantes :

  • Réduction de la surcharge de gestion. Il s’agit d’un service entièrement géré.
  • Vitesse et volume. Il dispose d’un débit de données élevé et de 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é pour toutes les instances de l’application web à utiliser.
  • Magasin de données externe. Les serveurs d’applications locaux ont effectué la mise en cache locale des machines virtuelles. 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. L’externalisation de l’état de session prend en charge les sessions non rouges.

• équilibreur de charge : applications web qui utilisent des solutions PaaS doivent utiliser Azure Front Door, Azure Application Gateway ou les deux, en fonction de l’architecture et des exigences de l’application web. Utilisez l’arbre de décision de l’équilibreur de charge pour choisir l’équilibreur de charge approprié. Relecloud avait besoin d’un équilibreur de charge de couche 7 capable d’acheminer le trafic entre plusieurs régions. L’entreprise avait besoin d’une application web multirégion pour répondre au SLO de 99,9%. Relecloud 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 d’intégrité. L’application nécessite 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. Il 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 Relecloud 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. Relecloud utilise le pare-feu d’applications web Azure 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’exécutait derrière un pare-feu d’applications web géré par le service informatique.
  • Facilité d’utilisation. Le pare-feu d’applications web s’intègre à Azure Front Door.

• Stockage de la configuration : choisissez d’ajouter ou non le stockage de la configuration de l’application à votre application web. Azure App Configuration est un service pour la gestion centralisée des paramètres d’application et des indicateurs de fonctionnalité. Passez en revue bonnes pratiques App Configuration pour déterminer si ce service convient parfaitement à votre application. Relecloud souhaitait remplacer la configuration basée sur les fichiers par un magasin de configuration central pouvant s’intégrer à la plateforme d’application et au code. La société a ajouté App Configuration à l’architecture pour les raisons suivantes :

  • Flexibilité. Il prend en charge les indicateurs de fonctionnalité. Les indicateurs de fonctionnalité permettent aux utilisateurs de refuser et de désactiver les fonctionnalités en préversion anticipée dans un environnement de production sans nécessiter de redéploiement d’application.
  • Prise en charge du pipeline Git. La source de vérité pour les données de configuration doit être un référentiel Git. Pipeline nécessaire pour mettre à jour les données dans le magasin de configuration central.
  • Prise en charge des identités managées. Il prend en charge les identités managées pour simplifier et sécuriser la connexion au magasin de configuration.

• Gestionnaire de secrets : il utilise Azure Key Vault si vous gérez des secrets dans Azure. Vous pouvez incorporer des Key Vault dans des applications .NET à l’aide de l’objet ConfigurationBuilder. L’application web locale de Relecloud a stocké des secrets dans des fichiers de configuration de code, mais une meilleure pratique de sécurité consiste à stocker des secrets dans un emplacement qui prend en charge les contrôles RBAC et d’audit. Bien que identités managées sont la solution préférée pour la connexion aux ressources Azure, Relecloud avait des secrets d’application nécessaires pour gérer. Relecloud 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 (App Configuration) et à la plateforme d’hébergement web (App Service).

• solution de stockage : consultez options de stockage Azure pour choisir la solution de stockage appropriée en fonction de vos besoins. L’application web locale de Relecloud disposait d’un stockage sur disque monté sur chaque serveur web, mais l’équipe souhaitait utiliser une solution de stockage de données externe. Relecloud a choisi Stockage Blob Azure pour les raisons suivantes :

  • Accès amélioré à la sécurité. L’application web peut éliminer les points de terminaison pour accéder au stockage exposé à l’Internet public avec un accès anonyme.
  • Chiffrement. Le stockage Blob chiffre les données au repos et en transit.
  • Résilience. Le stockage Blob prend en charge le stockage redondant interzone (ZRS). Le stockage redondant interzone réplique les données de façon synchrone dans trois zones de disponibilité Azure de la région primaire. Chaque zone de disponibilité est dans un emplacement physique distinct qui a une alimentation, un refroidissement et une mise en réseau indépendants. Cette configuration doit rendre les images de ticket résilientes contre la perte.

• sécurité de point de terminaison : utiliser Azure Private Link pour accéder aux solutions PaaS (Platform as a Service) 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. Relecloud a choisi Private Link pour les raisons suivantes :

  • Communication améliorée en matière de sécurité. Private Link 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é réseau. Utilisez 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. Relecloud 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. Relecloud 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.

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 des mécanismes de nouvelle tentative intégrés. Utilisez le mécanisme de nouvelle tentative intégré que la plupart des services Azure fournissent pour accélérer votre implémentation. Par exemple, l’implémentation de référence utilise résilience de connexion dans Entity Framework Core pour appliquer le modèle nouvelle tentative dans les requêtes à SQL Database :

  services.AddDbContextPool<ConcertDataContext>(options => options.UseSqlServer(sqlDatabaseConnectionString,
      sqlServerOptionsAction: sqlOptions =>
      {
          sqlOptions.EnableRetryOnFailure(
          maxRetryCount: 5,
          maxRetryDelay: TimeSpan.FromSeconds(3),
          errorNumbersToAdd: null);
      }));
  

• Utiliser des bibliothèques de programmation de nouvelles tentatives. Pour les communications HTTP, intégrez une bibliothèque de résilience standard comme Polly ou Microsoft.Extensions.Http.Resilience. Ces bibliothèques fournissent des mécanismes de nouvelle tentative complets qui sont essentiels pour la gestion des communications avec des services web externes. Par exemple, l’implémentation de référence utilise Polly pour appliquer le modèle Nouvelle tentative chaque fois que le code construit un objet qui appelle l’objet IConcertSearchService :

  private void AddConcertSearchService(IServiceCollection services)
  {
      var baseUri = Configuration["App:RelecloudApi:BaseUri"];
      if (string.IsNullOrWhiteSpace(baseUri))
      {
          services.AddScoped<IConcertSearchService, MockConcertSearchService>();
      }
      else
      {
          services.AddHttpClient<IConcertSearchService, RelecloudApiConcertSearchService>(httpClient =>
          {
              httpClient.BaseAddress = new Uri(baseUri);
              httpClient.DefaultRequestHeaders.Add(HeaderNames.Accept, "application/json");
              httpClient.DefaultRequestHeaders.Add(HeaderNames.UserAgent, "Relecloud.Web");
          })
          .AddPolicyHandler(GetRetryPolicy())
          .AddPolicyHandler(GetCircuitBreakerPolicy());
      }
  }
  
  private static IAsyncPolicy<HttpResponseMessage> GetRetryPolicy()
  {
      var delay = Backoff.DecorrelatedJitterBackoffV2(TimeSpan.FromMilliseconds(500), retryCount: 3);
      return HttpPolicyExtensions
        .HandleTransientHttpError()
        .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
        .WaitAndRetryAsync(delay);
  }
  

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.

Par exemple, l’implémentation de référence applique le modèle Disjoncteur sur toutes les demandes à l’API. Il utilise la logique HandleTransientHttpError pour détecter les requêtes HTTP qu’elle peut réessayer en toute sécurité, mais limite le nombre d’erreurs d’agrégation sur une période spécifiée :

private static IAsyncPolicy<HttpResponseMessage> GetCircuitBreakerPolicy()
{
    return HttpPolicyExtensions
        .HandleTransientHttpError()
        .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
        .CircuitBreakerAsync(5, TimeSpan.FromSeconds(30));
}

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. Les applications de production doivent utiliser un cache Redis distribué. Ce cache améliore les performances en réduisant les requêtes de base de données. Il active également des sessions non rouges afin que l’équilibreur de charge puisse distribuer uniformément le trafic. L’implémentation de référence utilise un cache Redis distribué. La méthode AddAzureCacheForRedis configure l’application pour utiliser Le Cache Azure pour Redis :

  private void AddAzureCacheForRedis(IServiceCollection services)
  {
      if (!string.IsNullOrWhiteSpace(Configuration["App:RedisCache:ConnectionString"]))
      {
          services.AddStackExchangeRedisCache(options =>
          {
              options.Configuration = Configuration["App:RedisCache:ConnectionString"];
          });
      }
      else
      {
          services.AddDistributedMemoryCache();
      }
  }
  

• 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. Par exemple, l’implémentation de référence met en cache les données les plus nécessaires à la page des concerts à venir. La méthode GetUpcomingConcertsAsync extrait les données dans le cache Redis à partir de la base de données SQL et remplit le cache avec les données de concert les plus récentes :

  public async Task<ICollection<Concert>> GetUpcomingConcertsAsync(int count)
  {
      IList<Concert>? concerts;
      var concertsJson = await this.cache.GetStringAsync(CacheKeys.UpcomingConcerts);
      if (concertsJson != null)
      {
          // There is cached data. Deserialize the JSON data.
          concerts = JsonSerializer.Deserialize<IList<Concert>>(concertsJson);
      }
      else
      {
          // There's nothing in the cache. Retrieve data 
          // from the repository and cache it for one hour.
          concerts = await this.database.Concerts.AsNoTracking()
              .Where(c => c.StartTime > DateTimeOffset.UtcNow && c.IsVisible)
              .OrderBy(c => c.StartTime)
              .Take(count)
              .ToListAsync();
          concertsJson = JsonSerializer.Serialize(concerts);
          var cacheOptions = new DistributedCacheEntryOptions {
              AbsoluteExpirationRelativeToNow = TimeSpan.FromHours(1)
          };
          await this.cache.SetStringAsync(CacheKeys.UpcomingConcerts, concertsJson, cacheOptions);
      }
      return concerts ?? new List<Concert>();
  }
  

• 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. Par exemple, l’implémentation de référence met en cache les données pendant une heure et utilise la méthode CreateConcertAsync pour effacer la clé de cache lorsque les données changent :

  public async Task<CreateResult> CreateConcertAsync(Concert newConcert)
  {
      database.Add(newConcert);
      await this.database.SaveChangesAsync();
      this.cache.Remove(CacheKeys.UpcomingConcerts);
      return CreateResult.SuccessResult(newConcert.Id);
  }
  

• 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. L’implémentation de référence utilise la méthode UpdateConcertAsync pour maintenir la cohérence des données dans le cache :

  public async Task<UpdateResult> UpdateConcertAsync(Concert existingConcert), 
  {
     database.Update(existingConcert);
     await database.SaveChangesAsync();
     this.cache.Remove(CacheKeys.UpcomingConcerts);
     return UpdateResult.SuccessResult();
  }
  

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.

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.

• 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.

• Utiliser les fonctionnalités de la plateforme. Réduisez le besoin de code d’authentification personnalisé en utilisant les capacités de la plateforme pour authentifier les utilisateurs et accéder aux données. Par exemple, app Service fournit une prise en charge intégrée de l’authentification. Vous pouvez donc connecter des utilisateurs et accéder aux données tout en écrivant un code minimal ou aucun code dans votre application web.

• Appliquez l’autorisation dans l’application. Utilisez RBAC pour attribuer des privilèges minimum à 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 aux ressources et actions nécessaires uniquement.

• 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.

Utiliser des 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.

L’implémentation de référence utilise l’argument Authentication dans la chaîne de connexion de base de données SQL afin que App Service puisse se connecter à la base de données SQL à l’aide d’une identité managée : Server=tcp:my-sql-server.database.windows.net,1433;Initial Catalog=my-sql-database;Authentication=Active Directory Default. Il utilise DefaultAzureCredential pour permettre à l’API web de se connecter à Key Vault à l’aide d’une identité managée :

    builder.Configuration.AddAzureAppConfiguration(options =>
    {
         options
            .Connect(new Uri(builder.Configuration["Api:AppConfig:Uri"]), new DefaultAzureCredential())
            .ConfigureKeyVault(kv =>
            {
                // Some of the values coming from App Configuration
                // are stored in Key Vault. Use the managed identity
                // of this host for the authentication.
                kv.SetCredential(new DefaultAzureCredential());
            });
    });

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 utilise des paramètres Bicep pour déployer des niveaux plus coûteux (SKU) dans l’environnement de production :

    var redisCacheSkuName = isProd ? 'Standard' : 'Basic'
    var redisCacheFamilyName = isProd ? 'C' : 'C'
    var redisCacheCapacity = isProd ? 1 : 0

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.

Implémenter la supervision

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 d’apporter de modifications de code pour utiliser cette télémétrie.

  L’implémentation de référence utilise AddApplicationInsightsTelemetry à partir du package NuGet Microsoft.ApplicationInsights.AspNetCore pour activer collecte de données de télémétrie:

  public void ConfigureServices(IServiceCollection services)
  {
     ...
     services.AddApplicationInsightsTelemetry(Configuration["App:Api:ApplicationInsights:ConnectionString"]);
     ...
  }
  

• Créer des métriques d’application personnalisées. Utilisez l’instrumentation basée sur le code pour la télémétrie d’application personnalisée. Ajoutez le Kit de développement logiciel (SDK) Application Insights à votre code et utilisez l’API Application Insights.

  L’implémentation de référence rassemble les données de télémétrie sur les événements liés à l’activité du panier. this.telemetryClient.TrackEvent compte les billets ajoutés au panier. Il fournit le nom de l’événement (AddToCart) et spécifie un dictionnaire qui a le concertId et le count:

  this.telemetryClient.TrackEvent("AddToCart", new Dictionary<string, string> {
      { "ConcertId", concertId.ToString() },
      { "Count", count.ToString() }
  });
  

• 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.

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

L’implémentation de référence guide les développeurs par le biais d’une migration simulée à partir d’une application locale ASP.NET vers Azure, en mettant en évidence les modifications nécessaires pendant la phase d’adoption initiale. Cet exemple utilise une application de billetterie de concert pour la société fictive Relecloud, qui vend des billets via son application Web locale. Relecloud définit les objectifs suivants pour son 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é.

Relecloud a déterminé que leur infrastructure locale n’était pas une solution rentable pour atteindre ces objectifs. Ils ont décidé que la migration de leur application web 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 Relecloud.

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