Praktische Umsetzung von Zustandslosigkeit und Zustandsbewusstsein

Zustand verschwindet nie, er bewegt sich nur

Zustandsbewusstes Komponente: enthält Informationen, deren Verlust das Verhalten ändern würde. Eine Datenbank, die Benutzerkonten enthält. Ein Cache, der Sitzungstoken enthält. Ein Arbeiter, der eine langlaufende Streaming-Verbindung zu einem bestimmten Benutzer festhält.

Zustandslose Komponente: enthält keine Informationen, deren Verlust relevant wäre. Eine Web-Schicht, die eine Anfrage liest, eine Datenbank abfragt und eine Antwort schreibt. Jede Anfrage steht alleine; die Schicht erinnert an nichts zwischen den Anfragen.

Schlüsselerkenntnis: Zustand verschwindet nie aus einem System. Er wandert in eine Schicht, die ihn speichern soll (eine Datenbank, ein Redis-Cluster, ein Objektspeicher). Die Schichten, die Verkehr auf sich ziehen, können dann stateless sein, und stateless-Schichten skalieren horizontal, weil jedes Replica jede Anfrage beantworten kann.

Praktischer Test: Wenn Sie eine zufällig einen Prozess in dieser Schicht töteten und neu starten würden, würde irgendein Benutzer eine falsche Antwort oder eine verlorene Sitzung erleben? Wenn ja, enthält sie Zustand. Wenn nein, enthält sie keinen Zustand.

Beispiele

- Ein Python-Web-Prozess, der Anfragen liest, Postgres abfragt und JSON zurückgibt: zustandslos. Der Zustand befindet sich in Postgres.

- Ein Python-Web-Prozess, der lokale Speicher für Benutzerwarenkörbe verwendet: zustandsbewusst. Der Verlust des Prozesses führt zu verlorenen Warenkörben.

- Ein WebSocket-Server, der offene Verbindungen zu Chat-Benutzern hält: zustandsbewusst im Sinne der Verbindung. Der Verlust des Prozesses führt zu abgerissenen Verbindungen; die Client müssen sich erneut verbinden. In der Regel skalieren diese auch horizontal, wenn vorsichtig (stabile Sitzungen, konsistente Hashing).

- Eine Redis-Cache-Abdeckung für Postgres: zustandsbasiert für die Cache-Inhalte, aber akzeptabel, wenn Cache-Miss vertragen sind. Ein Replica-Fehler bedeutet Cache-Miss, nicht Datenverlust.

Entwerfen für horizontales Skalieren = Zustände aus der Schicht drängen, die skalieren muss.

Auditieren eines verdächtigen Tiers

Ein Team betreibt eine Empfehlungs-API auf 6 hinter einem umgekehrten Proxy befindlichen Backend-VMs. Die Anwendung: liest einen Benutzer-ID aus der Anfrage ab, holt die jüngste Aktivität des Benutzers aus Postgres, führt einen Skoring-Algorithmus aus und gibt eine Liste mit empfohlenen Artikeln aus.

- Die Anwendung hält einen 'jüngsten Benutzeraktivitäts'-Cache in der Prozessspeichermemorie, der bei der ersten Anfrage für einen Benutzer initialisiert wird und bei nachfolgenden Anfragen wiederverwendet wird.

- Die Anwendung verwendet stickige Sitzungen: Sobald ein Benutzer auf VM #3 trifft, gehen alle nachfolgenden Anfragen an VM #3 (der Proxy ist für stickiges Routing auf der Grundlage eines Cookies konfiguriert).

Die Replica-Formel

Die einfachste Kapazitätsformel

Sobald ein Tier stateless wird, wird die Größenbestimmung zu einer Rechnung. Sie benötigen genügend Kopien, damit die stetige Last ein- und ausgeht, mit Puffer für Spitzenlast.

Die Formel:

Repliken = ⌈ (Spitzenlast × Spitzenlastfaktor) / pro_Replika_Kapazität ⌉ + Puffer

Wobei:

- Spitzenlast: maximale, dauerhaft erwartete Anfragen pro Sekunde

- Spitzenlastfaktor: Multiplikator für kurze Spitzen über der Spitzenlast (üblich 1,5x bis 2x für vorhersehbaren Verkehr, 3x oder mehr für viralen / unvorhersehbaren)

