Modifier

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

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.

Diagramme de l’architecture de l’implémentation de référence.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 planifier une implémentation du modèle d'application web fiable, procédez comme suit :

Définir les objectifs métier

La première étape de la transition vers le cloud computing consiste à définir vos objectifs métier. Le modèle d'application web fiable met l’accent sur l’importance de définir des objectifs immédiats et futurs pour votre application web. Ces objectifs influencent votre choix de services cloud et l’architecture de votre application web dans le cloud.

Exemple : La société fictive Relecloud vend des billets via son application web locale. 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.

Choisir les services gérés 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.

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

Choisissez la meilleure plateforme d’hébergement d’applications pour votre application web. Azure propose de nombreuses options de calcul pour répondre aux exigences des applications web. Pour vous aider dans votre démarche, consultez l'arbre de décision de calcul Azure.

Exemple : 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-up, un scale-down, un scale-in et un scale-out en fonction du trafic utilisateur et des paramètres.

Gestion des identités

Choisissez la meilleure solution de gestion des identités pour votre application web. Pour plus d’informations, consultez la documentation relative à la comparaison des solutions de gestion des identités et aux méthodes d’authentification.

Exemple : 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

Choisissez la meilleure base de données pour votre application web. Pour vous aider dans votre démarche, consultez l'arbre de décision de magasin de données Azure.

Exemple : L’application web utilisait SQL Server localement, et Relecloud souhaitait 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.

Analyse des performances des applications

Choisissez un outil de monitoring des performances des applications pour votre application web. Application Insights est la solution de gestion des performances des applications (APM) native d'Azure. Il s’agit d’une fonctionnalité de la solution de supervision Azure, Azure Monitor.

Exemple : 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.

Exemple : La charge de l’application web de Relecloud est fortement axée sur l’affichage des concerts et des détails de la salle. Relecloud a ajouté Azure Cache pour 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

Choisissez le meilleur équilibreur de charge pour votre application web. Azure dispose de plusieurs équilibreurs de charge. Pour vous aider dans votre démarche, consultez la documentation relative au choix du meilleur équilibreur de charge pour votre application.

Exemple : 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.

Pare-feu d’application web

Choisissez un pare-feu d’applications web pour protéger votre application web contre les attaques web. Azure Web Application Firewall (WAF) est le pare-feu d’applications web d'Azure, qui fournit une protection centralisée de vos applications web contre les vulnérabilités et exploitations web courantes.

Exemple : Relecloud avait besoin de protéger l'application web contre les attaques web. La société 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 définir des configurations pour résoudre les problèmes de sécurité des 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 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.

Exemple : 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

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

Exemple : L’application web locale de Relecloud stockait des secrets locaux dans des fichiers de configuration de code, mais il est préférable d'externaliser les secrets. 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.

  • 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

Choisissez la meilleure solution de stockage pour votre application web. Pour plus d’informations, consultez Évaluer vos options de stockage.

Exemple : Localement, l’application web 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

Choisissez d’activer l’accès privé uniquement aux services Azure. Azure Private Link permet d’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.

Exemple : Relecloud a utilisé 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

Choisissez s’il faut ajouter des services de sécurité réseau à vos réseaux virtuels. Le pare-feu Azure est un pare-feu réseau avec état qui inspecte le trafic réseau. Azure Bastion vous permet de vous connecter de manière sécurisée aux machines virtuelles sans exposer de ports RDP/SSH.

Exemple : 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.

Choisir l’architecture appropriée

Après avoir défini les moyens disponibles pour votre application web et sélectionné les services cloud les plus appropriés, vous devez déterminer la meilleure architecture pour votre application web. Votre architecture doit prendre en charge vos exigences métier, les exigences techniques et le SLO.

Choisir la redondance d’architecture

Les objectifs métier déterminent le niveau d’infrastructure et de redondance des données dont votre application web a besoin. Le SLO de l’application web fournit une bonne base de référence pour comprendre vos exigences de redondance. Calculez le contrat SLA composite en tenant compte de toutes les dépendances sur le chemin critique de disponibilité. Les dépendances doivent inclure des services Azure et des solutions non Microsoft.

Attribuez une estimation de disponibilité à chaque dépendance. Les contrats de niveau de service (SLA) fournissent un bon point de départ, mais ils ne tiennent pas compte du code, des stratégies de déploiement et des décisions architecturales en matière de connectivité.

Exemple : Relecloud a identifié les services sur le chemin critique de disponibilité. La société a utilisé des contrats SLA Azure pour les estimations de disponibilité. Sur la base du calcul du SLA composite, Relecloud avait besoin d’une architecture multirégion pour respecter le SLO de 99,9 %.

Choisir une topologie de réseau

Choisissez la topologie de réseau adaptée à vos exigences web et de mise en réseau. La topologie de réseau hub-and-spoke est la configuration standard d'Azure. Elle offre des avantages en matière de coût, de gestion et de sécurité. Elle prend également en charge les options de connectivité hybride pour les réseaux locaux.

Exemple : Relecloud a choisi une topologie de réseau hub-and-spoke pour renforcer la sécurité de son déploiement multirégion tout en réduisant les coûts et les frais généraux de gestion.

Choisir la redondance des données

Assurez la fiabilité des données en les répartissant entre les régions et les zones de disponibilité d'Azure ; plus la séparation géographique est importante, plus la fiabilité est élevée.

  • Définissez un objectif de point de récupération (RPO). Le RPO définit la perte maximale de données tolérable pendant une panne, ce qui détermine la fréquence à laquelle les données doivent être répliquées. Par exemple, pour un RPO d'une heure, il faut accepter de perdre jusqu'à une heure de données récentes.

  • Implémentez la réplication de données. Alignez la réplication de données sur votre architecture et votre RPO. Azure prend généralement en charge la réplication synchrone dans les zones de disponibilité. L'utilisation de plusieurs zones permet d'améliorer facilement la fiabilité. Pour les applications web multirégions dans une configuration active et passive, répliquez les données dans la région passive en fonction du RPO de l’application web, en veillant à ce que la fréquence de réplication soit supérieure au RPO. Les configurations actives-actives nécessitent une synchronisation des données en quasi-temps réel entre les régions, ce qui peut nécessiter des modifications du code.

  • Créez un plan de basculement. Élaborez un plan de basculement (reprise d’activité après sinistre) décrivant les stratégies de réponse aux pannes, caractérisées par un temps d'arrêt ou une perte de fonctionnalité. Spécifiez les objectifs de temps de récupération (RTO) pour le temps d’arrêt maximal acceptable. Veillez à ce que le processus de basculement soit plus rapide que le RTO. Optez pour des mécanismes de basculement automatisés ou manuels afin d'assurer la cohérence et le contrôle, et détaillez le processus de retour à la normale. Testez le plan de basculement pour s'assurer de son efficacité.

Étape suivante

Cet article vous a montré comment planifier une implémentation du modèle d’application web fiable. L’étape suivante consiste à mettre en application les techniques d’implémentation du modèle d'application web fiable.