Mise à l’échelle des ressources de calcul

Un des principaux avantages du cloud est la possibilité de mettre à l’échelle les ressources d’un système à la demande. Le scale-up (provisionnement de ressources plus importantes) ou le scale-out (provisionnement de ressources supplémentaires) peuvent aider à réduire la charge sur un système en diminuant l’utilisation en raison d’une capacité accrue ou d’une distribution plus étendue de la charge de travail.

La mise à l’échelle permet d’améliorer la réactivité (et les performances perçues du point de vue de l’utilisateur) en augmentant le débit, car un plus grand nombre de demandes peuvent alors être traitées. Cela peut également contribuer à réduire la latence pendant les pics de charge, car un nombre réduit de demandes sont mises en file d’attente sur une même ressource lors de ces pics. En outre, la mise à l’échelle peut améliorer la fiabilité du système en réduisant l’utilisation des ressources et en leur évitant de se rapprocher du 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 contrariant 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-in ou un scale-down pour limiter les coûts.

Mise à l’échelle horizontale (scale-in et scale-out)

La mise à l’échelle horizontale est une stratégie par laquelle des ressources supplémentaires sont ajoutées au système ou des ressources superflues sont supprimées du système au fil du temps. Ce type de mise à l’échelle est bénéfique pour le niveau serveur quand la charge sur le système fluctue de façon irrégulière ou imprévisible. La nature de la charge fluctuante rend essentiel le provisionnement de la quantité de ressources correcte pour gérer la charge à tout moment.

Voici quelques facteurs qui rendent cette tâche délicate :

• Le temps de rotation d’une instance (par exemple une machine virtuelle)
• Le modèle de tarification du fournisseur de services cloud
• La perte potentielle de chiffre d’affaires résultant de la dégradation de la qualité de service (QoS) en l’absence de mise à l’échelle en temps voulu

Figure 5 : exemple de modèle de charge.

À titre d’exemple, considérez le modèle de charge de la figure 5 ci-dessus.

Supposez que nous utilisons Amazon Web Services, que chaque unité de temps est équivalente à une heure de temps réel, et que nous avons besoin d’un serveur pour traiter 5 000 requêtes. Des pics de demande ont lieu entre les unités de temps 6 et 8, et les unités de temps 14 et 16. Prenons cette dernière période en guise d’exemple. Nous pouvons détecter une baisse de la demande autour de l’unité de temps 16, et nous commençons à réduire le nombre de ressources allouées. Étant donné que nous passons d’environ 90 000 à 10 000 requêtes en l’espace de trois heures, mathématiquement nous pouvons économiser le coût d’une douzaine d’instances supplémentaires qui auraient été en ligne à l’heure 15.

La figure 6 illustre un modèle de mise à l’échelle qui ajuste le nombre d’instances à la volée afin qu’il corresponde au modèle de charge, avec le nombre d’instances affiché en rouge. Pendant les pics de demande, on effectue un scale-out du nombre d’instances respectivement à 20 et 18, afin de fournir les ressources nécessaires pour gérer le trafic. À d'autres moments, le nombre d'instances est réduit pour maintenir l'utilisation des ressources relativement constante. Si nous partons du principe que chaque instance coûte 20 centimes par heure, le coût lié à l’exécution de 20 instances pendant 24 heures est de 96 euros. La mise à l’échelle du nombre d’instances comme indiqué réduit le coût à environ 42 euros, soit une économie annuelle de plus de 15 000 euros. C'est une somme conséquente pour presque n'importe quel budget informatique.

Figure 6 : réduction et augmentation d'échelle en fonction de la demande.

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, comme le streaming de films à partir d’un service web le soir), 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.

Il est intéressant de noter que le scale-in et le scale-out peuvent être effectués avec des instances de conteneur ainsi que des instances de machine virtuelle. Les charges de travail s’exécutent traditionnellement dans le cloud sur des machines virtuelles, mais leur exécution dans des conteneurs est de plus en plus courante. La mise à l’échelle s’effectue avec des charges de travail basées sur des machines virtuelles, en augmentant et en diminuant le nombre de machines virtuelles. De même, les charges de travail basées sur des conteneurs peuvent être mises à l’échelle en variant le nombre de conteneurs. Les conteneurs ayant tendance à démarrer plus rapidement que les machines virtuelles, l’élasticité est légèrement supérieure car les nouvelles instances de conteneur peuvent être mises en ligne plus rapidement que les instances de machine virtuelle.

Mise à l’échelle verticale (scale-up et scale-down)

La mise à l’échelle horizontale est un moyen d’obtenir une élasticité, mais il en existe d’autres. Supposez que le trafic vers votre site web dépasse rarement 15 000 requêtes par unité de temps, et que vous provisionnez une seule grande instance capable d’en gérer 20 000 (suffisamment pour bien traiter le trafic normal et tenir compte des pics mineurs). Si la charge sur le site web augmente, vous pouvez raisonnablement prendre en charge l’augmentation du trafic en remplaçant l’instance de serveur par une instance qui a deux fois plus de cœurs de processeur et deux fois plus de RAM. C’est ce que l’on appelle le scale-up.

