Sticky Sessions: Einen Nutzer immer an dieselbe Instanz leiten

Skalierung

Sticky Sessions

Einen Nutzer immer an dieselbe Instanz leiten

Die Idee und ihr Nutzen

Ein Kunde meldet im Schadenportal seiner Versicherung einen Schaden in mehreren Schritten: Er lädt Fotos hoch, ergänzt seine Kontaktdaten und schickt die Meldung erst am Ende endgültig ab. Das Schadenportal läuft auf zwei Servern, Server A und Server B, auf beiden dasselbe Programm. Weil das Schadenportal ursprünglich für einen einzigen Server gebaut wurde, hält es die noch nicht abgeschickten Eingaben nur im Arbeitsspeicher des Servers, bei dem der Kunde begonnen hat. Jede Anfrage eines Kunden geht zuerst an einen Lastverteiler, ein Programm, das die Anfragen auf die Server verteilt. Hat der Kunde bei Server A begonnen, schickt der Lastverteiler alle weiteren Anfragen dieses Kunden an Server A. Die Eingaben müssen so weder zwischen den Servern kopiert noch in einem gemeinsamen Speicher abgelegt werden. Dieses Verfahren heißt Sticky Sessions, auf Deutsch etwa klebende Sitzungen. Die noch nicht abgeschickten Eingaben eines Kunden, also Fotos, Kontaktdaten und wie weit er im Formular gekommen ist, heißen seine Sitzung. Der Name meint: Die Sitzung eines Kunden bleibt an Server A, bei dem der Kunde begonnen hat.

Bausteine: Kunde: meldet einen Schaden in mehreren Schritten; Lastverteiler: merkt sich, welcher Server zum Kunden gehört; Server A: hält noch nicht abgeschickte Eingaben im Arbeitsspeicher; Server B: kennt die Eingaben nicht. Verbindungen: Kunde — Lastverteiler; Lastverteiler — Server A (alle Anfragen dieses Kunden). Keine Verbindung zwischen Lastverteiler und Server B. Der Lastverteiler schickt alle Anfragen des Kunden an Server A, weil nur Server A die Eingaben des Kunden kennt.

Wie funktioniert es?

Der Kunde lädt auf der ersten Seite der Schadenmeldung drei Fotos hoch. Der Lastverteiler wählt für diese erste Anfrage Server A und gibt dem Browser des Kunden ein Cookie mit einer Kennung für Server A mit. Ein Cookie ist ein kleiner Eintrag, den der Browser speichert und bei jeder Anfrage an das Schadenportal mitschickt. Server A hält die Fotos in seinem Arbeitsspeicher. Die Meldung ist noch nicht endgültig abgeschickt. Danach wechselt der Kunde zur Seite mit seinen Kontaktdaten. Der Lastverteiler liest das Cookie, das der Browser mitschickt, und leitet die Anfrage wieder an Server A, wo die Fotos liegen. Zehn Minuten später wird Server A wegen einer Aktualisierung neu gestartet, und die noch nicht abgeschickten Eingaben gehen verloren. Die nächste Anfrage des Kunden enthält weiterhin das Cookie für Server A, kann aber nicht mehr an Server A gehen. Der Lastverteiler schickt die Anfrage an Server B. Server B hat weder die Fotos noch die Kontaktdaten, und der Kunde muss neu beginnen.

Server A hält die Sitzung des Kunden in seinem Arbeitsspeicher, genau wie zu der Zeit, als das Schadenportal nur auf einem Server lief. Am Programm des Schadenportals ändert sich durch Sticky Sessions nichts. Der Lastverteiler ordnet jeden Kunden bei dessen erster Anfrage einem Server zu und hält sich bei allen weiteren Anfragen an diese Zuordnung. Dafür muss der Lastverteiler den Kunden bei jeder Anfrage wiedererkennen, und das geschieht meist über das Cookie. Formulardaten kopiert der Lastverteiler nicht. Er sorgt nur dafür, dass der Kunde immer wieder denselben Server und damit denselben Arbeitsspeicher erreicht. Angaben, die der Kunde nur in seinen Browser getippt und noch nicht an den Server geschickt hat, liegen noch im Browser und nicht im Arbeitsspeicher von Server A.

Fällt Server A aus, statt neu zu starten, verliert der Kunde seine Eingaben auf dieselbe Weise. Läuft das Cookie ab, wählt der Lastverteiler den Server neu, auch wenn Server A noch läuft.

