TwentyFeet: Tomcat-Cluster wird um Memcached erweitert

Der von //SEIBERT/MEDIA entwickelte Ego-Tracking-Dienst TwentyFeet gewinnt täglich viele neue Anwender und wächst stetig schneller. Das freut uns enorm – aber es ergeben sich zugleich neue Herausforderungen, denen wir begegnen müssen. Um stets gute Antwortzeiten liefern zu können, nutzen wir bereits einen Tomcat-Cluster mit mehreren Servern. Dieser soll nun mithilfe von Load Balancing und Memcached optimiert werden. In diesem Artikel erfahren Sie wie und warum.

Eine der größten Herausforderungen heutiger Webanwendungen besteht unumstritten in der Realisierung einer ausgeglichenen Lastverteilung (engl. Load Balancing). Jeder Nutzer, egal ob er gerade der einzige ist oder nur einer von extrem vielen, soll zeitnah Antworten vom Server erhalten.

Häufige oder lange Wartezeiten sind Usability-Probleme: Sie schmälern die Nutzungsfreude und führen unweigerlich zu Nutzungsabbrüchen.

Was bei Facebook der Super Bowl ist und bei Amazon das Weihnachtsgeschäft, gibt es auch bei TwentyFeet: Leistungsspitzen, die überdurchschnittlich viel Ressourcen beanspruchen, aber nach kurzer Zeit schon wieder vorbei sind.

Wie wappnet man sich für solche Momente? Massig Hardware kaufen, um dem größtmöglichen Druck standzuhalten? Eine ziemlich kostspielige Strategie, wertvolle Geräte die meiste Zeit unbenutzt rumstehen zu lassen, nur um in wenigen kurzen Zeiträumen Verfügbarkeit sicherzustellen.

Elastic Load Balancing mit Amazons EC2

Wie viele andere Unternehmen, haben auch wir uns schon vor geraumer Zeit für den Einsatz von Amazons Wolke entschieden. Die zahlreichen verschiedenen Dienste und vielfältigen Skalierungsmöglichkeiten waren Pluspunkte, von denen TwentyFeet unbedingt profitieren sollte.

Einer dieser Dienste, der für uns gewissermaßen unverzichtbar geworden ist, nennt sich Elastic Load Balancing und macht genau das, was man vermutet: Eintreffende Daten werden auf verfügbare EC2-Instanzen verteilt. Fällt eine aus, registriert der Dienst dies und verteilt den Verkehr auf die anderen noch laufenden Instanzen. So weit, so gut. Das Problem liegt nun aber im Detail.

Für TwentyFeet haben wir den Load Balancer von Amazon so konfiguriert, dass dieser Sticky Sessions verteilt, eine Variante, bei der ein Nutzer am Anfang einmalig einer laufenden EC2-Instanz zugewiesen wird und an dieser bis zum Ende, etwa durch das Löschen des Cookies, "kleben bleibt" (engl. to stick).

Diese Strategie hat jedoch zwei entscheidende Haken: Werden neue Instanzen – bei uns Tomcat-Server – hinzugefügt, können bestehende Nutzer diesen nicht zugewiesen werden, da sie an ihren alten Servern haften bleiben. Und fällt gar ein Server aus, so gehen die Session-Daten der dortigen Nutzer komplett verloren, da kein anderer Rechner von ihnen "wusste".

Die Frage, die sich nun stellt, lautet also: Wie schaffen wir es, dynamisch zu skalieren und Session Sharing zwischen den Tomcat-Servern zu realisieren?

Auto Scaling mit Round Robin

Wie bereits festgestellt, bietet Elastic Load Balancing in seiner einfachsten Form die Möglichkeit, eintreffenden Datenverkehr auf laufende Server zu verteilen. Richtig spannend wird es allerdings dann, wenn wir Auto Scaling ins Spiel bringen: Mit dieser Funktion von Amazons Wolke ist es möglich, Bedingungen zu definieren, bei deren Eintreten automatisch neue Instanzen gestartet oder laufende wieder gestoppt werden.

Der vermutlich typischste Fall ist der, Auto Scaling anzuweisen, neue Server zu starten, wenn die Antwortzeiten der laufenden Instanzen eine Obergrenze übersteigen bzw. zu stoppen, wenn eine Untergrenze unterschritten wird.

Damit diese dynamische Skalierung funktioniert, brauchen wir eine Alternative zu den "klebrigen" Sticky Sessions: Round Robin. Bei dieser Variante werden Nutzer reihum auf die jeweils laufenden EC2-Instanzen verteilt – und das nicht nur einmalig zu Beginn, sondern für jeden Request, den sie senden, erneut.

