Appliquer les modèles WAF à des architectures réelles

Appliquer les modèles du WAF à des architectures réelles n’est pas un exercice théorique : cela nécessite d’évaluer chaque décision de conception au regard des cinq piliers et d’effectuer des compromis éclairés. Un point de départ courant est le diagramme d’architecture : suivez le parcours d’une demande utilisateur à travers chaque composant et demandez-vous, pour chaque étape, ce qui se passe si ce composant tombe en panne, combien il coûte et comment il est sécurisé.

Considérez une application web monolithique traditionnelle : une seule VM exécutant ensemble un serveur web et une base de données derrière une adresse IP publique. Au regard des piliers du WAF, cette architecture obtient de mauvais résultats dans les cinq domaines : absence de redondance (fiabilité), base de données sur le même hôte que la couche web (sécurité), VM active en permanence quel que soit le trafic (coût), absence de CI/CD (excellence opérationnelle) et mise à l’échelle verticale uniquement (efficacité des performances).

Pour répondre au pilier Fiabilité, répartissez le niveau web sur plusieurs VMs situées dans différentes zones de disponibilité, protégez la base de données par une réplication géographique vers une région secondaire et placez un Azure équilibreur de charge en frontal. Cela élimine le point unique de défaillance et permet à l’application de continuer à fonctionner en cas de panne d’une zone ou d’une région, sans intervention manuelle.

Pour le pilier Sécurité, séparez le niveau web et la base de données dans des sous-réseaux différents, avec des règles NSG qui autorisent uniquement le niveau web à se connecter au port de la base de données. Stockez la chaîne de connexion à la base de données dans Azure Key Vault et utilisez une identité managée sur l’application web pour la récupérer à l’exécution, afin d’éliminer les identifiants codés en dur du code de l’application et des fichiers de configuration.

Pour l’optimisation des coûts, remplacez les VMs toujours actives par un Virtual Machine Scale Set qui réduit le nombre d’instances pendant les heures creuses. Pour la base de données, évaluez si un service PaaS managé tel qu’Azure SQL Database, avec un niveau DTU approprié, coûte moins cher qu’une VM complète avec SQL Server. Achetez des instances réservées pour toute capacité de base que vous pouvez prévoir 12 mois à l’avance.

Améliorez l’excellence opérationnelle en définissant toute l’infrastructure sous forme de modèles Bicep ou ARM stockés dans un système de contrôle de version. Créez un pipeline CI/CD dans Azure Pipelines ou GitHub Actions qui déploie automatiquement les modifications de l’infrastructure et du code de l’application. Ajoutez des étapes de validation du déploiement — tests automatisés de bon fonctionnement et approbation manuelle — avant que les modifications n’atteignent la production.

Pour l’efficacité des performances, introduisez Azure Cache for Redis devant la base de données afin de mettre en cache les requêtes fréquemment lues et de réduire la charge de la base de données. Déployez les ressources statiques (images, CSS, JavaScript) via Azure CDN afin de les servir depuis des nœuds périphériques proches des utilisateurs du monde entier. Effectuez un test de charge de l’application après chaque modification pour confirmer que les améliorations sont mesurables.

Chaque modification de l’architecture implique un compromis. Par exemple, adopter une architecture multizone améliore la fiabilité, mais augmente les coûts (deux zones = deux VMs). Ajouter la mise en cache Redis améliore les performances, mais accroît la complexité opérationnelle (un autre service à surveiller et à gérer). Une bonne documentation de l’architecture consigne explicitement ces compromis afin que les futurs architectes comprennent pourquoi les décisions ont été prises.

Évitez d’essayer d’atteindre la perfection en une seule refonte : cette approche est coûteuse, risquée et lente. Adoptez plutôt un cycle d’amélioration itératif : effectuez une évaluation Well-Architected, identifiez les trois problèmes ayant le plus fort impact, corrigez-les, mesurez les progrès, puis recommencez. Cette approche aligne les améliorations architecturales sur la livraison agile et rend les progrès visibles pour les parties prenantes à chaque sprint.

Microsoft publie des architectures de référence pour les modèles courants de charges de travail dans l’Azure Architecture Center. Elles comprennent des architectures d’applications web, des microservices sur AKS, des pipelines d’analyse de données et bien d’autres modèles. Chaque architecture de référence a déjà été évaluée selon les piliers WAF et contient des remarques sur les compromis effectués pour le modèle concerné.

Utilisez des enregistrements de décisions d’architecture (ADR) pour documenter les choix architecturaux importants, le contexte dans lequel ils ont été faits, les solutions envisagées et leurs implications pour les piliers WAF. Les ADR stockés dans le système de contrôle de version avec le code source créent un historique vérifiable qui aide les nouveaux membres de l’équipe à comprendre pourquoi l’architecture se présente ainsi.

Vérifiez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) abordés dans cette leçon.

Dans cette leçon, vous avez appris que les modèles WAF s’appliquent en évaluant chaque décision architecturale selon les cinq piliers ; que les améliorations peuvent être apportées de manière itérative en commençant par les problèmes ayant le plus fort impact ; et que les compromis doivent être documentés afin que les futurs architectes comprennent le raisonnement suivi. Nous allons maintenant étudier les SLA Azure et voir comment calculer des SLA composites pour les architectures composées de plusieurs services.