Consolidez plusieurs tâches ou opérations en une seule unité de calcul. Cela permet d’augmenter l’utilisation des ressources de calcul et de réduire les coûts et la surcharge de gestion associés au traitement du calcul dans des applications hébergées dans le cloud.
Contexte et problème
Une application cloud implémente souvent des opérations diverses. Dans certaines solutions, il est logique de suivre le principe de conception de séparation des problèmes initial et de diviser ces opérations en unités de calcul distinctes hébergées et déployées de façon individuelle (par exemple en tant qu’applications web App Service séparées ou machines virtuelles séparées). Toutefois, bien que cette stratégie permette de simplifier l’étude logique de la solution, le fait de déployer un grand nombre d’unités de calcul pour la même application peut augmenter les coûts d’hébergement du runtime et rendre plus complexe la gestion du système.
À titre d’exemple, la figure illustre la structure simplifiée d’une solution hébergée dans le cloud qui est implémentée à l’aide de plusieurs unités de calcul. Chaque unité de calcul s’exécute dans son propre environnement virtuel. Chaque fonction a été implémentée en tant que tâche séparée (de la Tâche A à la Tâche E) s’exécutant dans sa propre unité de calcul.
Chaque unité de calcul consomme des ressources facturables, même lorsqu’elle est inactive ou peu utilisée. Par conséquent, cette solution n’est pas toujours la plus rentable.
Dans Azure, cette préoccupation s’applique à App Services, Container Apps et aux machines virtuelles. Ces éléments s’exécutent dans leur propre environnement. L’exécution d’une collection de sites web, microservices ou machines virtuelles séparés qui sont conçus pour exécuter un groupe d’opérations bien définies, mais qui ont besoin de communiquer et de coopérer car ils font partie d’une solution unique, peut constituer une utilisation inefficace des ressources.
Solution
Dans l’optique de faciliter la réduction des coûts, l’augmentation de l’utilisation et l’amélioration de la vitesse de communication et la diminution de la gestion, il est possible de consolider plusieurs tâches ou opérations dans une seule unité de calcul.
Les tâches peuvent être regroupées en fonction de critères basés sur les fonctionnalités fournies par l’environnement et les coûts associés à ces fonctionnalités. Une approche courante consiste à rechercher des tâches qui ont un profil similaire en matière d’exigences de traitement, de durée de vie et d’extensibilité. Le regroupement de ces éléments leur permet d’effectuer une mise à l’échelle en tant qu’unité. L’élasticité fournie par de nombreux environnements cloud permet de démarrer et d’arrêter des instances supplémentaires d’une unité de calcul en fonction de la charge de travail. Par exemple, Azure propose une fonctionnalité de mise à l’échelle automatique que vous pouvez appliquer à des rôles, App Services et des groupes de machines virtuelles identiques. Pour plus d’informations, consultez Mise à l’échelle automatique.
En tant que contre-exemple pour montrer comment l’extensibilité peut être utilisée pour déterminer quelles opérations ne doivent pas être regroupées, pensez aux deux tâches suivantes :
- La tâche 1 interroge les messages peu fréquents et non sensibles au temps envoyés à une file d’attente.
- La tâche 2 gère les pics de trafic réseau de volume élevé.
La seconde tâche nécessite de l’élasticité qui peut impliquer le démarrage et l’arrêt d’un grand nombre d’instances de l’unité de calcul. Appliquer la même mise à l’échelle à la première tâche entraînerait simplement davantage de tâches d’écoute de messages peu fréquents dans la même file d’attente et constitue un gaspillage de ressources.
Dans de nombreux environnements cloud, il est possible de spécifier les ressources disponibles sur une unité de calcul en termes de nombre de cœurs de processeur, de quantité de mémoire, d’espace disque, etc. En règle générale, plus il y a de ressources spécifiées, plus le coût est élevé. Pour faire des économies, il est important d’optimiser le travail qu’une unité de calcul coûteuse effectue, et de ne pas la laisser inactive pendant une période prolongée.
S’il existe des tâches qui nécessitent beaucoup de ressources de processeur lors de courtes périodes de pics d’activité, envisagez de les consolider dans une seule unité de calcul qui fournit la puissance nécessaire. Toutefois, il est important d’équilibrer ce besoin pour que les ressources coûteuses restent occupées par rapport à la contention qui pourrait se produire si elles étaient trop sollicitées. Les tâches gourmandes en ressources de calcul et longues à exécuter ne doivent pas partager la même unité de calcul par exemple.
Problèmes et considérations
Prenez en compte les points suivants lorsque vous implémentez ce modèle :
L’extensibilité et l’élasticité. De nombreuses solutions cloud implémentent l’extensibilité et l’élasticité au niveau de l’unité de calcul en démarrant et arrêtant des instances d’unités. Évitez de regrouper des tâches ayant des exigences d’extensibilité en conflit dans la même unité de calcul.
Durée de vie. L’infrastructure cloud recycle périodiquement l’environnement virtuel qui héberge une unité de calcul. Lorsqu’il existe de nombreuses tâches longues à exécuter à l’intérieur d’une unité de calcul, il peut être nécessaire de configurer l’unité pour l’empêcher d’être recyclée tant que ces tâches ne sont pas terminées. Vous pouvez également concevoir les tâches en utilisant une approche de création de points de contrôle qui leur permet de s’arrêter de façon nette et de reprendre à partir du point où elles ont été interrompues lorsque l’unité de calcul est redémarrée.
Cadence de mise en production. Si l’implémentation ou la configuration d’une tâche change fréquemment, il peut être nécessaire d’arrêter l’unité de calcul hébergeant le code mis à jour, de reconfigurer et de redéployer l’unité puis de la redémarrer. Ce processus nécessitera également l’arrêt, le redéploiement et le redémarrage de toutes les autres tâches dans la même unité de calcul.
Sécurité. Des tâches dans la même unité de calcul peuvent partager le même contexte de sécurité et être en mesure d’accéder aux mêmes ressources. Il doit y avoir un niveau élevé d’approbation entre les tâches et vous devez être sûr qu’une tâche ne va pas corrompre une autre ou y nuire. En outre, augmenter le nombre de tâches s’exécutant dans une unité de calcul augmente la surface d’attaque de l’unité. Chaque tâche est uniquement aussi sûre que celle avec le plus de vulnérabilités.
Tolérance de panne. Si une tâche dans une unité de calcul échoue ou se comporte de façon anormale, elle peut affecter les autres tâches s’exécutant dans la même unité. Par exemple, si une tâche ne démarre pas correctement, elle peut entraîner l’échec de l’ensemble de la logique de démarrage de l’unité de calcul et empêcher les autres taches de la même unité de s’exécuter.
Contention. Évitez d’introduire de la contention entre les tâches qui sont en concurrence pour bénéficier des ressources de la même unité de calcul. Dans l’idéal, les tâches qui partagent la même unité de calcul doivent présenter des caractéristiques d’utilisation de ressources différentes. Par exemple, deux tâches gourmandes en ressources de calcul ne doivent probablement pas résider dans la même unité de calcul, comme c’est le cas pour deux tâches qui utilisent d’importantes quantités de mémoire. Toutefois, associer une tâche gourmande en ressources de calcul à une tâche requérant une grande quantité de mémoire est possible.
Notes
Envisagez de consolider des ressources de calcul uniquement pour un système qui a été en production pendant un certain temps, afin que les opérateurs et développeurs puissent surveiller le système et créer une carte thermique qui identifie la façon dont chaque tâche utilise les différentes ressources. Cette carte peut être utilisée pour déterminer les tâches les plus adaptées au partage de ressources de calcul.
Complexité : Combiner plusieurs tâches dans une seule unité de calcul complique le code dans l’unité et le rend plus difficile à tester, déboguer et maintenir.
Architecture logique stable. Concevez et implémentez le code dans chaque tâche de façon à ce qu’il n’ait pas besoin d’être modifié même si l’environnement physique dans lequel la tâche s’exécute change.
Autres stratégies. Consolider des ressources de calcul n’est qu’une des méthodes permettant de réduire les coûts associés à l’exécution simultanée de plusieurs tâches. Cette opération nécessite une planification et une surveillance précises pour vous assurer que l’approche reste efficace. D’autres stratégies peuvent être plus appropriées, selon la nature du travail et l’emplacement où se trouvent les utilisateurs qui exécutent ces tâches. Par exemple, la décomposition fonctionnelle de la charge de travail (comme décrit dans Compute Partitioning Guidance (Conseils sur le partitionnement du calcul)) peut être une option plus judicieuse.
Quand utiliser ce modèle
Utilisez ce modèle pour les tâches qui ne sont pas rentables si elles s’exécutent dans leurs propres unités de calcul. Si une tâche est la plupart du temps à l’état inactif, l’exécuter dans une unité dédiée peut être coûteux.
Ce modèle peut ne pas être adapté pour les tâches qui effectuent des opérations critiques tolérantes aux pannes ou pour les tâches qui traitent des données privées ou extrêmement sensibles et qui nécessitent leur propre contexte de sécurité. Ces tâches doivent s’exécutent dans leur propre environnement isolé, dans une unité de calcul distincte.
Conception de la charge de travail
Un architecte doit évaluer la façon dont le modèle de consolidation des ressources de calcul peut être utilisé dans la conception de leurs charges de travail pour se conformer aux objectifs et principes abordés dans les piliers d’Azure Well-Architected Framework. Par exemple :
| Pilier | Comment ce modèle soutient les objectifs des piliers. |
|---|---|
| L’optimisation des coûts est axée sur le maintien et l’amélioration du retour sur investissement de votre charge de travail. | Ce modèle optimise l’utilisation des ressources informatiques en évitant les capacités provisionnées inutilisées grâce à l’agrégation de composants ou même de charges de travail entières sur une infrastructure groupée. - CO :14 Consolidation |
| L’excellence opérationnelle permet de fournir une qualité de charge de travail grâce à des processus standardisés et à la cohésion d’équipe. | La consolidation peut mener à une plateforme informatique plus homogène, ce qui peut simplifier la gestion et l’observabilité, réduire les approches disparates des tâches opérationnelles et réduire le nombre d’outils nécessaires. - OE :07 Système de supervision - OE 10 Conception de l’automatisation |
| L’efficacité des performances permet à votre charge de travail de répondre efficacement aux demandes grâce à des optimisations de la mise à l’échelle, des données, du code. | La consolidation optimise l’utilisation des ressources de calcul en utilisant la capacité du nœud de réserve et en réduisant le besoin de surapprovisionnement. De grandes instances de calcul (scale-up) sont souvent utilisées dans le pool de ressources de ces infrastructures. - PE :02 Planification de la capacité - PE :03 Sélection de services |
Comme pour toute autre décision de conception, il convient de prendre en compte les compromis par rapport aux objectifs des autres piliers qui pourraient être introduits avec ce modèle.
Choix de plateforme d’application
Ce modèle peut être réalisé de différentes façons, en fonction du service de calcul que vous utilisez. Consultez les exemples de services suivants :
- Azure App Service et Azure Functions : Déployez des plans App Service partagés, qui représentent l’infrastructure du serveur d’hébergement. Une ou plusieurs applications peuvent être configurées pour s’exécuter sur les mêmes ressources informatiques (ou dans le même plan App Service).
- Azure Container Apps : déployez des applications de conteneur dans les mêmes environnements partagés, en particulier dans les situations où vous devez gérer des services connexes ou si vous devez déployer des applications différentes sur le même réseau virtuel.
- Azure Kubernetes Service (AKS) : AKS est une infrastructure d’hébergement basée sur un conteneur dans laquelle plusieurs applications ou composants d’application peuvent être configurés pour s’exécuter sur les mêmes ressources de calcul (nœuds), regroupées par exigences de calcul, comme les besoins en processeur ou en mémoire (pools de nœuds).
- Machines virtuelles : Déployez un SINGLE set de machines virtuelles à utiliser pour tous les clients, de manière à ce que les coûts de gestion soient partagés entre les locataires. Les groupes de machines virtuelles identiques sont une fonctionnalité qui prend en charge la gestion des ressources partagées, l’équilibrage de charge et la mise à l’échelle horizontale des machines virtuelles.
Ressources associées
Les modèles et les conseils suivants peuvent aussi présenter un intérêt quand il s’agit d’implémenter ce modèle :
Mise à l’échelle automatique. La mise à l’échelle automatique peut être utilisée pour démarrer et arrêter des instances de service qui hébergent des ressources de calcul, en fonction de la demande prévue pour le traitement.
Compute Partitioning Guidance (Conseils sur le partitionnement du calcul). Cet article explique comment allouer les services et composants d’un service cloud pour minimiser les coûts de fonctionnement tout en préservant l’extensibilité, les performances, la disponibilité et la sécurité du service.
Approches architecturales pour le calcul dans les solutions multilocataires. Fournit une aide relative aux considérations et aux exigences qui sont essentielles pour les architectes de solution lorsqu’ils planifient les services de calcul d’une solution multilocataire.