Penser la conception des applications pour effectuer un scale-out
Concevoir votre application de manière à permettre sa mise à l’échelle horizontale
Le principal avantage du cloud est la mise à l’échelle élastique, la possibilité d’utiliser exactement la capacité dont vous avez besoin, en effectuant une montée en charge à mesure que la charge augmente et une mise à l’échelle lorsque vous n’avez plus besoin de cette capacité supplémentaire. Concevez votre application de manière à ce qu’elle puisse évoluer horizontalement, en ajoutant ou supprimant des instances, pour correspondre à l’offre et à la demande.
La scalabilité est mesurée par le ratio du gain de débit par rapport à l’augmentation des ressources. Idéalement, dans un système bien conçu, ces deux valeurs sont proportionnelles : une allocation de ressources doublée doublera le débit. La scalabilité est généralement limitée par l’introduction de goulets d’étranglement ou de points de synchronisation dans le système.
Recommandations
Évitez l’adhérence des instances. L’adhérence, ou affinité de session, intervient lorsque les requêtes émanant du même client sont toujours routées vers le même serveur. L’adhérence limite les possibilités de scale-out de l’application. Par exemple, le trafic provenant d’un utilisateur générant beaucoup de volume ne sera pas distribué entre les différentes instances. L’adhérence peut être due au stockage de l’état de session en mémoire et à l’utilisation de clés spécifiques à l’ordinateur pour le chiffrement. Assurez-vous que n’importe quelle instance peut gérer n’importe quelle requête.
Identifiez les goulots d’étranglement. La montée en puissance ne règle pas tous les problèmes de performance. Par exemple, si votre base de données principale est le goulot d’étranglement, ajouter des serveurs web ne servira à rien. Identifiez et éliminez les goulots d’étranglement au niveau du système avant de multiplier les instances. Les parties avec état du système sont les causes les plus courantes des goulots d’étranglement.
Décomposez les charges de travail par exigences d’évolutivité. Les applications se composent souvent de plusieurs charges de travail, avec des exigences différentes en matière d’évolutivité. Par exemple, une application peut avoir un site web public et un site d’administration distinct. Le site public peut rencontrer des pics de trafic soudains, alors que le site d’administration a une charge moins élevée et plus prévisible.
Concevez des composants autonomes et découplés qui communiquent via des protocoles de communication asynchrones. Idéalement, les composants devraient avoir leur propre état indépendant et utiliser des événements pour communiquer tout changement ou activité aux composants extérieurs. Cela permet de faire évoluer de manière indépendante uniquement le composant surchargé. Mettez en œuvre des mécanismes de contrôle de flux pour gérer le trafic et se dégrader progressivement. Les consommateurs doivent contrôler leur propre taux de consommation. Les producteurs doivent contrôler leur propre taux de transmission, y compris l’arrêt. Les files d’attente de messages sont de bonnes options pour absorber la charge de travail supplémentaire et permettre aux consommateurs de vider le travail à leur rythme.
Évitez les communications, coordinations et attentes inutiles.
Déchargez naturellement les tâches asynchrones. Les tâches comme l’envoi d’e-mails, les actions pour lesquelles l’utilisateur n’a pas besoin d’une réponse immédiate et l’intégration à d’autres systèmes sont tous de bons candidats à l’utilisation de modèles de messagerie asynchrones.
Déchargez les tâches gourmandes en ressources. Dans la mesure du possible, les tâches qui nécessitent beaucoup de ressources de processeur ou d'E/S doivent être déplacées vers des travaux situés en arrière-plan afin de réduire la charge au niveau du serveur frontal qui traite les requêtes utilisateur.
Mise à l’échelle automatique basée sur des métriques d’utilisation en temps réel et utilisez les fonctionnalités intégrées d’auto-scaling. De nombreux services de calcul Azure offrent une prise en charge intégrée de la mise à l’échelle automatique. Si l’application a une charge de travail régulière et prévisible, nous vous recommandons de planifier le scale-out, par exemple pendant les heures ouvrables. Sinon, lorsque la charge de travail n’est pas prévisible, utilisez les indicateurs de performance tels que la longueur de file d’attente du processeur ou des requêtes pour déclencher la mise à l’échelle automatique. Observez les applications et leurs communications pour identifier les goulots d’étranglement et prendre des décisions plus précises. Pour connaître les bonnes pratiques en matière de mise à l'échelle automatique, consultez Mise à l'échelle automatique.
Envisagez une mise à l’échelle automatique agressive pour les charges de travail critiques. Pour les charges de travail critiques, il est essentiel d’anticiper la demande. Il est préférable d’ajouter de nouvelles instances rapidement en cas de charge importante afin de pouvoir gérer le trafic supplémentaire, puis de réduire progressivement le nombre d’instances.
Pensez la conception des applications pour effectuer un scale-in. N’oubliez pas que dans le cadre d’une évolutivité élastique, l’application connaîtra des périodes de scale-in, lorsque des instances sont supprimées. L’application doit gérer de manière appropriée les instances en cours de suppression. Voici quelques méthodes de gestion de la mise à l’échelle :
- Détectez les événements d’arrêt (le cas échéant) et arrêtez correctement les instances.
- Les clients/consommateurs d’un service doivent prendre en charge les nouvelles tentatives et la gestion des erreurs temporaires.
- Pour les tâches longues, envisagez de fragmenter le travail à l'aide de points de contrôle ou du modèle Canaux et filtres.
- Placez les éléments de travail dans une file d’attente afin qu’une autre instance puisse s’en charger dans le cas où une instance est supprimée au cours du processus de traitement.
Envisagez une mise à l'échelle pour la redondance. La mise à l'échelle peut améliorer la fiabilité de votre application. Par exemple, envisagez une montée en charge sur plusieurs zones de disponibilité, par exemple en utilisant des services redondants entre les zones. Cette approche peut améliorer le débit de votre application et assurer la résilience si une zone subit une panne.
Modélisez et optimisez la scalabilité de votre système. Vous pouvez modéliser votre système en utilisant une approche telle que la loi d’Amdahl. Quantifiez la scalabilité en fonction de paramètres tels que la contention et la cohérence. La contention fait référence au retard dû à l’attente ou à la mise en file d’attente pour des ressources partagées. La cohérence fait référence au retard nécessaire pour que les données deviennent cohérentes. Par exemple, une forte contention indique un traitement séquentiel qui pourrait être parallélisé, tandis qu’une forte cohérence suggère des dépendances excessives entre les processus, vous incitant à minimiser les interactions. Lors de la conception de la charge de travail, vous pouvez calculer la capacité effective maximale de votre système pour éviter de fournir plus d’offre que de demande, ce qui mène à du gaspillage.