Mise à l'échelle automatique de Rails sur CPU et temps de réponse, pas au hasard

La plupart des conseils sur la mise à l’échelle automatique supposent que vous avez déjà un pipeline de métriques, un tableau de bord, et une opinion sur ce que « charge élevée » veut dire pour votre application spécifique. La plupart des petites applications Rails n’ont rien de tout ça, ce qui explique généralement pourquoi la mise à l’échelle automatique est complètement sautée au profit d’un serveur plus gros que nécessaire, tout le temps, par précaution.

La version plus simple : définissez un minimum et un maximum, et laissez les deux chiffres qui corrèlent vraiment avec un processus Rails en difficulté — le CPU et le temps de réponse p95 — décider ce qui se passe entre les deux.

Comment ça décide vraiment

App → Settings → General → Autoscaling prend un nombre minimum et maximum de réplicas. Railyard ajoute ou retire des réplicas web entre ces deux bornes selon :

• Target CPU per replica (%) — le CPU moyen qu’un réplica peut atteindre avant qu’un autre ne soit ajouté.
• Temps de réponse p95 — la cible de temps de réponse au 95e percentile; un processus Rails qui met des requêtes en file derrière une requête lente ou un thread bloqué apparaît ici avant d’apparaître comme une panne.

Laissez Max vide et rien de réactif ne se passe — l’application tourne juste avec un nombre fixe de réplicas, ce qui est le bon réglage par défaut pour tout ce qui ne voit pas vraiment de charge variable.

Une contrainte réelle à connaître d’entrée de jeu : les réplicas partagent le serveur de l’application, donc ça aide avec une charge limitée par le CPU ou des requêtes lentes spécifiquement, pas un serveur qui manque vraiment de capacité — et ça n’ajoute jamais de réplicas tant que la mémoire du serveur est déjà élevée, puisqu’ajouter un réplica à une machine à court de mémoire empire les choses, pas l’inverse.

PATCH /api/applications/:id/autoscale
{ "min": 1, "max": 4, "cpu": 70, "p95_ms": 400 }

Préchauffer pour un pic que vous pouvez vraiment prévoir

La mise à l’échelle réactive est bonne pour répondre à une charge; elle n’est pas bonne pour répondre à une charge qui va se produire dans les soixante prochaines secondes, parce que le temps que le CPU soit assez élevé pour déclencher une montée en charge, le pic a déjà commencé à nuire aux temps de réponse. Les fenêtres programmées règlent le cas précis où vous savez déjà quand le pic arrive — un lancement de produit à une heure fixe, un motif de trafic quotidien, une tâche par lot hebdomadaire qui tourne toujours à la même heure.

mon,tue,wed,thu,fri 08:00-18:00 3

Des jours, une plage début-fin, et un nombre minimum de réplicas, dans le fuseau horaire de l’application. La fenêtre ne relève que le plancher — les règles habituelles de CPU/p95 décident toujours de tout le reste au-dessus de ce minimum, donc un pic plus gros que prévu à l’intérieur de la fenêtre continue de monter en charge davantage. Ça préchauffe; ça ne remplace pas la mise à l’échelle réactive.

Ce que ça remplace

L’alternative que la plupart des équipes font tourner aujourd’hui est un nombre de serveurs fixe et surdimensionné, choisi une fois et rarement revisité, parce que construire un vrai signal de mise à l’échelle automatique depuis zéro est un projet en soi. Deux chiffres qui corrèlent déjà avec les difficultés spécifiques à Rails — le CPU et le p95 — s’avèrent suffisants pour automatiser le cas courant sans avoir besoin d’une pile de métriques installée d’abord.

Référence complète, y compris comment ça s’articule avec le basculement automatique : Mise à l’échelle automatique et basculement.