Sicher durch die Wolke: Persistenz in der Cloud

Stop by Timeout

Wir suchen einen Weg, das Problem der „verschwundenen“ Sessions beim Downscaling zu umgehen. Wenn die Gesamtlast auf eine Webanwendung sinkt, wird die Verwaltung unserer Cloud-Anwendung einzelne Instanzen nach ihrer eigenen Strategie herunterfahren. Vermeiden kann man das zum Beispiel, indem die Cloud-Infrastruktur nur die Instanzen stoppen darf, auf denen alle Sessions im Timeout-Bereich, also abgelaufen sind. Diese können verworfen werden, denn der User würde beim nächsten Zugriff eine „Session abgelaufen!“-Meldung bekommen. Dies erfordert aber, dass für die Infrastruktur die Möglichkeit zur Prüfung besteht, die Anwendung ein entsprechendes Interface implementiert und diese Checkfunktion dann auch korrekt durch die Anwendung implementiert wird.

Generell hat dieser Ansatz aber den Nachteil, dass Knoten nicht gestoppt werden können, solange Sessions darauf aktiv sind. Im Extremfall kann die Anwendung dann gar nicht oder nur sehr schleppend herunterskalieren, denn dabei ist sie direkt vom Userverhalten abhängig.

Nachdem wir nun die Probleme des traditionellen Session Handlings in einer Cloud- Webanwendung kurz beschrieben haben, konzentrieren wir uns auf die Idee des Artikels: Sie besteht darin, die Session weder im Client noch im Server zu halten, sondern persistent zu machen. Das ist alles andere als neu, aber gerade in der Cloud können wir kostengünstig Persistenzdienste, wie Amazons SimpleDB oder Googles Bigtable nutzen. Diese sind immer verfügbar, unabhängig von der Anzahl der parallel laufenden Webserver.

Caching

Da diese Dienste verteilt und damit redundant angeboten werden, kann es gemäß des CAP-Theorems [2] vorkommen, dass sie nicht immer konsistente Daten liefern. Ein Caching-Mechanismus kann das Problem umgehen und zusätzlich die Permance steigern. Die Einträge des Caches bekommen einen Zeitstempel, um ihren Timeout-Zeitpunkt bestimmen zu können.

Lesen

Wenn ein Wert aus der Session gelesen werden soll, wird zunächst im Cache gesucht. Wird nichts gefunden oder der Cache Timeout ist abgelaufen, wird im Cloud-Dienst gesucht. Wird dort etwas gefunden, wird dieser Wert in den Cache eingetragen und an die Anwendung zurückgeliefert. Wird in beiden kein Wert geliefert, so wird „null“ zurückgegeben.

Schreiben

Soll ein Wert in die Session geschrieben werden, so wird er im Cache und im Cloud-Dienst vermerkt bzw. aktualisiert. Zusätzlich wird der Timestamp des Schreibens für den Eintrag vermerkt, um später bestimmen zu können, ob der Timeout-Zeitpunkt überschritten wurde.

Wir sehen, dass ein einfacher Persistenzdienst völlig ausreicht, um die Information der Session zu halten. Je simpler, desto besser um die Verwaltung der Session einer Anwendung nicht unnötig kompliziert zu machen. Wir schauen uns das konkret am Beispiel von Amazons SimpleDB (SDB) an. Amazon stellt ein einfaches API bereit, mit dem Key-Value-Paare in Domänen unterteilt, redundant in der Cloud gespeichert werden können. Eine Domäne korrespondiert zu einer Entität bzw. Tabelle einer relationalen Datenbank.

Objekte in Sessions

Amazon SDB persistiert nur Strings, die HTTP-Session des Servlet-API hingegen jedes beliebige Objekt:

Object o = session.getAttribute(name);

Hier kommt die freie xStream [3] Library zum Einsatz. xStream erlaubt es, mit wenig Code beliebig tief verschachtelte Objekte in XML zu transformieren und zurück. Diese XML-Strings können dann in der SDB persistent gehalten werden.

Das Projekt

Unter [4] kann das Eclipse-Projekt online getestet und zum Testen und Ausprobieren heruntergeladen werden. Es basiert auf Maven, d. h. in Eclipse muss ein Maven Plug-in [5] installiert sein. Als Container kommt jetty zum Einsatz, der mithilfe von Maven mittels des goals jetty:run gestartet werden kann. Somit kann das Demoprojekt vollständig innerhalb von Eclipse getestet werden. Die Libraries von Amazon sind in der pom.xml eingetragen und werden automatisch durch Maven nachgeladen. Mit dem Maven goal clean package wird das Projekt kompiliert und im sessiontest/target ein WAR-File erzeugt. Es kann also auch in Tomcat oder JBoss getestet werden. Das Projekt hat eine typische Maven-Web-Project-Struktur (Abb. 2).

Abb. 2: Maven-Struktur des Projekts
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.