Von Studierenden für Studierende: Grundlagentutorium – Unterstützung & Empowerment

Kim Bastiaanse, Tamara Hezel

Einleitung

Die Idee zu unserem Projekt entstand aus einem Gespräch mit einer Studentin des 3. Semesters. Aufgrund von Wissenslücken und Unsicherheiten hatte sie überlegt, ihr Studium abzubrechen. Wir fühlten uns direkt in unsere ersten Semester im Studiengang Mobile Medien zurückversetzt und überlegten, was uns damals geholfen hätte.

Daraus entstand unsere Idee, einen fächerübergreifenden Einstieg in die Informatik in Form eines Tutoriums anzubieten. Ziel dabei war nicht die Verbesserung oder Vertiefung einer bestimmten Vorlesung, sondern vielmehr die Verdeutlichung von Zusammenhängen zwischen den Themen sowie die Erklärung grundlegender Buzzwords. Die Vorlesungen sollten in einen größeren Kontext eingebettet, deren praktische Relevanz aufgezeigt und aufkommende Fragen der Studierenden geklärt werden.

Neben der rein fachlichen Kompetenz war es uns ein besonderes Anliegen, den Studierenden die Welt der Informatik auf eine ansprechende und motivierende Art näherzubringen. Wir wollten die vielfältigen Möglichkeiten und Facetten dieses spannenden Feldes aufzeigen und dabei helfen, eventuelle Ängste oder Vorbehalte abzubauen. Auch dem von Professor Walter Kriha beobachteten “Rückzugseffekt”, der durch negative Gefühle der Studierenden entsteht, wollten wir entgegenwirken.

Neben dem Tutorium boten wir den Teilnehmerinnen eine offene Sprechstunde an, in der auch nicht-fachliche Themen besprochen werden konnten.

Unser Angebot richtete sich an “Informatik-Anfänger” des 1., 2. und 3. Semester Mobile Medien (MM) und Medieninformatik (MI).

Problemstellung

Fragen zu stellen, sich freudig Neuem zu öffnen und auch mal ein Scheitern zu akzeptieren sind Eigenschaften, die nicht nur im Rahmen des Studiums wertvoll sind. Besonders in Bezug auf Softwareentwicklung und Informatik verlieren viele Studierende in den ersten Semestern schnell den Mut. Überforderung und Frustration, gepaart mit Ängsten, hindert eine bestimmte Gruppe daran, selbstbewusst in die Informatik einzusteigen. Die Unsicherheit wächst, Fragen bleiben ungestellt und die Hürde, vermeintlich einfache Dinge in der Vorlesung zu erfragen, steigt von Woche zu Woche. Besonders für Studienanfänger:innen ohne Vorwissen im Bereich der Informatik sind viele, vermeintlich einfache, Begriffe unbekannt und Zusammenhänge zwischen den Vorlesungsinhalten unklar.

Für genau diese Gruppe an Studierenden gibt es bisher kein passendes Angebot. Auch wenn vertiefende Tutorien und Übungen bereits einen wichtigen Beitrag leisten, gibt es aktuell keine Veranstaltung, die grundlegende Wissenslücken und Zusammenhänge abdeckt und Buzzwords themenübergreifend erklärt. Die Unterstützung von Studierenden diesbezüglich halten wir jedoch für sehr relevant und wegweisend für die akademische sowie berufliche Zukunft.

Unser Ziel war es daher, mit diesem Projekt einen sicheren Rahmen für Studierenden zu schaffen, in dem sie frei von Scham, Ängsten und Zurückhaltung handeln, ihre grundlegenden Wissenslücken schließen und damit zu Kommilitonen mit Vorwissen aufschließen können. Dabei ist es uns wichtig, den Studierenden zu zeigen, dass sie nicht alleine mit ihren Zweifeln und Unsicherheiten sind und ihr Selbstbewusstsein zu stärken.

Forschungsfrage und Hypothesen

Wie kann man Studierende motivieren, ihre Fragen offen und ehrlich zu stellen und ihre Unklarheiten anzusprechen? Wie kann man einen sicheren Rahmen schaffen und Inhalte so vermitteln, damit sie nachhaltig verstanden werden? Und welche spezifischen Themen müssen behandelt werden, um diese Wissenslücken zu schließen? Diese Fragen haben wir uns zu Beginn des Projekts gestellt und versucht mithilfe von theoretischer Recherche, qualitativen sowie quantitativen Methoden zu beantworten. Die Forschungsfrage: “Gibt es das Problem von einschränkenden, grundlegenden Wissenslücken bei Studierenden und wie könnte eine Unterstützung für betroffene Personen aussehen?”, spielte dabei jederzeit eine zentrale Rolle und deren Beantwortung floss direkt in die konkrete Umsetzung des Tutoriums ein. Um sich schrittweise den Antworten zu nähern, wurden verschiedene Hypothesen aufgestellt, die in zwei Phasen belegt oder widerlegt werden sollten. 

Es ergaben sich konkret folgende Hypothesen H1 – H4, die sich auf den aktuellen Wissensstand und die Situation der Studierenden im Studium beziehen. Sie werden im Umfang der ersten Studien überprüft. Dabei soll grundsätzlich herausgefunden werden, ob das Angebot eines Grundlagentutoriums von den Studierenden als notwendig und hilfreich empfunden wird, welche Thematiken in dessen Rahmen behandelt werden sollen als auch wie eine solche Umsetzung explizit aussehen könnte.

H1: Es wird erwartet, dass es grundlegende Wissenslücken bei Studierenden bzgl. den Grundlagen der Informatik gibt.

H2: Studierende, die ohne Vorwissen ins Studium gestartet sind, haben grundlegende Wissenslücken.

H3: Studierende fühlen sich durch ihre Wissenslücken abgehängt und haben negative Gefühle (z.B. Angst, Stress, Rückzug etc.).

H4: Es wird erwartet, dass ein zusätzliches Angebot von Studierenden, mit ähnlichen Erfahrungen, in Form eines Tutoriums als hilfreich eingestuft wird (und Personen teilnehmen würden).

Zur Validierung des Nutzens und der Reflektion des Grundlagentutoriums nach der Durchführung wurden die nachfolgenden Hypothesen H5 – H8 aufgestellt: 

H5: Studierende, die am Tutorium teilgenommen haben, fühlen sich sicherer mit den Buzzwords und den Zusammenhängen der Informatik.

H6: Studierende, die das Tutorium besucht haben, fühlen sich vom Kenntnisstand aufgeholt in Bezug zu den anderen Studierenden in ihrem Semester.

H7: Durch das Grundlagentutorium konnten grundlegende Wissenslücken für Studierende, die das Tutorium besucht haben, geschlossen werden.

H8: Es macht für die Studierenden einen Unterschied, ob solch ein Tutorium von Studierenden angeboten wird, die mit ihrer Lebensrealität näher an den Studienanfänger:innen sind oder von Dozenten mit viel Erfahrung.

Diese Hypothesen werden im zweiten Forschungsteil, nach der Durchführung durch eine Umfrage und persönliche Rückmeldungen der Studierenden validiert und dienen als Grundlage für Verbesserungen und für die Entscheidung zur Fortführung des Angebots.

Herausforderungen

Um einen möglichst hohen Lerneffekt bei den Studierenden zu erreichen, war es wichtig sich tiefgehende Gedanken zu folgenden Fragen zu machen:

–       Wie schafft man einen sicheren Raum?

–       Wie bekommt man die Studierenden dazu Fragen zu stellen?

In den nachfolgenden Teilen werden diese Fragen aufgegriffen und unsere Lösungsansätze dazu vorgestellt.

Vorgehen

Um zu erfahren, ob unsere Idee von den Studierenden als notwendig erachtet wird, haben wir eine quantitative Studie mit 96 Studierenden des 1. – 3. Semesters der Studiengänge MMB und MI durchgeführt. Parallel dazu befragten wir Personen aus derselben Personengruppe in Form von Fokusgruppen und Interviews, um qualitative Ergebnisse zu sammeln. Darüber hinaus haben wir durch Experteninterviews die Meinungen von Prof. Walter Kriha, Dr. Tobias Jordine und Benjamin Binder einbezogen.

Mit den ausgewerteten Studienergebnissen konnten die Thementage konzipiert und das Tutorium geplant werden. Die ausgewählten Themen wurden aufbereitet und Skripte, Checkerfragen und Präsentationen zu den Inhalten erstellt. 

Während der Durchführungsphase wurden Tutorien zu den verschiedenen Themen abgehalten. Insgesamt wurden 12 Plätze an Studierende aus dem 1. – 3. Semester vergeben. Die Konzeptions- und Durchführungsphase wurden dabei häufig parallel bearbeitet.

Die zweite Recherchephase beinhaltet erneute qualitative und quantitative Umfragen nach Abschluss des Tutoriums. Dabei wurden die teilnehmenden Studierenden zur Durchführung befragt und Verbesserungsvorschläge sowie Ideen gesammelt.

Theorie

Wenn man googelt, wie man Informatik lernt, ist die komplette erste Seite von Google voll damit, wie man programmieren lernt. Dabei steckt in der Informatik noch viel mehr:

Es geht darum, Probleme zu analysieren, Sachverhalte zu verstehen und effektive Lösungen zu finden. Die Informatik ist ein sehr breites und multidisziplinäres Feld, das sich mit vielen verschiedenen Aspekten der Technologie und des menschlichen Lebens befasst. Es ist wichtig, ein umfassendes Verständnis für die Konzepte und Grundprinzipien der Informatik zu entwickeln, um erfolgreich in diesem Bereich zu sein.

In der Literatur finden sich viele Ansätze zum Lernen von Informatik. So beschreibt Schwill die Brunerschen Prinzipien [1]. Das erste Prinzip, das genannt wird, ist die Fortsetzbarkeit. So sollte bereits bei der Auswahl des zu behandelnden Themas darauf geachtet werden, dass ein späterer Niveau-Ausbau möglich ist. Bei der Behandlung der Themen sollte zudem stets bedacht werden, dass keine Halbwahrheiten vermittelt werden, die ein Umdenken der Lernenden zu einem späteren Zeitpunktes benötigen [1]. Für unser Grundlagentutorium haben wir unsere Themen zwar selbst gewählt – diese sind jedoch eng mit den Vorlesungen, die angeboten werden, verknüpft. Dabei sind die Einzelthemen so konzipiert, dass auf die Fortsetzbarkeit geachtet wurde. Für unser Tutorium war es außerdem relevant, dass wir uns selbst so gut vorbereiten, dass wir keine Halbwahrheiten erzählen. Bei Unwissenheit sollte diese transparent gemacht und fehlendes Wissen zusammen mit den Studierenden nachrecherchiert werden.

Als zweites Prinzip führt er die Präfiguration von Begriffen auf. Damit ist gemeint, dass Bilder und Handlungen verwendet werden sollen, um Begriffe und Konzepte zu veranschaulichen und verständlich zu erklären. Anstatt die Syntax einer Programmiersprache oder ihrer Elemente direkt zu erklären, ist es besser, sie zunächst einfach praktisch anzuwenden – beispielsweise durch die Verwendung von Pseudocode [1]. Auch wir wollten viel mit Metaphern und Analogien arbeiten. Ein Beispiel dafür ist die Vorstellung des abstrakten Begriffes eines Servers als eine Art Raum: Es gibt Türen, die zum Frontend und zur Datenbank führen. Andere Türen dienen als Schnittstelle, um das Prinzip von APIs zu erklären. Für manche Türen ist eine Authentifizierung durch einen Token oder Passwort notwendig, um sie zu öffnen, Andere sind gar nicht “betretbar”.

Final kommt Schwill noch auf das Prinzip des vorwegnehmenden Lernens zu sprechen. Damit ist gemeint, dass es besser sei, ein Wissensgebiet schon auf früheren Stufen in einfacher Form zu behandeln, anstatt auf eine endgültige und abschließende Behandlung zu warten [1]. Da wir in unserem Tutorium Studierende des 1. bis 3. Semesters betreuen wollen, ist es unumgänglich, dass manche Studierende mit Teilen in Kontakt kommen, die sie noch nicht gehört haben oder noch nicht gänzlich verstehen. Dabei war es uns wichtig, die Studierenden auf einer hohen Flugebene abzuholen und ihnen die groben Konzepte zu verdeutlichen. Das komplette Verständnis kann dann nachfolgend in den vertiefenden Vorlesungen erfolgen. Dieser Ansatz hilft Ängste vor zu vielen Details, Starre vor Überforderung und die Flucht in das Konkrete vorzubeugen.

Da wir die Vermutung haben, dass die Studierenden, die unser Angebot besuchen, vor allem mit Ängsten und Selbstzweifeln zu kämpfen haben, haben wir uns auch mit Literatur zum Thema Leistungsdruck und Lernen beschäftigt. Schwarzbauer et al. [2] bestätigt, was wir auch schon selbst erlebt haben: Gelernt wird für den Erfolg in der Prüfung. Der eigene Fokus geht weg vom Interesse am Thema und die damit einhergehende intrinsische Motivation, sich mit diesem zu beschäftigen, und wandelt sich hin zu einer vorwiegend extrinsischen Motivation. Durch den Wunsch nach guten Noten verlieren betroffene Studierende häufig den Blick auf das große Ganze sowie dessen praktische Relevanz und vermeiden es Risiken einzugehen. Mögliche negative Gefühle, die durch die Verknüpfung mit Leistung entstanden sind, übertragen sich auf das Thema selbst. Es wird das fälschliche Gefühl geweckt, dass der Misserfolg im Rahmen des Studiums sich nur auf die eigenen Werte und Kenntnisse zurückführen lässt, was jeglichen neuen Mut und Selbstbewusstsein sowie Wachstum und Möglichkeiten in der Berufswelt vermeintlich versperrt.

Schwarzbauer führt zudem auf, dass der Lernerfolg stark unter Ängsten leidet. Gelerntes gerät schneller in Vergessenheit, die Angst verfestigt sich und wird immer wieder abgerufen. Diese Tatsache bestärkt das oben beschriebene Gefühl von Misserfolg und hält diese Studierende auf, sich an Neues zu wagen und selbstbewusst für sich und ihre Kenntnisse einzustehen. Die entstandene Verknüpfung von Leistungsdruck, Angst und Informatik ist schwer zu reflektieren und eigenständig aufzubrechen.

Leistungsabfragen müssen jedoch nicht immer negativ sein. Als positive Methoden werden in der Literatur beispielsweise kontinuierliches Feedback und Lerntipps aufgeführt [2]. Für uns war daher klar, dass unser Checkerfragen-Ansatz ein wichtiger Baustein für das Grundlagentutorium ist. Um den Studierenden kontinuierliches Feedback zu geben, gab es zu wenige Kontaktpunkte. Sie nach jeder Stunde allerdings noch einmal über Gehörtes reflektieren zu lassen und ihnen den Freiraum zu geben, noch einmal nachzuhaken, war für uns einfach realisierbar. Zusätzliche Lernangebote, wie Links zum Selbststudium, gute Quellen und Webseiten zur Verfügung zu stellen, war uns ebenso wichtig.

Ein weiterer Aspekt, den wir beleuchten möchten, ist die Wichtigkeit des Fragenstellens im Lernprozess. Im ersten Teil ihres Buch “Lernen durch Fragen” geht die Autorin Levin auf diese Thematik ein [3]. So können sich die Studierenden durch das aktive Nachdenken über den Lernstoff und den Prozess des Formulierens einer Frage tiefer mit dem Stoff auseinandersetzen. Dabei steht das Gespräch zwischen dem Lehrenden und der lernenden Person im Vordergrund. Die Aufgabe eines Lehrers besteht grundsätzlich darin, ein kindliches Interesse zu wecken. Dieses Interesse führt im Optimalfall dann automatisch zum Bedürfnis des Fragenstellens. Der Wunsch, mehr darüber erfahren zu wollen, führt zu aktivem Nachfragen, um eine gefühlte Erkenntnislücke zu schließen. Zudem führt Levin auf, dass Fragen Wissen bei der Person voraussetzt, die sie stellt. Demnach ist es nur möglich Fragen zu stellen, wenn bereits ein gewisser Kenntnisstand vorhanden ist. Für das Stellen von allgemeinen Fragen wird allgemeines Wissen benötigt. Wenn man spezifische Fragen stellen möchte, die auch die Antwortmöglichkeiten begrenzen, braucht man bereits ein tieferes Verständnis des Kontexts [3].

Ein ehrliches Interesse bei den Studierenden zu wecken, ist sicher nicht immer möglich. Die Wichtigkeit dessen, um Mitarbeit durch Fragen zu erreichen, sollte jedoch nicht unterschätzt und demnach nicht im Unterrichtsgeschehen vernachlässigt werden. Auch sind Missverständnisse bezüglich der Fragestellung und der damit unzufriedenstellenden Beantwortung auf die Tatsache des individuellen Kenntnisstandes zurückzuführen. So kann auch erklärt werden, warum die Wahrscheinlichkeit für Misskommunikation zwischen Personen mit sehr unterschiedlichen Kenntnisständen (z.B. Erstsemesterstudierende:r und Professor) häufig höher ist, als bei Personen mit ähnlichem Wissen. Tutorien von Studierenden für Studierende sind folglich ein wichtiger, zusätzlicher Baustein im Studium.

Frauen in der Informatik sind noch in der Unterzahl – das sagen nicht nur die Statistiken. Es reicht ein Blick in die Seminar- und Vorlesungsräume unserer Informatikstudiengänge an der HdM. Mit dem Ruf “Hochschule der Mädchen” ist der Anteil der “Informatik-Mädels” schon allgemein höher als an manchen anderen Universitäten – Frauen sind aber noch immer unterrepräsentiert. Aber an was könnte es liegen? Auch wenn diese Tatsache sicher sehr vielschichtige Gründe hat, bemerkt Schinzel et al [4], dass Männer sehr früh in ihrer Entwicklung in Kontakt mit Computern und Informatik kommen. Frauen hingegen haben diese Kontaktpunkte oft erst am Ende oder nach der Schulausbildung. Sie berichtet außerdem von Tutorien, die speziell für Frauen angeboten werden. Dabei war interessant, dass diese total unterschiedlich von den Frauen bewertet werden. Die allgemeine Beurteilung solcher Veranstaltungen (ohne Teilnahme) war eher negativ, da die Frauen eine Abwertung ihrer Fähigkeiten fürchten. Die Frauen, die allerdings teilgenommen hatten, haben es als Zugewinn erfahren [4]. In der von Schinzel et al angeführten Studie zeigen Studentinnen offenbar ein geringeres Selbstbewusstsein bei ihrem Studium, insbesondere in den Bereichen Programmierung, Computerwissen und Software, wie aus der Befragung hervorgeht. Im Vergleich zu den männlichen Studierenden empfinden mehr Studentinnen trotz guter Leistungen das Gefühl, fachlich den anderen Studierenden unterlegen zu sein [4].

Für uns war es wichtig, ein Tutorium für alle offen anzubieten und keine Einschränkung aufgrund des Geschlechts zu machen. Wir sind gespannt, wie sich die Verteilung von männlichen und weiblichen Teilnehmer:innen bei Fortführung des Projekts verhält.

Recherche

Studie 1: Quantitative Umfrage

Zu Beginn des Semesters führten wir eine quantitative Umfrage mit 94 Studierenden aus den ersten drei Semestern Mobile Medien und Medieninformatik durch. Davon gehören 34 Personen dem Studiengangs Mobile Medien (MM) an, 60 sind im Studiengang Medieninformatik (MI) eingeschrieben.

