Les fondamentaux du cloud computing
Scalabilité et élasticité
Pourquoi un système capable de grandir et un système qui grandit et rétrécit tout seul sont 2 compétences différentes, et comment les réglages de capacité et les politiques d'un groupe Auto Scaling livrent la seconde.
- Distinguer la scalabilité de l'élasticité et expliquer pourquoi elles répondent à 2 questions différentes
- Expliquer comment la capacité minimale, souhaitée et maximale d'un groupe Auto Scaling fonctionnent ensemble
- Comparer les politiques de mise à l'échelle par suivi de cible, par palier et planifiée, et identifier celle qui convient à un profil de demande donné
- Appliquer l'élasticité à un exemple chiffré montrant l'impact sur le coût d'ajuster la capacité à la demande en temps réel
Les 2 façons dont un plan pour plus de trafic peut mal tourner
Un détaillant dimensionne ses serveurs de paiement pour une journée de vente moyenne et se fait écraser la première fois qu'une vente flash double le trafic du jour au lendemain ; les requêtes s'accumulent, les pages expirent, et la vente devient l'histoire de la panne plutôt que celle du chiffre d'affaires. Une autre équipe surcorrige : elle provisionne assez de serveurs pour survivre à sa plus grosse journée de vente de l'année, puis paie cette même flotte les 364 autres jours, la plupart passés à tourner à une fraction de sa capacité. Aucune des 2 équipes n'a résolu le vrai problème, qui compte 2 volets distincts : le système peut-il grandir tout court, et grandit-il (et rétrécit-il) de lui-même pour suivre ce qui se passe réellement à cet instant.
Rappel : une croissance que vous connaissez déjà
La leçon sur le calcul, plus tôt dans ce cours, a couvert la scalabilité horizontale, ajouter d'autres instances de même taille derrière un load balancer, comme réponse au manque de capacité. Ce qu'elle n'a pas couvert, c'est qui décide d'ajouter ces instances, ni quand les retirer une fois la charge redescendue. Cet écart, la couche de décision posée au-dessus de la scalabilité horizontale, est exactement ce que cette leçon vient combler.
La scalabilité : la capacité à grandir
La scalabilité est l'aptitude d'un système à absorber davantage de charge en ajoutant des ressources, que cela signifie redimensionner 1 machine (scalabilité verticale) ou ajouter d'autres machines de même taille (scalabilité horizontale). Rien dans cette définition n'impose que la croissance soit automatique. Une équipe qui remarque un trafic en hausse et lance manuellement 3 instances de plus a fait grandir le système. Il en va de même pour un service informatique sur site qui commande et installe 2 nouveaux serveurs physiques sur plusieurs semaines. Les 2 ont amélioré la capacité du système à absorber la charge ; aucun des 2 ne l'a fait tout seul, en temps réel, ni n'a rendu la moindre capacité une fois qu'elle n'était plus nécessaire.
L'élasticité : ajuster la capacité à la demande, automatiquement
L'élasticité, c'est ce qui se produit quand cette prise de décision devient automatisée dans les 2 sens : la capacité augmente quand la demande monte et diminue quand elle redescend, sans qu'une personne surveille un tableau de bord et clique sur un bouton à chaque fois. C'est une idée réellement propre au cloud. Un serveur physique que vous possédez déjà et avez déjà payé ne réduit pas votre facture quand il tourne au ralenti la nuit ; une instance cloud terminée pendant une période creuse cesse de vous coûter quoi que ce soit dès l'instant où elle disparaît. L'élasticité est la raison pour laquelle « ne payer que ce que vous utilisez » est plus qu'un slogan : cela exige que le système remarque réellement quand « ce que vous utilisez » a changé, et agisse en conséquence, en continu, sans attendre un humain.
Imaginez une autoroute qu'une équipe de chantier peut élargir sur plusieurs mois, face à une autoroute dotée d'une voie réversible qui s'ouvre automatiquement quand des capteurs détectent le trafic des heures de pointe et se referme une fois qu'il se dissipe. Élargir l'autoroute, c'est la scalabilité : une vraie capacité, un vrai effort, et aucune raison de jamais l'annuler. La voie réversible, c'est l'élasticité : la même route, redimensionnée instantanément et automatiquement selon le trafic réellement présent à cet instant, puis refermée dès qu'elle n'est plus nécessaire. Poussez la comparaison plus loin et elle se brise : une voie réversible est une infrastructure fixe qu'on bascule, pas créée puis détruite, alors qu'une instance cloud est provisionnée puis démantelée entièrement à chaque fois, ce qui est exactement ce qui la rend gratuite pendant son absence.
Exemple chiffré : 1 journée à l'intérieur d'un groupe Auto Scaling
Un groupe Auto Scaling est le mécanisme AWS qui automatise cela. Disons qu'un groupe est configuré avec une capacité minimale de 4 instances, une capacité souhaitée de 6, et une capacité maximale de 12. Le minimum et le maximum sont des bornes strictes que le groupe ne franchira jamais dans un sens ni dans l'autre ; la capacité souhaitée est le point de départ qu'une politique de mise à l'échelle ajuste à l'intérieur de cette plage.
À 9h, le trafic monte et l'utilisation moyenne du CPU sur le groupe dépasse sa cible. Une politique de suivi de cible lance de nouvelles instances, 1 ou 2 à la fois, jusqu'à ce que l'utilisation du CPU se stabilise près de la cible, la capacité atteignant environ 10 instances en milieu de matinée. Le trafic se maintient dans la journée puis retombe vers 18h ; la même politique termine alors des instances à mesure que l'utilisation du CPU repasse sous la cible, ramenant la capacité vers 6, puis vers le minimum de 4 pendant la nuit. Le groupe ne touche jamais son plafond de 12 instances ce jour-là, et il ne descend jamais sous 4. L'équipe paie environ 10 instances pendant les 9 heures chargées qui en avaient besoin, et bien moins la nuit, au lieu de faire tourner 12 (ou même 10 en continu) pendant les 24 heures.
Les politiques de mise à l'échelle : 3 façons de dire au groupe quand agir
| Politique | Comment elle décide | Convient le mieux à |
|---|---|---|
| Suivi de cible | Ajuste la capacité en continu pour maintenir une métrique choisie, comme l'utilisation moyenne du CPU, proche d'une valeur cible | Une demande en direct, quelque peu imprévisible |
| Mise à l'échelle par palier | Ajoute ou retire de la capacité par paliers définis, dimensionnés selon l'écart d'une métrique par rapport à son seuil | Une demande qui peut s'emballer brusquement et réclame une réponse proportionnellement plus large |
| Mise à l'échelle planifiée | Fixe la capacité avant un moment connu, indépendamment de toute métrique en direct | Des profils prévisibles, comme le pic quotidien à 9h d'un détaillant ou un traitement par lot mensuel |
Ces politiques ne s'excluent pas mutuellement. Une équipe de vente au détail peut faire tourner une mise à l'échelle planifiée pour préchauffer la capacité juste avant son pic connu de 9h, puis laisser le suivi de cible gérer les fluctuations plus petites du reste de la journée par-dessus cette avance.
L'élasticité, c'est aussi de l'auto-guérison
Les groupes Auto Scaling font plus que redimensionner selon la demande. Ils vérifient en continu la santé de chaque instance et remplacent celles qui échouent, automatiquement, pour maintenir le groupe à sa capacité souhaitée même quand rien n'a changé côté trafic. Cela rejoint directement la leçon précédente : un groupe Auto Scaling réparti sur plusieurs zones de disponibilité fait partie de la façon dont une architecture hautement disponible se construit dès le départ, pas un sujet séparé.
Idée reçue : « Auto Scaling » ne concerne pas que la montée en charge
Il est tentant, en entendant « Auto Scaling », de n'imaginer que la moitié excitante : ajouter automatiquement de la capacité pour survivre à un pic de trafic. La moitié qui économise réellement de l'argent, c'est la réduction, retirer de la capacité une fois la demande retombée. Un groupe sans minimum réellement respecté ou sans politique de réduction attachée devient juste une version coûteuse et auto-lancée de la simple scalabilité : il grandit tout seul, mais ne rend jamais rien, et l'avantage de coût que l'élasticité est censée apporter n'apparaît jamais sur la facture.
Repères d'examen : lire une question scalabilité contre élasticité
| Le scénario mentionne... | Pointe vers |
|---|---|
| « Absorber une charge croissante en ajoutant des ressources » | La scalabilité |
| « S'ajuste automatiquement à la demande en temps réel », « ne payer que ce qu'on utilise », « redescend au repos » | L'élasticité |
| « Minimale », « souhaitée », « capacité maximale » | Les réglages d'un groupe Auto Scaling |
| « Pic connu et prévisible à un moment précis » | La mise à l'échelle planifiée |
| « Maintenir une utilisation du CPU cible » | Le suivi de cible |
Où cela vous mène
La scalabilité répond à la question de savoir si un système peut grandir tout court ; l'élasticité répond à celle de savoir s'il grandit, et rétrécit, lui-même, automatiquement, au rythme d'une demande qui change minute après minute. Toute charge de travail cloud a besoin de la première. Seules les charges de travail à demande réellement variable tirent une valeur réelle de la seconde, ce qui concerne la plupart d'entre elles, un trafic parfaitement constant restant rare en dehors de quelques systèmes internes stables. La prochaine leçon suppose tout cela acquis, redondance, vérifications de santé, capacité bien dimensionnée, et se demande ce qui se passe malgré tout : quand une panne dépasse ce que tout cela peut absorber, et qu'une équipe doit s'appuyer sur des sauvegardes et un plan de reprise après sinistre.