Modèle d’application web fiable pour .NET : appliquer le modèle

Azure App Service

Azure Front Door

Cache Azure pour Redis

.NET

Cet article vous montre comment appliquer le modèle d’application web fiable. 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 modifier des applications web (création d'une nouvelle plateforme d'applications) 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.

Pour faciliter la mise en œuvre de ces conseils, vous pouvez déployer l'implémentation de référence du modèle d'application web fiable.

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

Les instructions suivantes utilisent l’implémentation de référence comme exemple tout au long de cet article. Pour appliquer le modèle d'application web fiable, suivez ces recommandations alignées sur les piliers du Well-Architected Framework :

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour en savoir plus, consultez la liste de contrôle de l'examen de la conception pour la fiabilité. Le modèle d’application web fiable introduit deux modèles de conception clés au niveau du code pour améliorer la fiabilité : le modèle Nouvelle tentative et le modèle Disjoncteur.

Utiliser le modèle Nouvelle tentative

Le modèle Nouvelle tentative traite les interruptions de service temporaires, appelées erreurs temporaires, qui sont généralement résolues en quelques secondes. Ces erreurs résultent souvent de la limitation de service, de la distribution de charge dynamique et des problèmes réseau dans les environnements cloud. L’implémentation du modèle Nouvelle tentative implique de renvoyer des requêtes ayant échoué, en prévoyant des délais et des tentatives configurables avant l'acceptation de l'échec.

Les applications utilisant le modèle Nouvelle tentative doivent intégrer les kits de développement logiciel (SDK) client d’Azure et les mécanismes de nouvelle tentative spécifiques au service pour améliorer l’efficacité. Les applications dépourvues de ce modèle doivent l'adopter en suivant les recommandations ci-dessous.

Essayer d’abord le service Azure et les kits de développement logiciel (SDK) clients

La plupart des services Azure et des kits de développement logiciel (SDK) clients disposent d’un mécanisme de nouvelle tentative intégré. Vous devez utiliser le mécanisme de Nouvelle tentative intégré pour les services Azure afin d’accélérer l’implémentation.

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 la bibliothèque Polly lorsque la bibliothèque cliente ne prend pas en charge les nouvelles tentatives

Vous devrez peut-être effectuer des appels vers une dépendance qui n’est pas un service Azure ou qui ne prend pas en charge le modèle Nouvelle tentative en mode natif. Dans ce cas, vous devez utiliser la bibliothèque Polly pour implémenter le modèle Nouvelle tentative. Polly est une bibliothèque de résilience .NET et de gestion des erreurs temporaires. Avec elle, vous pouvez utiliser les API courants pour décrire le comportement dans un emplacement central de l’application.

Exemple : L’implémentation de référence utilise Polly pour configurer l’injection de dépendances ASP.NET Core. Polly applique le modèle Nouvelle tentative chaque fois que le code construit un objet qui appelle l’objet IConcertSearchService . Dans l’infrastructure Polly, ce comportement est appelé stratégie. Le code extrait cette stratégie dans la méthode GetRetryPolicy, et la méthode GetRetryPolicy applique le modèle Nouvelle tentative chaque fois que l’application web front-end appelle des services service de recherche de concerts de l'API web (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);
}

Le gestionnaire de stratégie de l’instance RelecloudApiConcertSearchService applique le modèle Nouvelle tentative sur toutes les demandes à l’API. Il utilise la logique HandleTransientHttpError pour détecter les requêtes HTTP qu’il peut réessayer en toute sécurité, puis pour réessayer la requête en fonction de la configuration. Il inclut un certain caractère aléatoire pour lisser les rafales potentielles du trafic vers l’API en cas d’erreur.

Utiliser le modèle Circuit Breaker

L’association des modèles Nouvelle tentative and Disjoncteur accroît la capacité d'une application à gérer les interruptions de service qui ne sont pas liées à des erreurs temporaires. Le modèle Disjoncteur empêche une application d'essayer continuellement d'accéder à un service qui ne répond pas. Le modèle Disjoncteur 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.

Exemple : L’implémentation de référence ajoute le modèle Disjoncteur dans la méthode GetCircuitBreakerPolicy (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));
}

