Évolutivité du cloud : quand faut-il augmenter ou diminuer la capacité ?

Les responsables informatiques sont fréquemment confrontés à des défis en matière d'évolutivité dans le cadre de leurs fonctions. Prévoir les taux de croissance des applications, les besoins en capacité de stockage de données et les demandes en bande passante n'est pas une mince affaire. Lorsqu’un workload approche des limites de capacité, la question devient : comment maintenir un niveau de performance élevé tout en garantissant l’efficacité lorsque nous faisons évoluer l’architecture ou l’évolutivité de l’architecture ?

La capacité à exploiter rapidement la puissance du cloud, qu'il s'agisse d'une scale-up ou scale-out, pour s'adapter à une croissance rapide imprévue ou aux fluctuations saisonnières de la demande, est devenue un avantage considérable des services cloud public. Cependant, sans une gestion efficace, elle peut également devenir un poids mort. L’avantage d’accéder à une infrastructure supplémentaire en quelques minutes est indéniable. Toutefois, pour y parvenir efficacement, des décisions doivent être prises quant au type d’évolutivité nécessaire pour répondre à la demande, aux cas d’utilisation spécifiques et à la manière de contrôler méticuleusement les dépenses.

L'évolutivité gère l'évolution des besoins d'une application en ajoutant ou en supprimant statiquement des ressources pour répondre à l'évolution de la demande d'application, selon les besoins. Dans la plupart des cas, ces défis sont relevés par une augmentation de la capacité (évolutivité verticale) et/ou une réduction de la capacité (évolutivité horizontale). De nombreuses études et développements architecturaux ont été menés autour de l'évolutivité du cloud, abordant divers aspects de son fonctionnement et de son architecture pour les nouvelles applications Kubernetes ou cloud natives. Dans cet article, nous nous concentrerons tout d'abord sur la comparaison entre l'évolutivité verticale et l'évolutivité horizontale.

Le scale-up, souvent appelée « mise à l'échelle verticale », consiste à ajouter des ressources supplémentaires à un système existant afin d'atteindre le niveau de performance souhaité. Par exemple, une base de données ou un serveur web peut nécessiter des ressources supplémentaires pour maintenir un certain niveau de performance afin de respecter les accords de niveau de service (SLA). Il est possible d'ajouter du processeur, de la mémoire, du stockage ou du réseau à ce système pour maintenir les performances aux niveaux souhaités.

Lorsque cette opération est effectuée dans le cloud, les applications sont souvent déplacées vers des instances ou des machines virtuelles plus puissantes et peuvent même migrer vers un autre hôte afin de minimiser les temps d'arrêt, puis le serveur sur lequel elles se trouvaient est mis hors service. Bien entendu, ce processus doit être transparent pour le client.

Cette mise à l'échelle peut également être réalisée au niveau logiciel en ajoutant davantage de threads, davantage de connexions ou, dans le cas des applications de base de données, en augmentant la taille des caches. Ces types d'opérations à grande échelle se produisent sur site dans les centres de données depuis des décennies. Cependant, le temps nécessaire pour obtenir des ressources supplémentaires afin de faire évoluer un système donné peut prendre des semaines, voire des mois, dans un environnement traditionnel sur site, tandis que l'évolution dans le cloud ne prend que quelques minutes, ce qui peut avoir un impact sur les modèles de tarification.

Le scale-out est généralement associé aux architectures distribuées. Il en existe deux formes principales :

• Ajout de capacité d'infrastructure supplémentaire dans des blocs d'infrastructure ou des nœuds préconfigurés (c'est-à-dire hyperconvergés)
• Utilisation d'un service distribué capable de récupérer les informations client tout en restant indépendant des applications ou des services, afin de résoudre les problèmes de performances et d'optimiser les ressources informatiques cloud

Les deux approches sont aujourd'hui utilisées par les fournisseurs de services cloud (CSP) modernes, ainsi que la mise à l'échelle verticale (scale-up) pour les composants individuels (calcul, mémoire, réseau et stockage), afin de réduire les coûts. La mise à l'échelle horizontale (scaling out) permet aux fournisseurs de services de proposer facilement des infrastructures et des services « pay-as-you-grow » (paiement en fonction de la croissance), ce qui influence les stratégies de tarification.

L’infrastructure hyperconvergée est devenue de plus en plus populaire pour une utilisation dans le cloud privé et même pour les fournisseurs de services de niveau 2. Cette approche n'est pas aussi flexible que d'autres formes d'architectures distribuées, mais elle aide les responsables informatiques habitués aux architectures traditionnelles à passer à la mise à l'échelle horizontale et à réaliser les économies associées.

Une architecture distribuée faiblement couplée permet de faire évoluer chaque partie de l'architecture de manière indépendante, éliminant ainsi efficacement les goulots d'étranglement. Cela signifie qu’un groupe de produits logiciels peut être créé et déployé en tant qu’éléments indépendants, même s’ils fonctionnent ensemble pour gérer un workflow complet. Chaque application est composée d'une collection de services abstraits qui peuvent fonctionner et opérer indépendamment. Cela permet une mise à l’échelle horizontale au niveau du produit et du service. Les capacités de mise à l’échelle encore plus granulaires peuvent être délimitées par SLA ou par type de client (par exemple, bronze, argent ou or), voire par type d’API, si la demande pour certaines API est différente. Cela peut promouvoir une utilisation efficace de l'évolutivité au sein d'une infrastructure donnée.

Les fournisseurs de services ont continuellement adapté leurs infrastructures pour répondre aux besoins changeants des clients, en mettant l’accent sur la performance et l’efficacité. Un exemple notable est l’auto-scaling d’AWS, qui aligne l’utilisation des ressources sur les besoins réels, garantissant que les utilisateurs ne sont facturés que pour ce qu’ils consomment activement. Cette approche présente un potentiel important de réduction des coûts, bien que la compréhension de la facturation complexe puisse s'avérer difficile.

C’est précisément là qu’IBM Turbonomic intervient pour simplifier la facturation du cloud, en fournissant des informations claires sur les dépenses et en permettant de prendre des décisions éclairées concernant les stratégies d’extension ou de mise à l’échelle, ce qui se traduit par des économies encore plus importantes. Turbonomic rationalise l’allocation du budget pour la gestion informatique à travers les infrastructures sur site et hors site en proposant une modélisation des coûts pour les deux environnements et des plans de migration afin de garantir une performance et une efficacité optimales des workloads tout en atténuant les problèmes de performance.

Pour les fournisseurs de services cloud actuels, les architectures distribuées faiblement couplées sont essentielles à la mise à l'échelle dans le cloud. Associées à l'automatisation du cloud, elles offrent aux clients de nombreuses options de mise à l'échelle verticale ou horizontale adaptées à leurs besoins commerciaux. Turbonomic peut vous aider à choisir les meilleures options dans votre parcours cloud, en fonction des exigences propres à votre système de stockage.