Validation continue avec Test de charge Azure et Azure Chaos Studio
À mesure que les applications et les services natifs Cloud deviennent plus complexes, le déploiement des modifications et des nouvelles mises en production s’y rapportant peut être problématique. Les pannes sont fréquemment provoqués par des mises en production ou des déploiements défaillants. Mais les erreurs peuvent également se produire après les déploiements, quand une application commence à recevoir un trafic réel, particulièrement dans des charges de travail complexes qui s’exécutent dans des environnements cloud multi-locataire hautement distribués et qui sont gérées par plusieurs équipes de développement. Ces environnements nécessitent d’autres mesures de résilience, telles qu’une logique de nouvelle tentative et une mise à l’échelle automatique, qui sont généralement difficiles à tester pendant le processus de développement.
C’est la raison pour laquelle une validation constante est importante dans un environnement similaire à l’environnement de production afin que vous puissiez rechercher et corriger tout problème ou bogue aussi rapidement que possible dans le cycle de développement. Les équipes de charge de travail doivent effectuer des tests de manière anticipée dans le processus de développement (décalage vers la gauche) et faciliter la tâche de test des développeurs dans un environnement proche de l’environnement de production.
Les charges de travail stratégiques ont des exigences de haute disponibilité avec des cibles de 3, 4 ou 5 neuf (99,9 %, 99,99 % ou 99,999 % respectivement). Il est indispensable d’implémenter des tests automatisés rigoureux pour atteindre ces objectifs.
La validation constante dépend de chaque charge de travail et des caractéristiques d’architecture. Cet article offre un guide pour préparer et intégrer Test de charge Azure et Azure Chaos Studio dans un cycle de développement régulier.
1 : Définir des tests en fonction de seuils attendus
Les tests constants constituent un processus complexe qui nécessitent une préparation appropriée. La définition des éléments testés et des résultats attendus doit être claire.
Dans PE:06 – Recommandations en matière de tests de performances et RE:08 – Recommandations en matière de conception d’une stratégie de test de fiabilité, les Azure Well-Architected Framework vous recommandent de commencer par l’identification des scénarios, des dépendances, de l’utilisation attendue, de la disponibilité, des performances et des cibles de scalabilité clés.
Vous devez ensuite définir un ensemble de valeurs de seuil mesurables pour quantifier les performances attendues des scénarios clés.
Conseil
Les exemples de valeurs attendues incluent le nombre attendu de connexions utilisateur, de requêtes par seconde d’une API donnée et d’opérations par seconde d’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, tant pour les tests que pour l’exploitation de l’application en production.
Utilisez ensuite 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 des applications, valider les opérations de mise à l’échelle attendues, et ainsi de suite. Un trafic utilisateur artificiel soutenu est nécessaire dans des environnements de pré-production, car il est difficile de révéler des problèmes de runtime sans utilisation.
Un test de charge garantit que les modifications apportées à l’application ou à l’infrastructure n’occasionnent pas de problèmes, et que le système remplit toujours les critères de performances et de test attendus. Un échec d’exécution de test 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 des tests automatisés sont utilisés quotidiennement, vous devez exécuter régulièrement des tests de charge manuels pour vérifier la façon dont le système répond à des pics inattendus.
La deuxième partie de la validation continue consiste en l’injection de défaillances (ingénierie du chaos). Cette étape vérifie la résilience d’un système en testant la manière dont celui-ci répond à des défaillances. Elle vérifie également que toutes les mesures de résilience (logique de nouvelle tentative, mise à l’échelle automatique et autres) fonctionnent comme prévu.
2 – Implémenter une validation avec Test de charge et Chaos Studio
Pour implémenter des tests de charge et une ingénierie du chaos, Microsoft Azure fournit les services gérés suivants :
- Test de charge Azure génère une charge utilisateur synthétique sur des applications et services.
- Azure Chaos Studio offre la possibilité d’effectuer une expérimentation de chaos, en injectant systématiquement des défaillances dans les composants et l’infrastructure d’une application.
Vous pouvez déployer et configurer Chaos Studio et Test de charge via le Portail Azure mais, dans le contexte d’une validation constante, il est plus important que vous ayez des API pour déployer, configurer et exécuter des tests de manière programmatique et automatisée. L’utilisation conjointe de ces deux outils en même temps vous permet d’observer la manière dont le système réagit aux problèmes, et sa capacité à se réparer automatiquement pour répondre à des défaillances d’infrastructure ou d’application.
La vidéo suivante montre une implémentation combinée de Chaos et de Test de charge, intégrée dans Azure DevOps :
Si vous développez une charge de travail stratégique, tirez parti des architectures de référence, des conseils détaillés, des exemples d’implémentation et des artefacts de code fournis dans le cadre du Projet stratégique Azure et de Azure Well-Architected Framework.
L’implémentation stratégique déploie le service Test de charge Azure via Terraform et contient une collection de scripts wrapper PowerShell Core pour interagir avec le service via son API. Ces scripts peuvent être incorporés directement dans un pipeline de déploiement.
Une option dans l’implémentation de référence consiste à exécuter le test de charge directement à partir du pipeline de bout en bout (e2e) utilisé pour exécuter des environnements de développement individuels (spécifiques d’une branche) :
Le pipeline exécute automatiquement un test de charge, avec ou sans expériences de chaos (selon 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 longs et des taux d’erreur temporairement accrus. Vous constaterez de telles augmentations par rapport à une exécution sans expérience de chaos jusqu’à ce qu’une opération de scale-out ou un basculement s’achèvent.
Si les tests de chaos sont activés, selon le choix des expériences, les définitions de ligne de base peuvent varier, car la tolérance aux erreurs peut différer dans l’état « normal » et dans l’état « chaos ».
3 – Ajuster des seuils et établir un planning de référence
Enfin, ajustez les seuils de test de charge des exécutions régulières pour vérifier que l’application fournit (toujours) les performances attendues et ne génère aucune erreur. Dotez-vous d’une ligne de base distincte pour les tests de chaos, qui tolère les pics attendus de taux d’erreur et de baisses de performances temporaires. Cette activité est continue et doit être répétée régulièrement. Par exemple, après avoir introduit de nouvelles fonctionnalités, modifié des références (SKU) de service, etc.
Le service Test de charge Azure fournit une fonctionnalité intégrée appelée critères de test, qui permet de spécifier des critères qu’un test doit réunir. Cette fonctionnalité peut être utilisée pour implémenter différentes lignes de base.
La fonctionnalité est disponible via le portail Azure et l’API de test de charge, et les scripts wrapper développés dans le cadre de l’infrastructure stratégique Azure offrent une option permettant de remettre une définition de ligne de base basée sur JSON.
Nous vous recommandons vivement d’intégrer ces tests directement dans vos pipelines CI/CD, et de les exécuter lors des premières étapes de développement de fonctionnalités. Pour obtenir un exemple d’implémentation, voir l’exemple d’implémentation dans l’implémentation de référence critique Azure.
En résumé, une défaillance étant inévitable dans tout système distribué complexe, la solution doit donc être architecturée (et testée) pour gérer les défaillances. Les conseils sur les charges de travail critiques Well-Architected Framework et les implémentations de référence peuvent vous aider à concevoir et à exploiter des applications hautement fiables pour dégager une valeur maximale du cloud Microsoft.
Étape suivante
Découvrez la zone de conception de déploiement et de test pour les charges de travail stratégiques.