Modèle d’application web fiable pour .NET

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

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

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

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

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

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

Le contexte métier

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

Par exemple, 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 :

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

L’infrastructure locale de Relecloud ne permettait pas d'atteindre ces objectifs de manière rentable. La société a donc décidé que la migration de son application web vers Azure était le moyen le plus rentable d'atteindre ses objectifs immédiats et futurs.

Conseils sur l’architecture

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

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

Concevoir l’architecture

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

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

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

  

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

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

Choisir les services Azure appropriés

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

Pa exemple, avant la migration vers le cloud, l’application web de billetterie de Relecloud était une application ASP.NET monolithique locale. Elle était exécutée sur deux machines virtuelles et disposait d'une base de données Microsoft SQL Server. 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. Relecloud a choisi Azure App Service comme plateforme d’application pour les raisons suivantes :

  • Contrat de niveau de service élevé (SLA) : Il dispose d'un SLA élevé qui répond au SLO de 99,9 % de l'environnement de production.
  • Charge de gestion réduite : Il s’agit d’une solution entièrement managée qui gère la mise à l’échelle, les contrôles 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 vers 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 automatiquement effectuer 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 Microsoft Entra ID pour les raisons suivantes :

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

• Base de données : utilisez un service qui vous permet de conserver le même moteur de base de données. Utilisez l’arbre de décision de magasin de données. L’application web de Relecloud a utilisé SQL Server localement. Ils souhaitaient donc utiliser le schéma de base de données, les procédures stockées et les fonctions existants. 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.
  • Charge de gestion réduite : Il fournit une instance de base de données SQL managée.
  • Prise en charge de la migration : Il prend en charge la migration de bases de données depuis une instance SQL Server locale.
  • 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 instant dans le passé.
  • Expertise et remaniement minimal : SQL Database tire parti de l’expertise interne et son adoption ne nécessite qu'un minimum d'efforts.

• Surveillance des performances des applications : utilisez Application Insights pour analyser les données de télémétrie sur 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 d’anomalies : Il détecte automatiquement les anomalies de performances.
  • Résolution des problèmes : Il vous aide à diagnostiquer les problèmes dans l’application en cours d’exécution.
  • Surveillance : Il collecte des informations sur la façon dont les utilisateurs utilisent l’application et vous permet de suivre facilement les événements personnalisés.
  • Manque de visibilité : La solution locale ne comportait pas de solution de surveillance des performances des applications. Application Insights offre une intégration facile à la plateforme et au code de l’application.

• Cache : choisissez si vous souhaitez ajouter du cache à votre architecture d’application web. Azure Cache pour Redis est la solution de cache principale d’Azure. Il s'agit d'un magasin de données managé en mémoire basé sur le logiciel Redis. La charge de l’application web de Relecloud est fortement axée sur l’affichage des concerts et des détails de la salle, et l’entreprise a ajouté Azure Cache for Redis pour les raisons suivantes :

  • Charge de gestion réduite : Il s’agit d’un service entièrement managé.
  • Vitesse et volume : Il offre un débit de données élevé et des lectures à faible latence pour les données couramment sollicitées et à variation lente.
  • Prise en charge diversifiée : Il s’agit d’un emplacement de cache unifié que toutes les instances de l’application web doivent utiliser.
  • Magasin de données externe : Les serveurs d’applications locaux ont effectué la mise en cache locale de la machine virtuelle. Cette configuration n’a pas déchargé les données très fréquentées et n’a pas pu invalider les données.
  • Sessions non persistantes : L’externalisation de l’état de session prend en charge les sessions non persistantes.

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

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

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

• 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 d’accepter et de refuser les fonctionnalités de préversion anticipée dans un environnement de production sans redéployer l’application.
  • Prise en charge du pipeline Git : La source de vérité pour les données de configuration devait ê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 stockait les secrets dans des fichiers de configuration du code, mais une meilleure pratique de sécurité consiste à le faire dans un emplacement qui prend en charge les contrôles RBAC et d’audit. Bien que les identités managées soient la solution privilégiée pour se connecter aux ressources Azure, Relecloud devait gérer des secrets d'application. 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 : Il facilite l’accès à l’audit et génère des alertes lorsque les secrets stockés sont modifiés.
  • Intégration : Il fournit une intégration native avec le magasin de configuration Azure (App Configuration) et la plateforme d’hébergement web (App Service).

• Solution de stockage : examinez les 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 sécurisé : L’application web peut éliminer les points de terminaison pour accéder au stockage exposé à l’Internet public avec un accès anonyme.
  • Chiffrement : Il chiffre les données au repos et en transit.
  • Résilience : Il 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é des points de terminaison : il utilise Azure Private Link pour accéder à des solutions de plateforme en tant que service via un point de terminaison privé sur votre réseau virtuel. Le trafic entre votre réseau virtuel et le service transite par le réseau principal de Microsoft. Relecloud a choisi Private Link pour les raisons suivantes :

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

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