Dans le code, le gestionnaire de stratégie de l’instance RelecloudApiConcertSearchService applique le modèle Disjoncteur à toutes les requêtes envoyées à l’API. Il 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.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour en savoir plus, consultez la liste de contrôle de l'examen de la conception pour la sécurité. Le modèle d’application web fiable utilise des identités managées pour mettre en œuvre une sécurité centrée sur l'identité. Les points de terminaison privés, le pare-feu d’applications web et l’accès restreint à l’application web assurent une entrée sécurisée.

Appliquez les privilèges minimum

Pour des raisons de sécurité et d'efficacité, n'accordez aux utilisateurs (identités utilisateur) et aux services Azure (identités de charge de travail) que les autorisations dont ils ont besoin.

Attribuer des autorisations aux identités utilisateur

Évaluez les besoins de votre application pour définir un ensemble de rôles qui couvrent toutes les actions de l'utilisateur sans chevauchement. Mappez chaque utilisateur au rôle le plus approprié. Veillez à ce qu'ils n'aient accès qu'aux données nécessaires à l'exercice de leurs fonctions.

Attribuer des autorisations aux identités de charge de travail

N'accordez que 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.

Privilégiez le contrôle d’accès en fonction du rôle (RBAC). Commencez toujours par utiliser Azure RBAC pour attribuer des autorisations. Cette solution offre un contrôle précis, garantissant un accès à la fois contrôlable et granulaire. Utilisez Azure RBAC pour n'accorder que les autorisations nécessaires à l'exécution des fonctions prévues du service.
Ajoutez des contrôles d'accès au niveau du service Azure. Si Azure RBAC ne couvre pas un scénario spécifique, utilisez des politiques d'accès au niveau du service Azure.

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

L’authentification et l’autorisation sont des aspects critiques de la sécurité des applications web. L’authentificationest le processus de vérification de l'identité d'un client. L’autorisation spécifie les actions qu’un utilisateur est autorisé à effectuer dans l’application. L’objectif est d’implémenter l’authentification et l’autorisation sans affaiblir votre posture de sécurité. Pour atteindre cet objectif, vous devez utiliser les fonctionnalités de la plateforme d’applications Azure (Azure App Service) et du fournisseur d’identité (Microsoft Entra ID).

Configurer l’authentification de l’utilisateur

Sécurisez votre application web en activant l’authentification utilisateur via les fonctionnalités de votre plateforme. Azure App Service prend en charge l’authentification avec des fournisseurs d’identité tels que Microsoft Entra ID, ce qui permet de décharger votre code de la charge de travail liée à l'authentification.

Configurer l’authentification et l’autorisation du service

Configurez l’authentification et l’autorisation des services afin que les services de votre environnement disposent des autorisations nécessaires pour exécuter les fonctions attendues. Utilisez les identités managées dans Microsoft Entra ID pour automatiser la création et la gestion des identités de service, et évitez ainsi de devoir gérer manuellement les informations d'identification. Une identité managée permet à votre application web d’accéder en toute sécurité aux services Azure, tels qu’Azure Key Vault et les bases de données. Elle facilite également l'intégration de pipelines CI/CD pour les déploiements vers Azure App Service. Toutefois, dans des scénarios tels que les déploiements hybrides ou avec des systèmes existants, continuez à utiliser vos solutions d'authentification locales pour simplifier la migration. Passez aux identités gérées lorsque votre système est adapté à une approche moderne de la gestion des identités. Pour plus d’informations, consultez la documentation relative à la surveillance des identités managées.

Utiliser DefaultAzureCredential pour configurer le code

Utilisez DefaultAzureCredential afin de fournir des informations d'identification pour le développement local et les identités managées dans le cloud. DefaultAzureCredential génère un TokenCredential pour l’acquisition de jeton OAuth. Il gère la plupart des scénarios du SDK Azure et des bibliothèques clientes Microsoft. Il détecte l’environnement de l’application pour utiliser l’identité correcte et demande des jetons d’accès si nécessaire. DefaultAzureCredential simplifie l’authentification pour les applications déployées dans Azure. Pour plus d’informations, consultez la documentation relative à DefaultAzureCredential.

Exemple : L’implémentation de référence utilise la classe DefaultAzureCredential pendant le démarrage pour permettre l’utilisation de l’identité managée entre l’API web et Key Vault (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 Key Vault. Use
            // the managed identity of this host for the authentication.
            kv.SetCredential(new DefaultAzureCredential());
        });
});

Utiliser l’infrastructure en tant que code pour créer des identités managées

