Elastic Load Balancer und Session-Handling

Keine Web-Applikation kommt eigentlich ohne ein Session-Management aus. Um die einzelnen Requests einem User zu zuordnen übermittelt der Applikationsserver dem Anwender beim ersten Zugriff oder besser nach dem Login eine SessionID, die dann in Form eines Cookies oder einer URL-Variable bei jedem Request an den Applikationsserver übergeben wird. Der Applikationsserver hat dann i.d.R. entsprechende Session-Variablen in seinem RAM, die er aufgrund der übermittelten SessionID dem User zuordnen kann.

Wenn man aber nun für eine bessere Skalierung den Amazon AWS Elastic Load Balancer vor seine Applikation-Server setzen möchte, dann verteilt der Load Balancer die Requests zunächst unabhängig von der SessionID auf einen beliebigen Server, wo dann ggf. die entsprechende Session des Users bei dem zweiten Request gar nicht existiert.

Wie kann man dieses Problem lösen?

Wichtiger Hinweis vorweg:  Das Sticky Session Szenario funktioniert nur mit einem Cookie, aktuell unterstützt der AWS Elastic Load Balancer keine URL-basierten SessionIDs (wobei im Rahmen der nachfolgend beschriebenen Variante 1 Alternative 2 das kein Problem darstellt, da ja dann der entsprechende Cookie vom Load Balancer selbst gesetzt wird.)

Variante 1: Sticky Sessions

Im Sticky Session Szenario wird der User aufgrund der SessionID über den Load Balancer auf einen bestimmten Applikationsserver verteilt, dies merkt sich der Load Balancer, so dass er alle Folge-Requests des Users mit der bestimmten SessionID wieder genau auf den gleichen Applikationsserver verteilt. Der Amazon AWS Elastic Load Balancer bietet für die Konfiguration des Sticky Session Szenarios zwei Alternativen an:

Sticky Session Alternative 1 – Cookie wird durch das Session-Management des Applikationsservers erstellt

In der Regel generiert das Session-Management des  Applikationsservers den entsprechenden Cookie (bei PHP z.B. PHPSESSID  oder bei Java JSESSIONID). Die Lebensdauer dieses Cookies wird durch das Session-Management des Applikationsservers bestimmt. Den entsprechenden Cookie-Namen trägt man dann in der nachfolgenden Konfigurationsmaske des Elastic Load Balancers ein.

Der AWS Elastic Load Balancer erzeugt aber zusätzlich einen weiteren Cookie mit dem Namen AWSELB, dieser identifiziert aus Sicht des Load Balancers den User und sorgt damit für eine entsprechende Zuordnung zu einem Applikationsserver. Der eigentliche Cookie mit der SessionID des Applikationsservers wird vom AWS Load Balancer nur verwendet, um die Lebensdauer der Session zu definieren … aus diesem Grunde muss bei dieser Alternative der Browsers des Users  in der Lage sein, zwei Cookies senden und empfangen zu können, was aber in der Regel kein Problem darstellt.

Sticky Session Alternative 2 – Cookie wird durch den Load Balancer erstellt

Bei dieser Alternative verzichtet man darauf, dass die Lebensdauer der Session durch den entsprechenden Cookie des Applikationsservers definiert wird. Wie bei Alternative 1 erstellt der Load Balancer einen eigenen Cookie mit dem Namen AWSELB für die SessionID, der die Grundlage für die Verteilung darstellt. Die max. Lebensdauer der Session wird in der nachfolgenden Konfigurationsmaske definiert. Damit allerdings der Applikationsserver den User einer Session zuordnen kann, braucht man natürlich trotzdem den entsprechenden Cookie des Applikationsservers.

Vorteile des Sticky Session Szenarios: Über die beiden Sticky Session Alternativen kann man jede Webapplikation (sofern sie nicht nur auf URL SessionIDs basiert) sehr schnell Load Balancer tauglich machen, um die Last auf mehrere Server zu verteilen.

Nachteile des Sticky Session Szenarios: Bei einem AutoScaling werden nur neue User auf neue Server verteilt und bei einem Abschalten von Instanzen werden die Sessions der dortigen User zerstört und diese bekommen im besten Fall das Login-Fenster zu sehen …

.

Variante 2: Session Ablage auf einem Shared Storage

Gerade bei AutoScaling birgt das Sticky Session Szenario einige Risiken (siehe oben unter Nachteile). Aus diesem Grunde sollte man, sofern man AutoScaling verwenden möchte, die Applikation entsprechend umbauen. Zum einen kann man manche Applikationsserver zu einem Cluster zusammenfassen (aber Achtung … EC2 unterstützt kein Multicasting) so dass diese ihren Session Scope innerhalb des Clusters stets entsprechend replizieren oder man lagert den Inhalt der Session Variablen in eine Datenbank (SimpleDB für TomCat Sessions, DynamoDB) oder auf einen Shared Storage wie S3 aus … oder auf ElastiCache … oder oder …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.