Opsio - Cloud and AI Solutions
Compliance7 min de lecture· 1 605 mots

Qu'est-ce que l'élasticité rapide en cloud computing ? La définition du NIST

Fredrik Karlsson
Fredrik Karlsson

Group COO & CISO

Publié le: ·Mis à jour:
Traduit de l'anglais et relu par l'équipe éditoriale d'Opsio. Voir l'original →

L'élasticité rapide est la capacité du cloud à provisionner et libérer rapidement des ressources, souvent automatiquement, de sorte que la capacité s'étend et se réduit avec la demande. Le NIST la compte parmi les cinq caractéristiques essentielles du cloud computing. Pour l'utilisateur, la capacité disponible paraît illimitée : il peut en prendre la quantité voulue à tout moment, puis la rendre.

Points clés

  • Le NIST SP 800-145 la définit comme des capacités qui « peuvent être provisionnées et libérées de façon élastique, dans certains cas automatiquement, pour s'étendre et se réduire rapidement en fonction de la demande ».
  • Les deux sens comptent. Libérer de la capacité quand la demande baisse est ce qui transforme l'élasticité en économies.
  • En pratique, elle est assurée par l'autoscaling : métriques, politiques de mise à l'échelle, limites minimale et maximale, et un répartiteur de charge.
  • L'élasticité est de court terme et automatique ; la scalabilité est la capacité de croissance à long terme. Une charge cloud a besoin des deux.
  • Elle ne fonctionne que si l'application est conçue pour elle : serveurs sans état, stockage externe des sessions et base de données capable de suivre.

La définition du NIST, mot pour mot

Le National Institute of Standards and Technology américain a rédigé la définition que reprennent la plupart des manuels et des examens de certification. Dans la publication spéciale NIST 800-145, The NIST Definition of Cloud Computing, elle se lit ainsi (traduction libre) :

« Les capacités peuvent être provisionnées et libérées de façon élastique, dans certains cas automatiquement, pour s'étendre et se réduire rapidement en fonction de la demande. Pour le consommateur, les capacités disponibles au provisionnement paraissent souvent illimitées et peuvent être acquises en toute quantité à tout moment. »

Les quatre autres caractéristiques essentielles sont le libre-service à la demande, l'accès réseau étendu, la mise en commun des ressources et le service mesuré. Chaque expression de la définition a une portée pratique :

  • « Provisionnées et libérées » : la capacité se rend autant qu'elle s'ajoute. Un système qui ne fait que croître est scalable, pas élastique.
  • « Dans certains cas automatiquement » : l'automatisation est courante mais pas obligatoire. Une personne qui clique sur « ajouter cinq serveurs » et les obtient en quelques minutes respecte encore la définition.
  • « S'étendre et se réduire » : la définition décrit une mise à l'échelle horizontale, avec ajout et retrait d'instances, plutôt que le redimensionnement d'une seule machine.
  • « En fonction de la demande » : la capacité doit suivre la charge réelle, pas une prévision faite des mois plus tôt.
  • « Paraissent illimitées » : le réservoir du fournisseur est si vaste qu'un client seul en atteint rarement la limite, même si des quotas de compte s'appliquent.

Comment cela fonctionne-t-il en pratique ?

Les fournisseurs cloud assurent l'élasticité grâce à des services d'autoscaling. AWS Auto Scaling, par exemple, « surveille vos applications et ajuste automatiquement la capacité pour maintenir des performances stables et prévisibles au coût le plus bas possible » (traduction libre). Azure et Google Cloud proposent des services équivalents pour les groupes de machines virtuelles, les conteneurs et les bases de données.

Une configuration type comprend cinq éléments :

  1. Des métriques comme l'usage du CPU, les requêtes par cible ou la longueur d'une file d'attente, collectées chaque minute ou plus souvent.
  2. Des politiques qui disent quand agir : maintenir le CPU autour de 50 %, ajouter deux instances quand la file dépasse un seuil, ou ajouter de la capacité chaque jour ouvré à 08:00.
  3. Des limites : un minimum pour rester disponible et un maximum pour plafonner le coût.
  4. Le provisionnement à partir d'un modèle ou d'une image, pour que les nouvelles instances soient identiques et démarrent vite.
  5. Un répartiteur de charge qui envoie le trafic vers les nouvelles instances une fois les contrôles de santé réussis, et les vide avant leur retrait.

L'Azure Well-Architected Framework de Microsoft en tire la conséquence de conception : étendre des machines virtuelles « nécessite un répartiteur de charge distinct, une gestion des requêtes clientes et un état stocké en externe » (traduction libre). L'élasticité est autant une propriété de conception de l'application qu'une fonction de la plateforme.

Élasticité rapide et scalabilité

La scalabilité, c'est la capacité d'un système à absorber plus de charge quand on lui donne plus de ressources. L'élasticité, c'est la capacité à obtenir et libérer ces ressources rapidement et automatiquement quand la charge évolue.

ScalabilitéÉlasticité
HorizonCroissance à long termeDe quelques minutes à quelques heures
SensSurtout à la hausseExtension puis retour en arrière
Déclencheur typiqueCroissance de l'activité, nouveaux marchésPics de trafic, rythmes quotidiens et saisonniers
Bénéfice principalCroître sans refontePerformance en pointe, coût réduit hors pointe

Pour une vue d'entreprise des options, y compris les groupes d'autoscaling de VM, les conteneurs et le serverless, lisez notre guide sur la scalabilité élastique dans le cloud computing.