Eine Frage in unserer Umfrage zielte darauf ab, herauszufinden, ob die Studierenden sich von ihrem Wissensstand her gegenüber ihren Mitstudierenden hinterher, auf Augenhöhe oder überlegen fühlen. Etwas mehr als zwei Drittel der Studierenden von MM gaben an (Abb. 1), mit ihrem Wissensstand hinterher oder weit hinterher zu sein. Beim Studiengang MI waren es 41% (Abb. 2). Insgesamt gaben 48 der 94 Studierenden an, hinterher oder weit hinterher zu sein. Dadurch kann unsere erste Hypothese H1 bestätigt werden. Mögliche Gründe für die Unterschiede zwischen MM und MI können nicht sicher genannt werden. Denkbar ist jedoch die technischere Ausrichtung des MI-Studiengangs und damit die Einschreibung von Personen mit mehr technischen Vorwissen als bei MM.

Abb. 1: MMB + Wissensstand
Abb. 2: MI + Wissensstand

Des Weiteren wollten wir herausfinden, wie viele der Personen ohne Vorwissen in ihr Studium gestartet sind und sich zur Zeit der Befragung fühlen, als hätten sie grundlegende Wissenslücken. Die Ergebnisse sind in Abbildung 3 zu sehen. Dabei gab knapp ⅓ aller befragten Personen an grundlegende Wissenslücken zu haben. 46% der Teilnehmenden, die ohne Vorwissen ins Studium gestartet sind, fühlen sich, als hätten sie grundlegende Wissenslücken. Nur 12% der Personen ohne Vorwissen geben an, keine Wissenslücken zu haben. Die restlichen 42% geben an, teilweise Wissenslücken zu haben. Somit gilt die zweite Hypothese ebenfalls als validiert, womit eine Verbindung zwischen fehlendem Vorwissen und grundlegenden Wissenslücken im Rahmen der durchgeführten Studie hergestellt werden kann.

Abb. 3: Person hat kein Vorwissen + hat grundlegende Wissenslücken

Außerdem wurden negative Gefühle und Reaktionen bzw. Ängste ermittelt, die aufgrund von grundlegenden Wissenslücken bei den Studierenden ausgelöst wurden. 36,2 % der befragten Studierenden haben das Gefühl, dass ihre Schwachstellen sie zurückhalten. Weitere 33% haben Angst vor schlechten Noten oder den Abschluss nicht zu schaffen. 29,8% haben das Gefühl, nicht mehr “aufholen” und damit mithalten zu können, und 25,5% der befragten Studierenden konzentrieren sich nur auf ihre Stärken (Comfort-Zone). Knapp 11% überlegen sich sogar, den Studiengang zu wechseln oder das Studium abzubrechen. Insgesamt traf die Frage auf nur 26,6% der Befragten gar nicht zu. Hypothese H3 wurde damit ebenfalls bestätigt.

Abschließend galt es herauszufinden, ob ein Hilfsangebot, wie wir es planten, angenommen werden und Personen daran teilnehmen würden. Dabei gaben 36,2 % der befragten Personen an, sehr gerne an einem solchen zusätzlichen Angebot teilzunehmen. 46,8 % der befragten Personen würden an dem Angebot vielleicht (weiß nicht/kommt darauf an) teilnehmen. Damit konnte auch eine Verifizierung der dritten Hypothese H4 erfolgen.

Studie 2: Qualitative Studie – Fokusgruppe

Zusätzlich zur quantitativen Studie wollten wir durch eine qualitative Umfrage noch detailliertere Erkenntnisse erlangen, die sich auf die konkrete Ausgestaltung des Grundlagentutoriums beziehen. Dazu haben wir uns in Form einer zweistündigen Fokusgruppe und eines einstündigen Interviews mit betroffenen Studierenden intensiv ausgetauscht. Ziel war es herauszufinden, welche Erlebnisse und Gefühle sie im Studium erlebt hatten, welche Themen(bereiche) im Tutorium bearbeitet werden sollen sowie Einzelheiten und Wünsche zur konkreten Umsetzung des Angebots. Uns war es wichtig, das Tutorium an die Bedürfnisse und Wünsche dieser Gruppe anzupassen und sie aktiv mit einzubeziehen.

An der Fokusgruppe hatten zwei Studierende teilgenommen, an dem Interview eine weitere Studentin. Dazu besuchten wir Vorlesungen der ersten drei Semester und riefen betroffene Studierenden zum Austausch auf. Zur Dokumentation und Interaktion wurde ein Miro-Board erstellt und im Laufe der Fokusgruppe und des Interviews gefüllt. Das gesamte Board inklusive aller Ergebnisse ist in Abbildung 4 zu sehen.

Abb. 4: Gesamtes Miro-Board mit Ergebnissen aus den beiden Fokusgruppen-Umfragen

Im persönlichen Gespräch wurde deutlich, dass die Studierenden von sich sagen, dass sie grundlegende Wissenslücken haben. Die Studierenden, mit denen wir gesprochen haben, sind ohne Vorwissen in ihr Studium gestartet. Alle drei Teilnehmerinnen würden sehr gerne an unserem Angebot teilnehmen. Aufgrund des inhaltlichen Feedbacks wurden die Rahmenbedingungen für das Tutorium festgelegt. Durch die qualitative Studie könnten somit H1 – H4 erneut bestätigt werden. Abbildung 5 und 6 zeigen die Ergebnisse im Detail.

Abb. 5: Ergebnisse zum Ablauf im Detail
Abb. 6: Ergebnisse zu den Themen im Detail

Experteninterviews

Neben den oben beschriebenen Umfragen führten wir auch Experteninterviews mit Prof. Walter Kriha, Dr. Tobias Jordine und Benjamin Binder durch, um die Sicht und Erfahrungen von aktiv lehrenden Personen miteinzubeziehen.

Benjamin Binder betonte im Gespräch, dass es eine Gruppe von Studierenden gibt, die von den Lehrenden nicht erreicht werden können und für die es derzeit kein Auffangnetz gibt. Während seiner Vorlesungen ist ihm zudem aufgefallen, dass diese Studierenden selten Fragen stellen. Angesichts dieser Situation sieht er einen deutlichen Bedarf für ein entsprechendes studentisches Angebot.

Tobias Jordine betonte die Bedeutung einer Unterstützung auf Augenhöhe, bei der ein sicherer Raum geschaffen wird, in dem, neben dem thematischen Inhalt, auch Raum für weiterführende Gedanken vorhanden ist. Durch seine Anregungen fühlten wir uns bestärkt, soziale Aspekte und die Vermittlung des richtigen Mindsets in die Gestaltung der Tutorium Inhalte einzubeziehen. Zudem betonte er, dass die Leistung nicht allein anhand von Noten oder dem Endergebnis bewertet werden sollte. Besonders Studienanfänger:innen haben diesbezüglich festgefahrene Muster und Verhaltensweisen, die es ihnen schwer machen, im Studium die übergeordneten Ziele zu sehen und Risiken (z.B. als Anfänger die Programmierung in einem Projekt übernehmen) einzugehen. Sie verstecken sich hinter bekannten Aufgaben und verpassen es, an ungewohnten Aufgaben zu wachsen. Zudem hatte Tobias Jordine Ideen, um einen sicheren Raum zu schaffen: kleine Erfolge feiern und betonen, dass Fehler machen dazu gehört und ganz normal im Lernprozess sind.

Als jahrelanger Professor der Softwareentwicklung kennt Prof. Kriha, die Probleme der Studierenden gut. Ein von ihm häufig beobachtetes Phänomen ist das Festkrallen am Konkreten. Studierende verlieren den Überblick und verlieren sich, besonders am Anfang des Studiums, in Details. Dieser falsche Fokus führe, laut Prof. Kriha, zu Überforderung und Angst. Viel wichtiger sei es zu lernen, abstrahiert zu denken, das übergeordnete Ziel im Blick zu behalten und Zusammenhänge anstatt alle einzelnen Details eines Themas zu verstehen. So schaffe man es auch später, im Berufsalltag effiziente Lösungen zu finden und komplexe Probleme zu lösen.

Insgesamt waren alle befragten Experten von der Idee eines Grundlagentutoriums begeistert und sehen solch ein studentisches Angebot als sehr hilfreich und wertvoll an.

Haupterkenntnisse (Zwischenstand)

Unter Beachtung aller Erkenntnisse aus den verschiedenen Studien und Befragungen haben wir uns auf ein regelmäßiges Angebot während des Semesters festgelegt. In jedem Termin (ca. 1,5h) wird ein Oberthema aus dem Bereich der Informatik und des Studiums behandelt und vorlesungsübergreifend in den Kontext gesetzt. Zudem sollte es Expertentage geben, bei denen von uns ausgewählte Experten auf dem jeweiligen Gebiet einen tieferen Einblick geben und von ihrem Arbeitsalltag erzählen. Praktische Beispiele, Demos, Hands-On-Beispiele und Mindset-Gedanken werden passend eingestreut. Der Fokus liegt auf dem übergeordneten Zusammenhang und Verständnis und nicht auf einzelnen Details.

Die Tutorien finden in einer Gruppe von maximal 12 Personen vor Ort an der HdM statt. Ein hybrides Format sollte weitgehend vermieden werden, um einen persönlichen Raum schaffen zu können. Für das Tutorium wird ein separater Raum mit Bildschirm und Whiteboard von uns reserviert und für Tee und Snacks gesorgt. Am Ende jedes Termins helfen Checkerfragen das Gehörte zu wiederholen und zu dokumentieren. Weiterführende Links zum Eigenstudium werden zur Verfügung gestellt. Die Kommunikation mit den Kursteilnehmerinnen und der Dokumentenaustausch findet zentral über einen eigenen Moodle-Kurs statt. Die Studierenden aus Semester 1 bis 3 werden per E-Mail über das Grundlagentutorium informiert und eingeladen. Sprechstunden werden zusätzlich angeboten.

Konzeption

Nach Auswertung der Studienergebnisse und Festlegung der Themengebiete begann die Konzeption. Es wurden relevante Unterthemen für das Verständnis eines Hauptthemas (z. B. Webentwicklung) überlegt und dabei einzelne Programmiersprachen und ihre Syntax bewusst ausgespart. Das Grundlagentutorium sollte die Informatik aus einer abstrakten Sicht erklären und sich nicht nur auf die Programmierung beschränken. Für jeden Termin wurde eine Präsentation mit den Unterthemen und Checkerfragen erstellt und den Teilnehmern einige Tage vor dem Tutoriumstermin über Moodle zur Verfügung gestellt. Zusätzlich wurde pro Termin ein Forum in Moodle eingerichtet, in dem vorab Fragen gestellt werden konnten.

Wie erwähnt, planen wir vertiefende Ergänzungen einzelner Inhalte in Form von Expertentagen. Für das Thema “Betriebssysteme & Hardware” entschieden wir uns aufgrund des hohen Interesses am Thema. Benjamin Binder als Experte und Lehrender auf diesem Gebiet erkundete mit den Studierenden das Innenleben eines Computers. Ein weiteres Thema, für das wir einen Expertentag planten, war die App-Entwicklung. Hierfür fragten wir Benjamin Kramser, ehemaliger MM-Absolvent und Frontend Engineer bei der Steuerbot GmbH, der den Weg “vom Code bis in den App Store” aufzeigte und von seiner Arbeit als App-Entwickler berichtete.

Themengebiete

Folgende Themengebiete wurden für das Tutorium festgelegt. Die Vorstellung der einzelnen Themenblöcke inkl. Unterthemen wurde auf die verschiedenen Termine verteilt.

  1. Termin “Kennenlernen”: Kennenlernen als Gruppe, Erwartungen einholen, Organisatorisches klären, Themen und Termine vorstellen
  2. Termin “Softwareentwicklung in der Praxis”: Wie arbeitet ein:e Softwareentwickler:in? Erklärung von Git und Vorstellung nützlicher Tools
  3. Termin “Betriebssysteme & Hardware”: Expertentag mit Benjamin Binder rund um das Thema Betriebssysteme und Hardware (wie sieht ein PC von innen aus?)
  4. “Softwareentwicklung”: Vorstellung der verschiedenen Bereiche der Softwareentwicklung, die verwendeten Programmiersprachen, Debugging & Testing
  5. “Web Development”: Unterschied Front- und Backend sowie dessen Basiskonzepte (API, Kommunikation Client – Server, Datenbanken)
  6. “App Development”: Expertentag mit Benjamin Kramser (Steuerbot GmbH) mit dem Thema “vom Code bis in den App Store – aus dem Alltag eines App-Entwicklers”
  7. “Rechnernetze”: Grundlagen wie Topologien, Adressierung, Subnetting & Co.
  8. “Cloud + Security”: Was ist die Cloud und welche Vorteile bringt sie mit? Außerdem Sicherheitskonzepte, Angriffe und Hands-On Übungen 

Durchführung

Das erste von acht Tutorien startete Anfang Dezember, die weiteren Termine folgten in einem ein- bis zweiwöchigen Rhythmus. Es haben sich für das Tutorium ausschließlich weibliche Studierende aus allen drei Semestern gemeldet und schlussendlich daran teilgenommen. Das Tutorium war von Anfang an jedoch bewusst an alle Studierende gerichtet.

Erstes Kennenlernen

Zu Beginn des Tutoriums gab es ein kleines Kennenlernen mit Tee und Lebkuchen. Wir wollten die Erwartungen und Wünsche der einzelnen Studierenden verstehen sowie die erste Hürde als Gruppe nehmen, sodass sich alle zum ersten inhaltlichen Termin wohlfühlen konnten. Auch war es uns wichtig, uns der Gruppe vorzustellen und die Beweggründe und Motivation hinter dem zusätzlichen Angebot zu erklären. Dies war zudem eine Möglichkeit, eventuelle Missverständnisse über den Umfang oder Schwierigkeitsgrad des Tutoriums zu klären, sodass die Gruppe einen homogenen Kenntnisstand aufweist und niemand abgehängt wird oder sich langweilt.

Das Ritual von Tee und Snacks führten wir über alle Termine hinweg fort. Auch war es uns wichtig, keine klassische Sitzordnung zu wählen. Wir wollten uns bewusst vom Stil der Vorlesungen abheben und eine möglichst angenehme und lockere Atmosphäre schaffen. Dazu gehörte auch das Tragen von bequemer Kleidung, Small-Talk vor und nach dem Tutorium sowie das direkte Reinrufen von Fragen und Anmerkungen ohne Handzeichen. Auch machten wir allen zu Beginn des Tutoriums klar, dass wir selbst Vieles auch nicht wissen und das (gemeinsame) Herausfinden von Lösungen ein ganz normaler Vorgang im Informatik-Alltag ist. Uns war es jederzeit wichtig, direkt auf Augenhöhe zu kommunizieren und die Barriere zwischen uns als Tutoren und den Studierenden so klein wie möglich zu halten. 

Mindset

Für uns war es außerdem von hoher Relevanz, neben fachlichen Erklärungen auch festgefahrene Glaubenssätze aufzulösen und kleine Erfolge zu feiern, um das richtige Mindset zu fördern. Wir teilten unsere Erfahrungen und Erkenntnisse mit den Studierenden, zum Beispiel über die Anforderungen an Programmierer:innen und Designer:innen sowie den Arbeitsalltag in crossfunktionalen Teams. Dabei betonten wir, wie wichtig es ist, den abstrakten Blick zu wahren, mit Rückschlägen umzugehen und Freude an eigenständigem Lernen zu haben. Unser Ziel war es, den Teilnehmerinnen Perspektiven über das Studium heraus für die Arbeitswelt aufzuzeigen und Ängste und Druck zu reduzieren. Dies half auch eigenen Fähigkeiten realistischer einschätzen und neues Selbstbewusstsein schöpfen zu können.

Feedback & Wirkung 

Beobachtungen

Während des Tutoriums beteiligten sich die Studierenden sehr aktiv, jedoch gab es kaum Interaktion in Moodle. Weder das Angebot, Fragen im Forum zu stellen, noch die angebotene Sprechstunde wurden genutzt. Keine der Teilnehmerinnen kontaktierte uns außerhalb des Tutoriums. Da es während des Tutoriums einen regen Austausch gab, war ein weiterer Austausch wohl nicht notwendig.

Zudem haben wir auch noch eine weitere Beobachtung gemacht, die, wie sich im finalen Austausch mit Tobias Jordine, Benjamin Binder und Walter Kriha herausstellte, so noch nicht gemacht wurde. Wir haben die Teilnehmerinnen des Tutoriums als sehr fleißig und begeistert an den Themen im Studium wahrgenommen. Bei Gesprächen darüber, wie Prüfungen liefen oder Prüfungsergebnisse ausgefallen sind, klang alles sehr positiv und unproblematisch. Und dennoch sind es genau diese Personen, die am Grundlagentutorium teilgenommen haben. Eine unsichtbare ruhige Gruppe, die kaum Fragen stellt, nicht als klassische Problemfälle wahrgenommen wird und (sehr) gute Noten schreibt. Eine Gruppe, bei der niemand merkt, wie viel Unsicherheit in ihren Köpfen herrscht und dass über einen Studienabbruch nachgedacht wird. Das Ganze findet im Inneren dieser Personen statt und kann nicht anhand irgendwelcher äußeren Kriterien gemessen werden. Das ist sicher auch ein Grund dafür, weshalb diese Gruppe bisher bei Analysen über Studienabgänger:innen kaum bis gar nicht beachtet wurde.

Studie 3: Quantitative Umfrage

Um die oben aufgestellten Hypothesen H5 – H8 zu validieren, führten wir am Ende des Tutoriums eine weitere Umfrage durch. Dabei ergaben sich folgende Ergebnisse:

H5: Studierende, die am Tutorium teilgenommen haben, fühlen sich sicherer mit den Buzzwords und den Zusammenhängen der Informatik.

→ Diese Hypothese konnte bestätigt werden. Alle Umfrageteilnehmerinnen haben der Aussage klar zugestimmt.

H6: Studierende, die das Tutorium besucht haben, fühlen sich besser vorbereitet als / vom Kenntnisstand aufgeholt zu den anderen Studierenden im Semester als Studierende, die kein Tutorium besuchen.

→ Hypothese 6 konnte im Rahmen der dritten Studie ebenfalls bestärkt werden. 80% der Antworten sind bejahend zu werten.

H7: Durch das Grundlagentutorium konnten grundlegende Wissenslücken für Studierende, die das Tutorium besucht haben, geschlossen werden.

→ 100% der Teilnehmerinnen stimmten dieser Hypothese zu. 

H8: Es macht für die Studierenden einen Unterschied, ob solch ein Tutorium von Studierenden angeboten wird, die mit ihrer Lebensrealität näher an den Studienbeginnern sind oder von Dozenten mit viel Erfahrung.

→ Zu dieser Hypothese konnten wir neben dem quantitativen Ergebnis von 100%iger Zustimmung auch noch detailliertere Erkenntnisse gewinnen. Als Begründung warum solche ein Angebot von Studierenden angeboten werden sollte, wurde unter Anderem die Nähe zum Studium und dessen Inhalte genannt: Studentin 1: “Bei Dozenten habe ich oft das Gefühl, das sie nicht (mehr) wissen wie man sich als Anfänger fühlt und welche Probleme man zu Beginn hat. Bei euch ist das alles noch viel präsenter und ihr könnt das besser nachvollziehen. Außerdem ist der Altersunterschied ja nicht so groß, was für mich dafür sorgt, dass ich mich wohler fühle.” oder Studentin 2: “Da Dozenten die Schwierigkeiten, die man als kompletter Neuling in diesem Themengebiet hat, oft nicht verstehen/ nachvollziehen können. Fragen, die man stellt [werden] oft falsch verstanden (ist mir leider so oft passiert in den Vorlesungen). Ihr dagegen habt immer genau verstanden, was ich mit meinen Fragen meine und sie kurz und verständlich beantwortet.”. Es half den Teilnehmerinnen, dass wir ähnliche Schwierigkeiten in unserem Studium hatten und sie sich somit mit ihren Problemen nicht alleine fühlen. Konkrete Meinung von Studentin 3: “Für mich persönlich war das Tutorium wichtig, damit meine Angst vorm Versagen kleiner wird und zu realisieren, dass es viele Leute gibt, die Schwierigkeiten im Studium haben. Sowas kommt nunmal besser rüber, wenn man mit Gleichgesinnten da durch geht.” und abschließend Studentin 4: “Die Atmosphäre ist besser, um ohne Ängste Fragen zu stellen.”.

