Modèle d’application web fiable pour .NET : planifier l’implémentation

Le modèle d’application web fiable fournit des conseils d’implémentation essentiels pour les applications web qui passent au cloud. Il définit la façon dont vous devez mettre à jour (replateformer) votre application web pour réussir dans le cloud.

Il existe deux articles sur le modèle d’application web fiable pour .NET. Cet article décrit les décisions importantes pour planifier l’implémentation du modèle. L’article complémentaire fournit des conseils sur le code et l’architecture pour appliquer le modèle. Il y a une implémentation de référence (exemple d’application web) du modèle que vous pouvez déployer.

Architecture

Le modèle d’application web fiable est un ensemble de principes avec des conseils d’implémentation. Il ne s’agit pas d’une architecture spécifique. Le contexte métier, l’application web existante et l’objectif de niveau de service (SLO) souhaité sont des facteurs critiques qui façonnent l’architecture de votre application web. Le diagramme suivant (Figure 1) représente l’architecture de l’implémentation de référence. Il s’agit d’un exemple qui illustre les principes du modèle d’application web fiable. Il est important que votre application web adhère aux principes du modèle d’application web fiable, et non à cette architecture spécifique. Figure 1. Architecture de l’implémentation de référence cible. Téléchargez un fichier Visio de cette architecture. Pour une estimation des coûts de cette architecture, consultez les sections Coût de l’environnement de production et Coût de l’environnement hors production.

Principes et implémentation

Le tableau suivant répertorie les principes du modèle d’application web fiable et la façon d’implémenter ces principes dans votre application web. Pour plus d’informations, consultez la Vue d’ensemble du modèle d’application web fiable et la Série de vidéos de modèles d’application web fiable (YouTube).

Tableau 1. Principes de modèle et comment les implémenter.

Le contexte métier

Pour le contexte métier, ces conseils suivent le parcours cloud d’une société fictive appelée Relecloud. Relecloud doit répondre à la demande croissante de l’entreprise avec un minimum d’investissement dans l’application monolithique existante. Le trafic vers l’actuelle application locale a augmenté en raison de la hausse des ventes. Relecloud s’attend à ce que la demande continue d’augmenter. D’après ses conclusions, l’infrastructure locale ne propose pas de solution économique de mise à l’échelle. Relecloud a déterminé que la migration de l’application web vers le cloud offrait le meilleur retour sur investissement. Ce choix lui permettrait d’atteindre ses objectifs à court et à long terme.

Tableau 2. Objectifs à court et à long terme concernant les applications web.

Application web existante

L’application web existante est locale. Il s’agit d’une application web ASP.NET monolithique. Relecloud exécute une application web métier d’e-commerce sur deux machines virtuelles et dispose d’une base de données Microsoft SQL Server. L’application web est destinée aux employés. Les seuls utilisateurs de l’application sont les employés du centre d’appels de Relecloud. Les employés de Relecloud utilisent l’application pour acheter des tickets pour le compte de clients de Relecloud. L’application web locale souffre de problèmes courants. Ces défis incluent des chronologies étendues pour générer et expédier de nouvelles fonctionnalités difficiles à mettre à l’échelle différents composants de l’application sous une charge plus élevée.

Objectif de niveau de service

Un objectif de niveau de service (SLO) pour la disponibilité définit la disponibilité d’une application web pour les utilisateurs. Vous devez définir un SLO et les moyens disponibles pour votre application web. Relecloud a défini un SLO cible de 99,9 % en termes de disponibilité, soit environ 8,7 heures de temps d’arrêt par an. Pour Relecloud, l’application web est disponible lorsque les employés du centre d’appels peuvent acheter des billets 99,9 % du temps. Lorsque vous avez une définition de disponible, répertoriez toutes les dépendances sur le chemin critique de disponibilité. Les dépendances doivent inclure des services Azure et des solutions tierces.

Pour chaque dépendance dans le chemin critique, vous devez attribuer un objectif de disponibilité. Les contrats de niveau de service (SLA) d’Azure constituent un bon point de départ. Cependant, les contrats SLA ne prennent pas en compte (1) les temps d’arrêt associés au code d’application s’exécutant sur ces services ; (2) les méthodologies de déploiement/opérations ; ni (3) les choix d’architecture pour connecter les services. Par conséquent, la métrique de disponibilité que vous affectez à une dépendance ne doit pas dépasser le contrat SLA.

Relecloud a utilisé des contrats SLA Azure pour les services Azure. Le diagramme suivant illustre la liste des dépendances de Relecloud avec des objectifs de disponibilité pour chaque dépendance (voir Figure 2).