Vous devez utiliser des modèles Bicep pour créer et configurer l’infrastructure Azure pour prendre en charge les identités managées. Les identités managées n’utilisent pas de secrets ou de mots de passe. Vous n’avez donc pas besoin de Key Vault ou d’une stratégie de rotation des secrets pour garantir l’intégrité. Vous pouvez stocker les chaînes de connexion dans le service App Configuration.

Exemple : L’implémentation de référence utilise des modèles Bicep pour (1) créer l’identité managée, (2) associer l’identité à l’application web et (3) octroyer à l’identité l’autorisation d’accéder à la base de données SQL. L’argument Authentication de la chaîne de connexion suivante indique à la bibliothèque cliente Microsoft de se connecter avec une identité managée (voir le code suivant).

    Server=tcp:my-sql-server.database.windows.net,1433;Initial Catalog=my-sql-database;Authentication=Active Directory Default

Pour plus d’informations, consultez Se connecter à une base de données SQL à partir de .NET App Service.

Utiliser un magasin de secrets central pour gérer les secrets

Lorsque vous migrez votre application vers le cloud, utilisez Azure Key Vault pour stocker ces secrets en toute sécurité. Ce référentiel centralisé offre un stockage sécurisé, une rotation des clés, un audit des accès et une surveillance des services qui ne gèrent pas les identités managées. Pour les configurations d’application, il est recommandé d'utiliser Azure App Configuration.

Exemple : L’implémentation de référence stocke les secrets suivants dans Key Vault : (1) le nom d’utilisateur et le mot de passe de la base de données PostgreSQL, (2) le mot de passe du cache Redis et (3) le secret client pour Microsoft Entra ID associé à l’implémentation Microsoft Authentication Library (MSAL).

Ne placez pas Key Vault dans le flux de requêtes HTTP.

Chargez des secrets à partir de Key Vault au démarrage de l’application plutôt qu'à chaque requête HTTP. Key Vault est destiné à stocker et récupérer en toute sécurité des données sensibles pendant le déploiement. Les accès très fréquents dans le cadre de requêtes HTTP peuvent excéder les capacités de débit de Key Vault, ce qui entraîne des limitations de requêtes et des erreurs de code d’état HTTP 429. Pour plus d’informations, consultez limites de transaction Key Vault.

Utiliser une méthode pour accéder aux secrets dans Key Vault

Lors de la configuration d'une application web en vue d'accéder aux secrets dans Key Vault, deux options principales s'offrent à vous :

Paramètre d’application App Service : Utilisez un paramètre d’application dans App Service pour injecter le secret directement en tant que variable d’environnement.
Référence directe à un secret : Référencez directement le secret dans votre code d’application. Ajoutez une référence spécifique dans le fichier de propriétés de votre application pour qu'elle communique avec Key Vault. Par exemple, application.properties pour les applications Java.

Il est important de choisir une de ces méthodes et de s'y tenir par souci de simplicité et pour éviter toute complexité inutile.

Préférer les méthodes d’accès temporaire

Utilisez des autorisations temporaires pour vous prémunir contre les accès non autorisés et les violations. Utilisez des signatures d’accès partagé (SAP) pour offrir un accès temporaire. Utilisez la 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 et ne nécessite pas de clé de compte de stockage.

Utiliser des points de terminaison privés

Utilisez des points de terminaison privés dans tous les environnements de production et pour tous les services Azure pris en charge. Les points de terminaison privés fournissent des connexions privées entre les ressources d’un réseau virtuel Azure et les services Azure. Par défaut, la communication de service vers la plupart des services Azure traverse l’Internet public. Les points de terminaison privés n’ont pas besoin de modifications de code, de configurations d’application ou de chaînes de connexion. Pour plus d’informations, consultez Comment créer un point de terminaison privé et Meilleures pratiques pour la sécurité des points de terminaison.

Exemple : Azure App Configuration, Azure SQL Database, Azure Cache pour Redis, Stockage Azure, Azure App Service et Key Vault utilisent un point de terminaison privé.

Utiliser le pare-feu d’applications web et restreindre le trafic Internet entrant

Tout le trafic Internet entrant vers l’application web doit être filtré par un pare-feu d’applications web afin de se prémunir contre les attaques web courantes. Acheminez l'intégralité du trafic Internet entrant via l’équilibreur de charge public (si vous en avez un) et le pare-feu d’applications web.

