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é, nous allons utiliser Azure Chaos Studio. Le service vous aidera à mesurer, comprendre et améliorer la résilience de votre application cloud et de votre service. Vous serez prêt à réagir rapidement si cette défaillance se produit dans des conditions défavorables en production.
Effectuer une analyse du mode d’échec
Lorsque vous concevez une expérience de chaos, la première étape consiste à effectuer une analyse du mode d’échec (FMA) des composants d’application afin d’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 Services, Functions, et une base de données Cosmos DB.
Pour chaque composant, listez les cas de défaillance possibles, leur impact et les atténuations 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. | La fonctionnalité de contrôle d’intégrité App Service entraîne l’identification automatique des instances non saines et leur remplacement par de nouvelles instances saines. |
Azure Functions pour la logique de paiement
| Risque | Impact | Atténuation possible |
|---|---|---|
| Performances de démarrage lentes (à froid) | Un plan de consommation Azure Functions étant utilisé, les nouvelles instances n’offriront pas de garanties de performances. 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 fonctionner. | 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é dans la configuration, il peut y avoir une perte de données. L’application ne pourra pas accéder aux données tant que la configuration n’aura pas été mise à jour et que ses composants n’auront pas été redémarrés. | É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 principale (ou région d’écriture) subit une panne, le compte Azure Cosmos DB promeut automatiquement une région secondaire en tant que nouvelle région d’écriture principale lorsque le basculement automatique (managé par le service) est configuré dans le compte Azure Cosmos DB. Le basculement intervient 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 avec plusieurs régions et le basculement automatique. En cas de défaillance, le service bascule automatiquement 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. En guise d’exemple d’hypothèse, supposez que vous exécutez votre application sur App Service avec la redondance de zone activée. Si toutes les instances sous-jacentes d’une zone tombent en panne, vous vous attendez à ce que votre application continue à 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 hors production avec 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 s’avère vraie, vous avez validé le fait que votre mesure de résilience de réplication dans 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. Lorsque vous utilisez des cibles et des fonctionnalités avec d’autres mesures de sécurité, vous pouvez éviter l’injection accidentelle ou malveillante d’erreurs.
Maintenant que vous avez conçu à la fois des tests de charge et des expériences de chaos, vous devez les automatiser dans vos pipelines afin 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.