Figure 2. Carte des dépendances du SLA. Les SLA Azure peuvent faire l’objet de modifications. Les SLA représentés ici sont des exemples visant à illustrer le processus d’évaluation de la disponibilité composite. Pour plus d’informations, voir la section SLA pour Online Services.

Avec une carte des dépendances SLA, vous devez utiliser les formules des SLA composites pour estimer la disponibilité composite des dépendances sur le chemin critique. Ce nombre doit atteindre ou dépasser votre SLO. Relecloud a besoin d’une architecture multirégion pour répondre au SLO de 99,9 %. Pour plus d’informations, consultez Formule SLA composite et Formule SLA multirégionale.

Choisir les services appropriés

Les services Azure que vous choisissez doivent prendre en charge vos objectifs à court terme. Ils doivent également vous préparer à atteindre tous les objectifs à long terme. Pour accomplir les deux, vous devez choisir des services qui (1) répondent au SLO ; (2) nécessitent un effort minimal de changement de plateforme ; et (3) prennent en charge les plans de modernisation futurs.

Lorsque vous migrez une application web vers le cloud, vous devez sélectionner les services Azure qui mettent en miroir les fonctionnalités locales clés. L’alignement permet de réduire l’effort de changement de plateforme. Par exemple, vous devez conserver le même moteur de base de données (de SQL Server à Azure SQL Database) et la même plateforme d’hébergement d’applications (d’IIS sur Windows Server à Azure App Service). La conteneurisation de votre application ne répond généralement pas aux objectifs à court terme du modèle d’application web fiable. Cependant, la plateforme d’application que vous choisissez maintenant doit prendre en charge la conteneurisation s’il s’agit d’un objectif à long terme.

Plateforme d’application

Azure App Service est un service HTTP géré pour l’hébergement d’applications web, d’API REST et de back-ends mobiles. Azure propose de nombreuses options de calcul viables. Pour plus d’informations, consultez l’arbre de décision de calcul. L’application web utilise Azure App Service car elle répond aux exigences suivantes :

• SLA haut. Il a un contrat SLA élevé qui répond au SLO 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-up, un scale-down, un scale-in et un scale-out en fonction du trafic utilisateur et des paramètres.

Gestion des identités

Microsoft Entra ID est un service de gestion des identités et des accès basé sur le cloud. Il authentifie et autorise les utilisateurs en fonction des rôles qui s’intègrent à notre application. Microsoft Entra ID fournit à l’application les capacités suivantes :

• Authentification et autorisation. L’application doit authentifier et autoriser les employés du centre d’appels.
• Évolutif. 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.
• Prendre en charge les protocoles d’autorisation. Il prend en charge OAuth 2.0 pour les identités managées et OpenID Connect pour la prise en charge future de B2C.

Base de données

Azure SQL Database est une base de données relationnelle polyvalente et un service géré qui prend en charge les données relationnelles et spatiales, JSON, spatiales et XML. L’application web utilisée SQL Server localement, et l’équipe souhaite 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 l’application web utilise Azure SQL Database, car elle répond aux exigences 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 base de données à partir de SQL Server locaux.
• 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 temps.
• Expertise et remaniement minimal. SQL Database tire parti de l’expertise interne et nécessite un minimum de travail.

Analyse des performances des applications

Application Insights est une fonctionnalité d’Azure Monitor qui fournit une gestion extensible des performances des applications et une surveillance pour les applications web en direct. L’application web utilise Application Insights pour les raisons suivantes :

• Détection des anomalies. Il détecte automatiquement les problèmes de performances.
• Résolution des problèmes. Il vous aide à diagnostiquer les problèmes dans l’application en cours d’exécution.
• Données de télémétrie. 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.
• Résolution d’un manque de visibilité local. La solution locale n’a pas d’APM. Application Insights offre une intégration facile à la plateforme et au code de l’application.

Azure Monitor est une suite complète d’outils de supervision qui collectent des données à partir de différents services Azure. Pour plus d'informations, consultez les pages suivantes :

• Détection intelligente dans Application Insights
• Cartographie d’application : triage des applications distribuées
• Profiler des applications App Service en production avec Application Insights
• Analyse de l'utilisation avec Application Insights
• Bien démarrer avec Metrics Explorer
• Tableau de bord de vue d’ensemble d’Application Insights
• Requêtes de journal dans Azure Monitor

Cache