Feedback und persönliche Einblicke der Studierenden

Von einigen Studentinnen haben wir außerdem noch weiteres persönliches Feedback und Dank mündlich oder per Mail erhalten. Dazu gehören Rückmeldungen wie “Das Tutorium war für mich ein Ort, wo ich mich nie dumm gefühlt habe, weil ihr uns ein Gefühl von Sicherheit gegeben habt.” oder “die Atmosphäre war super, man konnte Fragen stellen; man hat sich nicht geschämt, wenn man was nicht wusste”. Eine Studentin fragte sogar, ob sie nochmal am Tutorium teilnehmen darf, falls es erneut angeboten wird. 

Sehr hilfreich und wertvoll waren auch Verbesserungsvorschläge und Ideen. So wurde mehrfach gewünscht, das Tutorium auf zwei Stunden zu verlängern, um mehr Zeit für die Themen und unsere persönlichen Tipps und Erfahrungen zu haben. Auch gab es die Idee für regelmäßiges Feedback nach jedem Tutorium in Form einer kurzen Emoji-Umfrage, um herauszufinden, ob man alles verstanden hat oder es noch ungeklärte Fragen gibt. Ein weiterer Wunsch war es, mehr Informationen über die Folien festzuhalten, sodass Inhalte auch später eigenständig nochmal nachgearbeitet werden können.

Abschließendes Expertengespräch

Direkt im Anschluss an das Feedback der anwesenden Studierenden haben wir uns noch einmal mit Tobias Jordine, Benjamin Binder und Walter Kriha zusammengesetzt, um unsere Erfahrungen und Wahrnehmungen auszutauschen sowie die Fortführung des Projekts zu besprechen. 

Unser Projekt ging nicht nur darum, einigen Studierenden dabei zu helfen, sich mutiger mit dem Themengebiet der Informatik auseinanderzusetzen, sondern auch darum, eine bisher unentdeckte Gruppe zu identifizieren. Diese Gruppe besteht aus stillen, fleißigen und guten Studierenden, die jedoch unsicher und ängstlich sind. Bei ihnen besteht die Gefahr, dass ein Studienabbruch unvorhergesehen geschieht und nicht nachvollziehbar ist, da äußere Signale fehlen und ihre innere Welt nicht sichtbar gemacht oder beobachtet werden kann. Im Gespräch wurde viel reflektiert und darüber nachgedacht, wie diesen Personen geholfen werden könnte.

Gemeinsam haben wir uns auch mit der Frage beschäftigt, wie man mit solchen “Snowflake”-Lösungen wie unser Tutorium umgehen soll, die im Hochschul- und Universitätskontext nicht universal umsetzbar sind. Dabei handelt es sich um Lösungen, die speziell auf die Bedürfnisse und Wünsche von Einzelpersonen zugeschnitten sind. Für uns ist es von großer Bedeutung, dass sich diese Studierenden, auch wenn es nur ein kleiner Teil der Gesamtgruppe ist, gehört und gesehen fühlen. Solch engagierte, hoch motivierte, neugierige und zuverlässige Studierende zu verlieren, empfinden wir als äußerst bedauerlich und vermeidbar, wenn man bedenkt, mit wie vergleichsweise wenig Aufwand die Gruppe unterstützt und bestärkt werden kann.

Wir haben auch darüber nachgedacht, wie man “Snowflake”-Lösungen auf eine größere Gruppe ausweiten kann. Leider konnten wir keine endgültigen allgemeinen Ergebnisse finden, aber es wurden einige Ansätze diskutiert, die ähnliche Effekte erzielen können. Dazu gehört zum Beispiel das konkrete Nachfragen, ob auch wirklich die gestellte Frage beantwortet wurde, das Einbinden von Checkerfragen und die gezielte Verkleinerung von Tutoriumsgruppen, wo dies möglich ist. Es wird versucht, diese Ansätze auszuprobieren, um zu sehen, ob sie für eine größere Gruppe von Studierenden geeignet sind.

Abschließend haben wir einstimmig beschlossen, das Tutorium im nächsten Semester erneut anzubieten. Wir haben auch diskutiert, dass nicht jeder das Tutorium leiten können sollte, sondern dass es besser wäre, Studierende auszuwählen, die ähnliche Erfahrungen gemacht haben, ein gewisses Einfühlungsvermögen haben und bereit sind, sich verletzlich zu zeigen. So können wir sicherstellen, dass die Teilnehmer:innen bestmöglich unterstützt werden und sich in einer vertrauensvollen Umgebung wohl fühlen.

Schlussbetrachtung

Insgesamt sind wir sehr zufrieden mit dem Projektverlauf und -ergebnis. Auch konnten wir selbst die einzelnen Themen vertiefen und haben ein erstes Gefühl bekommen, wie man schwierige Inhalte verständlich aufbereiten und erklären kann. Auch wenn sich die Teilnehmerzahl über die fortlaufenden Termine reduzierte, hatten wir bei jedem Tutorium viel Spaß und es war großartig zu sehen, wie Themen und Zusammenhänge verstanden wurden und zunehmend Fragen gestellt wurden. 

Die Erfüllung der Hypothesen stützt unser persönliches Gefühl und bestätigt die Notwendigkeit sowie den Erfolg des Grundlagentutoriums. Die grundlegenden Wissenslücken konnten geschlossen und negative Gefühle abgelegt werden. Die positiven Rückmeldungen und persönlichen Geschichten der Studierenden haben uns sehr gefreut. Neben den fachlichen AHA-Momenten macht es uns besonders zufrieden, dass auch Mindset-Änderungen bei den Studierenden stattfanden. Wir hoffen, dass sie zukünftig selbstbewusst neue Aufgaben annehmen können und ihre Leistung nicht nur an dem Endergebnis messen.

Der Wunsch, damals gerne selbst solch ein Angebot gehabt zu haben, um unseren Wissenslücken und Unsicherheiten im Studium zu begegnen, war ein großer Motivationsgrund für uns. Aus eigenen Erfahrungen wissen wir, wie wichtig solch eine Unterstützung für den weiteren akademischen und beruflichen Werdegang sein kann. Diese Gruppe an Studierenden aufzufangen und neuen Mut zu geben, kann sehr prägend und wegweisend sein, weshalb es uns eine Herzensangelegenheit ist, uns auch weiterhin dafür einzusetzen.

Reflektion 

Abschließend möchten wir noch einmal einen kritischen Blick auf das Projekt werfen und reflektieren, ob das Projekt seinen gewünschten Effekt erzielen konnte. 

Der Rückmeldung nach war das Tutorium ein sicherer Raum, um Fragen und Unklarheiten zu adressieren. Rückblickend war es sicher wichtig, uns von Anfang an sehr ehrlich und verletzlich zu zeigen und immer wieder zu betonen, dass auch wir Vieles selbst nicht wissen und uns auch fachlich auf die Tutorien vorbereiten mussten. Wissenslücken haben wir immer gemeinsam als Team erarbeitet. Wir wollten den Studentinnen zeigen, dass sie nicht alleine in ihrer Situation sind und Nichtwissen ganz normal ist. Auch wenn es im Studium oft nicht so wirkt und man von dem Wissen und der Erfahrung der Professor:innen und Kommilitonen schnell eingeschüchtert wird, es wird nie verlangt alles zu wissen oder zu können. In der sich schnell verändernden Welt der Informatik ist es viel wichtiger, eigeninitiativ, motiviert und neugierig zu bleiben und die groben Konzepte zu verstehen. Wir haben schnell gemerkt, dass dieser Gedanke durch den Studienalltag bisher zu kurz kam und den Studierenden der Bezug zur Praxis und damit die realitätsnahe Einordnung ihrer Fähigkeiten und Stärken gefehlt hat. Des Weiteren war es uns sehr wichtig wirklich alle offenen Fragen zu beantworten. Dazu haben wir auch gezielt nachgefragt, ob wir ihre Frage richtig verstanden haben und bewusst Zeit zum Nachdenken gelassen. Beides war rückblickend sehr wichtig und sollte so fortgeführt werden.

Allgemein hatten viele der Teilnehmerinnen ein geringes Selbstbewusstsein bezüglich ihrer Fähigkeiten und Wissen in der Informatik. Auch die Tatsache, dass ausschließlich weibliche Studierende am Tutorium teilgenommen haben, bestätigt die Erkenntnisse aus dem Theorieteil im Rahmen unseres Projektes. Umso wichtiger ist es uns daher, Frauen in der Informatik zu stärken und zu ermutigen. Ihre hohe Leistungs- und Lernbereitschaft sowie ihr Interesse sollten nicht durch Ängste und fehlendem Selbstbewusstsein überschattet werden und sie zurückhalten. Unsere Geschichte und die Tatsache, dass wir, als eine von ihnen, nun erfolgreich im Studium und Beruf stehen, hat ihnen eine neue Perspektive aufgezeigt. Weibliche Vorbilder weiterhin im Studiengang sichtbar zu machen, halten wir daher als essentiell wichtig.

Auf organisatorischer Ebene hatten wir zu Beginn des Tutoriums kleine Probleme mit den Moodle-Foren. Die von uns erstellten Foren zu jedem Termin/Thema werden von uns und den Teilnehmerinnen nicht automatisch abonniert. Diese Default-Einstellung war uns nicht bewusst. Es führte anfangs dazu, dass wir Nachrichten von Teilnehmerinnen übersehen hatten und zu unseren Nachrichten keine E-Mail Benachrichtigung versendet wurde. Diese Hürde wurde jedoch schnellstmöglich behoben und alle Foren auf “verbindliches Abonnieren” umgestellt. 

Grundsätzlich eignet sich Moodle als Plattform zur Kommunikation und Informationsaustausch gut für unsere Zwecke, da an der HdM jeder Studierende bereits damit gearbeitet hat. Wie oben erwähnt, nahm die Teilnehmerzahl im Verlauf des Tutoriums ab. Die Gründe waren dabei unterschiedlicher, zeitlicher Natur. Wir halten es für wichtig, das kommende Tutorium nicht mehr in der vorlesungsfreien Zeit abzuhalten und das Abmelden bei Nichterscheinen nochmals deutlicher zu kommunizieren und einzufordern. Es war schade, dass wir Studierenden aufgrund voller Teilnehmerzahl absagen mussten, ein paar wenige, angenommene Teilnehmer dann aber ab dem 2. Termin nicht mehr erschienen sind.

Ausblick: Weiterführung des Projekts

Grundsätzlich streben wir an, das Grundlagentutorium im kommenden Semester erneut anzubieten. Da man im folgenden Semester direkt zu Semesterbeginn mit der Durchführung starten kann, wird es zudem möglich sein, alle Tutorien innerhalb der Vorlesungszeit abzuhalten. Die Konzeption des jetzigen Semesters wird dabei größtenteils übernommen und mit dem Feedback der Studierende und unseren Learnings verbessert bzw. angepasst. Je nach Interesse der Studierenden wird auch der terminliche Rahmen und Teilnehmerzahl entsprechend neu geplant. Über eine Anwesenheitspflicht und eine ECTS-Vergütung für die Tutoren wird nachgedacht.

Leider wird Kim kommendes Semester auf Grund ihrer Masterarbeit nicht mitwirken können. Erfreulicherweise hat sich jedoch die Studentin bereit erklärt, Tamara zu unterstützen, durch die dieses Angebot inspiriert wurde. Wir sind begeistert, dass wir bei ihr so viel Selbstvertrauen und Mut geweckt haben und freuen uns, mit ihr das Grundlagentutorium weiter zu gestalten.

Abschließend möchten wir uns nochmal bei allen Teilnehmerinnen für ihre Offenheit, ihr Vertrauen und ihre Mitarbeit bedanken, die für uns das Projekt erst richtig wertvoll gemacht haben. Ihr seid alle wirklich klasse und wir sind uns sicher, dass ihr euer Studium und Berufsleben rocken werdet!

Quellen

[1] Schwill, Andreas; Fundamentale Ideen der Informatik, Fachbereich Informatik, Universität Oldenburg, http://informatikdidaktik.de/Forschung/Schriften/ZDM.pdf

[2] ‘Nur’ Geschmackssache? : Der Umgang mit kreativen Leistungen im Musik- und Kunstunterricht (2020),  Schwarzbauer,Michaela und Steinhauser, Katharina und Friedl, Juliane, LIT, Wien 

[3] Levin, A. (2005). Lernen durch Fragen. Wirkung von strukturierenden Hilfen auf das Generieren von Studierendenfragen als begleitende Lernstrategie. In D.H. Rost (Hrsg.): Reihe Pädagogische Psychologie und Entwicklungspsychologie, Band 48, Münster: Waxmann.

[4] Schinzel, B., Kleinn, K., Wegerle, A. et al. Das Studium der Informatik: Studiensituation von Studentinnen und Studenten Ziel ist die Stärkung des Selbstbewußtseins von Frauen in der Informatik. Informatik-Spektrum 22, 13–23 (1999). https://doi.org/10.1007/s002870050120

Wie Ticketmaster Taylor Swift verärgerte und was Software Developer daraus lernen können

Verkaufsstarts für große Ereignisse wie Konzerte oder Sportveranstaltungen sind immer mit Spannung erwartete Ereignisse. Doch wenn es bei diesen Verkaufsstarts zu Problemen kommt, kann dies für Veranstalter und Kunden gleichermaßen ärgerlich sein. Ein bekanntes Beispiel hierfür ist das Debakel von Ticketmaster bei dem Verkauf von Taylor Swift Tickets für ihre “Eras Tour” letzten November. Aufgrund technischer Probleme war es für Kunden nur schwer möglich Tickets zu kaufen, was zu Frustration und Enttäuschung führte.

Doch wie kam es dazu? Das ist nicht das erste Mal, dass ein System unter zu großer Last zusammenbricht. Black Friday ist hier ein bekanntes Beispiel. Selbst Ticketmaster ist das in der Vergangenheit schon mehrfach passiert. Doch Taylor Swift hat die Aufmerksamkeit darauf noch einmal erhöht und bevorstehende Großevents, wie die Beyoncé Tour, erhöhen die Relevanz weiter. In diesem Blogeintrag werden wir zunächst die Taylor Swift Situation untersuchen, um herauszufinden wie es aus technischer Sicht dazu kommen konnte. Anschließend schauen wir auf mögliche Maßnahmen, die helfen können, um in der Zukunft besser mit solch starken Anstiegen im Traffic umzugehen und Abstürze zu vermeiden.

Was passiert ist

Taylor Swift ist eine der beliebtesten Musikerinnen des letzten Jahrzehnts und ihre Fans haben ihre Rückkehr auf Tournee sehnlichst erwartet. Im Jahr 2022 veröffentlichte sie ein neues Album und kündigte die zugehörige „Eras Tour“ an. Ihre erste seit sechs Jahren. Entsprechend groß war der Andrang auf die Tickets. Der Kartenverkauf erwies sich jedoch für viele als chaotisch und frustrierend, da das System von Ticketmaster unter dem Gewicht einer noch nie dagewesenen Nachfrage überlastet war.

Wie Ticketmaster sich auf den Ansturm vorbereitete

Der Verkauf der Tickets startete am 15. November 2022. Zum Verkauf standen insgesamt 2,4 Millionen Tickets für 52 verschiedene Shows. Aufgrund dieser hohen Zahlen und der großen Bekanntheit von Taylor Swift war schon im Vorhinein klar, dass es einen großen Andrang auf die Tickets geben wird. Um diesen Andrang zu steuern und gleichzeitig Bots und Scalpers vom Kauf der Tickets fernzuhalten wurde das eigens entwickelte System Verified Fans eingesetzt. Ein Konto bei Verified Fan war Voraussetzung, um Tickets erwerben zu können, denn von dort bekam eine begrenzte Anzahl an Fans einen eindeutigen Code, mit dem sie Zugang zum Ticketkaufprozess erhielten. Insgesamt haben sich 3,5 Mio Fans bei Verified Fans angemeldet. Von diesen erhielten am Verkaufstag 1,5 Mio nach Zufallsprinzip einen direkten Zugangscode und die restlichen 2 Mio Fans wurden zu einer Warteschlange hinzugefügt. Auf diese Nachfrage war das System eingestellt.

Thundering Herd stürmt das Ticketmaster System

Zur Überraschung von Ticketmaster wurde die Website am Tag des Kartenverkaufs jedoch von weit mehr Besuchern überschwemmt als erwartet: 14 Millionen versuchten auf die Website zuzugreifen. Deutlich mehr als die geplanten 1,5 Millionen Fans. Der übermäßige Datenverkehr wurde unter anderem durch Bots und Scalpers verursacht, die eigentlich gar keinen Zugang zur Website hätten haben sollen sowie durch Fans, die keinen Code erhalten hatten, aber trotzdem versuchten auf die Website zuzugreifen.

Eben solch eine enorme Menge an Personen, die schlagartig, zur gleichen Zeit Anfragen stellen, wird auch als Thundering Herd bezeichnet. Vorstellen kann man sich das im Prinzip wie eine Horde wildgewordener Stiere, die auf das Ticketmaster System losgeht und es förmlich niederstampft. Das Thundering Herds Problem entsteht, wenn eine Menge an Clients oder Prozessen plötzlich und zur gleichen Zeit auf eine bestimmte Ressource zugreifen wollen. Auf diese schlagartig gestiegene Nachfrage ist die Ressource nicht vorbereitet und kann nicht alle gleichzeitig bearbeiten. Als Folge stürzt sie ab und steht nicht mehr zur Verfügung. Daraus kann als Resultat ein Cascading Failure entstehen, wenn die unbearbeiteten Requests sich auf andere Netzwerkknoten verteilt.

Cascading Failure führt zu Systemfehlern und Abstürzen

Ein Cascading Failure in der IT bezieht sich auf eine Situation, in der ein Fehler in einem Teil des Systems eine Kettenreaktion auslöst, die schließlich zu einem vollständigen Systemausfall führen kann. Auslöser kann der Ausfall eines einzelnen Knotens oder Teilsystems sein, wodurch die Last auf weniger Knoten des verbleibenden Systems verteilt wird. Dadurch steigt die Wahrscheinlichkeit weiterer Systemausfälle, was zu einem Schneeballeffekt führt. Cascading Failures sind äußerst kritisch, da sie einen gesamten Dienst innerhalb kurzer Zeit lahmlegen und menschliches Eingreifen erforderlich machen können.

Eben solch einen plötzlichen Ansturm wie eine Thundering Herd und somit Überlastung des Systems erlebte Ticketmaster. Das führte zu einem Cascading Failure und letztendlich zu Systemfehlern und Abstürzen der Seite. Ein wesentliches Problem war, dass es keine Begrenzung für die Anzahl der angenommenen Requests gab. User konnten immer wieder, während sie noch auf die Antwort zu ihrer ersten Anfrage warteten, ungeduldig weitere Requests schicken, ohne dass diese abgelehnt wurden. Gleichzeitig ließ das Bots freie Hand, sodass unter anderem DDoS Attacken ausgeführt werden konnten. Insgesamt summierte sich die Anzahl an Requests so auf rund 3,5 Milliarden! Das Überstieg den vorherigen Spitzenwert um das Vierfache.

Abb. 1: Traffic-Verlauf auf der Ticketmaster Website letztes Jahr macht die Thundering Herd sichtbar [1]

Fans am Boden zerstört, Taylor Swift wütend