Exemple : L’implémentation de référence achemine l'intégralité du trafic Internet entrant via Front Door et le pare-feu d’applications web Azure. En production, conservez le nom d’hôte HTTP d’origine.

Configurer la sécurité de la base de données

L’accès au niveau de l’administrateur à la base de données accorde des autorisations pour effectuer des opérations privilégiées. Les opérations privilégiées incluent la création et la suppression de bases de données, la modification de schémas de table ou la modification des autorisations utilisateur. Les développeurs ont souvent besoin d’un accès au niveau de l’administrateur pour gérer la base de données ou résoudre les problèmes.

Évitez les autorisations permanentes avec élévation de privilèges. Vous devez accorder uniquement aux développeurs un accès juste-à-temps pour effectuer des opérations privilégiées. Avec un accès juste-à-temps, les utilisateurs reçoivent des autorisations temporaires pour effectuer des tâches privilégiées
N’accordez pas d’autorisations élevées à l’application. Vous ne devez pas accorder un accès administrateur à l’identité de l’application. Vous devez configurer l’accès le moins privilégié pour l’application à la base de données. Cela limite le rayon d’explosion des bogues et des violations de sécurité.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et les frais généraux de gestion. Pour plus d'informations, consultez la liste de contrôle de la révision de la conception pour l'optimisation des coûts. Le modèle d’application web fiable implémente des techniques de dimensionnement, de mise à l’échelle automatique et d'utilisation efficace des ressources pour optimiser les coûts de l'application web.

Dimensionnement des ressources pour chaque environnement

Il est important de comprendre les différents niveaux de performance des services Azure et de n'utiliser que la référence SKU appropriée aux besoins de chaque environnement. 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. Les environnements hors production n’ont normalement généralement pas besoin des mêmes fonctionnalités. Pour réaliser des économies supplémentaires, envisagez les tarifs de développement/test Azure, les réservations Azure et les plans d’économies Azure pour le calcul.

Exemple : L’implémentation de référence utilise des paramètres Bicep pour déclencher des configurations de déploiement de ressources. L’un de ces paramètres indique les niveaux de ressources (SKU) à déployer. L’application web utilise les références SKU les plus performantes et les plus chères pour les environnements de production et les références SKU les moins coûteuses pour l’environnement de non-production (voir le code suivant).

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

Utiliser la mise à l’échelle automatique

La mise à l'échelle automatique permet d'automatiser la mise à l'échelle horizontale des environnements de production. Mise à l’échelle automatique selon les métriques de performance. Les déclencheurs de performances d’utilisation du processeur sont un bon point de départ si vous ne comprenez pas les critères de mise à l’échelle de votre application. Vous devez configurer et adapter les déclencheurs de mise à l’échelle (processeur, RAM, réseau et disque) pour qu’ils correspondent au comportement de votre application web. Ne procédez pas à une mise à l'échelle verticale pour répondre à des changements fréquents de la demande. C’est moins rentable. Pour plus d’informations, consultez Mise à l’échelle dans Azure App Service et Mise à l’échelle automatique dans Microsoft Azure.

Exemple : L’implémentation de référence utilise la configuration suivante dans le modèle Bicep. Il crée une règle de mise à l’échelle automatique pour le Azure App Service. La règle est mise à l’échelle jusqu’à 10 instances et est définie par défaut sur une instance. Elle fait appel à l’utilisation du processeur comme déclencheur pour le scale-in et le scale-out. La plateforme d’hébergement d’applications web effectue un scale-out à 85 % d’utilisation du processeur et un scale-in à 60 %. Le paramètre de scale-out de 85 %, au lieu d’un pourcentage proche de 100 %, fournit une mémoire tampon pour se protéger contre le trafic utilisateur cumulé causé par des sessions persistantes. Il protège également contre les rafales élevées de trafic en effectuant une mise à l’échelle précoce pour éviter une utilisation maximale du processeur. Ces règles de mise à l’échelle automatique ne sont pas universelles (voir le code suivant).

resource autoScaleRule 'Microsoft.Insights/autoscalesettings@2022-10-01' = if (autoScaleSettings != null) { 
  name: '${name}-autoscale' 
  location: location 
  tags: tags 
  properties: { 
    targetResourceUri: appServicePlan.id 
    enabled: true 
    profiles: [ 
      { 
        name: 'Auto created scale condition' 
        capacity: { 
          minimum: string(zoneRedundant ? 3 : autoScaleSettings!.minCapacity) 
          maximum: string(autoScaleSettings!.maxCapacity) 
          default: string(zoneRedundant ? 3 : autoScaleSettings!.minCapacity) 
        } 
        rules: [ 
          ... 
        ] 
      } 
    ] 
  } 
}

