Mettre à l’échelle des ressources
- 11 minutes
L’un des principaux avantages du cloud est la mise à l’échelle des ressources d’un système à la demande. Le scale-up (provisionnement de ressources plus grandes) ou le scale-out (provisionnement de ressources supplémentaires) permettent de réduire la charge sur une seule ressource en diminuant l’utilisation en raison d’une capacité accrue ou d’une répartition plus large de la charge de travail.
La mise à l’échelle permet d’améliorer les performances en augmentant le débit, car un plus grand nombre de requêtes peuvent ensuite être traitées. Elle peut également contribuer à réduire la latence pendant les pics de charge, car un nombre réduit de requêtes sont mises en file d’attente sur une même ressource au moment de ces pics. De plus, elle peut contribuer à améliorer la fiabilité du système en réduisant l’utilisation de la ressource pour l’éloigner de son point de rupture.
Il est important de noter que même si le cloud nous permet de provisionner facilement des ressources plus récentes ou plus performantes, le coût est toujours un facteur opposé qui doit être pris en compte. Ainsi, même s’il est avantageux d’effectuer un scale-up ou un scale-out, il est également important de savoir quand effectuer un scale-down ou un scale-in pour limiter les coûts. Dans une application multiniveau, il est également essentiel d’identifier les goulots d’étranglement et le niveau à mettre à l’échelle, qu’il s’agisse de la couche Données ou du niveau serveur.
La mise à l’échelle des ressources est facilitée par l’équilibrage de charge (nous l’avons abordé plus tôt), ce qui permet de masquer l’aspect de mise à l’échelle d’un système en le masquant derrière un point de terminaison cohérent.
Stratégies de mise à l’échelle
Mise à l’échelle horizontale (scale-out et scale-in)
La mise à l’échelle horizontale est une stratégie qui permet d’ajouter des ressources supplémentaires au système, ou de supprimer des ressources inappropriées de ce dernier. Ce type de mise à l’échelle est bénéfique pour le niveau serveur, quand la charge du système n’est pas prévisible, et qu’elle fluctue de manière incohérente. La nature fluctuante de la charge rend indispensable le provisionnement efficace de la quantité de ressources appropriée pour gérer la charge à tout moment.
Vous devez prendre en compte plusieurs éléments qui rendent cette tâche délicate, notamment le délai de mise en route d’une instance, le modèle tarifaire du fournisseur de services cloud ainsi que la perte potentielle de revenus résultant de la dégradation de la qualité de service (QoS) en l’absence d’un scale-out opportun. Par exemple, prenons le modèle de charge suivant :
Figure 6 : Exemple de modèle de charge de requête
Supposons que nous utilisions Amazon Web Services. Supposons également que chaque unité de temps soit équivalente à 3 heures de temps réel, et que nous ayons besoin d’un serveur pour traiter 5 000 requêtes. Si vous examinez la charge au cours des unités de temps 16 à 22, sa fluctuation est considérable. Nous pouvons détecter une baisse de la demande autour de l’unité de temps 16, et commencer à réduire le nombre de ressources allouées. Dans la mesure où nous passons d’environ 50 000 requêtes à près de 0 requête en l’espace de 3 heures, mathématiquement nous pouvons économiser le coût de 10 instances qui auraient été en ligne à l’unité de temps 16.
À présent, supposons que chaque unité de temps soit égale à 20 minutes de temps réel. Dans ce cas, le fait de mettre à l’arrêt toutes les ressources à l’unité de temps 16 uniquement pour mettre en route de nouvelles ressources après 20 minutes va augmenter le coût au lieu de le réduire, car AWS facture chaque instance de calcul sur une base horaire.
En plus des deux considérations ci-dessus, un fournisseur de services doit également évaluer les pertes qu’il subit en proposant une qualité de service (QoS) dégradée pendant l’unité de temps 20, si sa capacité est seulement de 90 000 requêtes et non de 100 000 requêtes.
La mise à l’échelle dépend des caractéristiques du trafic et de la charge résultante générée au niveau d’un service web. Si le trafic suit un modèle prévisible (par exemple un modèle basé sur le comportement humain, tel que le streaming de films à partir d’un service web en soirée), la mise à l’échelle peut être prédictive pour maintenir le niveau de QoS. Toutefois, dans de nombreux cas, le trafic ne peut pas être prédit, et les systèmes de mise à l’échelle doivent être réactifs en fonction de différents critères, comme l’ont montré les exemples ci-dessus.
Mise à l’échelle verticale (scale-up et scale-down)
Certains genres de charge relatifs aux fournisseurs de services sont plus prévisibles que d’autres. Par exemple, si vous savez d’après les modèles historiques que le nombre de requêtes est toujours compris entre 10 000 et 15 000, vous pouvez facilement supposer qu’un serveur pouvant traiter 20 000 requêtes est suffisant pour les besoins du fournisseur de services. Ces charges peuvent augmenter à l’avenir, mais tant qu’elles augmentent de manière cohérente, le service peut être déplacé vers une instance plus grande pouvant traiter plus de requêtes. Cela convient aux petites applications qui gèrent un faible trafic.
Le principal défi lié à la mise à l’échelle verticale est qu’il existe généralement un temps de basculement qui peut être considéré comme un temps d’arrêt. En effet, pour déplacer toutes les opérations de la plus petite instance vers une plus grande instance, même si le temps de basculement n’est que de quelques minutes, le niveau de QoS se dégrade pendant cet intervalle.
De plus, la plupart des fournisseurs de cloud offrent des ressources de calcul pour l’augmentation de la puissance de calcul en doublant la puissance de calcul d’une ressource. Ainsi, la précision du scale-up n’est pas aussi fine que dans le cas d’une mise à l’échelle horizontale. Dans ce cas, même si la charge est prévisible et qu’elle s’accroît régulièrement à mesure que la popularité du service augmente, de nombreux fournisseurs de services choisissent d’effectuer une mise à l’échelle horizontale à la place d’une mise à l’échelle verticale.
Considérations relatives à la mise à l’échelle
Supervision
La supervision est l’un des éléments les plus importants pour une mise à l’échelle efficace des ressources, car elle vous permet d’avoir des métriques qui peuvent servir à identifier les parties du système devant faire l’objet d’une mise à l’échelle, et à quel moment. La supervision permet d’analyser les modèles de trafic ou l’utilisation des ressources pour évaluer précisément le moment et le mode de la mise à l’échelle des ressources afin d’optimiser la qualité de service (QoS) et la marge bénéficiaire.
Plusieurs aspects des ressources sont supervisés pour permettre le déclenchement de leur mise à l’échelle. La métrique la plus courante est l’utilisation des ressources. Par exemple, un service de supervision peut suivre l’utilisation du processeur de chaque nœud de ressource et mettre à l’échelle ces dernières, si l’utilisation est excessive ou trop faible. Si, par exemple, l’utilisation de chaque ressource est supérieure à 95 %, il est probablement judicieux d’ajouter davantage de ressources dans la mesure où le système subit une charge importante. Les fournisseurs de services décident généralement de ces points de déclenchement en analysant le point de rupture des nœuds de ressource, en déterminant le moment où ils commencent à se dégrader et en mappant leur comportement sous différents niveaux de charge. Même si, pour des raisons de coût, il est important d’utiliser chaque ressource au maximum, il est recommandé de laisser une marge au système d’exploitation pour permettre les activités de surcharge. De même, si l’utilisation est faible, par exemple 50 %, il est possible que tous les nœuds de ressource ne soient pas nécessaires. Dans ce cas, certains d’entre eux peuvent être déprovisionnés.
En pratique, les fournisseurs de services supervisent généralement une combinaison de plusieurs métriques différentes d’un nœud de ressource pour évaluer le moment où les ressources doivent être mises à l’échelle. Parmi celles-ci figurent l’utilisation du processeur, la consommation de mémoire, le débit et la latence. Azure fournit Azure Monitor en tant que service supplémentaire capable de superviser toutes les ressources Azure et de fournir de telles métriques.
Absence d’état
Une conception de service sans état se prête à une architecture scalable. Un service sans état signifie essentiellement que la requête cliente contient toutes les informations nécessaires pour pouvoir être traitée par le serveur. Le serveur ne stocke aucune information relative au client dans l’instance, et ne stocke aucune information relative à la session dans l’instance de serveur.
Le fait de disposer d’un service sans état permet de changer les ressources à volonté, sans qu’aucune configuration ne soit nécessaire pour maintenir le contexte (l’état) de la connexion cliente pour les requêtes suivantes. Dans le cas d’un service avec état, la mise à l’échelle des ressources nécessite une stratégie pour transférer le contexte de la configuration de nœud existante vers la nouvelle configuration de nœud. Notez qu’il existe des techniques permettant d’implémenter des services avec état, par exemple la gestion d’un cache réseau pour que le contexte puisse être partagé par les serveurs.
Choisir les ressources à mettre à l’échelle
Selon la nature du service, différentes ressources doivent être mises à l’échelle en fonction des exigences. Au niveau serveur, au fur et à mesure que les charges de travail augmentent et en fonction du type d’application, il peut se produire une augmentation de la contention des ressources pour le processeur, la mémoire, la bande passante réseau ou tous les éléments ci-dessus. La supervision du trafic nous permet d’identifier la ressource soumise à des contraintes, et de mettre à l’échelle cette ressource spécifique de manière appropriée. Les fournisseurs de services cloud n’offrent pas forcément une scalabilité suffisamment précise pour effectuer uniquement une mise à l’échelle du calcul ou de la mémoire. En revanche, ils proposent différents types d’instance de calcul qui répondent spécifiquement aux besoins des charges lourdes en calcul ou en mémoire. Ainsi, par exemple, pour une application dont les charges de travail sont gourmandes en mémoire, il est plus judicieux d’effectuer un scale-up des ressources vers des instances à mémoire optimisée. Pour les applications censées traiter un grand nombre de requêtes qui ne sont pas nécessairement lourdes en calcul ou en mémoire, la mise à l’échelle de plusieurs instances de calcul standard peut être une meilleure stratégie.
L’augmentation des ressources matérielles n’est pas toujours la meilleure solution pour augmenter les performances d’un service. L’augmentation de l’efficacité des algorithmes utilisés dans le service peut également contribuer à réduire la contention des ressources et à améliorer l’utilisation, éliminant ainsi la nécessité de mettre à l’échelle les ressources physiques.
Mettre à l’échelle la couche Données
Pour les applications orientées données, où il existe un nombre élevé d’opérations de lecture et d’écriture (ou les deux) dans une base de données ou un système de stockage, le temps d’aller-retour de chaque requête est souvent limité par les temps de lecture et d’écriture des E/S du disque dur. Les instances plus importantes permettent d’obtenir des performances d’E/S plus élevées pour les opérations de lecture et d’écriture, ce qui peut améliorer les temps de recherche sur le disque dur, et donc entraîner une réduction importante de la latence du service. Le fait d’avoir plusieurs instances de données dans la couche Données peut améliorer la fiabilité et la disponibilité de l’application en fournissant des redondances de basculement. La réplication de données sur plusieurs instances présente des avantages supplémentaires, car elle permet de réduire le temps de réponse du réseau si le client utilise un centre de données physiquement plus proche de lui. Le partage ou le partitionnement des données sur plusieurs ressources est une autre stratégie de mise à l’échelle horizontale des données dans laquelle les données ne sont pas simplement répliquées sur plusieurs instances, elles sont partitionnées et stockées sur plusieurs serveurs de données.
Le défi supplémentaire quand il s’agit de mettre à l’échelle la couche Données est le maintien de la cohérence (une opération de lecture sur tous les réplicas est identique), de la disponibilité (les lectures et écritures réussissent toujours) et de la tolérance au partitionnement (les propriétés garanties du système sont conservées quand des défaillances empêchent la communication entre les nœuds). On emploie souvent pour cela le terme de théorème CAP, qui stipule que dans un système de base de données distribuée, il est très difficile d’obtenir complètement les trois propriétés. Le système peut donc présenter au maximum une combinaison de deux des propriétés. Vous en apprendrez plus sur les stratégies de mise à l’échelle des bases de données et le théorème CAP dans les prochains modules.
Vérifiez vos connaissances
Commentaires
Cette page a-t-elle été utile ?
No
Vous avez besoin d’aide pour cette rubrique ?
Vous souhaitez essayer d’utiliser Ask Learn pour clarifier ou vous guider dans cette rubrique ?