Dank diesen Änderung kann unser Tomcat-Cluster automatisch wachsen und schrumpfen, die Session-Daten würden dennoch pausenlos fehlen. Die Lösung lautet: Session Sharing mit Memcached. Aber der Reihe nach.

Session Sharing mit Memcached

Wir fassen zusammen: Mit Round Robin wurde die Basis geschaffen, um unseren Tomcat-Cluster dynamisch skalieren zu können. Mit Auto Scaling wurden die Bedingungen definiert, anhand derer die Skalierung automatisiert durchgeführt werden soll.

Was jetzt noch fehlt, ist eine Möglichkeit, Session-Daten zwischen den Tomcat-Servern zu teilen – Session Sharing eben. Zwar bietet Tomcat bereits von Haus aus eine Implementierung, mit der sich das Problem lösen ließe, diese läuft aber wiederum nicht in Amazons Cloud.

Eine Alternative ist schnell gefunden: Memcached, ein Cache-Server, der Daten zwecks schneller Zugriffszeiten im Arbeitsspeicher hält und verteilt auf mehreren Systemen laufen sowie von allen Tomcat-Servern erreicht werden kann.

Für TwentyFeet werden wir genau zwei Memcached-Server einsetzen, von denen einer für das Session Sharing zuständig ist und der zweite als reine Backup-Lösung dient, denn wenn wir auf eines verzichten können, dann auf einen Single Point of Failure, der unser ganzes Konstrukt in die Knie zwingen kann.

Nun fehlt nur noch ein einziges Glied in der Kette, um den aufgemotzten Cluster endlich in Betrieb nehmen zu können: Eine clientseitige Lösung, mit der Tomcat von den Memcached-Servern Gebrauch machen kann. Und diese Lösung nennt sich memcached-session-manager (MSM).

Der MSM ist ein vom Deutschen Martin Grotzke unter der Apache License 2.0 entwickeltes Programm, das in Tomcat installiert werden kann und nach einer kurzen Konfiguration sofort einsatzbereit ist. Anschließend kümmert sich MSM um die Kommunikation mit den Backend-Servern auf Basis von Memcached, liefert – wenn gewünscht – laufend Statistiken und versucht mit Ausfällen von Tomcat- bzw. Memcached-Servern fertig zu werden.

Lange Rede, kurzer Sinn: Der MSM versteht sich als Rundum-Sorglos-Lösung.

Fazit

Wer stets gute Antwortzeiten liefern und mit Leistungsspitzen auch ohne teure Serverfarm fertig werden will, kommt an Load Balancing nicht vorbei. Wer darüber hinaus jedoch keinen eigenen Load Balancer betreiben will, wird relativ schnell bei Amazons Elastic Computing Cloud landen.

Dank Auto Scaling und Elastic Load Balancing sind dynamisch skalierende Cluster schnell und unkompliziert eingerichtet. Doch Amazons Wolke hat auch ihre Grenzen: Manche Technologien - etwa das Session Sharing von Tomcat - werden schlicht und ergreifend nicht unterstützt.

Die Lösung: Zwei (oder mehr) separate Memcached-Server in der Wolke starten und Tomcat mit Martin Grotzkes memcached-session-manager ausstatten. Fertig ist Session Sharing in der EC2 von Amazon.

Weiterführende Informationen

Planen Sie ein Software-Projekt? Möchten Sie eine bestehende Anwendung relaunchen oder migrieren? Wollen Sie eine Web-Applikation im Hinblick auf Skalierbarkeit und Hochverfügbarkeit optimieren? Wir sind Experten für Web-Entwicklung seit 1996 und unterstützen Sie mit unseren agilen Scrum-Teams gerne.

Wir legen größten Wert auf Erweiterbarkeit, Performanz, Skalierbarkeit, Plattformunabhängigkeit und Testbarkeit und schaffen so individuelle High-End-Software-Lösungen, die sich auch im Nachhinein flexibel ausbauen und verändern lassen. Bitte sprechen Sie uns an. Ausführliche Informationen finden Sie auch in unserem öffentlichen Wiki: Einstieg in die Software-Entwicklung mit //SEIBERT/MEDIA.

TwentyFeet im Netz
Der TwentyFeet-Microblog


Mitwirkender an Konzeption und Umsetzung: Benjamin Borbe


Mehr über die Creative-Commons-Lizenz erfahren