Conseils sur le code

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

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

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

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

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

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

Implémenter le modèle Nouvelle tentative

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

• Mécanismes de nouvelle tentative intégrés Azure Utilisez le mécanisme de nouvelle tentative intégré dont dispose la plupart des services Azure pour accélérer l’implémentation. Par exemple, l’implémentation de référence utilise la résilience de connexion dans Entity Framework Core pour appliquer le modèle Nouvelle tentative dans les requêtes envoyées à Azure SQL Database (voir le code suivant).

  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 telle que Polly ou Microsoft.Extensions.Http.Resilience. Ces bibliothèques offrent 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 (voir le code suivant).

  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 évite de gaspiller les cycles de processeur afin que l’application conserve son intégrité de performance pour les utilisateurs finaux.

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

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

• Configurer l’application pour utiliser le cache. Les applications de production doivent utiliser le cache Redis distribué car il améliore les performances en réduisant les requêtes de base de données et il permet des sessions non statiques afin que l’équilibreur de charge puisse répartir le trafic de manière homogène. Par exemple, l’implémentation de référence utilise le cache Redis distribué. La méthode AddAzureCacheForRedis configure l’application de sorte à utiliser Azure Cache pour Redis (voir le code suivant).

  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 les plus nécessaires pour augmenter son efficacité. Utilisez Azure Monitor pour effectuer le suivi du processeur, de la mémoire et du stockage de la base de données. Ces métriques vous aident à déterminer si vous pouvez utiliser une référence SKU de base de données plus petite après avoir appliqué le modèle Cache-Aside. 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 dernières données des concerts (voir le code suivant).

  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. Déterminez la fréquence d’actualisation optimale en fonction de la volatilité des données et des besoins des utilisateurs. Cette pratique garantit que l'application utilise le modèle Cache-Aside pour fournir à la fois un accès rapide et des informations à jour. Par exemple, l’implémentation de référence met en cache les données pendant une heure seulement et utilise la méthode CreateConcertAsync pour effacer la clé de cache lorsque les données changent (voir le code suivant).

  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. Par exemple, l’implémentation de référence utilise la méthode UpdateConcertAsync pour garantir la cohérence des données du cache (voir le code suivant).

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

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

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

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

• Créer une inscription d’application. Microsoft Entra ID nécessite d'inscrire une application dans le locataire principal. L’inscription de l’application garantit que les utilisateurs qui ont accès à l’application web possèdent des identités dans le locataire principal.

• 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 offre une prise en charge intégrée de l’authentification, qui vous permet de connecter les utilisateurs et d’accéder aux données sans avoir à écrire beaucoup de code dans votre application web.

• Appliquez l’autorisation dans l’application. Utilisez des contrôles d’accès en fonction du rôle (RBAC) pour attribuer des privilèges moindres aux rôles d’application. Définissez des rôles spécifiques pour les différentes actions des utilisateurs afin d’éviter les chevauchements et de garantir la clarté. Mappez les utilisateurs aux rôles appropriés et assurez-vous qu’ils n’ont accès qu’aux ressources et aux actions nécessaires.

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

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

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

Implémentation d’identités managées

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

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

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

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

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

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

Environnements de taille appropriée

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

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

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

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

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

Par exemple, l’implémentation de référence 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 garantit la résilience, la réactivité et la capacité d’une application web à gérer efficacement des charges de travail dynamiques. Pour implémenter la mise à l’échelle automatique, suivez ces recommandations :

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

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

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

Automatiser le déploiement de ressources

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

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

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

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

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

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

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 l’autoinstrumentation dans Azure Application Insights pour collecter des données de télémétrie des applications, telles que le débit de la requête, la durée moyenne des requêtes, les erreurs et la surveillance des dépendances, sans modification du code.

  L’implémentation de référence utilise AddApplicationInsightsTelemetry du package NuGet Microsoft.ApplicationInsights.AspNetCore pour activer la collecte de données de télémétrie (voir le code suivant).

  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 doté de concertId et count (voir le code suivant).

  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 et envoyez des diagnostics à la même destination que les journaux d’activité de l’application pour la corrélation. Les services Azure créent automatiquement des journaux de plateforme, mais les stocke uniquement lorsque vous activez les diagnostics. Activez les paramètres de diagnostic pour chaque service qui prend en charge les diagnostics.

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

L’implémentation de référence guide les développeurs à travers une simulation de migration d’une application ASP.NET sur site vers Azure, en mettant en évidence les changements nécessaires au cours de la phase d’adoption initiale. Cet exemple utilise une application 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émenter des modifications de code à faible coût et à forte valeur ajoutée
• Atteindre un objectif de niveau de service (SLO) de 99,9 %
• Adopter des pratiques DevOps
• Créer des environnements à coût optimisé
• Améliorer la fiabilité et la sécurité

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

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