Exemples

  • Opérations commerciales du commerce en ligne. Une boutique en ligne étend ses couches web et paiement pour une campagne de Black Friday, puis revient à la normale la semaine suivante.
  • Activités saisonnières. Les sites de réservation et de webcams d'une station de ski concentrent l'essentiel de leur trafic sur quelques mois d'hiver.
  • Sorties médias. Un service de streaming ou d'information ajoute de la capacité quand une sortie très attendue ou une actualité chaude provoque un afflux.
  • Analytique par lots. Une équipe financière exécute ses rapports de fin de mois sur des centaines de cœurs pendant une heure plutôt que sur quelques serveurs pendant des jours.
  • Développement et test. Les environnements de test démarrent pour un test de charge ou une pull request, puis sont supprimés.

Le cas saisonnier est bien réel chez Branäsgruppen, client d'Opsio et l'un des plus grands groupes de stations de ski de Suède, avec jusqu'à 15 000 skieurs par jour en pointe. Son environnement VMware sur site devait être redimensionné à la main avant chaque pic de demande, et les performances chutaient tant que ce n'était pas fait. Après la migration vers AWS, l'étude de cas Branäsgruppen décrit des frontaux web, des middlewares et des couches de bases de données qui s'étendent et se réduisent désormais automatiquement avec la demande saisonnière.

Avantages et limites

Les avantages sont directs : vous ne payez la capacité de pointe que pendant la pointe, les utilisateurs bénéficient de temps de réponse constants, et personne n'a à ajouter des serveurs à la main avant une campagne.

Les limites sont tout aussi concrètes :

  • Temps de démarrage. Les nouvelles machines virtuelles mettent du temps à démarrer et à chauffer. Les pics très brusques demandent de la marge, de la capacité préchauffée ou du serverless.
  • La couche de données. Les serveurs web passent facilement à l'échelle ; les bases relationnelles beaucoup moins. Prévoyez des réplicas en lecture, du cache ou une base managée qui monte en charge.
  • Les quotas. Les limites de compte sur les instances ou la concurrence peuvent bloquer l'extension. Relevez-les avant les pics connus.
  • Les mauvaises surprises de coût. Un bug ou du trafic de bots peut vous faire monter très vite. Fixez toujours un maximum et des alertes budgétaires.
  • Les licences. Les logiciels licenciés par serveur ou par cœur peuvent ne pas autoriser des instances de courte durée.

Votre charge de travail est-elle élastique ? Un contrôle rapide

  • Peut-on arrêter n'importe quel serveur sans que les utilisateurs perdent leur session ou leurs données ?
  • Existe-t-il une politique de mise à l'échelle avec des limites minimale et maximale testées ?
  • La capacité baisse-t-elle réellement après un pic ? Consultez le graphique du nombre d'instances du mois dernier.
  • La base de données a-t-elle été soumise à un test de charge au trafic de pointe, et pas seulement la couche web ?
  • Les quotas de service sont-ils assez élevés pour votre pic attendu le plus important ?

Si plusieurs réponses sont « non », la charge est hébergée dans le cloud mais pas encore élastique. Les équipes d'Opsio en service managé AWS et en conseil cloud examinent et corrigent ces écarts dans le cadre du travail d'architecture.

Questions fréquentes

Qu'est-ce que l'élasticité rapide en cloud computing ?

C'est l'une des cinq caractéristiques essentielles du cloud computing définies par le NIST : la capacité peut être provisionnée et libérée rapidement, parfois automatiquement, pour s'étendre et se réduire avec la demande, et elle paraît illimitée à l'utilisateur.

Quel est un exemple d'élasticité rapide ?

Une boutique en ligne qui exploite quatre serveurs web un jour normal, passe automatiquement à vingt pendant une campagne de soldes, puis revient à quatre à la fin. Elle ne paie les seize serveurs supplémentaires que pendant leur fonctionnement.

Quelle différence entre élasticité et scalabilité ?

La scalabilité est la capacité d'absorber plus de charge en ajoutant des ressources, généralement sur le long terme. L'élasticité consiste à ajouter et retirer ces ressources rapidement, souvent automatiquement, au fil de la demande.

L'élasticité rapide est-elle la même chose que l'autoscaling ?

Pas tout à fait. L'élasticité est la caractéristique ; l'autoscaling est le moyen le plus courant de l'obtenir. La définition du NIST dit que le provisionnement se fait « dans certains cas automatiquement », donc une mise à l'échelle manuelle rapide compte aussi, mais en pratique les équipes cloud l'automatisent.

Pourquoi l'élasticité est-elle importante dans le cloud computing ?

Parce qu'elle supprime le dilemme entre payer une capacité inutilisée et manquer de capacité en pointe. Vous dimensionnez pour la demande du jour, vous étendez quand elle monte et vous réduisez quand elle baisse.

À lire aussi

Rédigé par

Fredrik Karlsson
Fredrik Karlsson

Group COO & CISO

Fredrik est le COO et CISO du groupe chez Opsio. Il se concentre sur l'excellence opérationnelle, la gouvernance et la sécurité de l'information, travaillant en étroite collaboration avec les équipes de livraison et de direction pour aligner technologie, risque et résultats métier dans des environnements IT complexes. Il dirige la pratique sécurité d'Opsio, incluant les services SOC, les tests d'intrusion et les cadres de conformité.

Charte éditoriale : Cet article a été rédigé par le praticien du cloud cité ci-dessus. Nous le révisons lorsque la technologie ou la réglementation qu'il traite évolue ; les dates de cette page indiquent la dernière mise à jour. Opsio est éditorialement indépendant.