Die Auswirkung: das System war völlig überlastet, wodurch es zu verschiedensten Systemfehlern kam. Fans wurden von der Warteliste gestrichen und verloren Tickets, die sich bereits in ihrem Einkaufswagen befanden. Rund 15% der Interaktionen auf der Seite enthielten Fehler. Um das System wieder zu stabilisieren, wurden mehr Fans in Warteschlangen gesetzt. Sie mussten so stundenlange Wartezeiten in Kauf nehmen, um zum Teil am Ende nur eine Fehlermeldung angezeigt zu bekommen. Die Erfahrung war so frustrierend, dass sogar Taylor Swift ihre Verärgerung zum Ausdruck brachte:

“I’m not going to make excuses for anyone because we asked [Ticketmaster], multiple times, if
they could handle this kind of demand and we were assured they could. … It really pisses me
off that a lot of [fans] feel like they went through several bear attacks to get them.”

– Taylor Swift [2]

Doch was kann verbessert werden, dass es nicht noch einmal zu so einer Situation kommt und auf so eine große Nachfrage besser reagiert werden kann?

Wie in Zukunft alle Swifties glücklich werden könnten

Der erste Gedanke, um mit solch einem Traffic Spike umzugehen: Skalieren. Letztendlich braucht es deutlich mehr Kapazitäten, um die Masse an Requests bearbeiten zu können.

1. Horizontales skalieren

Eine Möglichkeit das zu erreichen ist über horizontales Skalieren. Darunter wird die Möglichkeit verstanden, die Anzahl an System Ressourcen gemäß den Kapazitätsansprüchen anzupassen. Im Gegensatz zum vertikalen Skalieren wird die Kapazität nicht über die Verbesserung einzelner Komponenten oder die Erhöhung der Leistungsfähigkeit der vorhandenen Ressourcen verändert. Stattdessen werden zusätzliche Ressourcen, wie zum Beispiel weitere Server oder Computer, hinzugefügt, um die Kapazität eines Systems zu erhöhen. Das horizontale Skalieren bietet insbesondere den Vorteil, dass relativ einfach und schnell zusätzliche Kapazitäten geschaffen werden können, um den Workload zu bearbeiten. Ticketmaster setzt bereits seit 2014 auf Microservices. Daher eignet sich die Infrastruktur gut für eine horizontale Skalierung.

Dabei gibt es zwei Ansätze, wann die Skalierung erfolgen kann:

  • Pre-Scaling über eine Kapazitätsplanung:

Mithilfe einer Kapazitätsplanung kann im Voraus festgelegt werden, ob, wann und wie skaliert werden soll. Dadurch kann sichergestellt werden, dass jederzeit genügend Ressourcen zur Verfügung stehen. So kann beispielsweise zu bestimmten Peaks eingeplant werden, dass mehr Rechenkapazität bereitgestellt werden muss. Wichtig hierfür ist, dass bekannt sein muss, wie sich die Nachfrage verhält, um so gezielt zu skalieren.

Ein großes Problem bei dem Ticketmaster Debakel war sicherlich, dass die tatsächliche Load unterschätzt wurde. Es wurde keine ordentliche Kapazitätsplanung durchgeführt. Insgesamt standen zu wenig Rechenkapazitäten zur Verfügung, sodass die Systeme, à la Thundering Herd, förmlich überrannt wurden.

  • Auto-Scaling:

Der Nachteil am Pre-Scaling ist, dass die Ressourcen beansprucht werden, auch wenn es doch nicht zu der erwarteten hohen Nachfrage kommt. Entsprechend kann diese Methode kostenintensiv sein. Daher kann stattdessen Auto-Scaling sinnvoll sein. Beim Auto-Scaling wird die zur Verfügung stehende Ressourcenanzahl je nach vorherrschender Nachfrage dynamisch vom System angepasst.

Nachteil am Auto-Scaling ist, dass es nicht in Sekundenschnelle funktioniert. Zwar können kurzfristig automatisch mehr Kapazitäten zur Verfügung gestellt werden, trotzdem braucht es etwas Vorlaufzeit. Gerade bei einem Spike, wie es beim Taylor Swift Kartenverkauf der Fall war, ist so eine Methode zu langsam, um einen Systemabsturz vollends zu verhindern.

Im Fall von Ticketmaster ist eine Mischung aus beiden Skalierungsweisen sinnvoll. Anhand eines passenden Kapazitätsplans sollten genügend Ressourcen eingeplant und zur Verfügung gestellt werden. Sollte diese Annahme dennoch übertroffen werden muss Auto-Scaling ermöglicht sein, um kurzfristig reagieren und auch diese Nachfrage bedienen zu können.

2. Bot Management

Wie bereits beschrieben war ein Grund für die hohe Requestanzahl am 15. November, dass entgegen der Erwartung Bots auf der Seite waren. Präventive Maßnahmen wie der Einsatz des Verified Fan Systems waren also nicht erfolgreich. Ein adäquates Bot Management, um den Bottrafic zu stoppen hätte geholfen.

Ziel des Bot Managements ist es schlechte Bots zu identifizieren, um sie anschließend zu blockieren und so eindämmen zu können. Damit soll der ordnungsgemäße Betrieb des Systems und die Sicherheit der Benutzer und Daten gewährleistet werden. Mögliche Maßnahmen können sein:

  • Rate Limiting

Rate Limiting ist ein Verfahren um die Überlastung eines Servers zu verhindern, indem die Anzahl der Anfragen, die ein Client an einen Server sendet, begrenzt wird. Wenn ein Client versucht mehr Anfragen als die festgelegte Rate zu senden, wird die überschüssige Anfrage entweder abgelehnt oder in eine Warteschlange gestellt, bis die Rate wieder unter der Grenze liegt.

Gerade so eine harte Grenze hätte Ticketmaster geholfen, dass es nicht zu den 3,5 Milliarden Requests kommt. Insbesondere als grundlegender Schutz gegen DDoS Attacken wäre der Bot Traffic so deutlich verringert worden.

  • Anzeichen für Bot Traffic früh erkennen

Ein Anzeichen kann ein Anstieg an fehlgeschlagenen Logins in User Konten sein, da es eine Art des Angriffes ist User Konten zu übernehmen und mithilfe dieser den Angriff durchzuführen. Für gewöhnlich ist auch ein plötzlicher, starker Anstieg an Traffic ein Anzeichen für einen möglichen Bot Angriff. Allerdings war hier ähnlich wie auch zu Events wie Black Friday sowieso mit einem Traffic Spike zu rechnen. Daher hilft diese Information für den Ticketmaster Fall nicht.

3. Message Queues

Eine weitere Möglichkeit, um die Systeme bei einer Thundering Herd stabil zu halten, ist über den Einsatz einer Message Queue oder auch Warteschlange. Diese dient als Puffer zwischen den Clients und Servern. Die Request werden dort zunächst abgelegt und dann asynchron, sobald Rechenkapazität verfügbar ist, weiterverteilt. Das System kann so Anfragen aus der Queue abarbeiten, ohne dass es durch eine große Anzahl von gleichzeitigen Anfragen überlastet wird.

Zusätzlich bietet eine Queue die Möglichkeit die Anzahl an Anfragen, die ein System annehmen kann, zu begrenzen. Sobald die Queue voll ist, können keine weiteren Anfragen mehr angenommen werden und neue Clients bekommen einen Fehler angezeigt. Warteschlangen hat Ticketmaster bereits eingesetzt. Insbesondere eine harte Grenze hätte jedoch helfen können die Anzahl an Requests, die gleichzeitig zu bearbeiten sind, zu reduzieren und die Thundering Herd abzuschwächen.

4. Caching

Eine weitere Möglichkeit das Thundering Herd Problem abzuschwächen ist Caching einzusetzen, um vielfach verwendete Daten zwischenzuspeichern und somit schneller verfügbar zu machen. Im Falle von Ticketmaster eignen sich insbesondere Meta-Daten über das Event also bspw. wann findet es statt, wer ist der Act, wo findet das Konzert statt.

5. Testen, Testen, Testen

Ein weiterer wichtiger Aspekt ist das Testen. Ein Fehler kann einen Cascading Failure auslösen und zu großen Systemfehlern und Abstürzen führen. Entsprechend ist es wichtig das System und seine Komponenten ordentlich zu testen, um die Wahrscheinlichkeit eines solchen Fehlers möglichst gering zu halten. Dabei gilt es nicht nur die Funktionalität zu prüfen, sondern auch nicht funktionale Aspekte, wie bspw. welcher Load ein System standhalten kann. Insbesondere in Hinblick auf ein geplantes Großevent wie der Verkaufsstart von Taylor Swift Tickets sollte ein System getestet werden, um zu prüfen, ob das System vorbereitet ist. Möglichkeiten ein System auf seine Widerstandsfähigkeit zu prüfen sind dabei:

  • Load Testing: Simulieren einer bestimmten Load, um zu prüfen, wie sich das System unter bestimmten Loads verhält. Es werden bspw. Antwortzeiten und Durchsatz des Systems gemessen.
  • Scalability Testing: Testen, ob das System fähig ist, sich an verschiedene Loads anzupassen und entsprechend zu skalieren.
  • Stress Testing: Überprüfung der Leistungsfähigkeit eines Systems unter extremen Bedingungen, die über die erwartete oder normale Arbeitslast hinausgehen. Im Gegensatz zu Load Testing geht es hier darum die Kapazitätslimits eines Systems aufzudecken.
  • Chaos Engineering: Methode, um die Widerstandsfähigkeit eines Systems gegenüber unerwarteten Ereignissen und Fehlern zu verbessern, indem gezielt Chaos eingeführt wird. Es werden kontrolliert Störungen und Fehler ausgelöst, um zu sehen, wie das System auf diese Ereignisse reagiert und ob es in der Lage ist sich selbst wiederherzustellen. Bekanntes Beispiel: Netflix’s Simian Army.
  • Monitoring: Die Überwachung der Systeme in Echtzeit, um Probleme, Engpässe oder Schwachstellen frühzeitig identifizieren und entsprechend reagieren zu können.
  • Testing in Production: Das Durchführen von Tests in der produktiven Umgebung, um die tatsächliche Leistung und Reaktionsfähigkeit des Systems unter realen Bedingungen zu bewerten. Zwischen speziellen Testumgebungen und der Produktion gibt es oft große Unterschiede. Über das Testen in Produktion können daher Fehler identifiziert werden, die in speziellen Testumgebungen vielleicht nicht entdeckt worden wären. Dieses Zitat bringt es auf den Punkt:

„I’m more and more convinced that staging environments are like mocks – at best a pale imitation of the genuine article and the worst form of confirmation bias. It’s still better than having nothing – but “works in staging” is only one step better than “works on my machine”.“ [13]

Insbesondere Stress Testing und Chaos Engineering hätten bei der Ticketmaster Situation sicherlich geholfen Fehler und potenzielle Bottlenecks im Voraus zu identifizieren. Mit den Testarten lässt sich eine Thundering Herd simulieren und beobachten, wie das System darauf reagiert und ob es sich selbst wiederherstellt. Da genau so eine Stress bzw. Chaos Situation eingetreten ist hätte man über entsprechende Tests sehen können, dass das System auf eine solche Situation nicht vorbereitet ist. So hätte man die Fehler vorher lösen und mit der Thundering Herd klarkommen können. Dabei ist zu empfehlen diese Tests ebenfalls im produktiven System auszuführen, um möglichst nah an den realen Bedingungen zu sein. Denn wenn man es nicht vor dem geplanten Tag in Produktion schafft, wie soll es dann an dem Tag funktionieren?

Lessons Learned für Ticketmaster und Fazit

Die richtige Kapazitätsplanung mit ausgiebigen Stress und Chaos Engineering in produktiven Umgebungen, der direkten Bereitstellung einer Queue mit harter Grenze und der Begrenzung der Requests über Rate Limiting sind wichtige Aspekte die helfen können, um einer Thundering Herd vorzubeugen und diese im Ernstfall abzuschwächen.

Ob Ticketmaster aus dem Debakel mit dem Taylor Swift Kartenverkauf gelernt hat, konnten sie bereits kürzlich unter Beweis stellen. Anfang Februar dieses Jahres kündigte Beyoncé eine neue Tour an. Wie auch Taylor Swift ist sie eine weltweit bekannte und beliebte Sängerin, die zuletzt 2016 auf Tour war. Entsprechend war auch hier mit einer überdurchschnittlich hohen Nachfrage zu rechnen.

Ein großer Unterschied zum vorherigen Kartenverkauf war, dass sich Ticketmaster diesmal dazu entschied, nicht alle Tickets für alle Shows zur gleichen Zeit zum Verkauf freizugeben. Stattdessen wurden die Konzerte je nach Region in drei Gruppen, mit zeitlich versetzten Verkaufsstart eingeteilt. Bei Taylor Swift wurden dagegen zur gleichen Zeit 2,4 Millionen Tickets zu 52 Shows angeboten.

Auch scheint es so, als würden sie diesmal Rate Limiting eingesetzt haben. Ein paar Fans klagten über die Fehlermeldung 403. Ticketmaster gab dazu an, dies eingesetzt zu haben, um „known Bad Traffic“ zu blockieren. Insgesamt wurden so allein im Verkauf für Londoner Konzerttermine 1,5 Mio Requests blockiert. Sobald ein User die Website mehr als einmal innerhalb von 3 Sekunden aktualisiert oder innerhalb von 24 Stunden mehr als 1000 Seiten auf Ticketmasters Website besucht erscheint die 403 Fehlermeldung.

Insgesamt verliefen die Ticketverkäufe deutlich ruhiger als im vergangenen Jahr. Allerdings weiterhin nicht fehlerfrei. Es gab keinen großen Systemzusammenbruch, trotzdem gab es individuell einige Fehlermeldungen und weiterhin längere Wartezeiten.

Es scheint so, als konnte Ticketmaster zumindest zu großen Teilen aus dem Systemzusammenbruch bei Taylor Swift lernen. Trotzdem scheint es noch weiteres Verbesserungspotenzial zu geben.

Etwas Gutes hatte die Sache: in der Zeit, in der die Fans in den Ticketschleifen verweilen mussten, hatten sie sehr viel Zeit kreative neue Memes und Posts zu erschaffen. Hier nur zwei:

Hauptquellen:

[1] TAYLOR SWIFT | THE ERAS TOUR ONSALE EXPLAINED,
https://business.ticketmaster.com/business-solutions/taylor-swift-the-eras-tour-onsale-explained/
(Letzter Zugriff: 24.02.2023)
[2] How Ticketmaster became the most hated name in music, https://www.latimes.com/entertainmentarts/music/story/2023-01-23/ticketmaster-live-nation-taylor-swift-pearl-jam (Letzter Zugriff: 22.02.2023)
[3] The thundering herd — Distributed Systems rate limiting,
https://medium.com/@venkteshsubramaniam/the-thundering-herd-distributed-systems-rate-limiting9128d20e1f00 (Letzter Zugriff: 21.02.2023)
[4] How to Avoid Cascading Failures in Distributed Systems, https://www.infoq.com/articles/anatomycascading-failure/ (Letzter Zugriff: 21.02.2023)
[5] When Taylor Swift crashed Ticketmaster: A lesson on scaling for spikes,
https://learningdaily.dev/when-taylor-swift-crashed-ticketmaster-a-lesson-on-scaling-for-spikes9931e2c888e9 (Letzter Zugriff: 25.02.2023)
[6] How AWS Powered Amazon’s Biggest Day Ever, https://aws.amazon.com/de/blogs/aws/howaws-powered-amazons-biggest-day-ever/ (Letzter Zugriff: 23.02.2023)
[7] Getting Ready for Some Holiday Shopping? So Are the Bots.,
https://www.akamai.com/blog/news/getting-ready-for-some-holiday-shopping-so-are-the-bots (Letzter
Zugriff: 20.02.2023)
[8] Rate limiting — A Good Approach for Scalable System, https://medium.com/geekculture/ratelimiting-a-good-approach-for-scalable-system-45e338b77ffc (Letzter Zugriff: 24.02.2023)
[9] Part 3 — Complete System Design Series,
https://medium.com/coders-mojo/part-3-complete-system-design-series-e1362baa8a4c (Letzter
Zugriff: 24.02.2023)
[10] Spikability – An Application’s Ability to Handle Unknown and/or Inconsistent Load,
https://blog.iron.io/spikability-applications-ability-to/ (Letzter Zugriff: 25.02.2023)
[11] Testing in Production, the safe way,
https://copyconstruct.medium.com/testing-in-production-the-safe-way-18ca102d0ef1 (Letzter Zugriff:
22.02.2023)
[12] How to increase robustness of a large scale system by testing,
https://blog.mi.hdm-stuttgart.de/index.php/2020/02/24/how-to-increase-robustness-of-a-large-scalesystem-by-testing/ (Letzter Zugriff: 26.02.2023)
[13] Tweet von Cindy Sridharan,
https://twitter.com/copyconstruct/status/974530841190608897?ref_src=twsrc%5Etfw%7Ctwcamp%5E
tweetembed%7Ctwterm%5E974530841190608897%7Ctwgr%5E673ea8db29d296e5f2d7c5de16250f
5031317612%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fcdn.embedly.com%2Fwidgets%2Fmedia.
html%3Ftype%3Dtext2Fhtmlkey%3Da19fcc184b9711e1b4764040d3dc5c07schema%3Dtwitterurl%3D
https3A%2F%2Ftwitter.com%2Fcopyconstruct%2Fstatus%2F974530841190608897image%3Dhttps3
A%2F%2Fi.embed.ly%2F1%2Fimage3Furl3Dhttps253A252F252Fpbs.twimg.com252Fprofile_images2
52F952353315240603648252FEaEy7nw__400x400.jpg26key3Da19fcc184b9711e1b4764040d3dc5c
07 (Letzter Zugriff: 25.02.2023)
[14] Beyoncé tour: UK fans snap up tickets despite Ticketmaster glitches,
https://www.bbc.com/news/entertainment-arts-64533856 (Letzter Zugriff: 26.02.2023)
[15] Why am I seeing a 403 or Forbidden error message?, https://help.ticketmaster.com.au/hc/enau/articles/360006509354-Why-am-I-seeing-a-403-or-Forbidden-error-message- (Letzter Zugriff: 26.02.2023)

How Riot Games created their own internet

Riot Games is the developer of a number of big on- and offline games, most notably ‘League of Legends’. League of Legends is a real-time multiplayer online battle arena game, where two teams consisting of five players each fight one another. As the game is a fast past real-time game, split-second decisions can be the deciding factor between winning and losing a game. Therefore, low latency times are one of the core concerns of Riot Games. The Game currently has around 150 million active players world wide[8]. Back in 2014, Riot Games took a closer look at what they needed to ensure that as many of their players as possible get to have the best possible experience. They identified a number of problems and came to an interesting conclusion: They needed to create their very own internet.

The Problems

Real-time multiplayer games, like League of Legends of Riot Games,have very demanding requirements regarding the latency of a connection. If you open up YouTube in your Browser and the site takes one or two seconds to load, that is totally fine. In a real-time game like League however, where split-second decisions and reactions can decide the outcome of a Match, your game taking one or two seconds to receive the newest game state has a huge impact. Therefore, real-time games have great interest in keeping latency as low as possible.

Buffering

Real-time games cannot lessen the impact of latency spikes using methods like buffering. To revisit the previous example, when watching a video on YouTube, it is exactly known what information is going to be requested, allowing the next few seconds of the video to already being buffered. If the latency spikes, the video can still run for a few seconds while it waits for new data to arrive. However, real-time games like League of Legends are not predictable as they are completely dependent on user input. Therefore, a slower response time will always be noticeable.

ISPs

