Sites web
Mise à l'échelle et auto-scaling d'une application Node.js
Auto-scaling grows and shrinks the number of instances running your Node.js app as CPU load changes, so busy periods get more capacity and quiet periods cost less. This guide covers the KPanel tab…
Mise à l'échelle et mise à l'échelle automatique d'une application Node.js
La mise à l'échelle automatique augmente et diminue le nombre d'instances exécutant votre application Node.js à mesure que la charge CPU change, de sorte que les périodes chargées obtiennent plus de capacité et les périodes calmes coûtent moins cher. Ce guide couvre l'onglet KPanel, tous les paramètres, ce qui est facturé et comment rendre une application sûre pour la mise à l'échelle.
Où se trouve la mise à l'échelle dans KPanel
- Connectez-vous à KPanel.
- Cliquez sur Websites dans la barre latérale gauche, puis cliquez sur le site.
- Dans la bande d'onglets du site, ouvrez Advanced, puis Scaling.
L'adresse directe est /websites/<site-id>/autoscale. L'ancienne adresse /websites/<site-id>/scaling fonctionne toujours et vous envoie au même endroit.
L'onglet n'apparaît que sur les sites Node.js. Il ne sera pas dans le menu pour un site WordPress, WooCommerce, statique, PHP, Python ou Ruby, car le mécanisme met à l'échelle un cluster de processus Node.js.
Un onglet, une configuration
KPanel avait l'habitude de porter deux onglets ici, Scaling et Autoscale, sur un ensemble de paramètres. C'était deux vues de la même configuration, ce qui n'a jamais été qu'une façon de se perdre, donc ils sont maintenant un seul onglet Scaling : état en direct, les paramètres, les événements de mise à l'échelle récents et le panneau d'utilisation et de coût pour la période de facturation actuelle, tout en un seul endroit.
Comment ça marche
Votre application s'exécute en tant que cluster de processus. La mise à l'échelle automatique surveille le CPU moyen sur les instances en cours d'exécution et ajoute ou supprime des instances selon les seuils que vous définissez.
Le mode cluster est obligatoire. Si votre application n'est pas déjà en mode cluster, l'activation de la mise à l'échelle automatique la bascule pour vous, ce qui implique un redémarrage bref. La page vous indique quand cela se produit.
Lecture de l'état en direct
La carte d'état affiche trois choses :
- Instances : combien en cours d'exécution en ce moment.
- Avg CPU : le CPU moyen sur ces instances.
- Cluster : si l'application est en mode cluster. S'il dit non, l'activation de la mise à l'échelle automatique la basculera.
Si l'application n'est pas du tout en cours d'exécution, la carte l'indique à la place d'afficher des zéros.
L'onglet affiche également Last scale, l'heure de l'événement de mise à l'échelle le plus récent, ou never.
Les paramètres
| Paramètre | Plage | Ce qu'il fait |
|---|---|---|
| Min instances | 1 à 16 | Le minimum. N'est jamais réduit en dessous de ceci |
| Max instances | 1 à 16 | Le maximum. N'est jamais augmenté au-delà de ceci |
| Scale up at CPU % | 5 à 99 | Une CPU moyenne au-dessus de ceci ajoute une instance |
| Scale down at CPU % | 1 à 95 | Une CPU moyenne en dessous de ceci supprime une instance |
| Cooldown (sec) | 30 à 3600 | Attente minimale entre les actions de mise à l'échelle |
Le commutateur maître est l'interrupteur dans l'en-tête de la carte des paramètres. Quand la mise à l'échelle automatique est désactivée, les paramètres sont grisés et votre application reste sur son nombre actuel d'instances.
Valeurs de départ sensées :
- Min instances 1 ou 2. Deux si vous ne pouvez pas tolérer qu'un redémarrage d'une seule instance mette l'application hors ligne.
- Max instances à ce que vous êtes disposé à payer au pic, non au maximum.
- Scale up autour de 70 pour cent. Assez haut pour que vous ne payiez pas pour de la réserve que vous n'utiliserez jamais, assez bas pour qu'il y ait du temps d'ajouter de la capacité avant que les demandes ne commencent à s'accumuler.
- Scale down autour de 30 pour cent. Laissez un écart important entre les deux seuils.
- Cooldown de quelques minutes. C'est le paramètre le plus sous-estimé.
Rapprocher les deux seuils CPU cause du flapping : le cluster augmente, tombe immédiatement sous le seuil de réduction d'échelle parce que la charge est maintenant répartie plus largement, se réduit, augmente à nouveau et se répète. Gardez un écart important et utilisez un cooldown généreux. Le flapping coûte de l'argent et déstabilise l'application.
Événements de mise à l'échelle
L'onglet répertorie les événements de mise à l'échelle récents, les plus récents en premier, chacun affichant la direction, le nombre d'instances avant et après, la lecture CPU qui l'a déclenché et l'heure.
C'est le journal à consulter quand l'application s'est mal comportée. Une rafale d'événements de hausse et de baisse en quelques minutes signifie que vos seuils sont trop proches ou votre cooldown trop court. Une augmentation d'échelle unique qui n'a jamais baissé signifie que la charge est restée élevée, ce qui est une question de capacité plutôt qu'une question de configuration. Aucun événement du tout quand vous en attendiez signifie soit que le CPU n'a jamais franchi un seuil, soit que la mise à l'échelle automatique est désactivée.
Ce que la mise à l'échelle automatique coûte
Les instances au-delà de l'allocation de base de votre plan sont mesurées et facturées à la seconde. L'onglet affiche, pour la période actuelle :
- Instance-time used, en heures et minutes, avec les instance-secondes brutes en dessous.
- Spent so far dans cette période.
- Projected month-end, extrapolé à partir de l'utilisation jusqu'à présent.
- Tracking, combien de fenêtres d'utilisation ont été facturées sur le total enregistré.
- Period progress, jours écoulés sur jours du mois.
Le taux par seconde est affiché en haut du même panneau, de sorte que le chiffre sur lequel vous êtes facturé est toujours visible à côté de l'utilisation à laquelle il s'applique.
La projection est le nombre à surveiller. Elle extrapole à partir de ce que vous avez utilisé jusqu'à présent, donc une semaine inhabituellement chargée au début du mois la surestimera. Vérifiez-la quelques jours plus tard, puis à nouveau à la mi-mois, avant de tirer des conclusions. Si elle est plus élevée que vous le souhaitez, diminuez le nombre maximal d'instances plutôt que d'augmenter le seuil de montée en échelle : le plafond est une limite stricte, un seuil n'est qu'une indication.
Réduire l'échelle au minimum arrête la mesure. Si vous désactivez entièrement la mise à l'échelle automatique, l'application reste sur le nombre d'instances qu'elle a actuellement, donc réduisez-le d'abord au minimum si le coût est la raison pour laquelle vous passez à l'arrêt.
Rendre une application sûre pour la mise à l'échelle
La page comporte un avertissement, et c'est la chose la plus importante qu'elle contient : votre application Node.js doit être compatible avec le cluster pour se mettre à l'échelle proprement sur les instances.
En pratique, cela signifie :
Pas d'é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é chaque fois qu'une demande atterrit sur une autre instance. Déplacez les sessions vers un magasin partagé.
Pas de cache en mémoire sur lequel vous comptez pour la justesse. Chaque instance a le sien. Un cache qui doit être cohérent doit être partagé.
Pas d'écritures locales sur le système de fichiers que vous vous attendez à relire. Les téléversements écrits sur le disque local par une instance sont invisibles pour les autres. Écrivez sur un stockage partagé.
Pas de travail planifié sans protection. Si une minuterie s'exécute à l'intérieur de l'application, chaque instance l'exécute, donc une tâche nocturne à quatre instances s'exécute quatre fois. Déplacez le travail planifié vers une tâche cron ou protégez-la avec un verrou. Voir Cron Jobs.
Pas de suppositions sur la stabilité du nombre d'instances. Tout ce qui partitionne le travail par index d'instance se casse au moment où le nombre change.
Si l'une de ces situations s'applique à votre application, corrigez-les avant d'activer la mise à l'échelle automatique. Une application qui n'est pas compatible avec le cluster échoue de manière intermittente et difficile à reproduire, car cela dépend de l'instance qui a servi quelle demande.
Dépannage
L'interrupteur ne peut pas être activé. L'activation nécessite la permission d'écriture du site. Avec un rôle en lecture seule, les contrôles sont désactivés.
L'application a redémarré quand j'ai activé la mise à l'échelle automatique. Attendu. Basculer en mode cluster nécessite un redémarrage, et cela se produit une fois.
Les utilisateurs sont déconnectés au hasard. Symptôme classique non compatible avec le cluster. Les sessions sont en mémoire et les demandes atterrissent sur des instances différentes.
Les instances augmentent d'échelle et ne redescendent jamais. Soit la charge est restée au-dessus du seuil de réduction d'échelle, soit quelque chose maintient le CPU élevé indépendamment du trafic. Vérifiez la liste des événements et regardez ce que l'application fait réellement.
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 se met à l'échelle. Confirmez que l'interrupteur est activé, que l'application s'exécute et que le mode cluster est activé. Ensuite, vérifiez si le CPU a réellement franchi votre seuil de montée en échelle dans la liste des événements.
Le coût est plus élevé que prévu. Consultez la liste des événements pour le flapping, puis diminuez le nombre maximal d'instances.
Pages connexes
- Site Performance and APM pour voir si le CPU est véritablement le goulot d'étranglement.
- Site Uptime Monitoring pour confirmer que la mise à l'échelle améliore réellement la disponibilité.
- Cron Jobs pour le travail planifié qui doit s'exécuter exactement une fois.
- Resizing a Cloud Server si vous avez besoin d'une plus grande machine plutôt que de plus d'instances.