- pro_Replika_Kapazität: Anfragen pro Sekunde, die eine Kopie bei akzeptabler Latenz und Auslastung (üblicherweise bei 70% CPU gemessen, nicht bei Sättigung) verarbeiten kann

- Puffer: zusätzliche Kopien, damit ein paar Replica-Fehler den Tier nicht zusammenbrechen lassen (üblich 1-2 Kopien für kleine Flotten, 10-20% für größere)

Beispielaufgabe: Eine Backend-Komponente verarbeitet 100 Anfragen pro Sekunde (req/s) mit 70% CPU pro Replika. Die Spitzenbelastung beträgt 600 req/s. Gelegentlich erwarten Sie 2-fach Spitzenwerte. Sie möchten, dass das System 2 Replika-Fehlersituationen überlebt.

Repliken = ⌈ (600 × 2) / 100 ⌉ + 2 = 12 + 2 = 14 Repliken

Das 80%-Regel

Die pro-replikatische Kapazität ist nicht der Sättigungspunkt. Messen Sie die Kapazität bei 70-80% CPU, nie bei 100%.

Über etwa 80% Auslastung steigen die Warteschlangenkurven stark an: Eine Warteschlange, die bei 60% Auslastung in 10 ms abgeschlossen wurde, benötigt 80 ms bei 90% Auslastung. Die Latenz, nicht die Durchsatzleistung, bricht zuerst. (Die begleitende Lektion geometry_of_stateless_horizontal_scaling zeigt diese Kurve mathematisch nach.)

Autoscaling vs. Statistische Bereitstellung

Statistisch: Bereitstellen für Spitzenwert × Puffer für Spitzenwerte & akzeptieren Sie den Kosten für die Ausführung bei niedriger Auslastung außerhalb der Spitzenzeiten.

Autoscaling: Ein Steuerungselement fügt & entfernt Repliken basierend auf beobachteter Auslastung, Ziellatenz oder Warteschlangentiefe hinzu.

Autoscaling-Hinweis: Die Startzeit bei kaltem Booten ist wichtig. Wenn eine neue Replika 2 Minuten zum Start braucht, kann das Autoscaling nicht auf eine 30-sekündige Spitzenlast reagieren. Reifes Autoscaling hält eine warme Pool von vorab bereitgestellten Repliken, der nur leicht unter dem Skalierungsanstiegsniveau liegt.

Größe einer Flotte für ein neues Service

Ihr Team plant, ein Video-Metadaten-API zu starten. Die Benchmarkergebnisse zeigen, dass eine einzelne Replika 250 req/s bei 70% CPU und 50 ms p99 Latenz verarbeiten kann. Der Marketing-Plan sieht eine Spitzenlast von 4.000 req/s während der Hauptverkaufszeit vor. Ein geplantes Werbeereignis könnte kurzzeitig auf 3-fache Spitzenwerte ansteigen lassen. Sie möchten, dass das Service unter 3 gleichzeitigen Replika-Fehlern ohne Überschreiten der 80%-Auslastung auf den Überlebenden zurechtkommt.

Kalte Startzeit, langsames Entleeren und andere echte Kanten

Real Flotten haben echte Kanten

Die Formel unterstellt, dass Repliken sofort erscheinen, Verkehr sofort akzeptieren und Verkehr sofort abgeben. All das ist in der Produktion nicht der Fall.

Kaltes Starten: Eine neue Kopie muss den Betriebssystem-Start, den Prozessstart, die Konfigurationsbeladung, die Erwärmung der Zwischenspeicher und die Durchführung von Gesundheitsprüfungen durchführen. Dazu benötigt man zwischen 5 Sekunden (Neustart eines Containers) und 5 Minuten (Vollzugriff-VM-Start + Bildabruf). Die Autovergrößerung kann auf Kurzschluss mit einer Verzögerung von mehr als dieser Zeitspanne nicht reagieren.

Langsame Entlastung: Eine Kopie, die aus dem Pool entfernt wird, benötigt Zeit, um laufende Anforderungen abzuschließen, bevor sie beendet wird. Ansonsten sehen die Benutzer gekürzte Antworten. Reverse Proxies unterstützen die Entlastung (Neue Anforderungen werden nicht mehr angenommen, aber aktive werden abgeschlossen), aber es dauert Sekunden bis Minuten.