Utiliser les ressources de manière efficace

Utilisez des services partagés. La centralisation et le partage de certaines ressources permettent d'optimiser les coûts et de réduire les frais généraux de gestion. Placez des ressources réseau partagées dans le réseau virtuel hub.

Exemple : L’implémentation de référence place le pare-feu Azure, Azure Bastion et Key Vault dans le réseau virtuel hub.
Supprimez les environnements inutilisés. Supprimez les environnements hors production après les heures de travail ou pendant les jours fériés pour optimiser les coûts. Vous pouvez utiliser l'infrastructure en tant que code pour supprimer des ressources Azure et des environnements entiers. Supprimez la déclaration de la ressource que vous souhaitez supprimer du modèle Bicep. Utilisez l’opération de simulation pour afficher un aperçu des modifications avant qu’elles ne prennent effet. Sauvegardez les données dont vous avez besoin ultérieurement. Renseignez-vous sur les dépendances de la ressource que vous supprimez. S'il existe des dépendances, il se peut que vous deviez également mettre à jour ou supprimer ces ressources. Pour plus d’informations, consultez la documentation relative à l'opération de simulation du déploiement Bicep.
Colocalisez les fonctionnalités. En cas de capacité excédentaire, il est possible de colocaliser les ressources et les fonctionnalités de l'application sur une seule ressource Azure. Par exemple, plusieurs applications web peuvent utiliser un seul serveur (plan App Service) ou un cache unique peut prendre en charge plusieurs types de données.

Exemple : L’implémentation de référence utilise une seule instance Azure Cache pour Redis pour la gestion des sessions dans les applications web front-end (stockage des jetons MSAL et des paniers) et back-end (stockage des données relatives aux concerts à venir). Elle opte pour la plus petite référence SKU Redis, offrant une capacité plus importante que nécessaire, exploitée de manière efficace en employant plusieurs types de données pour contrôler les coûts.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez la liste de contrôle de l'examen de la conception pour l'excellence opérationnelle. Le modèle d’application web fiable implémente l’infrastructure en tant que code pour les déploiements d’infrastructure et la surveillance pour l’observabilité.

Automatiser le déploiement

Utilisez un pipeline CI/CD pour déployer les modifications du contrôle de code source en production. Si vous utilisez Azure DevOps, vous devez utiliser Azure Pipelines. Si vous utilisez GitHub, utilisez les actions GitHub. Azure prend en charge les modèles ARM (JSON), Bicep et Terraform et dispose de modèles pour chaque ressource Azure. Pour plus d’informations, consultez la documentation relative aux modèles Bicep, Azure Resource Manager et Terraform et à l'infrastructure reproductible.

Exemple : L’implémentation de référence utilise Azure Dev CLI et l’infrastructure en tant que code (modèles Bicep) pour créer des ressources Azure, configurer l’installation et déployer les ressources requises.

Configuration de l’analyse

Pour surveiller votre application web, collectez et analysez les métriques et les journaux à partir du code de votre application, de l’infrastructure (runtime) et de la plateforme (ressources Azure). Ajoutez un paramètre de diagnostic pour chaque ressource Azure de votre architecture. Chaque service Azure a un ensemble différent de journaux et de métriques que vous pouvez capturer. Pour plus d’informations, consultez la documentation relative à la surveillance de la plateforme et à la surveillance d'App Service.

Surveiller les métriques de référence

Utilisez Azure Application Insights pour suivre les métriques de référence, telles que le débit des requêtes, la durée moyenne des requêtes, les erreurs et la surveillance des dépendances. Utilisez AddApplicationInsightsTelemetry à partir du package NuGet Microsoft.ApplicationInsights.AspNetCore pour activer la collecte de données de télémétrie. Pour plus d’informations, consultez la documentation relative à l'activation des données de télémétrie Application Insights et à l'injection de dépendances dans .NET.

Exemple : L’implémentation de référence utilise le code suivant pour configurer les métriques de référence dans Application Insights (voir le code suivant).

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

Créer des données de télémétrie personnalisées en fonction des besoins

