Stratégies de passage à l’échelle : verticale, horizontale et cube de scalabilité

Ce que signifie passer à l’échelle en pratique

La section 2.4 a défini la scalabilité comme la capacité à absorber davantage de charge en ajoutant des ressources, et a montré avec la loi d’Amdahl et la loi universelle de scalabilité pourquoi ajouter des ressources n’ajoute pas toujours de la capacité. Cette section porte sur les choix pratiques : quelles ressources ajouter, où, quand et avec quel degré d’automatisation. Le point de départ est toujours la même question : quel est le paramètre de charge, et quelle ressource vient à manquer en premier ? À midi, l’API de commandes d’une plateforme de livraison de repas est limitée par les requêtes par seconde ; son service d’affectation, par le nombre de livreurs actifs dont les positions doivent être rapprochées toutes les quelques secondes ; sa base de données, par les transactions d’écriture par seconde et par les connexions. Chacun appelle une réponse différente.

Faire passer un système à l’échelle, c’est en réalité faire passer à l’échelle son goulot d’étranglement actuel, puis trouver le suivant. Doubler le niveau web d’un système dont la base de données est occupée à 95 % n’apporte rien d’autre qu’une facture plus lourde et une base de données encore plus sollicitée. Toute décision de passage à l’échelle commence donc par une mesure : taux d’utilisation et saturation de chaque ressource (la méthode USE de Brendan Gregg, présentée dans Observabilité), et un test de charge qui trouve à partir de quand la latence commence à grimper (Planification de la capacité et tests de performances).

Scalabilité verticale : une machine plus grosse

La scalabilité verticale (scaling up) consiste à donner à la machine existante plus de cœurs de CPU, plus de mémoire, des disques plus rapides ou un réseau plus rapide. Sa grande vertu est que rien ne change dans le logiciel. Une base de données relationnelle unique sur un serveur plus grand conserve ses transactions, ses jointures et sa cohérence simple ; une application conserve ses caches en mémoire et ses fichiers locaux. Dans le cloud, le redimensionnement est un appel d’API suivi d’un redémarrage. Les plus grandes machines virtuelles du cloud offrent désormais des centaines de CPU virtuels et des téraoctets de mémoire, bien plus que ce dont la plupart des systèmes de gestion auront jamais besoin, et certains sites web très fréquentés ont décrit publiquement comment ils servent un trafic énorme à partir d’un petit nombre de serveurs de bases de données puissants.

Les limites sont pourtant réelles. Il existe une machine plus grande que toutes les autres, et le prix par unité de capacité augmente fortement en haut de la gamme. Une machine constitue un seul domaine de défaillance : quand elle tombe en panne, ou qu’elle est redémarrée pour être redimensionnée ou corrigée, tout ce qu’elle héberge s’arrête ; la scalabilité verticale seule n’apporte donc rien à la disponibilité. Le logiciel ne peut souvent pas exploiter pleinement une machine plus grosse : un processus monothread, un verrou global ou une ligne chaude de la base de données limitent l’accélération exactement comme le prédit la loi d’Amdahl. Et la capacité vient par grandes marches lentes, si bien que vous payez le pic jour et nuit. La scalabilité verticale reste néanmoins le bon premier geste bien plus souvent que la mode ne le laisse croire, en particulier pour les bases de données, où la scalabilité horizontale coûte cher en effort de conception.

Scalabilité horizontale : plus de machines

La scalabilité horizontale (scaling out) consiste à exécuter davantage d’instances et à répartir le travail entre elles, généralement avec un équilibreur de charge en amont. Elle va beaucoup plus loin, par petites marches peu coûteuses, et la redondance qui ajoute de la capacité permet aussi de tolérer les défaillances : avec huit instances, en perdre une coûte un huitième de la capacité plutôt que sa totalité. Les plateformes cloud permettent d’ajouter une instance en quelques secondes ou minutes, ce qui est le fondement de l’autoscaling.