The ‘internet’ is not a single, unified entity. It is made up of multiple backbone companies and Internet Service Providers(ISP). And these companies have vastly different priorities than companies like Riot Games. Riot Games wants their data to take the most latency efficient path. On the other hand, backbone companies and ISP will use the most cost efficient path, even if that one will take longer.

Figure 1: Map showing the routing connection from San Jose to Hillsboro. The optimal connection is marked in light green, while the actual connection is shown in red[1].

In Figure 1, a real traffic flow of a League of Legends player is shown. The player, in the San Jose area, tries to connect to the Hillsboro area. The optimal connection is marked in light green and would connect directly from San Jose to Hillsboro. In reality, the traffic flows to Los Angeles, over Denver, then to Seattle until finally reaching Hillsboro. In Figure 1, the path is marked in red. The optimal connection (green) would take 14 ms, while the actual connection (red) takes 70 ms, which makes a huge difference.

Routers

Another problem lies in the size of Riot Games traffic. Most internet traffic is transmitted in 1500 bytes sized packages[2]. In comparison, Riot Games traffic is usually relatively small, around 55 bytes, as it might only contain simple data like the location of a player’s click.

Figure 2: Size comparison of standard internet traffic and Riot Games traffic[1].

The problem with this size difference is that routers have the same processing overhead for packets of any size, meaning that for the router, every packets costs the same amount of work. To send the same amount of data as standard internet traffic, Riot Games needs to send around 27 packets. From the routers perspective, these packets cost the same amount of work as normal packets, meaning that Riot Games traffic has an 27x cost increase compared to the standard traffic. Furthermore, routers have an input buffer, that could theoretically hold the increased number of packets. But the buffers are not only limited by size, but also by a fixed number of packets, meaning that Riot Games also fills these buffers 27x as fast[3]. If the buffer is full and another package arrives, it will be dropped by the router, resulting in package loss in the game. As a result, a player would experience things like taking damage out of nowhere and similar things.

Figure 3: An illustration of the connection from a player in San Jose to the game server in Chicago[4].

Figure 3 shows a summary of all the problems that can occur while connecting a player to the game server: The traffic from the player first has to go through ISP access networks, is then routed across different routers, which may be already busy, increasing the chance of overburdening the routers, resulting in package loss.

Riot Games saw all these problems and intended to improve the situation. Their solution: Riot Direct, which basically turns the situation shown in Figure 3 into this:

Figure 4: The connection of a player in the San Jose area to the Chicago game servers using Riot Direct[4].

Riot Direct

After identifying all these problems shown above, Riot Games came to the conclusion, that the best solution is for them to create their own internet. The requirements they have are just too different from the ISPs. The ISPs want to have a network with as many routers as possible, to allow for as much traffic as possible, while routing along the most cost efficient path. In contrast, Riot Games wants to route the most time efficient path and also does not need excessive amounts of routers, which would just increase their latency.
So Riot Games got to work and started identifying the fastest fiber routes and co-locations with the most ISPs. They started setting up routers in these co-locations and peered with as many of the other ISPs as possible. Riot Games needed to be connected with as many ISPs in as many places as possible, as users data still needs to first go through their ISPs network to reach Riot Games network. Riot Games not only had to deal with hardware, but also with software side issues, mostly with the standard internet routing protocol, ‘Border Gateway Protocol (BGP)'[5]. The BGP is build for the common use of the ISPs, and therefore has multiple problems with the special requirements of Riot Games network.
One example of the problems with BGP is traffic leaving Riot Games network.

Figure 5: The routes of incoming traffic (green) and outgoing traffic (red) of players with the same ISP in different areas of the US[4].

In Figure 5, the incoming (green) and outgoing (red) traffic of Riot Games servers in Chicago is shown. In this case, Riot Games peered with the same ISP in the Hillsboro and Chicago area. Players in the Chicago area of this ISP would enter Riot Games network through the Chicago peering point, and when Riot Games sent traffic back, it would return to the players the exact same route. Players from the Hillsboro area of the same ISP would enter Riot Games network through the Hillsboro peering point. However, when Riot Games tried to send traffic back to those players, the BGP would compute the fastest route from the Riot Games network in Chicago to the ISP network. As they peered with the ISP in Chicago, that meant that the return traffic would leave Riot Games network in Chicago and was routed entirely through the ISPs network, effectively bypassing Riot Games Network. To fix this, Riot Games worked together with the ISPs and had them mark their traffic using ‘BGP Communities'[6]. This allowed Riot Games to create special rules for the return of traffic.

The Results

Riot Games released some statistics they used to measure the improvement their changes brought. For the statistics, they measured the number of players with a latency under 80 ms.

Figure 6: Riot Direct impact 21.11.2014 – 18.8.2015[4]

As shown in Figure 6, while Riot Games was working on establishing Riot Direct, the percentage of players with a latency of under 80 ms started out somewhere between 30 – 35 %. By the end of their work, that percentage climbed to around 50% of players. Furthermore, their servers used to be located on the east coast, but with the introduction of Riot Direct, they moved their servers to Chicago, a more central location.

Figure 7: Impact of the Chicago server move[4]

The impact of the server move to Chicago is shown in Figure 7. The percentage of players with a ping below 80 ms further increased from around 50% to 80%. All in all, Riot Games managed to increase the playing experience of around 50% of the players in the US, which is a huge success.

Conclusion

The modern internet is always evolving. In the past, every aspect was left to ISPs and backbone companies, which would deliver a one-size-fits-all approach. And for the longest time, this was completely okay. However, the internet has grown grown exponentially, and the requirements that individual companies may have has also greatly diversified. Riot Games looked at the state of the internet of their time, and realized that it simply was not build in the way they needed it to be. As a result, they spent a lot of time and effort to create ‘their own internet’, as close to their requirements as they could. Netflix came to a somewhat similar conclusion with their Netflix Open Connect[7]. And as the internet will continue to grow, even more companies will find that they have their own special kind of requirements for ‘their’ internet, and will continue to influence and adapt the current network to their uses.

References

[1] Peyton Maynard-Koran, “Fixing the Internet for Real Time Applications: Part I”, https://technology.riotgames.com/news/fixing-internet-real-time-applications-part-i (06.03.23)

[2] Wikipedia, Ethernet frame, https://en.wikipedia.org/wiki/Ethernet_frame (06.03.23)

[3] Guido Appenzeller, Isaac Keslassy, Nick McKeown, “Sizing Router Buffers”, http://yuba.stanford.edu/~nickm/papers/sigcomm2004.pdf (06.03.23)

[4] Peyton Maynard-Koran, “Fixing the Internet for Real Time Applications: Part II”, https://technology.riotgames.com/news/fixing-internet-real-time-applications-part-ii (07.03.23)

[5] Wikipedia, Border Gateway Protocol, https://en.wikipedia.org/wiki/Border_Gateway_Protocol (07.03.23)

[6] “Understanding BGP Communities”, https://www.noction.com/blog/understanding-bgp-communities (07.03.23)

[7] “A cooperative approach to content delivery”, https://openconnect.netflix.com/Open-Connect-Briefing-Paper.pdf (07.03.23)

[8] League of Legends Live Player Count and Statistics, https://activeplayer.io/league-of-legends/ (07.03.23)

How classical MMO-RPGs work, starring Final Fantasy XIV

Promotion Material Final Fantasy XIV [2]

Einleitung

MMO-RPGs oder Massiv-Multi-Player-Role-Playing-Games standen schon lange vor Facebook, Twitter und Co. vor der Herausforderung ein System für möglicherweise Millionen von Usern zeitgleich zu designen, dass ein Concurrent Gameplay und eine Concurrent Gameworld ermöglicht.

Doch wie konnten Spiele wie World of Warcraft, Everquest und Guild Wars diese Aufgabe ohne die Hilfe neuartiger Cloud- und Edge-Computing-Möglichkeiten lösen? Und welche Schlüsse können wir daraus ziehen, wenn wir ein System designen müssen, auf dem viele User zeitgleich agieren können? Muss es immer die Cloud sein? Oder können maßgeschneiderte Architekturen genauso gut funktionieren?

Hierfür schauen wir uns den groben Aufbau klassischer MMO-RPGs an und werden sehen, wie diese funktionieren. Final Fantasy XIV wird uns hierfür immer wieder als Beispiel dienen, um die Konzepte zu unterfüttern.
Unter klassischen MMO-RPGs verstehen wir für diesen Blogeintrag übrigens Spiele wie:

  • Final Fantasy XIV
  • Everquest II
  • World of Warcraft
  • Guild Wars 2
  • Lost Ark

MMO-RPG Server-Architecture

Stellen wir uns die Frage, was man für ein MMO-RPG benötigt, was muss es uns als Spieler bieten?

  1. Eine persistente Welt, in der Änderungen die wir durchführen, beim Ausloggen nicht verloren gehen.
  2. Die Möglichkeit, zusammen mit anderen Spielern zeitgleich Aktionen in der Spielwelt auszuführen und ihre Auswirkungen direkt zu bemerken. Zum Beispiel zusammen gegen den gleichen Feind kämpfen und den Schaden der anderen Spieler direkt sehen.
  3. Interaktion mit anderen Spielern zum Beispiel PvP (Player versus Player)

Um all dies überhaupt klären zu können, schauen wir uns erst mal an, wie eine klassische MMO-RPG Server Architektur aussieht und wie diese arbeitet.

Components

Ein klassisches MMO-RPG hat eine grobe Serverarchitektur wie folgt:


Abbildung 1 MMO-RPG Architecture

Login System

Das Login System ist zumeist das erste System mit dem der Spieler in Verbindung tritt, dieses Authentifiziert den Spieler und gibt ihm meist die Auswahl, welchen Charakter er spielen und auf welchen Server er sich verbinden möchte.
Zusätzlich beinhaltet dieses System eine andere wichtige Aufgabe, es dient als Gatekeeper.
Für den Fall, dass eine große Menge Spieler zeitgleich auf den gleichen Server möchte, kann das Login System erst überprüfen, ob der Server dafür bereit ist. Falls dies nicht der Fall ist oder der Server tatsächlich vollständig gefüllt ist, können die Spieler in eine Warteliste gesteckt werden oder ihnen die Verbindung nicht erlaubt werden. Somit kann ein gutartiger DDOS abgewehrt werden.

Gameserver

Das Herzstück einer jeden MMO-RPG Architektur ist der Gameserver. Dieser übernimmt die Kommunikation mit den Spielern, verarbeitet die Aktionen der Spieler und deren Auswirkungen und hält den Stand der Welt.

Hierbei treffen wir nun auch auf einen der Hauptunterschiede zwischen klassischen ULS’s und einem MMO-RPG.
Ein klassisches ULS wie z.B. Twitter ist ein recht standardmäßiges Request-Response System auf extremer Größe. Ein Tweet wird nur abgerufen, wenn ein User danach fragt. Tweets werden nur verschickt, wenn Users diese erzeugen.

Dagegen ist ein MMO-RPG eine Welt, die dauerhaft simuliert wird. Auch ohne die Anfrage eines Users (Spielers) kann sich die Welt ändern und sich weiter bewegen, zum Beispiel ein Monster greift einen Spieler an, auch wenn dieser keine Aktion ausführt.
Gleichzeitig muss jede Aktion, die ein Spieler durchführt, evaluiert werden und auf der Welt ausgeführt werden. Jeder Spieler erfährt die Änderungen aller anderen und kann mit der Spielwelt interagieren.

Um dies zu bewerkstelligen, wird der Zustand der Welt im Gameserver simuliert, dieser hält die absolute „Wahrheit“ über die Welt und die mit ihm verbundenen Spieler. Dies wird dadurch realisiert, in dem die Welt auf dem Server im RAM simuliert wird, also „gespielt“ wird und alle Spieler nur Aktionen und Anfragen an den Server leiten. Regelmäßig werden diese Informationen dann an das Persistent-Data Storage System weiter geleitet, um die Änderungen festzuhalten.
Dennoch können bei einem Serverabsturz oder Serverfehler Informationen verloren gehen. Dieser Single-Point-of-Failure wird über verschiedene Systeme minimiert, bleibt aber bei dieser klassischen Architektur eine ständige Gefahr.

In nahezu jedem der großen MMO-RPGs wird der Zustand der Welt nicht auf einmal auf einer Instanz für alle Spieler gehalten, sondern in Shards aufgeteilt, die sich um eine begrenzte Menge an Spielern kümmern. Um Sharding in MMO-RPGs und die Umsetzung in Final Fantasy XIV geht es etwas weiter unten genauer.

Persistent-Data Storage System

Als letzten Teil der Architektur kommt der Persistent-Data Storage. Dieser kümmert sich darum, dass die Daten der Server persistent gespeichert werden und auch bei Server-Neustart wieder verfügbar sein. Dieses Storage System kann unterschiedlich aufgebaut sein und kann ebenfalls in Shards aufgeteilt sein.

So wird zum Beispiel in Final Fantasy XIV das Charakter Storage System pro Gameserver aufgeteilt, während das Charakter-Inventar und andere Inventar-Systeme unabhängig von diesen gespeichert sind.

Sharding

Eine der wichtigsten Disziplinen in MMO-RPGs ist das Shrading.

Sharding ist nötig, um allen Spielern eine flüssiges und performantes Erlebnis zu bieten und überhaupt die Spielermenge zu verarbeiten.
Dieses Sharding wird in MMO-RPGs unterschiedlich gehandhabt. Um die Grundidee des Sharding zu erklären, sehen wir uns die Umsetzung von Final Fantasy XIV an.

Final Fantasy XIV hat zwei Hauptanteile an Sharding:

Hardware Sharding

Abbildung 2 Final Fantasy XIV Hardware Sharding [3]

Das Hardware Sharding ist in Abbildung 1 der Gameserver. Dieser ist nicht einfach ein Server für alle Spieler, sondern ist in verschiedene Layer aufgeteilt.

Final Fantasy XIV ist im Hardware Sharding folgend aufgebaut:

Regional Sharding

Final Fantasy XIV hat aktuell vier Data Center diese sind aufgeteilt nach Geografie:

  • North America Data Center
  • European Data Center
  • Oceanien Data Center
  • Japanese Data Center

Diese Data Center liegen (mittlerweile) in den jeweiligen Gebieten und haben damit die schnellste Verbindung für die jeweilige Region.

Logical Sharding

Jedes dieser Data Center ist wiederum in mehrere logische Bereiche unterteilt. Für das European Data Center sind das die beiden Logical Data Center:

  • Light
  • Chaos

Diese Logical Data Center besitzen die Aufgabe Spieler-Population aufzuteilen und Kontrolle über diese zu erhalten. Ebenfalls kann man davon ausgehen, dass jedes dieser Data-Center eine eigene Strom- und Wasserzufuhr haben, um Ausfallsicherheit zu gewährleisten.

Gameserver

Diese beiden Logical Data Center sind wiederum in jeweils acht Gameserver unterteilt.

Ein erstellter Charakter wird einem dieser Gameserver zugewiesen. Somit kann die Auslastung der einzelnen Server und deren Population kontrolliert werden. In Final Fantasy XIV kann zum Beispiel die Erstellung neuer Charaktere für einzelne Server gesperrt werden, wenn der Server mit Charakteren geflutet wird.

Diese Server sind in Final Fantasy XIV designt um bis zu 5000 gleichzeitige Verbindungen zu ermöglichen. Dies wurde den Spielern vor Augen geführt, als im Dezember 2021 mit Endwalker eine neue Erweiterung veröffentlicht wurde. Bei dieser Veröffentlichung gab es einen großen Andrang auf die Server, was zu Loginqueues von bis zu 4400 Spielern pro Server führte und Wartezeiten von bis zu acht Stunden mit sich brachte. [5]

Zusätzlich gibt es in Final Fantasy XIV auch noch Instanzsysteme, die unabhängig der Gameserver existieren. Dungeons, die man mit anderen Spielern bestreiten kann, werden auf eigenen Servern geladen und können von Spielern aller Gameserver des gleichen Logical Data Centers betreten werden, sodass ein Zusammenspiel zwischen Gameservern möglich ist.

Leider gibt es keine exakten Daten über die Hardware, die für Final Fantasy XIV verwendet wird, oder wie das Hardware Sharding für Final Fantasy XIV in Detail funktioniert.
Allerdings kann davon ausgegangen werden, dass ein Gameserver, entweder ein dedizierter Server Verbund ist, oder zumindest ein dedizierter Hardware Server, um die Spieler darauf zu verbinden.

Um dennoch ein paar Hardware Zahlen zu nennen:
In 2009 veröffentlichte Blizzard grobe Zahlen zu der Hardware, auf der World of Warcraft zu dieser Zeit lief. [2]

  • 13250 Server Blades
  • 75000 CPU Cores
  • 112.5 Terabyte Blade Ram

Man kann davon ausgehen, dass diese Zahlen sich bei Blizzard mittlerweile vervielfacht haben. Allerdings ist es gut möglich, dass wir bei Final Fantasy XIV von ungefähr diesen, beziehungsweise leicht höheren Spezifikationen ausgehen können, da Final Fantasy XIV dennoch eine geringere Spielerzahl als World of Warcraft besitzt.

Software Sharding / Instances

Nachdem wir nun auf einem Gameserver sind, wird das Spiel weiter aufgeteilt. Diese Shards ergeben sich meist aus dem Logischen Aufbau der Welt. Final Fantasy XIV, World of Warcraft und auch Guild Wars 2 teilen die Spielwelt in unterschiedliche Gebiete auf, jedes dieser Gebiete ist dann eine eigene Instanz die eine gewisse Menge an Spielern halten kann.

Diese Gebiete sind sowohl logisch-geografisch, so wie spiel-mechanisch voneinander getrennt. Der Gebietsübergang ist an festen Punkten vorgegeben und ist mit einem Shardübergang gekoppelt. Der Spieler bekommt währenddessen einen Ladebildschirm angezeigt.

Diese Instanzen der Spielwelt können auch unterschiedlich priorisiert werden, so ist zum Beispiel der Bereich Limsa Lominsa in Final Fantasy XIV ein Treffpunkt für viele Spieler und immer stark bevölkert. Diese Instanz hat mehr Ressourcen und kann mehr Spieler gleichzeitig halten als andere Shards des Spiels. Ebenso sind die Gebiete der jeweils neuen Erweiterung mit mehr Ressourcen ausgestattet, um die Spieler zu bedienen.

Diese Priorisierung könnte theoretisch auch dynamisch vorgenommen werden, allerdings nutzt Final Fantasy XIV diese Möglichkeit nicht.
Guild Wars 2 wiederum teilt die Spielwelt auch in verschiedene Gebietsshards auf, allerdings gibt es dort von jedem Gebiet wiederum auch mehrere Instanzen, diese werden dynamisch auf- und ab-gebaut, je nach benötigter Verfügbarkeit des Gebiets. Wenn sich eine der Instanzen langsam leert, werden die Spieler gebeten in eine belebtere Instanz des Gebietes zu wechseln, um den Abbau der Instanz zu beschleunigen und somit Ressourcen zu sparen.

Final Fantasy XIV Server Anecdote

Eines der Probleme, mit denen Final Fantasy XIV A Realm Reborn launchte, war der Standort des European Dat Centers. Das European Data Center befand sich nicht wie zu erwarten in Europa, sondern wurde in den USA gehostet. Dies führte dazu, dass europäische Spieler sehr hohen Latenzzeiten ausgesetzt waren. Dies gipfelte darin, dass einer der Boss-Kämpfe des Spiels „Titan Extrem“ für europäische Spieler fast unmöglich abzuschließen war und nur mit viel Glück beendet werden konnte.
Erst im Oktober 2015 wurde das European Data Center auch tatsächlich nach Europa verlegt und verbesserte so das Spielerlebnis für die europäischen Spieler. [4]

