Rails-Autoscaling nach CPU und Antwortzeit, nicht nach Bauchgefühl

Die meisten Autoscaling-Ratschläge setzen voraus, dass du schon eine Metrik-Pipeline, ein Dashboard und eine Meinung dazu hast, was “hohe Last” für deine konkrete App bedeutet. Die meisten kleinen Rails-Apps haben davon nichts, weshalb Autoscaling meist komplett übersprungen wird – zugunsten eines größeren Servers als nötig, immer, um auf der sicheren Seite zu sein.

Die einfachere Variante: Setze ein Minimum und ein Maximum, und lass die beiden Werte, die tatsächlich mit einem kämpfenden Rails-Prozess korrelieren – CPU und p95-Antwortzeit – entscheiden, was dazwischen passiert.

Wie die Entscheidung tatsächlich fällt

App → Settings → General → Autoscaling nimmt eine minimale und eine maximale Replica-Anzahl entgegen. Railyard fügt zwischen diesen beiden Grenzen Web-Replicas hinzu oder entfernt sie, basierend auf:

• Ziel-CPU pro Replica (%) – die durchschnittliche CPU, bei der eine Replica verbleiben darf, bevor eine weitere hinzukommt.
• p95-Antwortzeit – das Ziel für die Antwortzeit beim 95. Perzentil; ein Rails-Prozess, der Requests hinter einer langsamen Query oder einem blockierten Thread aufstaut, zeigt sich hier, bevor er sich als Ausfall zeigt.

Lass Max leer, und nichts Reaktives passiert – die App läuft einfach mit einer festen Replica-Anzahl, was für alles, das keine wirklich variable Last sieht, der richtige Standard ist.

Eine echte Einschränkung, die man vorher kennen sollte: Replicas teilen sich den eigenen Server der App, deshalb hilft das speziell bei CPU-gebundener oder langsamer Request-Last, nicht bei einem Server, dem echte Kapazität fehlt – und es skaliert nie hoch, während der Speicher des Servers bereits hoch ist, weil das Hinzufügen einer Replica zu einer speicherhungrigen Maschine die Dinge verschlimmert, nicht verbessert.

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

Vorwärmen für einen Spike, den du tatsächlich vorhersehen kannst

Reaktives Skalieren reagiert gut auf Last; es reagiert schlecht auf Last, die in den nächsten sechzig Sekunden erst passieren wird, denn wenn die CPU hoch genug ist, um ein Hochskalieren auszulösen, hat der Spike schon angefangen, die Antwortzeiten zu beeinträchtigen. Geplante Fenster lösen genau den Fall, in dem du bereits weißt, wann der Spike kommt – ein Produktlaunch zu einer festen Zeit, ein tägliches Traffic-Muster, ein wöchentlicher Batch-Job, der immer zur gleichen Stunde läuft.

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

Tage, ein Start-Ende-Bereich und eine Mindest-Replica-Anzahl, in der eigenen Zeitzone der App. Das Fenster hebt nur die Untergrenze – die üblichen CPU/p95-Regeln entscheiden weiterhin über alles darüber, sodass ein größerer als erwarteter Spike innerhalb des Fensters trotzdem weiter skaliert. Es wärmt vor; es ersetzt reaktives Skalieren nicht.

Was das ersetzt

Die Alternative, die die meisten Teams heute tatsächlich fahren, ist eine feste, überdimensionierte Serveranzahl, die einmal gewählt und selten überprüft wird, weil der Aufbau eines echten Autoscaling-Signals von Grund auf ein eigenes Projekt ist. Zwei Werte, die bereits mit Rails-spezifischer Belastung korrelieren – CPU und p95 – reichen offenbar aus, um den Normalfall zu automatisieren, ohne vorher einen Metrik-Stack aufsetzen zu müssen.

Vollständige Referenz, einschließlich wie das mit automatischem Failover zusammenspielt: Autoscaling und Failover.