Le framework Azure Well Architected : pilier de l’efficacité des performances

Un groupe de cinq piliers englobant la fiabilité, la sécurité, l’optimisation des coûts, l’excellence opérationnelle et l’efficacité des performances.

Le Well-Architected Framework a été introduit en juillet 2020 pour aider à gérer la complexité croissante du cloud. Les piliers du cadre peuvent rarement être mis en œuvre individuellement. Au fur et à mesure que vous développez la capacité fonctionnelle de vos charges de travail, l’impact sur le système peut être considérable. L’optimisation des coûts doit être mise en balance avec l’efficacité des performances. À l’inverse, l’excellence opérationnelle peut compléter et améliorer l’efficacité de la performance. Azure Well Architected Framework est un puissant groupe d’outils. Une fois la charge de travail en production, Azure fournit Azure Advisor pour comprendre les changements qui se produisent à mesure que des fonctionnalités et des services sont ajoutés. Il est donc recommandé d’examiner régulièrement vos charges de travail et d’utiliser les outils de surveillance d’Azure sur les charges de travail critiques.

Un exemple de la façon dont le pilier efficacité de la performance a été intégré dans le plan de conception pour répondre aux exigences d’un client

« Si le seul outil dont vous disposez est un marteau, il est difficile de manger des spaghettis. » ~David Allen.

Le scénario suivant représente l’exigence d’un client Azure en matière de performances ciblant la conception d’un service d’API RESTful avec une exigence de débit. Cette exigence a été mise en balance avec des exigences opposées de fiabilité et de coût.

Les modèles de fiabilité sont nécessaires pour augmenter la disponibilité du système, mais incluent généralement des mécanismes de nouvelle tentative qui sont invisibles pour l’utilisateur et ne sont pas disponibles dans les données de corrélation. Par conséquent, les performances perçues diminuent. Les tentatives ou d’autres modèles de fiabilité enregistreront l’occurrence et la durée pour identifier la baisse des performances.

Le coût peut être affecté en fonction de la nécessité de mettre à l’échelle les instances de ressources. Si le trafic augmente et que cela est inattendu, la mise à l’échelle augmentera le coût, ou le plafond de coût configuré dans Azure empêchera une mise à l’échelle suffisante pour répondre aux exigences de performances.

Utilisons un scénario avec une architecture cloud distribuée. Je couvrirai également certains outils supplémentaires tels que k6, Postman, WireMock, Faker et Azure Application Insights qui ont été utilisés et deviennent de nouveaux outils pour votre boîte à outils.

Le défi des architectures distribuées

« Je n’ai pas besoin d’un disque dur dans mon ordinateur si je peux accéder au serveur plus rapidement… transporter ces ordinateurs non connectés est byzantin en comparaison. » ~ – Steve Jobs, co-fondateur, ancien PDG et président, Apple Inc.

Vous avez peut-être déjà deviné que nous nous concentrerons sur un scénario client utilisant une architecture distribuée à l’échelle mondiale, une collecte de données opérationnelles et une instrumentation. Ce scénario utilise Azure Application Insightsune caractéristique de Moniteur Azure. Nous créons un tableau de bord affichant des données interrogées pour identifier les problèmes affectant les systèmes interdépendants, y compris les performances de la solution cible. Notre objectif est l’efficacité des performances, qui est obtenue en faisant correspondre les ressources disponibles d’une application à une demande pour ces ressources.

Revenant à notre scénario de projet, il utilise Services d’applications Azure en tant que ressource API orientée client. Il y a plusieurs raisons à cette décision qui sortent du cadre de notre Pilier de performance. Cependant, Services d’applications Azure est une sélection de conception naturelle pour nos besoins. Avec la plupart des autres options, vous devrez instrumenter votre application avec Azure App Insights, mais App Services intègre l’agent App Insights par défaut. En sélectionnant cette option, l’application dispose d’une surveillance d’exécution par défaut. L’installation du SDK App Insights offre une flexibilité supplémentaire, mais n’était pas requise pour le scénario de projet.

Notre scénario, si vous vous en souvenez, a une architecture distribuée. Notre instrumentation a une corrélation de télémétrie distribuée. C’est bon d’y aller, non ? Eh bien, seulement si vous configurez le « operation_Id » à la valeur de l’identifiant de la demande.

Écoute et bon dimensionnement

« Quand j’étais petite, j’ai toujours voulu être quelqu’un. Maintenant, je me rends compte que j’aurais dû être plus précis. ~ Lily Tomlin