Daraus lernen wir: In MMO-RPGs mit zeitkritischem Gameplay sollten die Data Center und Server so nah wie möglich an den Spielern liegen, um ein gutes Spielerlebnis zu bieten. Ebenfalls sollten Namen wie European Data Center auch tatsächlich eine Bedeutung für die geografische Lage des Data Centers haben.

Fazit und Ausblick

Auch wenn klassische MMO-RPGs schon älter sind und Spiele wie New World auf Cloud-Systeme setzten, lohnt es sich weiterhin auf die alten Systeme zu blicken. Maximale Scalability ist zwar nicht die stärke dieser Architekturen, dennoch lösen sie ihr Problem mit einer Perfekt maßgeschneiderten Architektur. MMO-RPGs haben die Probleme von ULS schon für sich gelöst, bevor es den Begriff des Ultra-Largescale-Systems überhaupt gab.

Dennoch glaube ich, dass die Zeit dieser Technologie langsam vorbei ist.
Segmentierte Spielwelten, die auf einzelnen Gameservern laufen, sind aus der Mode gekommen. Man sieht am Beispiel von New World zumindest, dass es möglich ist große Spielerzahlen auch auf Cloudsystem in einer vollständig zusammen hängenden Welt darzustellen. Doch glaube ich, das klassische MMO-RPG-System auch zeigen, dass wenn man sich seiner Aufgabe genau bewusst ist, die Cloud nicht immer die Lösung ist, sondern auch die Umsetzung in einer eigenen Architektur effizient sein kann. Ähnliche genaue Lösungen sieht man beispielsweise bei Stack-Overflow.

Während Cloudlösungen in den meisten Fällen auf möglichst variablen Systemen laufen und eine große Palette an Funktonen bieten, maximale Scalability und Resizability bieten, fasziniert mich genau die Spezialisierung, mit der klassische MMO-RPGs die Probleme einer Concurrent Gameworld gelöst haben und bei der Serverarchitektur und Applikations- beziehungsweise Spiel-Design miteinander verzahnt wurden.

Quellen

[1] https://www.datacenterknowledge.com/archives/2009/11/25/wows-back-end-10-data-centers-75000-cores/

[2] https://imgur.com/a/7EjuL

[3] https://images.mein-mmo.de/medien/2022/09/ffxiv-server-verteilung.jpg

[4] https://geekireland.com/launch-date-announced-final-fantasy-xiv-european-data-centre/

[5] https://forum.square-enix.com/ffxiv/threads/73680-Further-Details-on-Access-Restrictions

How to scale an IoT-Platform

Written by Marvin Blessing, Michael Partes, Frederik Omlor, Nikolai Thees, Jan Tille, Simon Janik, Daniel Heinemann – for System Engineering And Management

Introduction

The aim of the project was to develop a system with which the power consumption of any socket in a household is determined and stored in real time and can be read out by users with the corresponding access data. The user of the system should be able to read out the data via a web application to which he can log in with an account. This should also ensure mobile access to the data. Furthermore, the measured data should be permanently stored in a database, so that users also have the option of viewing measured values over a longer period of time.

The measurement of power consumption should be made possible with a hardware element that is attached to the socket and writes the measured values to the database described.

Fig. 1: Basic system structure

The finished system includes a hardware element and forwards the measured current to a database via a message broker. In addition, the system includes a front-end (web page) through which a user can then query this data via an individual user account.

A more detailed description of the architecture can be found in the following chapter “Architecture”.

According to statista.com there were about 3.6 million homes in Germany that used energy management applications in 2020. For the year 2025 there is an estimate of about 15.3 million homes using energy management systems. Therefore, taking competition and market growth into account, it’s not unlikely that a system like the one we created could reach 2 million homes in the near future.

Architecture

For the architecture of the project, we have to take a look at the system requirements which we defined based on the use case:

  • Read power data
  • Send power data from user to our system
  • Store power data
  • Store user data
  • Read power data based on the user
  • Visualize data for users
  • Monitoring and logging
  • (Authentification)

To implement these requirements, it is crucial to understand the needs of each requirement and figure out an efficient way to connect all the necessary components.


In the first step, we made a list of the technologies that we needed to implement those components:

  • Read power data: To measure the power data we need a Raspberry Pi that has access to the sockets of the user. On the Raspberry Pi is a Python script running that collects the power data.
  • Sending data from Raspberry Pi: To send the power data from the Raspberry Pi to our main system, we decided to use a message broker, since we have to be able to send a lot of data from many different users to our system at the same time.
  • Store power data: To store the power data we use a simple timeseries Database because all data points have a timestamp.
  • Store user data: For the user authentication we use a separate Database to store the user data.
  • Read power data based on the user: To access the stored data we decided to use multiple small services which are used to perform tasks on the databases. This includes an user authentication service which checks the correctness of the provided user data, as well as a read service and a write service to access the stored power data and write new power data to the timeseries database.
  • Visualize data for users: To visualize the data for the user we use a simple web app that uses the different services to access and present the power data to the user.
  • Monitoring and logging: To check the status of our system we use some self defined metrics that we can observe through dashboards.
  • (Authentification: We want to authenticate the user securely and therefore have planned an authentication service with Keycloak. However, this is not implemented at the current time.)

The connection of these components is shown in the following architecture diagram.

Fig. 2: The general architecture of the Energymonitor application

This diagram shows that each reading or writing access only occurs through a service defined by us. There is no direct access to a database, so that we have full control over the access options that we provide.
It also allows us to use those services as microservices. So each service is independent from the other ones and can be developed, tested and scaled on its own. The last aspect is especially important for the performance of our system. It gives us the option to only really scale up as needed. This means that if many users just want to read their data, only the read service needs to be scaled up, whereas the write service is not affected and we do not waste unnecessary resources on it.

This approach follows the CQRS (Command and Query Responsibility Segregation) pattern, which separates reading and writing data from a database. Interestingly, we didn’t know about this pattern when we implemented it, and through our own deliberations we realized the benefits of separating the services and only later discovered that this approach was already known as a pattern.

Scaling & Load Test

Estimations and predicted bottlenecks

To predict bottlenecks early and to estimate the overall requirements we created a scenario to check our resources and decisions against.

First of, the resources of our virtual machine are the following:

Fig. 3: Overview of the systems resources

We also created an overview of the data that would be sent throughout our system.

This helped us evaluate which components to choose and how to test our system in order to find bottlenecks.

DataValue
Estimate users (households)2.000.000
Power values per user~ 30 values (constantly changing)
Data per user~ 300 bytes / min
Max. messages per minute1 / user / min = 2.000.000 / min 
Max. Throughput @ full utilization~ 600 MB / min

The systems user would generate the following data:

UserValue per time increment
1 user~ 157,68 MB / year
2 Mio User~ 315,36 TB / year
2 Mio User~ 86,4 Mrd messages / month

With these values in mind we could reevaluate our systems components and make an informed prediction about possible bottlenecks.

These are shown in the diagram below.

Fig. 4: Predicted bottlenecks in the systems components

To tackle the bottlenecks we listed some possible solutions for scaling and reducing the overproportional utilization of single components. Some of them included specific load balancing instances, database sharding and spreading load over time.

Monitoring

Before we conducted a load test we made sure that we were able to see the utilization of the critical components in our system. We therefore implemented the ‘TICK’ stack.

Telegraf → Data collecting agent

InfluxDB → Time series DB

Chronograf → Data visualization

Kapacitor → (Data processing) & alerting

Fig. 5: Monitoring inside Influx DB’s ‘Telegraf’

Fig. 6: Monitoring inside Influx DB’s ‘Telegraf’

Fig. 7: Monitoring inside Influx DB’s ‘Telegraf’

We created different dashboards to monitor the current utilization and throughput, as seen above. To connect our own services we implemented logging while using a shared data format which can be easily read by Telegraf. This allowed us to add most of our components to the monitoring system.

Load Test

Initially, we were using JSON as our data format. However, due to the relatively large size of JSON messages, we decided to switch to Protocol Buffers (protobuf) instead. This was due to the promising smaller transmitting size of protobuf messages.

In our protobuf message, we utilized a container object which contained multiple measurements. Each measurement contained the measurement name, device ID, energy measurement, and timestamp. This allowed us to effectively and efficiently transmit multiple measurements in a single message while keeping the overall size of the message to a minimum. By utilizing protobuf and optimizing our message format, we were able to improve the efficiency and effectiveness of our data transmission process.

Fig. 8 General data format used for the application

In order to determine the potential traffic requirements of our system, we conducted measurements to assess the size of our messages. We found that a container object containing eleven measurements was approximately 470 bytes, while a single measurement was around 37 bytes. We also measured the improvement in size comparing the container object in JSON and in protobuf. For JSON we measured that a container had the size of around 1075 bytes and thus our improvement in size was about 50%, which in network throughput can go a long way.

Using this information, we calculated the amount of traffic that would be required if we were to scale up to 2 million messages per minute, each containing a container object. Breaking it down to seconds would mean we had to scale up to 33 thousand messages per second. With this calculation, we were able to gain insight into the potential traffic demands that our system might face at scale. The expected amount of traffic required for our scale was expected to be around 14.95 MB/s, in regards to network traffic this would be around 119.6 Mbps. Knowing the network requirements and the shortcomings of slow home networks upload performance in Germany we were required to conduct load tests either with combined forces of several home networks or to test on the virtual machine itself or at least from within the same local network. We then tried the same machine approach.

Our general approach to load testing the system involved deploying it on our virtual machine and conducting performance tests. Initially, we tested the system as a whole but found that its performance was not meeting our expectations. To identify the root cause, we checked our monitoring and validated the performance of RabbitMQ both as a standalone component and as a part of our write service.

Fig. 9: Load testing the whole system and load testing the message broker

To conduct our load tests we used the RabbitMQ Performance Test Tool (perftest). Simulating the traffic from several Raspberry Pi instances from our system architecture.

RabbitMQ Standalone
Data470 bytesOur dataOur data
AckAutoAutoManual
Producer222
Receiver444
Send rate Messages/s~51.000~46.000~21.000
Receive rateMessages/s~50.000~45.000~20.000

The default PerfTest result for the RabbitMQ Standalone is higher than with our dataformat. This is probably due to the internal workings of the performance tool. As for the difference with RabbitMQ Standalone versus Standalone with manual ack there’s a large difference in over 50% performance loss. Going for throughput would mean that we would have to drop our data consistency.

Full Application (RabbitMQ, WriteService & InfluxDB)
DataOur dataOur dataOur dataOur data
AckManualAutoManualAuto
Producer2222
Receiver1144
Send rate Messages/s~10.000~20.000~13.000~20.000
Receive rateMessages/s~5.000~19.000~6.000~20.000

For our application we see an even further decrease in messages per second. Using auto ack and four receiving threads we only achieved half the performance of the receiver from the testing tool. Also the amount of threads used for our Go application did not seem to make any difference for the throughput. For scaling we thus should rather deal with missing data and interpolation techniques. 

Achieving only half the performance kept us wondering, which is why we took a look on our monitoring dashboards. At first glance either the WriteService or InfluxDB somehow became our bottleneck.

Fig. 10: InfluxDB writes during load test

The InfluxDB dashboard clearly shows a write peak of ~61.000 writes per seconds around the performance test.

Looking at the dashboard for our RabbitMQ we can see the performance around 20k messages per second as stated before. A slight difference is visible between ack and delivery rate of around 400 messages per second. Also the amount of acked messages did not match the messages sent through RabbitMQ. The amount of acked messages is equivalent to 11 * 20.000 ⇒ 220.000 rows per second, which our InfluxDB clearly didn’t reach.

Fig. 11: Queue deliver and ack rate during load test.

We could see that we also validated the performance of our write service and InfluxDB, which led us to determine that the write service and InfluxDB were slowing RabbitMQ down. We then conducted additional tests to validate the performance of the write service in isolation.

Fig. 12: Load testing the Timeseries DB component

Using a customized Go client we conducted a write test outside our application. Writing 2 million data points first single threaded and then multithreaded to check if any performance gain is reached. We reached similar speeds leading us to the conclusion that our Go client might not be the issue. InfluxDB now being our main suspect of performance loss. Due to the custom testing tool we also discovered that using the convenience of the Point data object from the InfluxDB Go client library actually cost us time. Internally of the Go library the Point data object was just converted to the InfluxDB line protocol format. Removing the transformation from protobuf to point but instead writing line protocol ourselves we increased the performance of our writes.

Despite our efforts even when matching the throughput of InfluxDB to our RabbitMQ we could not have accommodated our use case of 2 Million users with 30 devices per minute. Achieving 46.000 messages per second for 11 metrics we would expect around 15.000 for 30 metrics per second. Scaling this to a per minute metric would mean that we can support up to 900.000 households which is roughly the half of our goal. So either way more improvements would be required for RabbitMQ and InfluxDB to reach our target.

Scaling

Our focus during system optimization was primarily on RabbitMQ, which resulted in neglecting the optimization of our writes to InfluxDB. As we were more accustomed to relational databases, we were unaware of the performance relevant configurations of InfluxDB. Our load tests revealed that the main issue was with our writes to the database, but we cannot be certain if we have optimized our single InfluxDB instance to its full potential. 

Given our VM constraints, it would have been better to place InfluxDB on a separate VM with an SSD and more RAM for better write performance. Additionally, we should have revisited our write design of the Go client, which we then could have verified with InfluxDBs own performance test tool called Inch. Moreover, we could have considered using multiple InfluxDB instances/sharding to further increase our write performance.

For RabbitMQ we would have required scaling as well, maxing our throughput for a single instance an improvement only could have been made with more instances and load balancing.

Unfortunately, most of these options were out of scope for our student project, but they can be explored with more time and computational resources.

Lessons Learned

Right from the beginning we were aware that running our observability solution on the same system we want to monitor is a bad idea. If there were a complete system outage there would be no way for us to see what happened as the monitoring would crash along with the system. 

We did it anyway because we were limited to our single VM on which we needed to deploy our entire application. We expected that we were not going to be able to monitor our system during network outages, deployments, etc. However, what we hadn’t fully considered is that this would also cause problems for us when trying to evaluate the performance of our services during the stress tests.

While performing a stress test, our Chronograf dashboards would first become slow and unresponsive because the system was under so much load. What we were able to see though was that the RabbitMQ and our write service would slowly eat up the entire system RAM, at which point the monitoring would only report back errors and Chronograf became completely unreachable. We did not anticipate that the other components would start stealing resources from our observability stack. Then again, part of that very stack, our InfluxDB, was being stress tested, which explains why the monitoring became slow to update. 

All this supports our plan to run the monitoring on and as a separate system in a market-ready version of the application.

Monitoring was also somewhat handy in finding bugs in our application: At one point our write service reported CPU usage of over 180 %. This was a clear indicator that there was a bug in our implementation. Thankfully though, it was just putting high demand on the CPU at that moment and hadn’t crashed our system yet. We rolled the service back to an older version where the bug hadn’t been observed, which gave us the time to find and fix the bug and quickly deploy the updated version without causing substantial disruption to the application. 

This, we think, is an excellent example of how monitoring paired with alerting can prevent outages or at least minimizes downtime. 

Development Process

Despite reaching a solution that works, there are quite a few things where we struggled along the way. Some of the lessons almost feel like they’re part of a book entitled “Wouldn’t it be cool… and other bad design approaches”. Making these mistakes can be embarrassing to admit, but struggles always bring an opportunity to learn with them. 

In retrospect, we lost ourselves in creating too much unnecessary functionality too early in the project. An example would be attempting to create a sharding resolver that lookups user tokens to distribute writes across different influx instances and buckets. Deep down we knew that it would probably be out of scope but we still fell victim to our curiosity. The proper way would have been to implement a minimal working prototype first, conduct a performance analysis, identify the bottleneck, and only then spend resources to resolve it.

While we recognize that anticipation of future problem sources is a valuable trait in developing software, not being able to resist these impulses massively harms overall productivity. In our case this meant we were constantly switching between problems, creating more and more zones of construction in the process. This made it harder to orient in the code and difficult to decide what to work on next.

What is so frustrating is that we are aware of this tendency and know the solution is to practice an iterative and incremental approach to development, yet we tend to repeat these rookie mistakes. Unfortunately, we realized too late that hexagonal architecture has a natural workflow to it that helps with the problem of getting lost. First, you start by getting a clear understanding of the problem domain. We recommend using draw.io to sketch out the components of the application and how they interact. Next, you define the application’s ports. Ports should be defined upfront, as they represent the key abstractions of the application and ensure that the application is designed to be technology-agnostic. The definition of port interfaces often happens in unison with the definition of domain objects, because domain objects inform the design of the interface and are often used as input and output parameters. Once ports are defined, develop the core business logic of the application. After that, it is a good practice to test the core business logic to validate it meets the functional requirements of the application. Testing the business logic before implementing the adapters also helps to ensure that any issues or bugs in the core functionality of the application are detected and resolved early in the development process.

Once the business logic is implemented and tested, proceed to implement the adapters that connect the application to the external environment. Test the adapters to ensure they conform to the ports and correctly transform data between the external environment and the business logic.

After adapters are implemented and tested, you can test the system as a whole, to ensure that all components work together as expected. This testing should include functional and integration testing. Last, refactor and continue to improve the design. In comparison, our unstructured and unfocused approach to implementation cost us valuable time.

Without following the workflow described above, you tend to push testing towards the end of the project. The combination of having acquired debt (need to re-factor code to make it easier to test) and a self-inflicted lack of time meant, we were not able to take advantage of hexagonal architecture offers in the domain of testing.

func WriteEvent(msg interface{}, target interface{}) error {
    // let the type checks begin …
}

func WriteWattage(m *domain.WattageMeasurement, token string) error {
    // no such problems
}

Fig. 13: Different approaches with very generic interfaces (top) and specific types (bottom)

Another problem we encountered was finding the right degree of abstraction. A generic solution is typically designed to be flexible and adaptable so that it can be used in a wide range of use cases without requiring significant modification. These adjectives sound highly desirable to the ears of a developer and, as a result, we wanted to build our code in a way that would allow completely changing out the message format, inject adapters via configuration instead of touching the source code, etc. It’s fair to say that my initial implementation was way too generic. More and more it felt like we were not building a solution to our specific use case, but almost a framework that could be used for similar problems. Eventually, we realized that generic doesn’t mean good. Adding lots of adaptability naturally adds more abstraction and indirection to the code. The most glaring indicators that something was going wrong were that our interfaces were inexpressive/vague, exhibited weak type safety, and forced us to write unnecessary code complexity to deal with that. When you build a highly adaptable system that can adapt to a whole bunch of cases that never happen, then all of that just ends up being a big waste of time. In hindsight, it is difficult to analyze what caused this obsession with developing something generic. Once we re-wrote everything to be as specific to our problem domain as possible, the code became expressive and readable, and the need for using empty interfaces as function parameters vanished. 

Identifying and improving bottlenecks

As software developers, we’ve all experienced the frustration of trying to identify and resolve bottlenecks in a system. We know that while it’s easy to detect the general location of a bottleneck, it can be hard to determine the actual issue. It’s also challenging to predict how software will perform with different hardware specifications or how all the components will interact with each other on a virtual machine. As we had no knowledge of the actual performance on our virtual machine we started to put everything on the machine and first tested the system as a whole. While the approach can work it is harder to determine the actual issue when a bottleneck seems to be prevalent. Also, using the numbers provided by the software vendors for the software solutions can help to get a rough estimate of the performance; it’s still different with each use case and current set up and can’t replace making your own measurements when going for performance.

One valuable lesson we’ve learned is to take a more methodical approach to identifying bottlenecks. Checking first if there is a load testing tool to produce load for a single component and then verifying the results with a custom implementation. For our approach as soon as we noticed a bottleneck we started to check each component individually on the target machine before adding additional components. This helped us isolate the source of the issue. Without our monitoring in place we would never have detected the bottleneck and we’ve thus realized that monitoring is crucial in detecting performance issues. By tracking performance metrics, we could identify areas of concern and take action to optimize processes such as unnecessary convenience data transformations and, depending on the use case, unrequired data consistency, which can significantly impact system performance.