Beteiligte: Kunde: meldet einen Schaden mit Fotos; Lastverteiler: merkt sich die Zuordnung per Cookie; Server A: hält noch nicht abgeschickte Eingaben im Arbeitsspeicher; Server B: kennt die Eingaben nicht. Ablauf: 1. Der Kunde lädt drei Fotos hoch. 2. Der Lastverteiler wählt Server A. 3. Der Browser des Kunden erhält vom Lastverteiler ein Cookie mit einer Kennung für Server A. 4. Server A hält die Fotos in seinem Arbeitsspeicher. Die Meldung ist noch nicht endgültig abgeschickt. 5. Der Kunde wechselt zu seinen Kontaktdaten. 6. Der Lastverteiler liest das Cookie und schickt die Anfrage wieder an Server A, wo die Fotos liegen. 7. Server A wird wegen einer Aktualisierung neu gestartet. Die noch nicht abgeschickten Eingaben gehen verloren. 8. Der Kunde macht im Formular weiter. Seine nächste Anfrage enthält das Cookie für Server A, kann aber nicht mehr an Server A gehen. 9. Der Lastverteiler schickt die Anfrage an Server B. 10. Server B hat weder die Fotos noch die Kontaktdaten, denn diese Eingaben lagen nur bei Server A. Sticky Sessions ersetzen keine dauerhafte Speicherung.

Wann ist es sinnvoll und wann nicht?

Sticky Sessions lohnen sich

Eine bestehende Anwendung hält Sitzungen im Arbeitsspeicher und soll auf mehrere Server verteilt werden, ohne dass die Anwendung umgebaut wird. Ohne Sticky Sessions könnte der Lastverteiler den nächsten Seitenaufruf an Server B schicken, und Server B fände die Sitzung nicht. Der Kunde müsste die Fotos erneut hochladen oder sich sogar neu anmelden, obwohl Server A weiterläuft und die Fotos noch hat.
Gelegentlich verlorene Eingaben sind vertretbar. Das ist zum Beispiel der Fall, wenn eine Meldung nur aus wenigen Angaben besteht. Ohne Sticky Sessions müsste das Team, das das Schadenportal entwickelt, das Schadenportal auf einen gemeinsamen Speicher für die Eingaben umbauen. Mit Sticky Sessions entfällt dieser Umbau. Startet Server A neu, gibt ein Kunde die wenigen Angaben noch einmal ein.
Ein Server hält für einen Kunden Daten im Arbeitsspeicher, die sich jederzeit neu laden lassen, zum Beispiel die Vertragsdaten des Kunden aus der Datenbank. Ohne Sticky Sessions geht die nächste Anfrage womöglich an Server B, und Server B lädt dieselben Vertragsdaten noch einmal aus der Datenbank. Die feste Zuordnung erspart das wiederholte Laden. Ein Neustart des Servers bedeutet dann nur, dass die Daten neu geladen werden, und es gehen keine Eingaben verloren.

Sticky Sessions sind nicht das Richtige

Eine Anwendung wird neu gebaut oder ohnehin überarbeitet. Sticky Sessions ersparen nur den Umbau einer Anwendung, die Eingaben im Arbeitsspeicher hält. Bei einer neuen Anwendung fällt dieser Umbau gar nicht an, und bei einer Überarbeitung ist er wenig zusätzliche Arbeit. Dann baut das Team, das das Schadenportal entwickelt, das Schadenportal als Stateless Services, also als zustandslose Dienste: Das Schadenportal legt die Eingaben in einem gemeinsamen Speicher ab, den Server A und Server B lesen. Ein solcher Speicher kann eine Datenbank sein. Dann kann der Lastverteiler jede Anfrage an jeden Server schicken, und bei einem Neustart geht keine Eingabe verloren.
Eingaben dürfen nicht verloren gehen. Ein Beispiel ist eine lange Schadenmeldung mit vielen Fotos, die Kunden nicht noch einmal von vorn ausfüllen sollen. Mit Sticky Sessions allein gehen diese Eingaben bei jedem Neustart von Server A verloren. Dann richtet das Team, das das Schadenportal betreibt, Session Replication ein: Server A kopiert jede Änderung an einer Sitzung auf Server B. Fällt Server A aus oder startet neu, kennt Server B die Eingaben, und das Programm des Schadenportals muss dafür nicht umgebaut werden. Dafür schickt Server A bei jeder Änderung einer Sitzung Daten an Server B.
Die Server werden häufig neu gestartet. Ein Beispiel sind mehrere Aktualisierungen am Tag. Mit Sticky Sessions löscht jeder Neustart die Eingaben aller Kunden auf dem neu gestarteten Server. Dann baut das Team, das das Schadenportal entwickelt, auch eine bestehende Anwendung auf einen gemeinsamen Speicher für die Eingaben um. Ein Neustart löscht danach keine Eingaben mehr.
Server werden je nach Last automatisch hinzugefügt und entfernt. Mit Sticky Sessions verlieren die Kunden eines entfernten Servers ihre Eingaben, und ein neuer Server erhält zunächst nur neue Kunden. Auch dann baut das Team, das das Schadenportal entwickelt, auf einen gemeinsamen Speicher für die Eingaben um. Ein neuer Server kann danach sofort Anfragen bestehender Kunden bearbeiten, und beim Entfernen eines Servers geht keine Eingabe verloren.