Maintenant que nous avons discuté de la surveillance des performances, abordons les exigences fonctionnelles du scénario. Le client a fourni à l’équipe un SLA de performance arbitraire de 3 secondes pour traiter toute demande. Heureusement, notre solution fournit « mise à l’échelle automatique » pour nos instances d’application. Nous pourrions utiliser notre instrumentation pour nous assurer que nous respectons l’exigence de 3 secondes en définissant une alerte. Bien que cette solution soit très réactive. Du point de vue de la production, nous ne savons pas à quoi ressemble le débit historiquement.

La ligne de base – Agir sur les faits

Revenons donc à notre pilier Efficacité de la performance. Supposons qu’une tempête inattendue se dirige vers l’un de vos sites régionaux. Le service commercial s’attend à une augmentation imprévue du trafic vers l’API. Que pensent les entreprises de cet accord de niveau de service en 3 secondes ? Nous pourrions deviner la quantité de trafic supplémentaire que nous obtiendrions de cette région et fixer une limite supérieure à notre mise à l’échelle automatique pour tenir compte du coussin spéculé. Nous pourrions garder quelqu’un sur appel pour gérer manuellement le besoin potentiel.

Cependant, nous demanderons des données historiques pour le trafic moyen et maximal, car nous avons utilisé le pilier Performance Efficiency. Une facette de l’ingénierie cloud lors de la collecte des exigences de performance consiste à s’assurer que vous disposez à la fois d’une référence historique et d’une référence cible pour les pics d’activité et la croissance attendue de la demande.

À ce stade, il est crucial d’interviewer, d’écouter, de comprendre et de documenter les principaux objectifs et mesures d’un projet. Identifiez comment il interagira dans le contexte et le domaine délimités, impactant à la fois les clients internes et externes. Posez des questions orientées pour identifier les attentes qui peuvent se transformer en lacunes. Parfois, ces données sont des connaissances tacites dans la mémoire de quelqu’un. Cependant, la plupart des entreprises conservent des analyses marketing remontant à au moins plusieurs années.

Ces données de base peuvent également fournir des avantages en termes de coûts en cas de ralentissements liés à des événements basés sur des secteurs d’activité saisonniers, tels que l’industrie du ski ou les fournitures de piscine ou des tendances économiques susceptibles d’entraîner des anomalies de trafic pour notre application.

Bon, alors maintenant nous avons fait notre diligence raisonnable. Nous avons fait nos déductions et reçu l’acceptation de nos conclusions. Cependant, nous devons maintenant tester notre application sous des charges moyennes et maximales, et nous avons une nouvelle exigence du Product Owner. Nous utilisons « Postman » pour effectuer des tests fonctionnels et automatiser les tests d’intégration pour notre API, et notre client souhaite réutiliser le travail effectué dans ces tests. Bien qu’il soit idéal d’utiliser JMeter en raison de son utilisation généralisée et donc de réduire les problèmes de personnel pour le client, il ne fournit pas l’interface requise avec Postman. Après quelques recherches, nous avons trouvé un produit (k6, 2021) et Microsoft l’approuve. Il s’agit d’un outil cloud moderne qui s’intègre aux tests automatisés DevOps et a une empreinte minimale. Cependant, il est disponible depuis moins d’un an mais jouit d’une solide réputation, d’une utilisation croissante et d’une excellente documentation. Une preuve de concept (POC) utilisant l’application (avec des réponses fictives) et exerçant tous les modèles de débit que nous avons rassemblés lors de l’analyse de base, a fourni la preuve que la solution était solide.

Directeurs

Nous avons pris en compte tous les principes Azure Well-Architected Framework (Microsoft, 2021) et sommes arrivés à une solution proposée. Nous avons évalué les modèles de performances (Microsoft, 2021) et les compromis du point de vue de la conception.

POC et test de modèle

« Si un utilisateur final perçoit une mauvaise performance de votre site Web, son prochain clic sera probablement sur your-competition.com. » ~ Ian Molyneaux

La conception et la mise en œuvre de l’exemple de projet utilisent k6 segmenté en URL et charge utile, Postman comme source de données, des modules JavaScript et l’inclusion de WireMock, et Faker fournissant des données de test fictives dans la charge utile sont la courtoisie d’une solution de performance. Vous pouvez développer la modularité nécessaire à la réutilisation dans les phases itératives de test lors du déploiement des API RESTful.