In summary, while the process of identifying and resolving bottlenecks can be challenging, we’ve learned that taking a structured approach and paying close attention to performance metrics can help us identify and address issues efficiently.

AMD EPYC 9004 – a small scale supercomputer?

For a long time the server and desktop space was dominated by intel CPUs. AMD lacked severely behind the competition with its processors but changed everything up, when they launched their ZEN architecture processors in February 2017. Suddenly they started to compete on the consumer side of processors again and started to bring some competition to the market. But in the server space intel was still reigning supreme, which was about to change.

AMDs ZEN architecture was designed to be scalable and they did scale it a lot over time. While their EPYC server grade processors started with up to 32 cores in 2017, they doubled this in late 2018 to up to 64 cores with ZEN2, improved performance with ZEN3 in late 2019 and finally scaled it up to 96 cores in November 2022 with ZEN4 (7)(8). With this massive scaling of CPU cores they managed to outperform Intel chips and produce incredibly powerful single system servers.

AMDs 9004 series EPYC server CPUs brought some massive improvements over their previous generation by increasing the core count by up to 50% form an already staggering 64 cores, to a total of 96 cores per CPU (1). Additionally, the frequency of all cores increased, while the ‘infinity fabric’ which allows cross communication between the single cores improved as well (1). Additionally, the new series of CPUs switched from PCIe 4.0 to PCIe 5.0 and DDR4 to DDR5 memory, for an huge increase in I/O and read/write performance (1). But even if this performance wasn’t enough already, EPYC allows you to link two of their flagship CPUs together in a single motherboard, to act like a single 192 core CPU (1).

What would such a possible max spec system look like?

2x AMD EPYC 9654 for 192 cores, 384 threads per system. 128 PCIe gen 5 lanes, plus 6 PCIe gen 3 lanes per CPU, with either 48 or 64 lanes used to connect the CPUs for up to 160 gen 5 lanes and 12 gen 3 lanes. 12 DDR5 memory controllers per CPU to support 6 TB of memory each for a total of 12 TB DDR5 memory in one system (1)(10).

With all of this, the system is theoretically able to offer 10.752 teraflops of double precision float operations (5), 1.280 terabyte/s of PCIe 5.0 I/O and up to 921.6 gigabyte/s of DDR5 ram I/O (10).

But what exactly do these numbers mean? If we compare them to some supercomputers, that once managed to hold the world records, we can see that the fastest supercomputer of 2000 was the ‘ASCII White’ of the ‘Lawrence Livermore National Laboratory’, being able to calculate 7.2 teraflops (6). The maximized AMD EPYC system would be able to outperform this system, without using any GPUs for parallelized computing, which in the case of an RTX 4090 would add about 1.14 to 1.29 teraflops per card used (9).

In 2002 the ‘ASCII White’ was beaten by the ‘Earth Simulator’ by ‘JAMSTEC Earth Simulator Center’ in Japan (6). It managed to calculate 35.68 teraflops. Only by this supercomputer, which used a bigger budget then ‘ASCII White’ to be constructed, is our theoretical system surpassed.

But what can such performance even be used for?

Scientist at CERN had to previously rely on huge data centers, to be able to store the collision data, which gets generated and collected near instantly (3). Before the data is filtered it arrives at a data rate of 40 terabyte per second from the sensors and has to be stored somehow. To alleviate this dependency on data centers they upgraded their processing for the data detectors to servers running AMD EPYC 7742 processors with 64 cores and 128 PCIe 4.0 lanes (3). These powered four 200Gbit Mellanox networking cards, which received 800Gbit of data per server. If these would be upgraded to the new top of the line EPYC systems, they would be able to handle 10 of these network cards per server for a staggering 2 terabit of I/O, cutting the number of servers needed by 3/5th (4). This would result in huge power and cost savings, while also reducing the complexity of the entire system and making it less error prone. Considering that the previous upgrade to the EPYC 7742 systems already reduced their amount of servers needed by 1/3rd it would overall reduce the amount to 1/5th.

If we consider this power and cost saving we have to roughly estimate how much power and parts cost such an system would bring. Since the main costs are in the processors and ram required the other parts of the machine will be roughly estimated. An AMD EPYC 9654 has a listing price of 11,805 USD (4). DDR5 ram in 256GB must be estimated at about 1,000 USD since kits in this size are nearly impossible to find but scale almost linearly with size in cost (12). With all of this in mind, the cost is about 1000 USD * 24 ram sticks + 2 * 11805 = 47,610 USD or about 50,000 USD considering other parts.

Power usage can be estimated by up to 400W per CPU (11) and about 600W for cooling and ram each (11), for a grand total of about 1400W base power usage.

If we compare this to the previously mentioned supercomputers, we can see some huge differences. The ‘ASCII White’ had a construction cost of about 110 million USD and a power usage of 6MW (6). The ‘Earth Simulator’ had a construction cost of about 600 million USD and a power usage of about 12.8 MW (6). Therefore, it is quite fair to say, that the scientific community can hugely profit by the cost reduction that these systems offer, especially considering power usage.

But an comparison to some supercomputers from 20 years ago, isn’t to fair either. Even with the upcoming ZEN4c architecture, which is announced to improve core count to 128 cores (2), these systems can’t hold up to modern supercomputers. Especially not if these computers use exactly these processors to reach new highs of performance (5). The ‘Frontier’ supercomputer, finished in 2022, manages to calculate a staggering 1.102 exaflops, or 100,000 times the performance of our dual CPU system, while also consuming 21 MW (6). To say such a system is a true supercomputer is an overstatement but considering the workloads it can calculate it truly isn’t an ordinary server either and thus offer newfound possibilities for huge monolithic systems.

Sources:

Modern application of Voice AI technology

Image of Voice AI header

With the advancement of technology and the gradually increasing use of artificial intelligence, new markets are developed. One of such is the market of Voice AI which became a commercial success with voice bots such as Alexa or Siri. They were mainly used as digital assistants who could answer questions, set reminders and they could generally tap into various databases to provide the aid and service that they were ask to provide. Although the popular use case seems to be primarily domestic, we have long since experienced other applications for Voice AI in areas such as UI speech control, voice recognition and replication and in use within entertainment media.

Faced with the ever-present but ever-growing interest in artificial intelligence which continue to further their influence on society, industry and the commercial landscape, my post will strive to demonstrate and inspect the technologies surrounding the application of Voice AI but also the concurrent obstacles it needs to overcome. However, before we can dive deeper into the topic, it is important to introduce the concept of Voice AI and its general technological workings.

Continue reading

AI and Scaling the Compute for the new Moore’s Law

AI and Scaling the Compute becomes more relevant as the strive for larger language models and general purpose AI continues. The future of the trend is unknown as the rate of doubling the compute outpaces Moore’s Law rate of every two year to a 3.4 month doubling.

Introduction

AI models have been rapidly growing in complexity and sophistication, requiring increasingly powerful computing resources to train and operate effectively. This trend has led to a surge of interest in scaling compute for AI, with researchers exploring new hardware architectures and distributed computing strategies to push the limits of what is possible. Figure 1 depicts the scale of compute required to train language models for the last ten years.

Figure 1: Computation used to train notable artificial intelligence systems [1]

The evolution of AI models has been driven by advances in deep learning, which allows models to learn from vast amounts of data and make predictions or decisions with remarkable accuracy. However, the sheer size and complexity of these models require an unprecedented amount of compute power to train and operate, presenting significant challenges for hardware designers and data center operators. Despite these challenges, progress has been impressive, with new breakthroughs in hardware and software helping to unlock the full potential of AI. Specialized hardware, such as GPUs (Graphics Processing Units) and TPUs (Tensor Processing Units) have emerged as powerful tools for training AI models, while distributed computing architectures are being developed to allow multiple machines to work together seamlessly. As AI models continue to grow in complexity, the need for scalable and efficient compute resources will only continue to grow. Researchers and engineers will need to work together to develop new hardware and software solutions that can keep pace with the rapid evolution of AI, unlocking new possibilities for intelligent automation, predictive analytics and other transformative applications.

Requiring compute beyond Moore’s Law

As explained in [2] the training of AI systems can be categorized in two distinct Eras, the First Era and the Modern Era. The First Era of compute usage in training AI systems, starting with the perceptron, lasted from the 1950s to the late 2000s and relied on limited computational resources and simple algorithms. In contrast, the Modern Era began around 2012 with the rise of deep learning and the availability of powerful hardware such as GPUs and TPUs, allowing for the training of increasingly complex models with millions or even billions of parameters. [3] even suggests three Eras with the current one being the “Large Scale Era” starting with AlphaGo around 2016.

Figure 2: AlexNet to AlphaGo Zero: 300,000x increase in compute [2]

Increase in AI computation

Figure 2 depicts the increase in computational resources needed to train AI systems over time, which is evident by the rise of GPUs and TPUs and the transition from Moore’s Law’s 2-year doubling of compute to a 3.4-month doubling. This increase in compute demand is exemplified by the difference between AlexNet and AlphaGo Zero, where the latter requires 300,000 times more computational resources to train than the former.

With the rise of large language models like GPT, more recently known due to the publicly available ChatGPT, the question arose on how the trend on computing such models will continue. As seen in Figure 3 the amount of parameters to be learned are increasing rapidly and thus the amount of data and compute required for the models.

Figure 3: Amount of Parameters for Large Language Models [4]

The new Moore’s Law

Moore’s law is the observation that the number of transistors in a dense integrated circuit doubles about every two year [5]. As Moore’s Law has a physical constraint on how many transistors can be placed on an integrated circuits, which will cease to apply, a new trend in compute seems to emerge in the field of AI. As stated in [4] the increase of the size of the language model and in regard of the 3.4-month doubling time stated in [2] we seem to establish a new “Moore’s Law for AI” for compute, which can only be achieved with massive parallelization techniques.

Scaling AI computation

An earlier blogpost [6] already handled the explanation on how deep learning models can be parallelized with the different computation paradigms single instance single device (SISD), multi-instance single device (MISD), single-instance multi-device (SIMD) and multi-instance multi-device (MIMD). Furthermore, the concepts of Model and Data parallelization are explained in that post in more detail.

GPT-3 Example

If we take GPT-3 for example it was scaled up in several ways to enable it to handle its massive size and complexity. Here are some of the key techniques that were used [7]:

  1. Distributed training: GPT-3 was trained using a distributed training approach that involved multiple GPUs and TPUs working together in parallel. The training data was partitioned across the multiple devices and the model parameters were updated using a process called gradient descent, where each device calculated a portion of the gradient and then combined them to update the parameters.
  2. Model parallelism: Because GPT-3 has so many parameters (up to 175 billion), it was not possible to store the entire model on a single device. Instead, the model was split across multiple devices using a technique called model parallelism, where each device stores a portion of the model parameters and computes a portion of the model’s output.
  3. Pipeline parallelism: To further scale up training, GPT-3 also used a technique called pipeline parallelism, where the model is divided into multiple stages and each stage is run on a separate set of devices in parallel. This enables the model to handle much larger batch sizes and process more data in less time.
  4. Mixed precision training: GPT-3 used mixed precision training, which involves using both 16-bit and 32-bit floating-point numbers to represent the model parameters and compute gradients. This can significantly speed up training and reduce the memory requirements of the model.
  5. Adaptive optimization: Finally, GPT-3 used an adaptive optimization algorithm called AdamW that adjusts the learning rate and weight decay of the model dynamically during training. This helps to avoid overfitting and achieve better performance on the validation set.

In summary, the training of GPT-3 was scaled up using a combination of distributed training, model parallelism, pipeline parallelism, mixed precision training and adaptive optimization. These techniques allowed the model to handle its massive size and complexity.

Distributed training, but how?

In order to train a large AI model, scaling across multiple GPUs, TPUs, and machines is necessary. However, achieving this becomes more complex when using a compute cluster, as distributing tasks and aggregating results requires careful consideration of several points. Specifically, when training a large model at scale using a cluster of machines, the following
factors must be taken into account [8][9]:

  1. Communication overhead: Distributed training involves exchanging gradients and model updates between different machines, which can introduce significant communication overhead. Optimizing communication and reducing the frequency of communication can help reduce the overhead and speed up training.
  2. Load balancing: Distributing the workload across multiple machines requires careful load balancing to ensure that each machine has a similar workload. Imbalanced workloads can lead to underutilization of some machines and slower training overall.
  3. Fault tolerance: When using clusters of machines, it is important to consider fault tolerance, as failures in one or more machines can interrupt training. Strategies for fault tolerance include checkpointing, replication of model parameters, and the use of redundant compute nodes.
  4. Network topology: The topology of the network connecting the machines can affect the performance of distributed training. For example, using a network with high bandwidth and low latency can reduce communication overhead and speed up training.
  5. Scalability: The ability to scale up the number of machines used for training is important to accommodate largermodels anddatasets. Ensuringthatthetrainingprocess is scalablerequires careful consideration of the communication patterns and load balancing across a large number of machines.

The trend continues

Taking a look at an even larger language model, the Megatron-Turing NLG [10], we can see that the trend continues. Such large models therefore are required to train on large-scale infrastructure with special software and hardware design optimized for system throughput for large datasets. In [10] the tradeoffs for some techniques are mentioned. Only the combination of several techniques and the use of a supercomputer powered by 560 DGX 100 servers using each eight NVIDIA A100 80GB Tensor Core GPUs allowed NVIDIA to use scale up to thousand of GPUs and train the model in an acceptable time.

Conclusion and outlook

The trend for more compute is expected to continue as AI applications become more complex and require larger datasets and more sophisticated algorithms. To keep up with this demand, we can expect continued improvements in specialized hardware and software optimization techniques, such as neural architecture search, pruning and quantization. Scaling aspects of both software and hardware are critical to meet the increasing demand for computing power and to make AI more efficient and accessible to a wider range of applications.
In contrast to chasing even larger models another approach would be to focus more on specific tasks than general purpose models. As language models continue to grow in size, researchers are beginning to see diminishing returns in terms of their performance improvements. While larger language models have shown impressive capabilities in natural language processing tasks, the computational and financial resources required to train and run them have also increased exponentially. Therefore, [4] proposes a more practical approach which might be more cost and environment friendly than the next big general purpose AI.
As for now we can continue to observe large tech companies joining together for the next big AI model, using supercomputers, cloud infrastructure and every compute they have to build even more impressive AI and thus develop even more sophisticated software and hardware architectures to facilitate the massive amounts of data and computation required to train such models.

Sources

[1] OurWorld in Data. “Computation usedtotrain notable artificial intelligence systems”. In: (2023). URL: https://ourworldindata.org/grapher/artificial-intelligence-training-computation.

[2] OpenAI. “AI and Compute”. In: (2018). URL: https://openai.com/research/ai-and-compute.

[3] Jaime Sevilla et al. Compute Trends Across Three Eras of Machine Learning. 2022. arXiv: 2202.05924 [cs.LG].

[4] Julien Simon. “Large Language Models”. In: (2021). URL: https://huggingface.co/blog/large-language-models.

[5] Wikipedia. Moore’s Law. 2023. URL: https://en.wikipedia.org/wiki/Moore%5C%27s_law.

[6] Annika Strauß and Maximilian Kaiser. “An overview of Large Scale Deep Learning”. In: (2021). URL: https://blog.mi.hdm-stuttgart.de/index.php/2022/03/31/an-overview-oflarge-scale-deep-learning/.

[7] Tom B. Brown et al. “Language Models are Few-Shot Learners”. In: CoRR abs/2005.14165 (2020).
arXiv: 2005.14165. URL: https://arxiv.org/abs/2005.14165.

[8] Martín Abadi et al. TensorFlow: A System for Large-Scale Machine Learning. 2016. URL: https://www.usenix.org/system/files/conference/osdi16/osdi16-abadi.pdf.

[9] Henggang Cui, Gregory R. Ganger, and Phillip B. Gibbons. Scalable deep learning on distributed GPUs with a GPU-specialized parameter server. 2015. URL: https://www.pdl.cmu.edu/PDLFTP/BigLearning/CMU-PDL-15-107.pdf.

[10] Paresh Kharya and Ali Alvi. “Using DeepSpeed and Megatron to Train Megatron-Turing NLG 530B, the World’s Largest and Most Powerful Generative Language Model”. In: (2021). URL: https://developer.nvidia.com/blog/using-deepspeed-and-megatron-to-trainmegatron-turing-nlg-530b-the-worlds-largest-and-most-powerful-generativelanguage-model/.

CDNs und die DSGVO

In Zeiten von weltweit verteilten großen Systemen im Internet und der überwiegend mobilen Bedienung von Webseiten ist die schnelle Datenübertragung an alle Orte auf der Welt ein entscheidendes Thema. Kein Deutscher Urlauber in Amerika möchte eine Ewigkeit auf die heißgeliebte online-Ausgabe der Bild-Zeitung länger als ein paar Sekunden warten. Und auch der durchschnittliche Facebook-Nutzer in Deutschland würden durchdrehen, wenn die Ladezeit wenige Sekunden übersteigt. Aber dazu gibt es ja Content-Delivery-Netzwerke, die uns auf der ganzen Welt verteilt den immer gleichen und stets aktuell gehaltenen statischen Inhalt von Webseiten vorhalten. Hauptsächlich CSS, JavaScript, Symbole und Schriftarten.

CDNs bieten also eine super Funktion, wäre da nicht die EU und der großartige Datenschutz der DSGVO und all die zum Teil schwachsinnigen Urteile von klagenden Menschen die wohl einfach nur zu viel Langeweile hatten… <Sarkasmus aus>

Weiterlesen…

Concurrent Game Play

Concurrent Game Play mit AWS am Beispiel des Videospiels “New World”

Amazon Games veröffentlichte 2021 mit dem Videospiel New World ein Massive Multiplayer Online Role Playing Game (MMORPG), das Amazon Web Services (AWS) für sämtliche serverseitigen Dienste nutzt. Trotz eher mittelmäßiger Rezensionen des Spiels mit durchschnittlich 3,2 von 5 Sternen auf der hauseigenen Amazon Webpage wollen wir in diesem Blogeintrag einmal unter die Haube des Spiels schauen und sehen, wie das Spiel in seiner Architektur funktioniert um Concurrent Gameplay zu ermöglichen und welche Probleme während des Releases und der Laufzeit auftraten.

New World statt Old World

New World ist ein 2021 erschienenes MMORPG aus den Amazon Game Studios, entwickelt von deren Abteilung Amazon Games Orange County. Es spielt im 17. Jahrhundert der fiktionalen Welt Aeternum und behandelt die Kolonisierung des Landes durch die Spieler. 

Wie für Amazon oftmals üblich, wird die Technik, die hinter dem Spiel steckt, als bahnbrechend bezeichnet. Es werden Vergleiche gezogen, in denen New World durch die Nutzung der AWS – im Vergleich zur “Old World” der traditionellen MMOs – selbstverständlich um Welten besser abschneidet. Was also steckt hinter den genutzten Services? Was macht das Spiel aus Sicht von Amazon zu einem Gamechanger? Oder handelt es sich hier eigentlich einfach nur um eine große Werbekampagne, um die Nutzung von AWS in der Spielentwicklung zu festigen?

Schauen wir uns dazu erst einmal die zugrundeliegende Serverarchitektur an.

Server Architektur

