3-2-1 Knall! Zusammenfassung des ersten Software Architecture Pressure Cooker Meetings

Letzten Donnerstag fand das erste Software Architecture Pressure Cooker Meetup statt. Das Ziel dieser Treffen ist der Erfahrungsaustausch über Softwarearchitektur. Dies geschieht durch die Arbeit an einem realen Fall in folgendem Format:

1. Ein spezifisches herausforderndes Szenario wird in allgemeiner Form vorgestellt
2. Ein Unternehmen wird eingeladen, einen realen Fall zu präsentieren, der dem vorgestellten Szenario entspricht. Sie fungieren während des Abends als Product Owner.
3. In ein paar Runden macht die Gruppe ein Brainstorming, teilt sich in Untergruppen auf und arbeitet an Lösungen.
4. Alle Lösungen werden dem Produktverantwortlichen präsentiert
5. Es kommt zu hitzigen Diskussionen zwischen den verschiedenen Untergruppen, in denen jede Gruppe versucht, die anderen Gruppen zu überzeugen.

Das Szenario für dieses erste Treffen war "3-2-1 Bang!". Merkmale dieses Szenarios sind:

• Es gibt einen Zeitpunkt, an dem Sie wissen, dass Ihre Website eine enorme Belastung erfahren wird.
• Der genaue Zeitpunkt, wann dies geschehen wird, ist bekannt.
• Der Umfang der Ladung ist unbekannt.

Beispiele für dieses Szenario sind der Online-Ticketverkauf für die Olympischen Spiele oder Madonna, der am Datum X um 09:00 Uhr beginnt. Oder eine große Marketingkampagne, die an einem bestimmten Datum und zu einer bestimmten Uhrzeit beginnt. Bei diesem Treffen hatten wir Le Champion als Organisation, die den Fall präsentierte. Le Champion organisiert beliebte Sportereignisse. Bei einigen dieser Veranstaltungen konkurrieren viele Teilnehmer um eine begrenzte Anzahl von verfügbaren Plätzen. Die Anmeldung für diese Veranstaltungen beginnt zu einem bestimmten Datum und einer bestimmten Uhrzeit. Zu diesem Zeitpunkt ist das Anmeldesystem mit einer enormen Lastspitze konfrontiert. Benutzer, die versuchen, sich anzumelden, erleben langsame Antwortzeiten, sind sich nicht sicher, ob ihre Anmeldung und Zahlung erfolgreich war oder nicht, usw. Zusammengefasst: eine schöne Übereinstimmung mit dem "3-2-1 Bang!"-Szenario. Nach einer ersten Brainstorming-Runde und einigen Diskussionen wurden drei Kategorien von Verbesserungen identifiziert:

1. Verbesserungen am bestehenden Anwendungscode (Caching, clientseitige Validierungen, etc.)
2. Verbesserungen bei der Bereitstellung von Teilen der Funktionalität und Infrastruktur (Hosting von Hintergrundprozessen auf separaten Rechnern, horizontale Skalierung der Anwendung usw.)
3. Schützen Sie die bestehende Anwendung vor Lastspitzen

