Concevoir des expériences de chaos
Votre application stratégique doit être résiliente et prête à répondre aux défaillances. Toutefois, il est difficile de prédire les scénarios de défaillance potentiels dans le cloud. L’ingénierie du chaos vous permet de mener des expériences de défaillance dans un environnement contrôlé pour identifier les problèmes susceptibles de survenir pendant le développement et le déploiement. Vous injectez délibérément des erreurs réelles et observez la façon dont le système réagit.
Dans cette unité, vous utilisez Azure Chaos Studio. Ce service vous aide à mesurer, comprendre et améliorer la résilience de vos applications et services cloud. Il vous prépare à réagir rapidement si une défaillance se produit dans des conditions défavorables en production.
Effectuer une analyse du mode d’échec
Quand vous concevez une expérience de chaos, la première étape consiste à effectuer une analyse des modes de défaillance (FMA) des composants d’application pour identifier les scénarios de défaillance potentiels :
Listez tous les composants pertinents pour un flux utilisateur qui doivent être disponibles et fonctionnels. Par exemple, le flux utilisateur de paiement utilise Azure App Service, Azure Functions et la base de données Azure Cosmos DB.
Pour chaque composant, listez les cas de défaillance possibles, leur impact ainsi que les mesures d’atténuation potentielles.
Voyons le résultat de l’analyse FMA effectuée pour les composants de l’exemple de flux utilisateur de paiement Contoso Shoes.
Azure App Service pour l’hébergement de l’application front-end
| Risque | Impact | Atténuation possible |
|---|---|---|
| Panne de zone de disponibilité | Les instances de cette zone peuvent devenir indisponibles. Une panne complète n’est pas attendue, car la redondance de zone est activée sur le plan App Service. |
Faites en sorte de pouvoir gérer la charge supplémentaire sur les instances restantes, et fournissez suffisamment d’espace pour ce scénario tout en atteignant les objectifs de performances. |
| Insuffisance de ports SNAT | Les connexions sortantes ne peuvent pas être créées. Par conséquent, les appels en aval, tels que les appels à la base de données, échouent. | Utilisez des points de terminaison privés pour la connexion aux composants en aval. |
| Une instance individuelle devient non saine | Le trafic utilisateur routé vers une instance non saine peut entraîner des performances médiocres ou même échouer complètement. | Utilisez la fonctionnalité de vérification d’intégrité d’App Service. Cette fonctionnalité permet l’identification automatique et le remplacement des instances non saines par de nouvelles instances saines. |
Azure Functions pour la logique de paiement
| Risque | Impact | Atténuation possible |
|---|---|---|
| Performances de démarrage lentes (à froid) | Dans la mesure où le plan Consommation d’Azure Functions est utilisé, les nouvelles instances n’offrent pas de garanties de performance. Une forte demande sur le service (de la part de « voisins bruyants ») peut provoquer une longue durée de démarrage de la fonction de paiement qui affecte les objectifs de performances. |
Effectuez une mise à niveau vers le plan Premium Azure Functions. |
| Panne de stockage sous-jacente | Si le compte de stockage sous-jacent devient indisponible, la fonction cesse de s’exécuter correctement. | Utilisez un calcul à charge équilibrée avec stockage régional ou un calcul à charge équilibrée avec stockage partagé GRS. |
Base de données Azure Cosmos DB
| Risque | Impact | Atténuation possible |
|---|---|---|
| Renommage d’une base de données ou d’une collection | En raison d’une incompatibilité de configuration, une perte de données est possible. L’application ne peut accéder à aucune donnée tant que la configuration n’a pas été mise à jour, et que ses composants n’ont pas redémarré. | Évitez cette situation en utilisant des verrous au niveau de la base de données et de la collection. |
| Panne dans une région d’écriture | Si la région primaire (ou la région d’écriture) rencontre une panne, le compte Azure Cosmos DB promeut automatiquement une région secondaire en tant que nouvelle région d’écriture primaire quand le basculement automatique (géré par le service) est configuré sur le compte Azure Cosmos DB. Le basculement s’effectue vers une autre région dans l’ordre de priorité des régions que vous avez spécifié. | Configurez le compte de base de données pour utiliser plusieurs régions et le basculement automatique. En cas de défaillance, le service effectue automatiquement un basculement, et empêche tout problème durable dans l’application. |
| Limitation importante due à l’absence d’unités de requête | Certaines empreintes peuvent présenter une très forte utilisation d’Azure Cosmos DB, tandis que d’autres peuvent toujours traiter les requêtes. | Utilisez une meilleure distribution de charge sur plus d’empreintes, ou ajoutez d’autres unités de requête. |
Concevoir une expérience de chaos
Pour concevoir une expérience de chaos, choisissez quelques cas de défaillance. Le choix peut être basé sur la probabilité que la défaillance se produise ou sur l’impact possible.
L’objectif de l’expérience est de valider les mesures de résilience que vous avez implémentées dans votre application. Par exemple, supposons que vous exécutiez votre application sur App Service, et que vous activiez la redondance de zone. Si toutes les instances sous-jacentes d’une zone tombent en panne, vous vous attendez à ce que votre application continue de s’exécuter.
Utilisez Chaos Studio pour injecter les erreurs dans les composants appropriés. Chaos Studio offre une bibliothèque d’erreurs parmi lesquelles vous pouvez choisir. Toutefois, étant donné que la bibliothèque d’erreurs ne couvre pas tout, vous devrez peut-être ajuster votre scénario. Vous devrez peut-être trouver d’autres outils pour vous aider à injecter l’échec.
Important
Ciblez uniquement un environnement de non-production durant vos expériences. L’injection d’erreurs dans votre environnement de production peut être risquée, et nécessite de l’expérience et une planification.
Exemple : panne et basculement Azure Cosmos DB
Supposez que vous choisissez le scénario de défaillance « panne de région d’écriture » d’Azure Cosmos DB listé dans le tableau. L’hypothèse est la suivante : un basculement lancé par le service ne doit pas avoir d’impact durable sur l’application. Si cette hypothèse se confirme, cela signifie que vous avez vérifié que votre mesure de résilience consistant à effectuer une réplication sur plusieurs régions a l’effet positif souhaité sur la fiabilité de l’application.
Pour simuler cette erreur, utilisez la défaillance Azure Cosmos DB de la bibliothèque d’erreurs Chaos Studio.
Cet exemple concerne un basculement Azure Cosmos DB qui s’exécute pendant 10 minutes (PT10M), et utilise West US 2 comme nouvelle région d’écriture. Il part du principe que West US 2 a déjà été configuré comme l’une des régions de réplication en lecture.
{
"name": "branchOne",
"actions": [
{
"type": "continuous",
"name": "urn:csci:microsoft:cosmosDB:failover/1.0",
"parameters": [
{
"key": "readRegion",
"value": "West US 2"
}
],
"duration": "PT10M",
"selectorid": "myCosmosDbResource"
}
]
}
Une fois l’expérience terminée, Chaos Studio retourne la région d’écriture à sa valeur d’origine.
Avant de pouvoir injecter une erreur sur une ressource Azure, vous devez activer le paramètre de cibles et fonctionnalités correspondant pour cette ressource. Ce paramètre contrôle les erreurs qui peuvent s’exécuter sur les ressources activées pour l’injection d’erreurs. Quand vous utilisez des cibles et des fonctionnalités avec d’autres mesures de sécurité, vous pouvez éviter l’injection d’erreurs accidentelle ou malveillante.
Vous avez conçu à la fois les tests de charge et les expériences de chaos, vous devez à présent les automatiser dans vos pipelines pour qu’ils s’exécutent de manière cohérente et régulière. Dans l’unité suivante, vous allez découvrir comment ajouter les tests à vos pipelines CI/CD.