Le principal défi lié à la mise à l’échelle verticale est qu’il y a 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, la qualité de service se dégrade pendant cet intervalle.

Une autre limitation de la mise à l’échelle verticale est la granularité réduite. Si vous avez 10 instances de serveur en ligne et que vous avez besoin d’augmenter temporairement la capacité de 10 %, vous pouvez effectuer un scale-out de 10 à 11 instances et obtenir le résultat souhaité. Toutefois, avec la mise à l’échelle verticale, la taille d’instance supérieure suivante a généralement environ deux fois plus de capacité que la précédente, ce qui équivaudrait à une mise à l’échelle horizontale de 10 à 20 instances pour répondre à une augmentation de seulement 10 % du trafic. Ceci est moins économique que la mise à l’échelle horizontale.

Le dernier élément a prendre en compte concernant la mise à l’échelle verticale est la disponibilité. Si vous avez une grande instance qui gère tous les clients d’un site web et que cette instance tombe en panne, le site web tombe également en panne. En revanche, si vous configurez 10 petites instances pour gérer la même charge et que l’une d’entre elles tombe en panne, les utilisateurs remarqueront peut-être une légère baisse des performances, mais ils pourront toujours accéder au site. Par conséquent, même si la charge est prévisible et augmente régulièrement au fur et à mesure de la popularité du service, de nombreux administrateurs de cloud choisissent de mettre à l’échelle horizontalement plutôt que verticalement.

Mise à l’échelle du niveau serveur

La scalabilité est parfois plus subtile que le simple provisionnement d'un plus grand nombre de ressources (extensibilité horizontale) ou de ressources plus volumineuses (extensibilité verticale). Au niveau du serveur, l’augmentation de la demande peut augmenter la concurrence pour des types de ressources spécifiques, tels que le processeur, la mémoire et la bande passante réseau. Les fournisseurs de services cloud offrent généralement des machines virtuelles optimisées pour les charges de travail à calcul intensif, gourmandes en mémoire et nécessitant beaucoup de ressources réseau. Le fait de connaître votre charge de travail et de choisir le bon type de machine virtuelle est aussi essentiel que de faire appel à des machines virtuelles plus nombreuses ou plus importantes. Il vaut mieux avoir cinq machines virtuelles qui gèrent des charges de travail à calcul intensif plutôt que 10, même si les machines virtuelles optimisées pour les charges de travail gourmandes en ressources processeur coûtent 20 % plus cher que les machines virtuelles plus génériques.

L’amélioration des ressources matérielles n’est pas toujours la meilleure solution pour améliorer les performances d’un service. L’augmentation de l’efficacité des algorithmes utilisés par le service peut également réduire la contention des ressources et améliorer l’utilisation, éliminant ainsi la nécessité de mettre à l’échelle les ressources physiques.

En matière de mise à l’échelle, un point important à prendre en compte est la caractéristique « avec état » (ou son absence). Une conception de service sans état se prête à une architecture scalable. Un service sans état signifie essentiellement que la requête du client contient toutes les informations nécessaires pour pourvoir être traitée par le serveur. Le serveur ne stocke pas d’informations relatives au client dans l’instance, et stocke toutes les informations relatives à la session dans l’instance de serveur.

Le fait de disposer d’un service sans état permet de changer de ressources à volonté, sans qu’aucune configuration soit requise pour maintenir le contexte (état) de la connexion du client pour les requêtes suivantes. Si le service est avec état, la mise à l’échelle des ressources nécessite une stratégie pour transférer le contexte de la configuration existante vers la nouvelle configuration. Notez qu’il existe des techniques permettant d’implémenter des services avec état, par exemple la tenue à jour d’un cache réseau afin que le contexte puisse être partagé par plusieurs serveurs.

Mise à l’échelle de la couche de données

Dans les applications orientées données, où il y a un grand nombre de lectures et d’écritures (ou les deux) dans une base de données ou un système de stockage, le temps d’aller-retour pour chaque requête est souvent limité par les temps de lecture et d’écriture sur le disque dur. Les grandes instances permettent d’obtenir des performances d’E/S plus élevées, ce qui peut améliorer les temps de recherche sur le disque dur et donc réduire la latence du service. Si 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 des données sur plusieurs instances présente des avantages supplémentaires en matière de réduction de la latence réseau si les requêtes des clients sont traitées par un centre de données physiquement proche. Le partitionnement des données parmi plusieurs ressources est une autre stratégie de mise à l’échelle horizontale des données dans laquelle, au lieu de répliquer simplement les données sur plusieurs instances, les données sont partitionnées en segments et stockées sur plusieurs serveurs de données.

Un défi supplémentaire en matière de mise à l’échelle de la couche Données concerne 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 parle souvent du Théorème CAP qui stipule que, dans un système de base de données distribuée, compte tenu de l’impossibilité de réunir complètement les trois propriétés, le système ne peut pas en présenter plus de deux¹.

Références

1. Wikipédia. Théorème CAP. https://en.wikipedia.org/wiki/CAP_theorem.