Azure Cache pour Redis est un magasin de données managé en mémoire basé sur le logiciel Redis. La charge de l’application web est fortement biaisée vers l’affichage des concerts et des détails de la salle. Il a besoin d’un cache qui offre les avantages suivants :

• 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.
• Externalisé. 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 collantes. L’externalisation de l’état de session prend en charge les sessions non collantes.

Équilibreur de charge global

Azure Front Door est un équilibreur de charge global de couche 7 qui utilise le réseau principal Azure pour acheminer le trafic entre les régions. Relecloud a besoin d’une architecture multirégion pour répondre au SLO de 99,9 %. Elle doit utiliser Front Door pour fournir un routage de couche 7 entre les régions. Front Door offre également des fonctionnalités supplémentaires (comme Web Application Firewall) et positionne Relecloud pour utiliser un réseau de distribution de contenu. Le réseau de distribution de contenu assure l’accélération du site à mesure que le trafic vers l’application web augmente. L’application web utilise Azure Front Door, car elle offre les avantages suivants :

• 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 de la sonde 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.
• Surveillance de la prise en charge. 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.

Azure dispose de plusieurs équilibreurs de charge. Évaluez vos fonctionnalités système actuelles et la configuration requise pour la nouvelle application s’exécutant sur Azure, puis choisissez le meilleur équilibreur de charge pour votre application.

Pare-feu d’applications web

Azure Web Application Firewall offre une protection centralisée de vos applications web contre les vulnérabilités et les attaques courantes. Il est intégré à Azure Front Door et permet d’empêcher les attaques malveillantes à proximité des sources d’attaque avant qu’elles n’entrent dans votre réseau virtuel. Le pare-feu d’applications Web offre les avantages suivants :

• 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 pour résoudre les problèmes de sécurité des botnets.
• Parité avec l’environnement local. La solution locale est exécutée derrière un pare-feu d’applications web géré par informatique.

Stockage de configuration

Azure App Configuration est un service pour la gestion centralisée des paramètres d’application et des indicateurs de fonctionnalité. L’objectif est de remplacer la configuration basée sur les fichiers par un magasin de configuration central qui s’intègre à la plateforme d’application et au code. App Config offre les avantages suivants :

• 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.
• Prend en charge le pipeline Git. La source de vérité pour les données de configuration devait être un dépôt 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.

Passez en revue bonnes pratiques App Configuration pour déterminer si ce service convient parfaitement à votre application.

Gestionnaire de secrets

Azure Key Vault fournit un stockage centralisé des secrets d’application pour contrôler leur distribution. Il prend en charge les certificats X.509, les chaînes de connexion et les clés API à intégrer à des services tiers. Les identités managées sont la solution préférée pour la communication de service intra-Azure, mais l’application a toujours des secrets à gérer. L’application web locale stockait des secrets locaux dans des fichiers de configuration de code, mais il s’agit d’une meilleure pratique de sécurité pour externaliser les secrets. L’application web utilise Key Vault, car elle fournit les fonctionnalités suivantes :

• Chiffrement. Il prend en charge le chiffrement au repos et en transit.
• Identités managées. Les services d’application peuvent utiliser des identités managées pour accéder au magasin de secrets.
• Supervision et journalisation. Il facilite l’accès à l’audit et génère des alertes lorsque les secrets stockés changent.
• Prise en charge des certificats. Il prend en charge l’importation de certificats PFX et PEM.
• 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).

Vous pouvez incorporer des Key Vault dans des applications .NET à l’aide de l’objet ConfigurationBuilder.

Stockage d’objets

Stockage Azure fournit un stockage de fichiers. Stockage Blob Azure stocke les images de ticket obtenues. Localement, l’application web disposait d’un stockage sur disque monté sur chaque serveur web, et l’équipe souhaitait utiliser une solution de stockage de données externe.

Pour stockage Blob, l’application web utilise 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. L’application utilise le Stockage Blob pour répondre aux exigences suivantes :

• Supprimez l’accès anonyme. 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. Stockage Blob doit rendre les images de ticket résilientes contre la perte.

Sécurité des points de terminaison

Azure Private Link fournit l’accès aux services PaaS (tels que les Azure Cache pour Redis et les SQL Database) 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. Azure DNS avec Azure Private Link permet à votre solution de communiquer via un lien de sécurité renforcée avec des services Azure tels que SQL Database. L’application web utilise 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 utilisées par l’application. Les deux plateformes reflètent les configurations locales existantes pour un minimum de modifications.

Étapes suivantes

Cet article décrit comment planifier l’implémentation du modèle d’application web fiable. Vous pouvez maintenant appliquer le modèle d’application web fiable.