Obwohl die Kategorien 1 und 2 eine gewisse Verbesserung bieten, gibt es immer eine Grenze für das, was die Anwendung selbst oder der Zahlungsanbieter bewältigen kann. Selbst wenn Sie die Anwendung selbst komplett neu aufbauen würden, müssen Sie immer noch Kategorie 3 durchführen. Daher haben wir beschlossen, uns auf #3 zu konzentrieren. In Untergruppen wurden Alternativen für Kategorie 3 ausgearbeitet. Die Überlegung hinter Kategorie 3 ist, dass die Anwendungslogik selbst vor Belastungen geschützt werden sollte, die sie nicht bewältigen kann. Es sollte also etwas vorangestellt werden, das nur einer kontrollierten Anzahl von Benutzern den Zugriff auf den Anmeldeprozess ermöglicht und eine Überlastung verhindert. Eine Anforderung von Le Champion war, dass die Tickets nach dem Prinzip "Wer zuerst kommt, mahlt zuerst" vergeben werden und es daher nicht akzeptabel war, Besuchern einfach mit der Meldung "Es ist besetzt, kommen Sie später wieder" zu antworten. Jeder, der versucht, sich anzumelden, sollte in eine Schlange gestellt werden und in der Reihenfolge der Position in der Schlange in den Anmeldeprozess eintreten, bis die Plätze ausverkauft sind. Beachten Sie, dass ich bewusst das Wort 'Schlange' anstelle von 'Warteschlange' verwende, da letzteres auf eine technische Umsetzung hindeutet. Ein weiterer Grund, Kategorie 3 anzustreben, war, dass die Realisierung dieser Lösung billiger ist als die Neuentwicklung der Anmeldeanwendung, die eine enorme Anzahl gleichzeitiger Anmeldungen bewältigen kann. In Anbetracht der Tatsache, dass (a) nur eine begrenzte Anzahl von Plätzen zur Verfügung steht und (b) die Nachfrage nach Plätzen deutlich höher ist als die Anzahl der Plätze, besteht keine Notwendigkeit, eine enorme Anzahl gleichzeitiger Anmeldungen zu verarbeiten. Die begrenzte Anzahl an verfügbaren Plätzen macht es unmöglich, "mehr Plätze zu verkaufen", wenn die Anwendung eine enorme Anzahl gleichzeitiger Anmeldungen bewältigen könnte. Es reicht aus, wenn die Anwendung in der Lage ist, die Spitzenlast kontrolliert zu bewältigen, so dass der Benutzer eine genaue Rückmeldung über seine Position in der Warteschlange erhält. [caption id="attachment_9242" align="alignright" width="300"] Vorstellung einer der Lösungen[/caption] Alle vorgestellten Lösungen hatten gemeinsam, dass der bestehenden Anwendung eine Komponente vorangestellt wurde, deren Aufgabe es war, die Schlange der Personen, die sich für die Veranstaltung anmelden wollten, zu verwalten und nur eine kontrollierte Anzahl von Personen mit dem eigentlichen Anmeldeprozess beginnen zu lassen. Der Rest wurde in der Warteschlange gehalten, bis ein Platz in der bestehenden Anwendung frei wurde und sie dann in den Anmeldeprozess einsteigen konnten. Variationen zwischen den Lösungen waren:

• Die Implementierung der Verwaltung der Warteschlange war unterschiedlich. Eine Lösung bestand darin, eine JMS-Warteschlange zu verwenden, eine andere schlug eine einfache Warteschlange im Speicher vor (die von verschiedenen Rechnern gemeinsam genutzt wird, wobei ein Open-Source- oder kommerzielles Produkt verwendet wird). Und eine dritte Lösung bestand darin, keine Warteschlange im Speicher zu erstellen, sondern die Lösung einfach auf Zählern zu basieren.
• Einige nutzten clientseitige Abfragen (alle X Sekunden), um zu prüfen, ob ein Kunde den Anmeldeprozess betreten konnte (und die Position in der Zeile zu aktualisieren), andere nutzten Comet, um Aktualisierungen an den Browser des Benutzers zu senden.
• Ein Team schlug vor, die Firewall-Regeln zur Laufzeit zu aktualisieren und mit Hilfe der Firewall-Regeln sicherzustellen, dass nur die richtigen Personen auf den Anmeldeprozess zugreifen können (obwohl dies zu Problemen führen könnte, wenn sich mehrere Personen hinter demselben Proxy-Server befinden).

Eine der Schlussfolgerungen war, dass es sich hierbei nicht um ein einzigartiges Problem handelt und dass es wahrscheinlich bereits eine Open-Source-Komponente gibt, mit der sich eine solche Lösung leicht realisieren lässt. Ein Beispiel, das wir gefunden haben, ist Haproxy. Allerdings scheint es nur auf der Ebene der HTTP-Anfrage zu funktionieren und kann sich nicht auf der Ebene der Clients/Benutzer in eine Warteschlange einreihen (out of the box). Wenn jemand andere Open-Source-Komponenten kennt, mit denen man eine Warteschlange von Personen verwalten kann, die sich nach dem Prinzip "Wer zuerst kommt, mahlt zuerst" anmelden wollen, hinterlassen Sie bitte einen Kommentar zu diesem Blogbeitrag und nennen Sie die Komponente. Es war ein interessanter Abend mit vielen guten Diskussionen. Wir werden Anfang September ein weiteres Meetup mit einem neuen Thema und einem realen Fall organisieren. Behalten Sie die Website des Software Architecture Pressure Cooker Meetups im Auge, um Details zu erfahren.