Utilisez Application Insights pour collecter des données de télémétrie personnalisées afin de mieux comprendre les utilisateurs de votre application web. Créez une instance de la classe TelemetryClient et utilisez les méthodes TelemetryClient pour créer la métrique appropriée. Transformez la requête en widget Tableau de bord Azure.

Exemple : L’implémentation de référence ajoute des métriques qui aident l’équipe des opérations à déterminer si l'application web réalise correctement les transactions. Il valide que l’application web est en ligne en surveillant si les clients peuvent passer des commandes, et non en mesurant le nombre de demandes ou l’utilisation du processeur. L’implémentation de référence utilise TelemetryClient via l’injection de dépendances et la méthodeTrackEvent pour collecter des données de télémétrie sur les événements liés à l’activité du panier. Les données de télémétrie permettent de garder trace des billets ajoutés, supprimés et achetés par les utilisateurs (voir le code suivant).

AddToCart compte le nombre de fois où les utilisateurs ajoutent un certain billet (ConcertID) au panier.
RemoveFromCart enregistre les billets que les utilisateurs suppriment du panier.
CheckoutCart enregistre un événement chaque fois qu’un utilisateur achète un billet.

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

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

Collecter des métriques basées sur les journaux

Suivez les métriques basées sur les journaux pour obtenir une meilleure visibilité sur l’intégrité et les métriques essentielles de l’application. Vous pouvez utiliser des requêtes Langage de requête Kusto (KQL) dans Application Insights pour rechercher et organiser des données. Pour plus d’informations, consultez Indicateurs de performance basés sur un journal d’Azure Application Insights et Indicateurs de performance pré-agrégés et basés sur le journal dans Application Insights.

Activer les diagnostics de plateforme

Un paramètre de diagnostic dans Azure vous permet de spécifier les journaux et les indicateurs de performance de plateforme que vous souhaitez collecter et où les stocker. Les journaux de plateforme sont des journaux intégrés qui fournissent des informations de diagnostic et d’audit. Vous pouvez activer les diagnostics de plateforme pour la plupart des services Azure, mais chaque service définit ses propres catégories de journaux. Différents services Azure ont des catégories de journaux à choisir.

Activer les diagnostics pour tous les services pris en charge. Les services Azure créent automatiquement des journaux de plateforme, mais le service ne les stocke pas automatiquement. Vous devez activer le paramètre de diagnostic pour chaque service, et vous devez l’activer pour chaque service Azure qui prend en charge les diagnostics.
Envoyez les diagnostics à la même destination que les journaux d’application. Lorsque vous activez les diagnostics, vous choisissez les journaux que vous souhaitez collecter et où les envoyer. Vous devez envoyer les journaux de plateforme à la même destination que les journaux d’application afin de pouvoir mettre en corrélation les deux jeux de données.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour en savoir plus, consultez la documentation relative à la liste de vérification de l'examen de la conception pour l'efficacité des performances. Le modèle d’application web fiable utilise le modèle Cache-Aside pour réduire la latence des données soumises à de nombreuses requêtes.

Utiliser le modèle Cache-Aside

Le modèle Cache-Aside est une stratégie de mise en cache qui améliore 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. Lorsque l'application web reçoit une requête de données, elle effectue d'abord une recherche dans le cache. Si les données sont introuvables, elle les récupère dans la base de données, répond à la requête et met à jour le cache en conséquence. Cette approche 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 renforce également la disponibilité du service en réduisant la charge sur le magasin de données principal et en minimisant les risques de panne.

Exemple : L’implémentation de référence améliore l’efficacité de l’application en mettant en cache des données critiques, les données critiques, telles que les informations sur les concerts à venir, essentielles pour la vente de billets. Elle utilise le cache en mémoire distribué d'ASP.NET Core pour le stockage des éléments en mémoire. L'application utilise automatiquement Azure Cache pour Redis lorsqu'elle trouve une chaîne de connexion spécifique. Elle prend également en charge les environnements de développement locaux sans Redis pour simplifier la configuration et réduire les coûts et la complexité. 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();
    }
}

Pour plus d’informations, consultez la documentation relative à la mise en cache distribuée dans ASP.NET Core et à la méthode AddDistributedMemoryCache.

Mettre en cache les données les plus nécessaires