Le prix à payer est que le logiciel doit être conçu pour cela. N’importe quelle instance doit pouvoir traiter n’importe quelle requête, ce qui signifie que les instances ne doivent rien conserver dont dépendrait une requête ultérieure (voir la section suivante). Le travail doit être divisible : une tâche qui exige un verrou global unique ne s’exécute pas plus vite sur dix machines. Les données doivent être accessibles depuis chaque instance, ce qui reporte la pression sur le niveau de données partagé. Et le système devient distribué, avec les défaillances partielles, les délais d’expiration et les nouvelles tentatives que décrit la section 6.1. La plupart des systèmes réels combinent les deux : les niveaux applicatifs sans état passent à l’échelle horizontalement, tandis que les bases de données passent à l’échelle verticalement aussi longtemps que c’est raisonnable, puis horizontalement avec des répliques et des partitions.

Le cube de scalabilité : trois façons différentes de passer à l’échelle horizontalement

Martin Abbott et Michael Fisher, qui ont dirigé la technologie chez eBay et PayPal, décrivent la scalabilité horizontale à l’aide du cube de scalabilité dans The Art of Scalability (première édition 2009, deuxième édition 2015). Il distingue trois façons indépendantes de découper un système, chacune représentée par un axe d’un cube dont l’origine est une instance unique qui fait tout.

L’axe X est la duplication horizontale, ou clonage : exécuter N copies identiques de toute l’application ou du service et répartir les requêtes entre elles. C’est l’axe le plus simple et le moins coûteux, et il convient bien au traitement de requêtes sans état et au trafic de lecture. Il n’apporte rien pour la taille des données ni pour le volume d’écriture, car chaque clone parle toujours aux mêmes données, et rien non plus pour la taille de la base de code ou le nombre d’équipes qui y travaillent.

L’axe Y découpe le système par fonction : des services différents pour les cartes, les commandes, l’affectation et les paiements, chacun n’exécutant que le code et les données de sa capacité. Chaque service peut alors passer à l’échelle, tomber en panne et être déployé séparément, et chacun est plus petit et plus facile à comprendre. C’est l’axe qui sous-tend les microservices (section 6.3), avec tous leurs coûts. L’axe Z découpe par données : chaque copie exécute le même code, mais chacune n’est responsable que d’une tranche des clients, des locataires, des régions ou des enregistrements, choisie selon une clé comme la ville ou l’identifiant client. Le sharding de base de données est l’axe Z appliqué au stockage (section 7.4) ; une architecture cellulaire l’applique à des piles entières, de sorte qu’une faute ou un mauvais déploiement dans une cellule n’affecte que les clients de cette cellule.

Les axes se combinent. Le service de commandes de la plateforme (un découpage sur l’axe Y) s’exécute sous forme de nombreux clones (X) dans chaque cellule régionale (Z). Le conseil pratique d’Abbott et Fisher est d’utiliser l’axe le moins coûteux qui résout le problème réel : X pour le volume de requêtes, Y quand des parties du système ont des besoins réellement différents en matière de passage à l’échelle, de défaillances ou d’équipes, et Z quand un jeu de données ou un rayon d’impact est devenu trop grand. Choisir Z parce que cela fait impression apporte le routage, le rééquilibrage et les requêtes entre partitions bien avant qu’on en ait besoin.

L’absence d’état : la condition préalable au clonage

La scalabilité sur l’axe X ne fonctionne que si n’importe quel clone peut servir n’importe quelle requête. Un service sans état ne conserve rien entre les requêtes dans sa propre mémoire ni sur son propre disque ; tout ce dont une requête ultérieure a besoin se trouve dans un stockage partagé ou voyage avec la requête. L’état qui se cache habituellement dans une instance est facile à recenser dès qu’on le cherche : sessions utilisateur conservées en mémoire, fichiers envoyés écrits sur le disque local, caches en mémoire traités comme la source de vérité, tâches planifiées qui doivent s’exécuter sur exactement une machine, verrous internes au processus protégeant une ressource partagée, et compteurs de limitation de débit.