Erwärmter Pool: Produktionsflotten halten einen Pool von vorab bereitgestellten, aber inaktiv gebliebenen Kopien bereit, die im Bedarfsfall den Verkehr aufnehmen können. Dabei wird ein kleiner ständiger Kosten ausgetauscht gegen eine schnelle Reaktion auf Stoßzeiten.

Entlastung beim Herunterfahren gegen sofortiges Töten: Ein sanftes Herunterfahren ist wichtig. Ein SIGTERM, das die Entlastung auslöst, dauert länger als SIGKILL, aber es wird den Benutzeranforderungen nicht schaden.

Gesundheitsprüfungsfenster: Eine gerade gestartete Kopie kann ihre erste Gesundheitsprüfung erst durchführen, bevor ihre Datenbankverbindungs-Pool warm ist; der Proxy sendet dann echten Verkehr und die ersten zwölf Anforderungen sind langsam. Die Gesundheitsprüfungen sollten so eingestellt werden, dass sie den tatsächlichen Pfad testen, nicht nur die Lebendigkeit des Prozesses.

Zuneigungskrampf: Selbst nominell stateless Schichten erwerben über die Zeit Zuneigung (CDN-Caches, DNS-Resolver-Caches, Verbindungs-Pool). Man sollte misstrauisch sein, wenn 'identische Kopien' dennoch unterschiedlich reagieren.

Warm Pool oder reaktive Autovergrößerung?

Ihr Video-Metadaten-API (das gleiche wie in der vorherigen Frage, mit einer Größe von 51 Kopien für die normale Spitze und den Stoß) erfährt einen 30-Sekunden-Stoß auf 5-fache normale Belastung, sobald ein neuer viraler Video hochgeladen wird. Die Autovergrößerung benötigt derzeit 90 Sekunden, um eine neue Kopie von Grund auf (Bildabruf + Warmup) zu erstellen. Während der 90-Sekunden-Pause steigt die Latenz stark an und einige Anforderungen laufen aus.

Entwerfen Sie einen stateless Schicht unter Einschränkungen

Synthese

Sie haben gelernt, warum die horizontale Skalierung über einen kleinen Schwellenwert hinaus gewinnt, was Zustand im praktischen Sinn bedeutet, wie man eine Flotte unter erwarteter und Überlastung abschätzt, und wo sich die horizontale Skalierung an den Rändern bricht.

Wenden Sie alle vier an.

Entwerfen Sie einen Back-End-Tier für feed.example.com, eine Social-Feed-API. Einschränkungen: pro-Replikakapazität 200 Anfragen/s bei 70% CPU; erwartete Spitzenlast 1500 Anfragen/s; Überlastungsfaktor 2,5x (gelegentliche Trends-Storys); Überleben bei 2 gleichzeitigen Replikafehlern; Startzeit bei kaltem System 60 Sekunden; Spreizungen können 45 Sekunden andauern; Budget ermöglicht einige Leerlaufkapazität, aber keine 2,5-fache dauerhafte Bereitstellung.

Wo sich dieser Kurs in Zukunft bewegt

Wo sich dieser Kurs in Zukunft bewegt

Sie haben jetzt ein funktionierendes mentales Modell eines stateless-Tiers: Warum es skalieren kann, wie man es dimensioniert, was bei seinen Rändern bricht und wo sich der Zustand verschieben muss, wenn man ihn aus dem Layer drängt, der wachsen muss.

Die nächste Lektion in diesem Kurs (cs_distsys_ingress_egress_separation) behandelt ein subtiler Problem: Selbst ein perfekt dimensioniertes stateless-Tier kann in überraschender Weise scheitern, wenn eingehende und ausgehende Verkehr den gleichen Netzwerkpfad teilen. Das klassische Beispiel beinhaltet einen Proxy, der versucht, sich selbst zu verbinden; Die Lösung beinhaltet die Trennung eines Tiers in zwei mit unterschiedlichen Verantwortlichkeiten.

Kommilitone-Lektion: geometry_of_stateless_horizontal_scaling entwickelt die Warteschlangenkurve, Little's Gesetz angewendet auf eine Replikaflotte und die geometrische Bedeutung des 80%-Auslastungsknie.

Gut gemacht. Weiter so.