In New World sammeln Spieler Erfahrungen und  Items. Sie treffen dabei mit vielen anderen Spielern und KI-Einheiten zusammen. Im Gegensatz zu Session-Based Games verlieren Spieler die Errungenschaften ihrer Sitzung nach einem Logout nicht. Sämtliche Gegenstände, die gesammelt wurden, getroffene Mitspieler und Fähigkeiten, werden als Wachstum des Spielcharakters abgespeichert und sind beim nächsten Login wieder verfügbar. Amazon Games erklärt diese Mechanik dafür verantwortlich, dass die Immersion für den Spieler steigt, auch wenn diese Mechanik beinahe schon eine Voraussetzung für MMOs multimillionen Dollar schwerer Unternehmen sein sollte. [1]

Abb. 1: Architektur hinter New World. Eigene Darstellung in Anlehnung an [1]

Während der Entwicklung der fiktiven Welt wurde Wert darauf gelegt, auf keine Ladebildschirme beim Wechsel zwischen Spiel-Arealen auf der Karte zurückgreifen zu müssen. Zu den weiteren Anforderungen gehört ebenso das Handling von unzähligen Spielern, die gleichzeitig auf das Spiel zugreifen wollen. Das führte letztendlich zur Verwendung eines massiven verteilten Systems. [1]

Zuallererst legten die Entwickler fest, die Anzahl der Spieler in der Welt Aeternum auf 2500 zu begrenzen und Spieler auf mehrere Welten zu verteilen. Zusätzlich befinden sich darin circa 7000 KI-Einheiten und mehrere 100.000 interagierbare Objekte. [1,2]

Abb. 2: Server Architektur einer Welt in New World. Eigene Darstellung in Anlehnung [2]

Werfen wir einen Blick in eine dieser Welten.

Möchte sich ein Client in einer Welt einloggen, stehen ihm dafür vier Remote Entry Points (REPs) zur Verfügung. Diese sind der einzige öffentliche Zugangspunkt für das gesamte Spiel und handhaben die Sicherheit und Belastbarkeit des Systems. Die REPs sind auf Amazon Elastic Compute Clouds, näher EC2 C5.9xlarge Instanzen, basiert. [1,3]

Abb. 3: Hubs und deren zugehörige Regionen. Eigene Darstellung in Anlehnung an [1]

Hinter diesen REPs befinden sich sieben Hubs, bestehend aus computational processing units, die ebenso auf Amazon EC2 C5.9xlarge Instanzen umgesetzt sind. Jeder dieser Hubs ist für die Berechnung eines Teils der Spielwelt verantwortlich. Dazu wird die Welt Aeternum mithilfe eines übergelegten Grids in 14 Regionen eingeteilt. Ein Hub ist hier nun für zwei nicht aneinandergrenzende Kacheln zuständig. Verlässt der Spieler die Region eines Hubs, wird er dem jeweils zuständigen Hub der neuen Region übergeben. So wird sichergestellt, dass die Last gleichmäßig über die Instanzen verteilt wird. [1]

Zusätzlich zu den Hubs existiert ein Instance Pool bestehend aus EC2 Instanzen. Dieser ist für den session-based Modus des Spiels zuständig, in New World sind das temporäre Abenteuer, die beispielsweise in einem Dungeon stattfinden. Entschließt sich ein Spieler, eine dieser Missionen zu beginnen, wird diese Session auf einer verfügbaren EC2 Instanz dieses Pools betrieben. Ist die Mission abgeschlossen, kehrt diese Instanz wieder in den Instance Pool zurück und ist für eine nächste Session bereit. [1,2]

Die Instanzen des HUBs sind im Grunde stateless. Dadurch wird gewährleistet, dass die einzelnen Instanzen bei Problemen neu gestartet und die Game-States wiederhergestellt werden können, selbst wenn alle HUB-Instanzen zeitgleich ausfallen. Hierfür ist es aber natürlich notwendig, die Game-States regelmäßig zu sichern. Bei New World wird hierzu Amazons DynamoDB verwendet, eine NoSQL-Datenbank, die flexibel und im Idealfall ohne Codeänderungen skaliert werden kann. Das Spiel kommt so auf 800.000 Schreibvorgänge der Gamestates alle 30 Sekunden. [1,4,13]

Um ein solches verteiltes System zu verwalten, ist es wichtig, einen guten Einblick über die unterschiedlichen Komponenten zu besitzen – eine gute Observability. Hierfür ist es wichtig, Events zu loggen und auszuwerten, um sich andeutende Störungen im laufenden Betrieb frühzeitig zu erkennen. In New World wird hierzu Amazon Kinesis verwendet. Mithilfe von Kinesis Data Streams, einem serverless streaming data service, werden große Streaming-Datenmengen in Echtzeit und hoher Geschwindigkeit erfasst und analysiert. Mithilfe von Kinesis Data Firehose werden die Daten schließlich an Amazon Simple Storage Service (S3) gesendet, einem Objektspeicherservice. [1,2]

Pro Minute verlassen so 23 Millionen Events Kinesis in Richtung S3. Die Daten in S3 können anschließend durch Analyse-Services wie Amazon Athena und OpenSearch ausgewertet werden. Die ausgewerteten Daten können die Entwickler des Spiels anschließend nutzen, um beispielsweise herauszufinden, welche KI-Einheit am häufigsten bekämpft wurde oder auf welchem Pfad die meisten Spieler unterwegs waren. Auf dieser Basis können die Gamedesigner Aspekte des Spiels verändern und damit die Spielerfahrung in Echtzeit verändern und verbessern, angepasst an die gesammelten Daten. Ebenso kann auch ein Fehlverhalten der Server frühzeitig entdeckt und behoben werden. [1,2]

Für die operative Seite, die der Seite des Core-Gameplay gegenüber steht, wird Amazon API Gateway verwendet. Es ist dafür zuständig, die externen Applikationen zu managen und kümmert sich darum, dass die Spieleentwickler Programmierschnittstellen erstellen, veröffentlichen, warten, überwachen und sichern können. Über dieses Gateway werden 200 Millionen Calls pro Minute verarbeitet. Dahinter werden globale Services und lokale / Cluster Services gehandhabt. Für diese Services wird Amazon Lambda verwendet, eine eventgesteuerte, serverlose Computing Platform. Für die globalen Services betreibt Lambda Microservices für Achievements, Channels und eindeutige globale Usernames, während für die lokalen Services Queues, Contracts, Sessions und Notifications, etc. gehandhabt werden. Dabei läuft jede Lambda Funktion in einer isolierten Umgebung mit eigenen Ressourcen und Filesystem. [1,2,5]

Abb. 4: Serverless Microservices. Eigene Darstellung in Anlehnung an [2]

Durch diese gesamte Architektur besitzt New World eine gute Scalability und kann schnell auf unerwartet hohe Nachfragen von Seiten der Spieler reagieren. Beim Release des Spiels wurden beispielsweise 185 verschiedene Welten zur Verfügung gestellt, also eine Bereitstellung für nahezu 500.000 Spieler. Innerhalb der ersten zehn Tage wuchs die Anzahl der Welten bereits auf 500 an. Das sind genügend für 1,25 Millionen Spieler. Für das Scaling setzt Amazon Games auf Scaling Out. [1,2]

Gespannt auf den Release?

Abb. 5: Wait, it’s only a queue? [15]

Soviel zur Theorie, aber wie sieht es denn jetzt in der Praxis aus? Verlief der Release, wie wir jetzt erwarten könnten, ohne Probleme? Leider nein.

Trotz der beschriebenen Möglichkeit, eine einfache Skalierbarkeit durch die Serverarchitektur zu besitzen, gab es zum weltweiten Release von New World am 28. September 2021 – ebenso wie auch bei anderen MMOs – große Probleme, um als Spieler auf den Server zu gelangen. In Warteschlangen sammelten sich meist zwischen 5.000 und 10.000 Spieler pro Welt, die bereits ihr Maximum an Spielern erreicht haben. Von einer schnellen Skalierbarkeit war nichts zu sehen. Um mehr Spieler pro Welt zuzulassen, wurden regional Tests gestartet, den initialen Wert von 2.000 auf bis zu 2.500 zu erhöhen. Hier wurde beobachtet, wie sehr sich die 2.500 Spieler über die gesamte Welt verteilen und ob sich nicht zu viele Spieler zeitgleich in der Region nur eines EC2 tummeln. Letzten Endes konnte die Spielerzahl nach positiv ausgefallenem Test erhöht werden. [6]

Why did the New World player cross the road? To get to the other queue!

Wieso also konnte – oder wollte – Amazon Games die Server trotz angepriesener Möglichkeit nicht skalieren? Das Problem liegt hier nicht unbedingt auf der Seite der Architektur. Beginnen wir beim Start eines neuen Spiels: der Spieler wählt eine Welt aus, auf der er spielen möchte. Auf dieser Welt wird nun der Spielcharakter erstellt. Ein Wechsel zu einer anderen Welt ist nicht möglich, es sei denn der Spieler erstellt einen neuen Charakter und startet von vorn. Ist eine Welt also voll besetzt, kann ein Spieler nicht einfach in eine andere Welt eintreten, deren Maximum noch nicht erreicht ist. Wie es beim Release von MMORPGs meist der Fall ist, gibt es vor allem in den ersten Wochen einen großen Andrang an Spielern, der sich jedoch meist wieder stark verkleinert. 

Abb. 6: New World Right Now [16]

Hätte Amazon also zum Start des Games direkt deutlich größer skaliert, um eine Wartezeit für Spieler zu vermeiden, wären die Welten in den ersten Wochen zwar gefüllt gewesen und alle Spieler glücklich, danach jedoch nur zum Bruchteil voll. Dies hätte dazu geführt, dass das Gameplay durch zu leere Gegenden leidet und viele Welten zusammengeführt hätten werden müssen, was wiederum für Downtimes der betroffenen Server gesorgt hätte. Für die Durchführung eines Merges sind einige Dinge zu beachten. New World Developer Kay sagte hierzu, es werde erst einmal sichergestellt, dass die neue Spitzenpopulation über 1.000 beträgt. Außerdem solle eine gleichmäßige Repräsentation der Fraktionen sichergestellt werden. Der komplexeste Punkt läge jedoch in der Sorge um eine Instabilität der Persistenz beim Merging von Häusern der Spielcharaktere. Diese könnte dafür sorgen, dass die Häuser der Spieler verloren gehen würden. [9,10]

An sich also ein logischer Schritt, Mergings zu vermeiden. Da das Spiel jedoch – sei es durch Bugs oder die zu langen Wartezeiten – nach dem anfänglichen Ansturm an Spielern schnell von 1,6 Millionen auf 150.000 Spieler pro Tag gesunken ist, konnten Merges von Welten nicht mehr lange vermieden werden. [8,14]

Und jetzt?

Nach dem Start des Games wurden verschiedene Exploits entdeckt, die es den Spielern unter anderem erlaubte, Ingame-Währungen und Items zu verdoppeln. Um diesen Fehler zu beseitigen, wurde ein Jahr nach dem Release angekündigt, sogenannte Fresh-Start-Server online zu nehmen. Diese Server beinhalten keinen Charaktertransfer aus den Welten älterer Server, und stellten damit sicher, dass kein Spieler von seinen Exploits profitieren konnte. Auch ein Merge zwischen alten und neuen Welten wird Stand jetzt nicht stattfinden. Somit fungierten die Server auch als Neustart des Spiels, bei dem sämtliche Spieler mit allen Verbesserungen, die das Spiel seit Release hatte, von vorn und auf demselben Stand beginnen konnten. Man könnte diese Fresh-Start-Server also auch einen zweiten Release des Games nennen. [7]

Why did the gamer quit playing New World? Because he couldn’t handle the “New” bugs every day!

Die fehlende Möglichkeit, zwischen Welten zu wechseln, wurde mittlerweile behoben. Amazon Games gab an aktive Spieler im November 2021 und Februar 2022 Tokens aus, um einen einmaligen Charaktertransfer zu ermöglichen. Diese Option wurde von vielen Spielern dringend erwartet, da Amazon Games zum Release des Spiels ankündigte, dass Spieler sich keine Sorgen machen müssten, wenn sie aufgrund der vollen Welten eine andere Welt als ihre Freunde wählten, da ein Servertransfer in Zukunft möglich sein würde. Etwas zu schön, einen Serverwechsel so simpel und vor allem kostenlos anzubieten, daher wurden ab April 2022 keine weiteren Tokens einfach so ausgehändigt, sondern für $15 USD im Ingame-Shop verkauft. 

Fazit

Stellen wir die ausgeklügelte Architektur mit den Problemen des Spiels vor allem während des Releases gegenüber, stellen wir fest, dass die Scalability nicht ganz wie angepriesen funktioniert hat. Zwar bietet die Architektur die Möglichkeit, schnell neue Welten für einen großen Andrang an Spielern mithilfe eines Scale-Outs zu öffnen, aber diese Möglichkeit ist angesichts der fehlenden Möglichkeit eines ebenso schnellen Scale-Downs relativ sinnlos. Durch den fehlenden Scale-Out während des Releases konnte man erkennen, dass dieses Problem den Entwicklern wohl bekannt war. 

Ein Merge von Welten hätte von Anfang an mit eingeplant werden müssen, das Team hätte an dieser Stelle also nicht nur an die Möglichkeit eines Scaling-Outs, sondern ebenso an ein Scale-Down denken müssen, um sich langfristig an eine dynamische Anzahl an Spieler anpassen zu können. Die fehlende Möglichkeit eines Transfers zwischen den Welten sperrte im späteren Verlauf Spieler in einer zu gering populierten Welt ein, in der zu wenige andere Spieler zur Interaktion vorhanden waren. Auch aktuell existieren Welten, in denen im Peak gerade nur einmal 500 Spieler aktiv sind [11]. An dieser Stelle hätten sich die Entwickler mit einem weniger statischen Management zwischen den Welten einige Probleme vor allem während des Starts des Spiels, aber auch im langfristigen Lauf erspart. 

Alles in allem muss man die aufgetretenen Probleme aber sicherlich auch auf den Aspekt des Arbeitsumfeldes in der Gaming-Branche schieben. Crunch ist mittlerweile zu einem Standard in diesem Sektor geworden und benötigte Alpha- und Betaphasen sind teilweise zu kurz angesetzt. Zwar wurde der Release von New World bereits um einige Monate nach hinten verschoben, um eine erkannte Instabilität der Server zu beheben – was auch ein schlechtes Licht auf AWS geworfen hätte – aber gerade der fehlende Scale-Down hätte ebenso mehr Zeit benötigt [12]. Vermutlich spielten hier Delays und Absagen von zwei weiteren Spielen, die Amazon Games zusammen mit New World 2026 ankündigte, eine Rolle. Aber das alles soll natürlich keine Ausrede für ein Multi-Milliarden Dollar Unternehmen sein. Und gerade für einen Anbieter, der das Scaling seiner Dienste anpreist, erntete das doch einige negative Kommentare und Artikel. 

Letzten Endes ist New World aber ein guter Startpunkt für folgende Releases und MMORPGs. Wenn Entwicklerteams aus den Fehlern des Spiels gelernt haben, könnte sich dahinter ein großes Potential für zukünftige Concurrent Games verstecken. (…Sofern die Beschreibung der zugrundeliegenden Architektur etwas sorgfältiger dokumentiert wird. Ich habe schon lange nicht mehr so viele Fehler und Inkonsistenzen zwischen Text und Diagrammen wie in Amazons selbst erstellten Beitrag gesehen.)

Quellen

[1] Nicholas Walsh und Amazon Game Tech Team, The Unique Architecture behind Amazon Games’ Seamless MMO New World. [online]. 06. April 2022. Verfügbar unter: https://aws.amazon.com/de/events/events-content/?awsf.filter-series=event-series%23reinvent&awsf.filter-session-type=*all&awsf.filter-level=*all&awsf.filter-topic=*all&awsf.filter-industry=*all&awsf.filter-language=language%23english&cards.q=new%2Bworld&cards.q_operator=AND&awsm.page-cards=2 (Zugriff am 19. Februar 2023)

[2] Werner Vogels und Amazon Web Services, AWS re:Invent 2021 – Keynote with Dr. Werner Vogels. [online]. 03. Dezember 2021. Verfügbar unter: https://www.youtube.com/watch?v=8_Xs8Ik0h1w (Zugriff am 21. Februar 2023)

[3] Jeff Barr, Now Available – Compute-Intensive C5 Instances for Amazon EC2. [online]. 06. November 2017. Verfügbar unter: https://aws.amazon.com/de/blogs/aws/now-available-compute-intensive-c5-instances-for-amazon-ec2/ (Zugriff am 21. Februar 2023)

[4] Amazon Game Tech Team, Stateful or Stateless? Choose the right approach for each of your game services. [online]. 22. Juli 2020. Verfügbar unter: https://aws.amazon.com/de/blogs/gametech/stateful-or-stateless/ (Zugriff am 22. Februar 2023)

[5] Jan-Dirk Kranz, Was ist AWS-Lambda und wozu nutzt man es?. [online]. 03. November 2021. Verfügbar unter: https://it-talents.de/it-ratgeber/programmieren-und-coden/was-ist-aws-lambda-und-wozu-nutzt-man-es/ (Zugriff am 21. Februar 2023)

[6] Peter Bathge, New World: Dass ausgerechnet Amazon Warteschlangen zulässt, ist ein Witz. [online]. 30. September 2021. Verfügbar unter: https://www.gamestar.de/artikel/warteschlangen-in-new-world-sind-ein-schlechter-witz,3373860.html (Zugriff am 22. Februar 2023)

[7] Anny, New World macht seine Neustart-Server so gut, dass kaum wer auf den alten spielen will – Muss jetzt handeln. [online]. 01. Dezember 2022. Verfügbar unter: https://mein-mmo.de/new-world-server-merge/ (Zugriff am 22. Februar 2023)

[8] Sean Murray, New World Faces Low Player Count Complaints – Again. [online]. 21. Januar 2022. Verfügbar unter: https://www.thegamer.com/new-world-low-player-count-server-merge/ (Zugriff am 24. Februar 2023)

[9] Susanne Braun, New World: Server-Transfers und Server-Merges – weiter geht’s im Jahr 2022!. [online]. 24. Dezember 2021. Verfügbar unter: https://www.buffed.de/New-World-Spiel-61911/News/Server-Transfer-Token-Merge-1386142/ (Zugriff am 24. Februar 2023)

[10] Susanne Braun, New World: Einmaliger Fraktions-Reset wegen Ungleichgewicht mit Server-Merge. [online]. 19. Dezember 2021. Verfügbar unter: https://www.buffed.de/New-World-Spiel-61911/News/Fraktions-Ungleichgewicht-Reset-Server-Merge-Housing-Problem-1385911/ (Zugriff am 24. Februar 2023)

[11] New World Server Status. [online]. Verfügbar unter: https://nwdb.info/server-status (Zugriff am 25. Februar 2023)

[12] Peter Steinlechner, Amazon liefert New World mit noch einer Verspätung. [online]. 05. August 2021. Verfügbar unter: https://www.golem.de/news/mmorpg-amazon-liefert-new-world-mit-noch-einer-verspaetung-2108-158687.html (Zugriff am 25. Februar 2023)

[13] Was ist Amazon DynamoDB?. [online]. Verfügbar unter: https://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/Introduction.html (Zugriff am 21. Februar 2023)

[14] New World Stats, Historical (5-years) breakdown of the player and subscriber populations for New World. https://mmo-population.com/r/newworldgame/stats (Zugriff an 22. Februar 2023)

[15] Abbildung verfügbar unter: https://preview.redd.it/jznitth3n4r71.jpg?width=640&crop=smart&auto=webp&v=enabled&s=f22cf4e8951034a17589d6d2cf1070fcd9c22079 (Zugriff am 24. Februar 2023)

[16] Abbildung Verfügbar unter: https://d13urrra316e2f.cloudfront.net/original/3X/8/5/85315c58aae1f624be145854dd9ec14a981d08a1.jpeg (Zugriff am 24. Februar 2023)