Chacun a un remède classique : les sessions vont dans un stockage partagé ou dans un jeton signé (section 9.2) ; les fichiers vont dans un stockage objet ; les caches deviennent une optimisation de performances qui peut être perdue à tout moment, ou passent dans un cache partagé (section 7.6) ; les tâches planifiées utilisent un ordonnanceur avec élection de leader ou une file d’attente ; les verrous passent dans la base de données ou dans un service de coordination ; les compteurs de limitation de débit passent dans un stockage partagé. La règle de l’application douze facteurs selon laquelle les processus sont sans état et ne partagent rien (section 10.3) exprime cette même idée. L’absence d’état coûte peu à intégrer dès la conception et cher à ajouter après coup, car l’état s’infiltre dans le code en de nombreux petits endroits.

Autoscaling : réactif, planifié et prédictif

L’autoscaling ferme une boucle de rétroaction : mesurer la charge, la comparer à une cible, modifier le nombre d’instances. L’autoscaling réactif le fait en continu à partir d’une métrique. Le suivi de cible (target tracking) en est la forme courante : maintenir le CPU moyen à 60 %, ou les requêtes en cours par instance à 30. Le Horizontal Pod Autoscaler de Kubernetes calcule desired = ceil(current replicas × current metric ÷ target) : six pods à 45 requêtes en cours en moyenne pour une cible de 30 deviennent ceil(6 × 45 ÷ 30) = 9. Par défaut, il réévalue la situation toutes les 15 secondes et ignore les écarts de moins de 10 % par rapport à la cible.

L’autoscaling planifié modifie la capacité à des heures connues : relever le minimum à 18 instances à 11 h 15 chaque jour de semaine avant le pic de midi, le rabaisser à 14 h 00. C’est rudimentaire mais très efficace pour des schémas prévisibles, et c’est le seul moyen d’avoir la capacité en place avant un changement brusque comme une mise en vente de billets à 10 h 00 précises. L’autoscaling prédictif, proposé par les principaux fournisseurs de cloud, prévoit la charge à partir de l’historique (cycles quotidiens et hebdomadaires) et passe à l’échelle en avance, avec l’autoscaling réactif comme filet de sécurité pour les surprises.

La propriété cruciale de tout schéma réactif est le décalage. Les métriques sont collectées et moyennées sur des dizaines de secondes ; l’autoscaler agit lors de sa prochaine évaluation ; une nouvelle machine virtuelle met une minute ou plus à démarrer, une image de conteneur doit être téléchargée, un service JVM ou Python doit démarrer, chauffer ses caches et ses pools de connexions et passer sa sonde de disponibilité avant que l’équilibreur de charge ne lui envoie du trafic. Dans un cluster, il faut parfois d’abord ajouter les nœuds eux-mêmes, au moyen d’un second autoscaler, plus lent. Entre le moment où la charge augmente et celui où la nouvelle capacité devient utile, il s’écoule couramment de deux à dix minutes. L’autoscaling réactif gère donc les changements progressifs ; les changements soudains doivent être absorbés par une marge de capacité, par des files d’attente (section 9.3) ou par une capacité planifiée à l’avance.

Sur quelle métrique passer à l’échelle, et pourquoi le CPU est souvent un mauvais choix

Le taux d’utilisation du CPU est le signal par défaut de la plupart des plateformes parce qu’il est toujours disponible. Ce n’est le bon signal que lorsque le service est limité par le CPU : redimensionnement d’images, chiffrement, sérialisation lourde. La plupart des services métier ne le sont pas. Une API de commandes passe l’essentiel de chaque requête à attendre la base de données, le prestataire de paiement et d’autres services ; son CPU peut rester à 25 % alors que tous les threads de travail sont occupés à attendre et que les nouvelles requêtes s’accumulent. Passer à l’échelle sur le CPU ne déclenche alors rien avant qu’il ne soit bien trop tard. La défaillance inverse se produit aussi : une tempête de ramasse-miettes ou un préchauffage JIT fait monter le CPU sans aucune hausse de la charge, et l’autoscaler ajoute des instances inutiles.