Nachteile und typische Fehler

Jeder Neustart eines Servers löscht alle Sitzungen auf diesem Server. Das Team, das das Schadenportal betreibt, muss Aktualisierungen deshalb in ruhige Zeiten legen oder mit dem Neustart eines Servers warten, bis die Sitzungen auf diesem Server abgelaufen sind. Der Lastverteiler muss Cookies lesen und setzen können, und das Team muss die Gültigkeitsdauer der Cookies auf die Dauer einer Sitzung abstimmen.

Typische Fehler und woran man sie erkennt:

Verlorene Eingaben beim Neustart: Server A wird für eine Aktualisierung neu gestartet. Der Lastverteiler schickt die nächsten Anfragen aller Kunden, deren Meldungen bei Server A lagen, an Server B. Server B kennt ihre Eingaben nicht, und diese Kunden müssen neu beginnen. Erkennbar ist das an abgebrochenen Meldungen und Beschwerden unmittelbar nach jeder Aktualisierung.
Ungleich verteilte Last: Der Lastverteiler ordnet jeden Kunden bei der ersten Anfrage einem Server zu und schickt danach alle Anfragen dieses Kunden an diesen Server. Landen bei Server A zufällig mehrere Kunden, die Dutzende Fotos hochladen, muss Server A alle ihre Anfragen bearbeiten, während Server B wenig zu tun hat. Erkennbar ist das an stark unterschiedlicher Auslastung der beiden Server.
Neuer Server ohne Arbeit: Ein neu hinzugefügter Server bekommt zunächst nur neue Kunden, weil die bestehenden Kunden ihren bisherigen Servern zugeordnet bleiben. Erkennbar ist das daran, dass zusätzliche Server die Überlastung der alten Server erst verringern, wenn die Sitzungen der bestehenden Kunden abgelaufen sind.
Cookie läuft zu früh ab: Die Gültigkeitsdauer des Cookies ist kürzer als eine typische Schadenmeldung. Mitten in der Meldung schickt der Browser das abgelaufene Cookie nicht mehr mit. Der Lastverteiler wählt den Server deshalb neu und schickt die nächste Anfrage zum Beispiel an Server B, der die Fotos nicht hat. Erkennbar ist das an verlorenen Fotos, obwohl kein Server neu gestartet wurde.
Cookie wird nicht mitgeschickt: Der Browser des Kunden lässt keine Cookies zu. Der Lastverteiler erkennt den Kunden deshalb nicht wieder und wählt für jede Anfrage einen beliebigen Server. Landet die Seite mit den Kontaktdaten bei Server B, fehlen dort die Fotos, die bei Server A liegen. Erkennbar ist das an Kunden, die immer wieder auf der ersten Seite der Meldung landen.

Weiterführend

Quellen

AWS: Sticky sessions for your Application Load Balancer: beschreibt, wie ein Lastverteiler einen Nutzer über ein Cookie an einen Server bindet, warum das die Last ungleich verteilen kann und dass bei einem ausgefallenen Server ein neuer Server gewählt wird.
nginx: Module ngx_http_upstream_module: Projektdokumentation zur Anweisung sticky, mit der nginx einen Browser per Cookie an einen Server bindet, und zu ip_hash, das Anfragen nach der IP-Adresse zuordnet, von der sie kommen.