Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
À mesure que les applications et services natifs cloud deviennent plus complexes, le déploiement de modifications et de nouvelles versions peut être difficile. Les pannes sont fréquemment causées par des déploiements ou des mises en production défectueux. Toutefois, les erreurs peuvent également se produire après le déploiement, lorsqu’une application commence à recevoir du trafic réel, en particulier dans les charges de travail complexes qui s’exécutent dans des environnements cloud multilocataires hautement distribués et qui sont gérées par plusieurs équipes de développement. Ces environnements nécessitent davantage de mesures de résilience, telles que la logique de nouvelle tentative et la mise à l’échelle automatique, qui sont généralement difficiles à tester pendant le processus de développement.
C’est pourquoi la validation continue dans un environnement similaire à l’environnement de production est importante, afin que vous puissiez trouver et résoudre les problèmes ou bogues dès le plus tôt possible dans le cycle de développement. Les équipes de charge de travail doivent tester au début du processus de développement (décaler vers la gauche) et permettre aux développeurs d’effectuer des tests dans un environnement proche de l’environnement de production.
Les charges de travail critiques ont des exigences de haute disponibilité avec des cibles de 3, 4 ou 5 neufs (99,9 %, 99,99 % ou 99,999 % respectivement). Il est essentiel d’implémenter des tests automatisés rigoureux pour atteindre ces objectifs.
La validation continue dépend de chaque charge de travail et des caractéristiques architecturales. Cet article fournit un guide pour la préparation et l’intégration d’Azure Load Testing et d’Azure Chaos Studio dans un cycle de développement normal.
1 : Définir des tests basés sur des seuils attendus
Le test continu est un processus complexe qui nécessite une préparation appropriée. Ce qui est testé et les résultats attendus doivent être clairs.
Dans PE :06 - Recommandations pour les tests de performances et RE :08 - Recommandations pour la conception d’une stratégie de test de fiabilité, Azure Well-Architected Framework vous recommande de commencer par identifier les scénarios clés, les dépendances, l’utilisation attendue, la disponibilité, les performances et les objectifs d’extensibilité.
Vous devez ensuite définir un ensemble de valeurs de seuil mesurables pour quantifier les performances attendues des scénarios clés.
Conseil / Astuce
Parmi les exemples de valeurs de seuil, citons le nombre attendu de connexions utilisateur, les demandes par seconde pour une API donnée et les opérations par seconde pour un processus en arrière-plan.
Vous devez utiliser des valeurs de seuil pour développer un modèle d’intégrité pour votre application, à la fois pour les tests et pour l’exploitation de l’application en production.
Ensuite, utilisez les valeurs pour définir un test de charge qui génère un trafic réaliste pour tester les performances de référence de l’application et pour valider les opérations de mise à l’échelle attendues. Le trafic utilisateur artificiel soutenu est nécessaire dans les environnements de préproduction, car sans utilisation, il est difficile de révéler des problèmes d’exécution.
Le test de charge garantit que les modifications apportées à l’application ou à l’infrastructure ne provoquent pas de problèmes et que le système répond toujours aux critères de performances et de test attendus. Une exécution de test ayant échoué qui ne répond pas aux critères de test indique que vous devez ajuster la ligne de base ou qu’une erreur inattendue s’est produite.
Même si les tests automatisés représentent une utilisation quotidienne, vous devez exécuter régulièrement des tests de charge manuels pour vérifier comment le système répond aux pics inattendus.
La deuxième partie de la validation continue est l’injection de défaillances (ingénierie du chaos). Cette étape vérifie la résilience d’un système en testant la façon dont il répond aux erreurs. En outre, toutes les mesures de résilience, telles que la logique de nouvelle tentative, la mise à l’échelle automatique et d’autres, fonctionnent comme prévu.
2 - Implémenter la validation avec le test de charge et Chaos Studio
Microsoft Azure fournit ces services managés pour implémenter le test de charge et l’ingénierie du chaos :
- Azure Load Testing génère une charge utilisateur synthétique sur les applications et les services.
- Azure Chaos Studio offre la possibilité d’effectuer des expérimentations de chaos en injectant systématiquement des défaillances dans les composants d’application et l’infrastructure.
Vous pouvez déployer et configurer Chaos Studio et Load Testing via le portail Azure, mais, dans le contexte de la validation continue, il est plus important que vous disposiez d’API pour déployer, configurer et exécuter des tests de manière programmatique et automatisée. L’utilisation de ces deux outils vous permet d’observer comment le système réagit aux problèmes et sa capacité à se guérir automatiquement en réponse aux défaillances de l’infrastructure ou de l’application.
La vidéo suivante montre une implémentation combinée de Chaos et load Testing intégrée dans Azure DevOps :
Si vous développez une charge de travail stratégique, tirez parti des instructions détaillées fournies dans le cadre d’Azure Well-Architected Framework.
Une option consiste à exécuter le test de performance directement à partir du pipeline de bout en bout (E2E) utilisé pour démarrer des environnements de développement individuels propres à une branche.
Le pipeline exécute automatiquement un test de charge, avec ou sans expériences chaos (en fonction de la sélection) en parallèle :
Remarque
L’exécution d’expériences de chaos pendant un test de charge peut entraîner une latence plus élevée, des temps de réponse plus élevés et des taux d’erreur temporairement accrus. Attendez-vous à des temps de réponse et une latence plus élevés jusqu’à ce qu’une opération de scale-out se termine ou qu’un basculement soit terminé, par rapport à une exécution sans expériences de chaos.
Selon que les tests de chaos sont activés et que le choix des expériences, les définitions de référence peuvent varier, car la tolérance aux erreurs peut être différente dans l’état « normal » et l’état « chaos ».
3 – Ajuster les seuils et établir une ligne de base
Enfin, ajustez les seuils de test de charge pour les exécutions régulières afin de vérifier que l’application (toujours) fournit les performances attendues et ne produit aucune erreur. Disposer d’une base de référence distincte pour les tests de chaos qui tolère les pics attendus des taux d’erreur et des performances réduites temporaires. Cette activité est continue et doit être répétée régulièrement. Par exemple, après l’introduction de nouvelles fonctionnalités, la modification des références SKU de service et d’autres.
Le service Azure Load Testing fournit une fonctionnalité intégrée appelée critères de test qui permet de spécifier certains critères qu’un test doit réussir. Cette fonctionnalité peut être utilisée pour implémenter différentes lignes de base.
La fonctionnalité est disponible via le portail Azure, et via l’API de test de charge, et les scripts wrapper développés dans le cadre d’Azure Mission-critical offrent une option permettant de transmettre une définition de base de référence JSON.
Nous vous recommandons vivement d’intégrer ces tests directement dans vos pipelines CI/CD et de les exécuter au cours des premières étapes du développement de fonctionnalités.
En résumé, l’échec est inévitable dans tout système distribué complexe et la solution doit donc être conçue (et testée) pour gérer les défaillances. Les directives de charge de travail critique du cadreWell-Architected et les implémentations de référence peuvent vous aider à concevoir et exploiter des applications hautement fiables pour tirer une valeur maximale du cloud Microsoft.
Étape suivante
Passez en revue la zone de conception de déploiement et de test pour les charges de travail stratégiques.