Un meilleur signal est un signal directement lié à la ressource qui vient à manquer. Pour les services requête-réponse, il s’agit généralement de la concurrence : le nombre de requêtes en cours par instance, comparé au nombre de threads de travail ou de connexions dont elle dispose. La loi de Little rend ce lien exact (en cours = taux d’arrivée × temps de réponse), et ce signal réagit à la fois à un trafic accru et à des réponses plus lentes. Pour les workers de file d’attente, c’est l’arriéré par worker ou l’âge du plus ancien message, qui exprime le temps que la file mettra à se résorber. La latence est tentante mais dangereuse comme signal de passage à l’échelle : elle augmente pour des raisons que davantage d’instances ne peuvent pas corriger, comme une base de données lente, et ajouter des instances à un service dont une dépendance est en difficulté envoie encore plus de charge à cette dépendance. Utilisez la latence pour les alertes, et passez à l’échelle sur une mesure du travail.

Cooldowns, stabilisation et flapping

Un autoscaler qui réagit à chaque soubresaut va osciller (flapping) : ajouter des instances quand une rafale arrive, les retirer une minute plus tard quand elle est passée, puis les rajouter, en payant chaque fois le coût du démarrage et en perturbant les caches et les pools de connexions. Il peut aussi courir après sa propre queue : les nouvelles instances sont froides et lentes, donc la latence ou le CPU par requête augmente brièvement après l’ajout d’instances, ce qui ressemble à davantage de charge.

Les défenses classiques sont asymétriques. Ajoutez des instances rapidement, car un manque de capacité pénalise les utilisateurs ; retirez-les lentement, car un excès de capacité ne coûte que de l’argent. Un cooldown, ou fenêtre de stabilisation, fait attendre l’autoscaler après une action, ou lui fait retenir la recommandation la plus élevée sur une fenêtre récente avant de réduire : par défaut, l’autoscaler de Kubernetes utilise une fenêtre de cinq minutes (300 secondes) pour la réduction et aucune pour l’augmentation. Une bande de tolérance ignore les petits écarts. Des nombres minimal et maximal d’instances bornent la boucle : le minimum conserve assez de capacité pour survivre à la perte d’une zone et aux premières minutes d’une hausse soudaine, et le maximum protège la base de données, les services en aval et le budget contre un autoscaler qui prendrait un problème pour de la charge. La réduction doit aussi se faire en douceur : une instance choisie pour être retirée doit cesser de recevoir de nouvelles requêtes et terminer celles en cours (drainage des connexions, section 9.2).

Faire passer le niveau des données à l’échelle

Les niveaux applicatifs sans état sont faciles à faire passer à l’échelle ; c’est tout l’intérêt de les rendre sans état. La pression retombe alors sur les bases de données, les caches et les courtiers qu’ils partagent, et c’est pourquoi le niveau des données est généralement la véritable limite d’un système. Les outils ont été présentés au chapitre 7 et sont résumés ici dans l’ordre où les professionnels y ont généralement recours. Premièrement, réduire le travail : index, meilleures requêtes, moins d’allers-retours par requête. Deuxièmement, absorber les lectures avec la mise en cache (section 7.6) et des répliques en lecture, en acceptant le retard de réplication là où le cas d’usage le permet. Troisièmement, protéger les connexions : chaque instance applicative détient un pool, donc le total croît avec le parc, et un pooler de connexions comme PgBouncer permet à des milliers de connexions clientes de partager quelques centaines de connexions à la base (la valeur par défaut de max_connections dans PostgreSQL n’est que de 100). Quatrièmement, faire passer le serveur primaire à l’échelle verticalement, ce qui est souvent moins coûteux que toute refonte. Seulement ensuite, partitionner les écritures selon l’axe Z par une clé comme la ville ou le client (section 7.4), ou passer à une base de données SQL distribuée.

Deux mises en garde s’imposent. Premièrement, l’autoscaling du niveau applicatif peut nuire au niveau des données : chaque nouvelle instance ouvre des connexions et chauffe son cache à partir de la base de données, si bien qu’un ajout massif d’instances peut à lui seul surcharger la base. Deuxièmement, certaines limites sont logiques et non physiques : une seule ligne chaude (le stock des 500 derniers billets d’un concert, ou un numéro de séquence global) sérialise les écritures quelle que soit la taille du serveur. Ces limites se suppriment par la conception, par exemple en répartissant le stock sur plusieurs compteurs ou en réservant les places par lots, et non par le matériel.