Donnez la priorité à la mise en cache des données les plus fréquemment consultées. Identifiez les points de données clés qui favorisent l'engagement utilisateur et les performances du système. Implémentez des stratégies de mise en cache pour ces zones spécifiques afin d'optimiser l'efficacité du modèle Cache-Aside, en réduisant de manière significative la latence et la charge de la base de données. 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.

Exemple : L’implémentation de référence met en cache les données relatives aux concerts à venir. La page Concerts à venir crée le plus de requêtes à SQL Database et produit une sortie cohérente pour chaque visite. Le modèle Cache-Aside met en cache les données après la première demande de cette page afin de réduire la charge sur la base de données. Le code suivant utilise la méthode GetUpcomingConcertsAsyncpour extraire des données dans le cache Redis à partir de SQL Database. La méthode remplit le cache avec les derniers concerts. La méthode filtre les données en fonction de l'heure, les trie et les renvoie au contrôleur pour l'affichage des résultats (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>();
}

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

Exemple : L’implémentation de référence met en cache les données pendant une heure uniquement. Il dispose d’un processus permettant d’effacer la clé de cache lorsque les données changent. La méthode CreateConcertAsync efface la clé de cache (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.

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

Tester les performances de la base de données

Les performances de la base de données peuvent affecter les performances et la scalabilité d’une application. Il est important de tester les performances de votre base de données pour vous assurer qu’elle est optimisée. Les principales considérations à prendre en compte incluent le choix de la région cloud appropriée, le regroupement de connexions, le modèle de mise en cache de côté et l’optimisation des requêtes.

Tester les tronçons réseau. Le déplacement d’une application vers le cloud peut introduire des tronçons réseau et une latence supplémentaires dans votre base de données. Vous devez tester les tronçons supplémentaires introduits par le nouvel environnement cloud.
Établissez un niveau de référence en matière de performances. Vous devez utiliser des indicateurs locaux de performances comme base de référence initiale pour comparer les performances des applications dans le cloud.

Étapes suivantes

Déployez l’implémentation de référence en suivant les instructions du référentiel GitHub. Utilisez les ressources suivantes pour en savoir plus sur les applications .NET, les applications web, les bonnes pratiques du cloud et le processus de migration.

Mise à niveau d’applications .NET Framework

L’implémentation de référence se déploie sur une App Service qui exécute Windows, mais elle peut s’exécuter sur Linux. La plateforme Windows App Service vous permet de déplacer des applications web .NET Framework vers Azure sans mettre à niveau vers des versions plus récentes du framework. Pour plus d’informations sur les plans de App Service Linux ou sur les nouvelles fonctionnalités et améliorations des performances ajoutées aux dernières versions de .NET, consultez les conseils suivants.

Vue d’ensemble du portage de .NET Framework vers .NET. Obtenez des conseils en fonction de votre type spécifique d’application .NET.
Vue d’ensemble de l’Assistant Mise à niveau de .NET. Découvrez un outil de console qui peut vous aider à automatiser un grand nombre des tâches associées à la mise à niveau de projets .NET Framework.
Migration de ASP.NET vers ASP.NET Core dans Visual Studio. Découvrez une extension Visual Studio qui peut vous aider avec les migrations incrémentielles d’applications web.

Présentation des applications web sur Azure

Pour une présentation pratique des applications web .NET sur Azure, consultez ce guide pour le déploiement d’une application web .NET de base.

Meilleures pratiques du cloud

Pour obtenir des conseils sur l’adoption et l’architecture d’Azure, consultez :

Cloud Adoption Framework. Peut aider votre organisation à préparer et à exécuter une stratégie pour créer des solutions sur Azure.
Well-Architected Framework. Un ensemble de principes directeurs qui peuvent être utilisés pour améliorer la qualité d’une charge de travail.

Pour les applications qui requièrent un SLO plus élevé que le modèle d’application web fiable, consultez la documentation relative aux charges de travail stratégiques.

Recommandations en matière de migration

Les outils et ressources suivants peuvent vous aider à migrer des ressources locales vers Azure.

Azure Migrate fournit un service simplifié de migration, de modernisation et d’optimisation pour Azure qui gère l’évaluation et la migration des applications web, des SQL Server et des machines virtuelles.
Les guides de migration Azure Database fournissent des ressources pour différents types de bases de données et différents outils conçus pour votre scénario de migration.
Azure App Service accélérateur de zone d’atterrissage fournit des conseils pour le renforcement et la mise à l’échelle des déploiements App Service.
Évaluation de l'application et du code Azure Migrate