Atteindre et maintenir des performances
 Protéger contre la dégradation des performances pendant que le système est en cours d’utilisation et qu’il évolue. |
|---|
Le développement n’est pas un effort unique. C’est un processus continu. Attendez-vous aux changements de performances à mesure que les fonctionnalités changent. Il existe une variance dans les modèles utilisateur et les profils, même les modifications des optimisations dans d’autres piliers Azure Well-Architected. Toute modification peut forcer les ressources de charge de travail.
Coffre guard le système des modifications afin qu’il ne revient pas sur les cibles de performances. Intégrez les tests et la surveillance dans le processus de développement. Testez les performances du système en production avec une charge réelle et simulez cette charge avec des tests automatisés avant la production. Dans les deux cas, vous devez avoir des pratiques de surveillance en place à des fins de vérification.
Tout au long du cycle de vie du développement, effectuez différents types de tests à différentes étapes. Dans les phases initiales, testez la preuve de concept pour vous assurer que les résultats des performances ne sont pas entièrement inattendus. Au fur et à mesure que le développement progresse, effectuez des tests manuels et à faible effort pour établir des benchmarks. Au cours de la phase de génération, commencez à développer des tests de performances de routine automatisés qui évaluent la latence, les niveaux de stress, la capacité de charge et d’autres caractéristiques définies dans les plans de test.
La surveillance doit faire partie intégrante de cet effort, plutôt que d’être un exercice isolé. Vous pouvez voir comment le système et ses ressources s’exécutent au fil du temps. Vous pouvez ensuite les affiner pour optimiser leur valeur et s’assurer qu’ils continuent à respecter les normes de performances.
N’oubliez pas que les cibles de performances varient au fil du temps, en réponse aux modifications. Mettez à jour le modèle de performances en fonction des métriques testées et surveillées. Indiquez clairement l’augmentation, la réduction ou l’absence d’effet sur les performances des flux.
Soyez toujours prêt à renégocier et à réinitialiser les attentes avec les parties prenantes de l’entreprise.
Exemple de scénario
Contoso Event Solutions propose un produit que le personnel de l’entrée d’événements peut utiliser pour analyser les tickets sur un appareil mobile et permettre rapidement l’entrée à un lieu ticketé pour ceux autorisés. Le système est disponible avec un mode complètement hors connexion et également en tant que version connectée au cloud pour les lieux préoccupés par la duplication des tickets. Le mode hors connexion est très performant, mais le mode en ligne a manqué ses objectifs de performances. L’équipe de développement a récemment investi quelques cycles de développement pour y travailler, et les performances sont désormais beaucoup améliorées et répondent aux objectifs. Les parties prenantes de l’entreprise aimeraient développer leur base de clients pour prendre en charge bientôt des lieux plus importants.
Tester les performances dans le développement
Formalisez les tests de performances en tant que portes de qualité qui peuvent approuver ou refuser la promotion de la mise en production et le déploiement final en production.
Ces case activée points garantissent que chaque étape de déploiement répond aux normes de performances requises avant de passer à la suivante. Les case activée points permettent d’empêcher la régression involontaire des performances. Par exemple, si les performances sont nettement inférieures aux attentes, vous pouvez bloquer une mise en production jusqu’à ce que des améliorations soient apportées.
Problématique de Contoso
- L’équipe a investi beaucoup de temps et d’efforts pour obtenir des performances acceptables pour la version en ligne de l’application, mais elle n’a pas de système en place actuellement pour empêcher une régression.
- La fonctionnalité suivante qu’ils prévoient d’ajouter est la possibilité pour un lieu de choisir d’afficher une image du participant, ainsi que l’analyse pour une vérification supplémentaire. Il y a un risque que la recherche de photos et le téléchargement supplémentaires ralentiront le processus.
- Sans processus formel en place, il existe un risque que les performances des versions en ligne et hors connexion puissent être affectées négativement par les fonctionnalités supplémentaires et qu’elles peuvent tomber en dessous de leurs cibles.
Application de l’approche et résultats
- L’équipe intègre des tests de performances automatisés dans le pipeline de build. En implémentant des critères stricts de « go/no-go » dans le pipeline de build, l’équipe est plus confiante que la nouvelle fonctionnalité ne sera pas publiée avec une régression des performances.
- L’équipe a été sage d’implémenter ce test, car elle a intercepté un bogue dans la dernière version de la build. Le bogue a forcé l’application à tenter de se connecter à Internet pour télécharger une image pendant que le scanneur était défini sur le mode hors connexion, ce qui entraînait un délai d’expiration avec chaque analyse de ticket. L’interception de ce bogue avec les tests automatisés a permis à l’équipe de corriger le bogue avant de publier la nouvelle version.
Optimiser à l’aide de l’observabilité
Configurez un processus reproductible pour surveiller les transactions réelles en production et les écarts par rapport à vos objectifs de performances. En outre, utilisez des transactions synthétiques en production et configurez des alertes de surveillance sur les régressions de performances.
Vous souhaitez obtenir des informations sur les performances réelles de votre système sous la charge réelle qui n’ont pas pu être simulées par le biais de tests. Vous pouvez ensuite identifier de manière proactive les problèmes et les domaines d’amélioration tels que les goulots d’étranglement potentiels, les ressources sous-utilisées et d’autres préoccupations.
Problématique de Contoso
- Pendant un événement où ils utilisent la validation de ticket en ligne, le système back-end est fortement utilisé.
- Il existe un système APM (Application Performance Monitoring) en place, mais il n’a pas été utilisé pour surveiller l’intégrité des transactions de production.
Application de l’approche et résultats
- L’équipe a décidé d’adopter des processus mis à jour pour mieux capturer les métriques d’intégrité :
- Ils configurent les alertes en fonction des centiles de performances et des valeurs hors norme des performances. Aucune alerte n’indique que le système effectue des plages acceptables pour la plupart des analyses de tickets.
- Une fois qu’un événement hors connexion est terminé, les données de télémétrie pour les analyses de ticket sont chargées par lots et ces métriques passent également par un processus pour rechercher des écarts par rapport aux performances acceptables.
- L’équipe implémente également des tests de transaction synthétiques pour améliorer leur surveillance des performances. Étant donné que presque tous les événements ont lieu le week-end et le soir, l’équipe utilise des tests de transaction synthétiques tout au long de la semaine pour générer une base de référence de performances plus cohérente.
Gérer les modifications de charge de travail intelligemment
Résolvez l’érosion des performances à mesure que l’utilisation augmente, que les fonctionnalités changent et que les données s’accumulent au fil du temps pour maintenir les performances. Réinitialisez les attentes et établissez de nouvelles cibles, si le réglage précis offre uniquement des avantages à court terme.
En adoptant cette approche, vous pouvez préserver l’état des performances avant que la dégradation ne se développe en problèmes qui affectent négativement l’expérience utilisateur au-delà de la plage acceptable.
La modification des cibles réinitialise le modèle de performances et vous ne perdez pas de temps dans l’optimisation du système qui a déjà atteint sa capacité.
Problématique de Contoso
- L’équipe commerciale a intégré de manière agressive de nouveaux lieux d’événements dans le système. Les affaires sont bonnes.
- Le système de surveillance de la charge de travail a commencé à remarquer que le budget des performances est consommé dans de plus en plus de temps, même sans l’introduction de nouvelles fonctionnalités.
- Sans changement, cette trajectoire peut entraîner une régression inacceptable des performances, ce qui risque de provoquer une panne si un incident se produit.
Application de l’approche et résultats
- L’équipe se rend compte que, à mesure que d’autres clients intègrent, le mécanisme de recherche de données pour les événements en ligne effectue une analyse très importante sur les données pour de nombreuses requêtes.
- Certaines optimisations de requête ont contribué à empêcher l’utilisation accrue d’entraîner des dommages supplémentaires. Au cours des prochains mois, l’équipe prévoit de décomposer différents événements en différentes partitions de données afin de réduire le besoin d’analyse des requêtes. Cela prendra en charge le scale-out continu de la charge de travail.
- Ils se rendent également compte qu’ils peuvent optimiser davantage le système pour augmenter en supprimant les données de ticket d’anciens événements. La recherche d’anciens événements n’est pas quelque chose que le système de validation de ticket doit faire, afin que les données puissent être déplacées dans un magasin dédié à la création de rapports et à la recherche historique.