L'auto-scaling augmente et réduit le nombre d'instances exécutant votre application Node.js en fonction des variations de charge CPU, afin que les périodes d'affluence disposent de plus de capacité et que les périodes calmes coûtent moins cher. Ce guide couvre l'onglet KPanel, chaque réglage, ce qui est facturé, et comment rendre une application apte à être mise à l'échelle en toute sécurité.
Où se trouve le scaling dans KPanel
- Connectez-vous à KPanel.
- Cliquez sur Sites web dans la barre latérale gauche, puis cliquez sur le site.
- Dans le menu de gauche du site, ouvrez Performances, puis Mise à l'échelle.
L'adresse directe est /websites/<site-id>/autoscale. L'ancienne adresse /websites/<site-id>/scaling fonctionne toujours et vous redirige vers le même endroit.
Cet onglet n'apparaît que pour les sites Node.js. Il ne figurera pas dans le menu pour un site WordPress, WooCommerce, statique, PHP, Python ou Ruby, car le mécanisme fait évoluer un cluster de processus Node.js.
Un seul onglet, une seule configuration
KPanel proposait autrefois deux onglets à cet endroit, Mise à l'échelle et Autoscaling, pour un seul et même ensemble de réglages. Il s'agissait de deux vues d'une même configuration, ce qui ne faisait que prêter à confusion. Il n'existe donc désormais qu'un seul onglet Mise à l'échelle : le statut en direct, les réglages, les événements de scaling récents, et le panneau d'utilisation et de coût pour la période de facturation en cours, le tout au même endroit.
Comment ça fonctionne
Votre application s'exécute sous forme de cluster de processus. L'auto-scaling surveille la moyenne du CPU sur les instances en cours d'exécution et ajoute ou retire des instances en fonction des seuils que vous définissez.
Le mode cluster est requis. Si votre application ne s'exécute pas déjà en mode cluster, l'activation de l'auto-scaling bascule celle-ci automatiquement, ce qui implique un bref redémarrage. La page vous informe lorsque cela se produit.
Lire le statut en direct
La carte de statut affiche trois éléments :
- Instances : combien sont en cours d'exécution actuellement.
- CPU moyen : la moyenne du CPU sur ces instances.
- Cluster : indique si l'application est en mode cluster. Si la réponse est non, l'activation de l'auto-scaling basculera le mode.
Si l'application n'est pas du tout en cours d'exécution, la carte l'indique au lieu d'afficher des zéros.
L'onglet affiche également Dernier scaling, l'heure du dernier événement de scaling, ou jamais.
Les réglages
| Réglage | Plage | Ce qu'elle fait |
|---|---|---|
| Instances minimales | 1 à 16 | Le plancher. Ne descend jamais en dessous |
| Instances maximales | 1 à 16 | Le plafond. Ne dépasse jamais cette valeur |
| Monter en charge à CPU % | 5 à 99 | Une moyenne CPU au-dessus de ce seuil ajoute une instance |
| Réduire à CPU % | 1 à 95 | Une moyenne CPU en dessous de ce seuil en retire une |
| Délai d'attente (sec) | 30 à 3600 | Attente minimale entre deux actions de scaling |
L'interrupteur principal se trouve dans l'en-tête de la carte des réglages. Lorsque l'auto-scaling est désactivé, les réglages sont grisés et votre application conserve son nombre d'instances actuel.
Valeurs de départ raisonnables :
- Instances minimales : 1 ou 2. Deux si vous ne pouvez pas tolérer qu'un redémarrage d'une seule instance mette l'application hors ligne.
- Instances maximales correspondant à ce que vous êtes prêt à payer au pic, pas au plafond absolu.
- Montée en charge autour de 70 pour cent. Suffisamment élevé pour ne pas payer une marge que vous n'utilisez jamais, assez bas pour qu'il y ait le temps d'ajouter de la capacité avant que les requêtes ne commencent à s'accumuler.
- Réduction autour de 30 pour cent. Laissez un large écart entre les deux seuils.
- Un délai d'attente de quelques minutes. C'est le réglage le plus sous-estimé.
Définir les deux seuils de CPU trop proches l'un de l'autre provoque un effet de battement (flapping) : le cluster monte en charge, repasse immédiatement sous le seuil de réduction parce que la charge est désormais répartie plus largement, réduit, remonte en flèche, et ainsi de suite. Gardez un large écart et utilisez un délai d'attente généreux. Le flapping coûte de l'argent et déstabilise l'application.
Événements de scaling
L'onglet répertorie les événements de scaling récents, du plus récent au plus ancien, chacun affichant la direction, le nombre d'instances avant et après, la valeur de CPU qui a déclenché l'événement, et l'heure.
C'est le journal à consulter lorsque l'application s'est mal comportée. Une rafale d'événements de montée et de réduction en quelques minutes signifie que vos seuils sont trop proches ou que votre délai d'attente est trop court. Une seule montée en charge qui n'est jamais redescendue signifie que la charge est restée élevée, ce qui est une question de capacité plutôt que de configuration. Aucun événement du tout alors que vous en attendiez signifie soit que le CPU n'a jamais franchi un seuil, soit que l'auto-scaling est désactivé.
Ce que coûte l'auto-scaling
Les instances au-delà de l'allocation de base de votre offre sont mesurées et facturées à la seconde. L'onglet affiche, pour la période en cours :
- Temps d'instance utilisé, en heures et minutes, avec les secondes-instances brutes en dessous.
- Dépensé jusqu'à présent sur cette période.
- Fin de mois projetée, extrapolée à partir de l'utilisation constatée jusqu'ici.
- Suivi, combien de fenêtres d'utilisation ont été facturées sur le total enregistré.
- Progression de la période, jours écoulés sur le nombre de jours du mois.
Le tarif par seconde est affiché en haut de ce même panneau, de sorte que le chiffre qui sert de base à la facturation est toujours visible à côté de l'utilisation à laquelle il s'applique.
La projection est le chiffre à surveiller. Elle extrapole à partir de ce que vous avez utilisé jusqu'à présent, de sorte qu'une semaine inhabituellement chargée en début de mois la surestimera. Vérifiez-la quelques jours après, puis à nouveau à la mi-mois, avant d'en tirer des conclusions. Si elle est plus élevée que vous ne le souhaitez, réduisez le nombre maximal d'instances plutôt que d'augmenter le seuil de montée en charge : le plafond est une limite stricte, un seuil n'est qu'une indication.
Réduire au minimum arrête la facturation au compteur. Si vous désactivez entièrement l'auto-scaling, l'application conserve le nombre d'instances qu'elle a actuellement, donc ramenez-la d'abord au minimum si le coût est la raison pour laquelle vous désactivez la fonction.
Rendre une application apte à être mise à l'échelle en toute sécurité
La page affiche un avertissement, et c'est l'élément le plus important qui y figure : votre application Node.js doit être compatible cluster pour être mise à l'échelle proprement sur plusieurs instances.
En pratique, cela signifie :
Aucun état de session en mémoire. Si la session d'un utilisateur connecté vit dans la mémoire d'une instance, il est déconnecté dès qu'une requête atterrit sur une autre instance. Déplacez les sessions vers un stockage partagé.
Aucun cache en mémoire dont vous dépendez pour l'exactitude des données. Chaque instance a le sien. Un cache qui doit rester cohérent doit être partagé.
Aucune écriture sur le système de fichiers local que vous comptez relire. Les fichiers téléversés en local par une instance sont invisibles pour les autres. Écrivez vers un stockage partagé.
Aucune tâche planifiée non protégée. Si un minuteur s'exécute à l'intérieur de l'application, chaque instance l'exécute, de sorte qu'une tâche nocturne sur quatre instances s'exécute quatre fois. Déplacez les tâches planifiées vers une tâche cron, ou protégez-les par un verrou. Voir Tâches cron.
Aucune hypothèse selon laquelle le nombre d'instances serait stable. Tout ce qui répartit le travail par index d'instance cesse de fonctionner dès que ce nombre change.
Si l'un de ces points s'applique à votre application, corrigez-le avant d'activer l'auto-scaling. Une application non compatible cluster échoue de façon intermittente et difficile à reproduire, car cela dépend de l'instance qui a traité telle ou telle requête.
Dépannage
L'interrupteur ne s'active pas. L'activation nécessite la permission d'écriture sur le site. Avec un rôle en lecture seule, les commandes sont désactivées.
L'application a redémarré lorsque j'ai activé l'auto-scaling. C'est normal. Le passage en mode cluster nécessite un redémarrage, qui ne survient qu'une seule fois.
Des utilisateurs sont déconnectés de manière aléatoire. Symptôme classique d'une application non compatible cluster. Les sessions sont en mémoire et les requêtes atterrissent sur des instances différentes.
Les instances ont augmenté et ne sont jamais redescendues. Soit la charge est restée au-dessus du seuil de réduction, soit quelque chose maintient le CPU élevé indépendamment du trafic. Consultez la liste des événements et observez ce que fait réellement l'application.
Une tâche planifiée s'est exécutée plusieurs fois. Chaque instance l'a exécutée. Déplacez-la vers une tâche cron ou ajoutez un verrou.
Rien ne change d'échelle. Vérifiez que l'interrupteur est activé, que l'application fonctionne, et que le mode cluster est activé. Vérifiez ensuite, dans la liste des événements, si le CPU a réellement franchi votre seuil de montée en charge.
Le coût est plus élevé que prévu. Regardez la liste des événements à la recherche d'un effet de flapping, puis réduisez votre nombre maximal d'instances.
Pages connexes
- Performance du site et APM pour voir si le CPU est réellement le goulot d'étranglement.
- Surveillance de la disponibilité du site pour confirmer que la mise à l'échelle améliore réellement la disponibilité.
- Tâches cron pour les tâches planifiées qui doivent s'exécuter exactement une fois.
- Redimensionner un serveur cloud si vous avez besoin d'une machine plus puissante plutôt que de plus d'instances.