• Générez les URL et les charges utiles en intégrant Postman à « k6 ».
• Injectez les données d’entrée fictives à l’aide de truqueur basé sur des règles métier dans des espaces réservés dans la charge utile.
• Nous définissons des scénarios de test basés sur l’emplacement mondial et le produit demandé en testant à la fois le scénario moyen et le scénario de pointe. Étant donné que notre test est isolé, nous pouvons nous assurer que les données de test fournies pour les emplacements avant d’introduire la prochaine phase de test.
• Les tests renvoient des résultats de débit moyen, min, max, moyen, 90 et 95 pour chaque scénario.

Les résultats ont été nettement plus rapides que prévu, même lors du déclenchement d’événements de nouvelle tentative. Au fur et à mesure que les emplacements globaux sont ajoutés, le débit se normalise. Bien que le résultat ci-dessus ait été exécuté sur un système de démonstration, les utilisateurs virtuels, les itérations et la durée sont cohérents avec les tests de performances résultant de la ligne de base du client.

Liste de contrôle

…. Même Han et Chewie utilisent une liste de contrôle. ~ Jon Stewart

Nous avons maintenant atteint le point dans les modèles de performance Azure Well-Architected (Microsoft, 2021) par rapport à l’applicabilité aux exigences non fonctionnelles et fonctionnelles. Ensuite, nous avons pesé et documenté les compromis du point de vue de la conception.

Nous avons terminé les tests de performances avec une population représentative tenant compte des problèmes de latence attendus. Nous avons terminé notre liste de contrôle Framework (Microsoft, 2021), y compris les recommandations de conception. Données de performances capturées par Azure Application Insights.

Conclusion

Ce scénario pour Azure Well-Architected Framework sert d’exemple des processus exécutés par les équipes Microsoft Azure de Perficient pour nos clients. Certains des modèles et pratiques discutés ici sont utilisés depuis des décennies, certains sont plus spécifiques à la conception Cloud. Ils ont des compromis de conception qui doivent être évalués par rapport aux exigences. Fournir une isolation lors des tests de performances avant une publication garantira que seule l’application et non ses dépendances sont validées pour une latence supplémentaire. L’utilisation d’Application Insights fournit des temps de réponse (débit) pour vos services et peut fournir des tests de corrélation lorsqu’ils sont correctement configurés. Le cadre est une ligne directrice et considère les compromis architecturaux (Microsoft, 2022) en fonction des exigences de domaine et fonctionnelles. L’utilisation du cadre s’est avérée efficace pour atteindre les objectifs commerciaux tout en offrant de la flexibilité.

k6. (2021, novembre). documentation k6. Récupéré de la documentation k6 : https://k6.io/docs/

Microsoft. (2021, décembre). Liste de contrôle de l’efficacité des performances. Extrait de la documentation du produit Azure : https://docs.microsoft.com/en-us/azure/architecture/framework/scalability/performance-efficiency

Microsoft. (2021, décembre). Modèles d’efficacité des performances. Extrait de la documentation du produit Azure : https://docs.microsoft.com/en-us/azure/architecture/framework/scalability/performance-efficiency-patterns

Microsoft. (2021, décembre). Principes d’efficacité de la performance. Extrait de la documentation du produit Azure : https://docs.microsoft.com/en-us/azure/architecture/framework/scalability/principles

Microsoft. (2022, mai). Compromis pour l’efficacité des performances. Extrait de la documentation du produit Azure : https://docs.microsoft.com/en-us/azure/architecture/framework/scalability/tradeoffs

Documentation Microsoft Azure. (2022, mai). Corrélation de télémétrie dans Application Insights. Récupéré de la documentation Azure Monitor : https://docs.microsoft.com/en-us/azure/azure-monitor/app/correlation

modularité nécessaire à la réutilisation dans les phases itératives de test lors du déploiement des API RESTful.

A propos de l’auteur

Rob est un architecte de solutions chez Perficient, dans l’unité commerciale Microsoft, travaillant dans l’équipe Azure, et est passionné par le travail avec les architectures et les cadres cloud émergents. Rob fournit des solutions d’architecture logicielle au niveau de l’entreprise depuis plus de deux décennies. Il a été consulté, encadré et coaché ​​en assurant la direction technique, de conception et de processus de nombreuses équipes et clients interfonctionnels dans divers marchés verticaux tout au long de sa carrière. Rob a terminé la classe de maître IDesign Architect et a étudié et mis en œuvre les méthodologies d’architecture logicielle Zachman, TOGOF et FEA et a commencé son parcours de migration et de solutions vers le cloud en 2005.

Plus de cet auteur