Résilience de la plateforme Azure
Conseil
Ce contenu est un extrait du livre électronique, Cloud Native .NET apps for Azure (Architecture d’applications .NET natives cloud pour Azure), disponible dans la documentation .NET ou au format PDF à télécharger gratuitement pour le lire hors connexion.
Concevoir une application fiable dans le cloud est un processus différent du développement d’applications locales traditionnelles. Bien que vous achetiez historiquement du matériel haut de gamme pour effectuer un scale-up, dans un environnement cloud, vous effectuez un scale-out. Au lieu d’essayer d’éviter les défaillances, l’objectif est de minimiser leurs effets et de maintenir la stabilité du système.
Cela dit, les applications cloud fiables présentent des caractéristiques distinctes :
- Elles sont résilientes, récupèrent normalement des problèmes et continuent de fonctionner.
- Elles offrent une haute disponibilité et s’exécutent comme prévu dans un état intègre et sans temps d’arrêt significatif.
Comprendre comment ces caractéristiques interagissent et leur incidence sur le coût est essentiel à la création d’une application native cloud fiable. Nous allons maintenant examiner les façons dont vous pouvez renforcer la résilience et la disponibilité de vos applications natives cloud en tirant parti des fonctionnalités du cloud Azure.
Concevoir avec résilience
Nous avons dit que la résilience permet à votre application de réagir en cas d’échec tout en restant fonctionnelle. Le livre blanc Résilience dans Azure fournit des conseils pour atteindre la résilience dans la plateforme Azure. Voici quelques recommandations clés :
Défaillance matérielle. Créez la redondance dans l’application en déployant des composants sur différents domaines d’erreur. Par exemple, vérifiez que les machines virtuelles Azure sont placées dans différents racks à l’aide de groupes à haute disponibilité.
Défaillance de centre de données. Créez une redondance dans l’application avec des zones d’isolation des pannes dans les centres de données. Par exemple, vérifiez que les machines virtuelles Azure sont placées dans différents centres de données isolés des pannes à l’aide de zones de disponibilité Azure.
Défaillance régionale. Répliquez les données et les composants dans une autre région afin que les applications puissent être récupérées rapidement. Par exemple, utilisez Azure Site Recovery pour répliquer des machines virtuelles Azure dans une autre région Azure.
Charge importante. Équilibrez la charge entre les instances pour gérer les pics d’utilisation. Par exemple, placez au moins deux machines virtuelles Azure derrière un équilibreur de charge pour distribuer le trafic à toutes les machines virtuelles.
Suppression ou altération accidentelle de données. Sauvegardez les données afin qu’elles puissent être restaurées en cas de suppression ou d’altération. Par exemple, utilisez Sauvegarde Azure pour sauvegarder régulièrement vos machines virtuelles Azure.
Concevoir avec redondance
L'ampleur de l'impact des défaillances est variable. Une défaillance matérielle, comme un disque défaillant, peut affecter un nœud unique dans un cluster. Mais un commutateur réseau défaillant peut impacter un rack tout entier de serveurs. Les défaillances moins courantes, comme la perte d’alimentation, peuvent perturber l’ensemble d’un centre de données. Exceptionnellement, une région entière peut être indisponible.
La redondance est un moyen de fournir la résilience des applications. Le niveau exact de redondance nécessaire dépend des besoins de votre entreprise et affecte à la fois le coût et la complexité de votre système. Par exemple, un déploiement à plusieurs régions est plus coûteux et plus complexe à gérer qu’un déploiement à une seule région. Vous aurez besoin de procédures opérationnelles pour gérer le basculement et la restauration. Tous les scénarios métiers ne justifient pas ce surcroît de complexité et ces frais supplémentaires.
Pour concevoir la redondance, vous devez identifier les chemins critiques dans votre application, puis déterminer s’il existe une redondance à chaque point du chemin d’accès. En cas de défaillance d’un sous-système, l’application basculera-t-elle vers un autre équipement ? Enfin, vous avez besoin d’une compréhension claire de ces fonctionnalités intégrées à la plateforme cloud Azure que vous pouvez utiliser pour répondre à vos exigences de redondance. Voici des recommandations pour l’architecture de la redondance :
Déployez plusieurs instances des services. Si votre application repose sur une seule instance unique d’un service, cela crée un point de défaillance unique. L’approvisionnement de plusieurs instances améliore à la fois la résilience et l’extensibilité. Lors de l’hébergement dans Azure Kubernetes Service, vous pouvez configurer de manière déclarative des instances redondantes (jeux de réplicas) dans le fichier manifeste Kubernetes. La valeur du nombre de réplicas peut être gérée par programmation, dans le portail ou via des fonctionnalités de mise à l’échelle automatique.
Tirer parti d’un équilibreur de charge. L’équilibrage de charge distribue les requêtes de votre application à des instances de service intègres, en retirant automatiquement de la rotation les instances non intègres. Lors du déploiement sur Kubernetes, l’équilibrage de charge peut être spécifié dans le fichier manifeste Kubernetes de la section Services.
Planifiez le déploiement multirégion. Si vous déployez votre application dans une seule région et que cette région devient indisponible, votre application sera elle aussi indisponible. Il se peut que cette situation soit inacceptable au regard des conditions du contrat SLA de votre application. Au lieu de cela, envisagez de déployer votre application et ses services dans plusieurs régions. Par exemple, un cluster Azure Kubernetes Service (AKS) est déployé dans une seule région. Pour protéger votre système d’une défaillance régionale, vous pouvez déployer votre application sur plusieurs clusters AKS dans différentes régions et utiliser la fonctionnalité Régions jumelées pour coordonner les mises à jour de la plateforme et hiérarchiser les efforts de récupération.
Activez la géo-réplication. La géoréplication pour des services comme Azure SQL Database et Cosmos DB crée des réplicas secondaires de vos données dans plusieurs régions. Bien que les deux services répliquent automatiquement les données dans la même région, la géoréplication vous protège contre une panne régionale en vous permettant de basculer vers une région secondaire. Une autre bonne pratique pour les centres de géoréplication concernant le stockage des images conteneur. Pour déployer un service dans AKS, vous devez stocker et extraire l’image d’un référentiel. Azure Container Registry s’intègre à AKS et peut stocker en toute sécurité des images conteneur. Pour améliorer les performances et la disponibilité, envisagez de géo-répliquer vos images dans un registre dans chaque région où vous disposez d’un cluster AKS. Chaque cluster AKS extrait ensuite des images conteneur du registre de conteneurs local dans sa région, comme illustré dans la figure 6-4 :
Figure 6-4. Ressources répliquées dans plusieurs régions
- Implémentez un équilibreur de charge pour le trafic DNS. Azure Traffic Manager fournit une haute disponibilité pour les applications critiques en équilibrant la charge au niveau du DNS. Il peut acheminer le trafic vers différentes régions en fonction de la zone géographique, du temps de réponse du cluster et même de l’intégrité du point de terminaison d’application. Par exemple, Azure Traffic Manager peut diriger les clients vers leur cluster AKS et leur instance d’application les plus proches. Si vous possédez plusieurs clusters AKS dans différentes régions, utilisez Traffic Manager pour contrôler la façon dont le trafic afflue vers les applications qui s’exécutent dans chaque cluster. La figure 6-5 illustre ce scénario.
Figure 6-5. AKS et Azure Traffic Manager
Conception dans l’optique de la scalabilité
Le cloud se développe grâce à la mise à l’échelle. La possibilité d’augmenter/diminuer les ressources système pour répondre à l’augmentation/la diminution de la charge système est un principe clé du cloud Azure. Toutefois, pour mettre à l’échelle efficacement une application, vous devez comprendre les fonctionnalités de mise à l’échelle de chaque service Azure que vous incluez dans votre application. Voici des recommandations pour implémenter efficacement la mise à l’échelle dans votre système.
Concevez pour la mise à l’échelle. Une application doit être conçue pour la mise à l’échelle. Pour commencer, les services doivent être sans état afin que les demandes puissent être routées vers n’importe quelle instance. L’utilisation de services sans état signifie également que l’ajout ou la suppression d’une instance n’a pas d’incidence négative sur les utilisateurs actuels.
Partitionnez les charges de travail. La décomposition de domaines en microservices indépendants et autonomes permet à chaque service de se mettre à l’échelle indépendamment des autres. En règle générale, les services ont des besoins et des exigences d’extensibilité différents. Le partitionnement vous permet de mettre à l’échelle uniquement ce qui doit l’être sans le coût inutile de la mise à l’échelle d’une application entière.
Privilégiez le scale-out. Les applications basées sur le cloud privilégient le scale-out des ressources plutôt que le scale-up. Le scale-out (également appelé mise à l’échelle horizontale) implique l’ajout de ressources de service supplémentaires à un système existant pour atteindre et partager un niveau de performances souhaité. Le scale-up (également appelé mise à l’échelle verticale) implique le remplacement des ressources existantes par du matériel plus puissant (plus d’espace disque, de mémoire et de cœurs de traitement). Le scale-out peut être appelé automatiquement avec les fonctionnalités de mise à l’échelle automatique disponibles dans certaines ressources cloud Azure. Le scale-out sur plusieurs ressources ajoute également une redondance au système global. Enfin, le scale-up d’une seule ressource est généralement plus coûteux que le scale-out sur de nombreuses ressources plus petites. La figure 6-6 illustre les deux approches :
Figure 6-6. Effectuer un scale-up ou un scale-out
Mettez à l’échelle proportionnellement. Lors de la mise à l’échelle d’un service, pensez en termes d’ensembles de ressources. Si vous deviez effectuer un scale-out considérable d’un service spécifique, quel impact cela aurait-il sur les magasins de données de back-end, les caches et les services dépendants ? Certaines ressources comme Cosmos DB peuvent effectuer un scale-out proportionnel, contrairement à d’autres. Vous souhaitez vous assurer que vous ne faites pas un scale-out d’une ressource à un point où cela épuisera les autres ressources associées.
Évitez les affinités. Une bonne pratique consiste à s’assurer qu’un nœud ne nécessite pas d’affinité locale, souvent appelée session persistante. Une demande doit être en mesure d’acheminer vers n’importe quelle instance. Si vous devez conserver l’état, il doit être enregistré dans un cache distribué, comme le cache Azure Redis.
Tirez parti des fonctionnalités de mise à l’échelle automatique de la plateforme. Utilisez autant que possible les fonctionnalités de mise à l’échelle automatique intégrées, plutôt que des mécanismes personnalisés ou tiers. Utilisez si possible des règles de mise à l’échelle planifiées pour vous assurer que les ressources sont disponibles sans délai de démarrage, mais ajoutez si nécessaire une mise à l’échelle automatique réactive aux règles pour faire face aux évolutions imprévues de la demande. Pour plus d’informations, consultez Recommandations en matière de mise à l’échelle automatique.
Effectuez un scale-out agressif. Une dernière pratique consisterait à effectuer un scale-out de manière agressive afin de pouvoir rapidement répondre aux pics immédiats de trafic sans perdre d’activité. Ensuite, effectuez une mise à l’échelle (c’est-à-dire supprimer les instances inutiles) de manière prudente pour maintenir la stabilité du système. Un moyen simple d’implémenter cela consiste à définir la période de refroidissement, qui est le temps d’attente entre les opérations de mise à l’échelle, à cinq minutes pour l’ajout de ressources et jusqu’à 15 minutes pour la suppression d’instances.
Nouvelle tentative intégrée dans les services
Nous avons recommandé l’implémentation d’opérations de nouvelle tentative par programmation dans une section précédente. N’oubliez pas que de nombreux services Azure et leurs kits SDK clients correspondants incluent également des mécanismes de nouvelle tentative. La liste suivante récapitule les fonctionnalités de nouvelle tentative dans les nombreux services Azure abordés dans ce livre :
Azure Cosmos DB. La classe DocumentClient de l’API cliente retente automatiquement les tentatives ayant échoué. Le nombre de nouvelles tentatives et le temps d’attente maximal sont configurables. Les exceptions levées par l’API cliente sont des demandes qui dépassent la stratégie de nouvelle tentative ou des erreurs non temporaires.
Cache Redis Azure. Le client Redis StackExchange utilise une classe de gestionnaire de connexions qui inclut les nouvelles tentatives en cas d’échec. Le nombre de nouvelles tentatives, la stratégie de nouvelle tentative spécifique et le temps d’attente sont tous configurables.
Azure Service Bus. Le client Service Bus expose une classe RetryPolicy qui peut être configurée avec un intervalle d’interruption, un nombre de nouvelles tentatives et TerminationTimeBuffer, qui spécifie le temps maximal qu’une opération peut prendre. La stratégie par défaut est de neuf tentatives maximales avec une période d’interruption de 30 secondes entre les tentatives.
Azure SQL Database. La prise en charge des nouvelles tentatives est fournie lors de l’utilisation de la bibliothèque Entity Framework Core.
Stockage Azure. La bibliothèque cliente de stockage prend en charge les opérations de nouvelle tentative. Les stratégies varient selon les tables de stockage Azure, les objets blob et les files d’attente. En outre, les nouvelles tentatives alternent entre les emplacements des services de stockage principal et secondaire lorsque la fonctionnalité de géoredondance est activée.
Azure Event Hubs. La bibliothèque cliente Event Hub comporte une propriété RetryPolicy, qui inclut une fonctionnalité d’interruption exponentielle configurable.
