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

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

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)

Kann man einen wissenschaftlichen Blogeintrag rein mithilfe von ChatGPT schreiben?

Einleitung

In den letzten Jahren hat die Künstliche Intelligenz (KI) einen enormen Aufschwung erlebt und ist zu einem wichtigen Teil unseres täglichen Lebens geworden. KI wird für eine Vielzahl von Aufgaben eingesetzt – von der Bilderkennung bis hin zur Sprachverarbeitung. Eine der neuesten Anwendungen von KI ist ChatGPT, ein System für die Generierung von Texten und hat in der Welt der künstlichen Intelligenz großes Aufsehen erregt, da es potentiell eine neue Ära des maschinellen Lernens einleitet, die es Maschinen ermöglicht, menschenähnliche Gespräche und Interaktionen zu führen. Das Modell wurde von OpenAI entwickelt und nutzt eine Technologie namens “Generative Pre-trained Transformer 3” (GPT-3), die es dem Modell ermöglicht, menschliche Sprache zu verstehen und darauf zu reagieren.

ChatGPT ist eine der fortschrittlichsten und leistungsstärksten Anwendungen von künstlicher Intelligenz. Es wurde entwickelt, um auf Anfragen in natürlicher Sprache zu antworten, indem es eine Vielzahl von Texten analysiert und ein tieferes Verständnis von Sprache und Bedeutung entwickelt. ChatGPT ist in der Lage, mühelos Millionen von Worten zu analysieren und zu verstehen, um intelligent auf Fragen zu antworten. Aber kann man nur mit ChatGPT einen kompletten wissenschaftlichen Artikel schreiben?

Diese Frage ist nicht leicht zu beantworten. Einerseits hat ChatGPT die Fähigkeit, viele Informationen aufzunehmen und in kürzester Zeit eine Unmenge an Text zu generieren. Andererseits ist es jedoch nicht in der Lage, die menschliche Fähigkeit zu ersetzen, logische Schlussfolgerungen zu ziehen und eine kritische Analyse durchzuführen. ChatGPT ist auch nicht in der Lage, den Kontext vollständig zu verstehen oder komplexe menschliche Emotionen wie Empathie und Mitgefühl zu zeigen.

Ein weiterer wichtiger Punkt, der bei der Verwendung von ChatGPT in Betracht gezogen werden muss, ist die Möglichkeit von Fehlern oder Vorurteilen. Wie bei jedem maschinellen Lernmodell hängt die Qualität der Ausgabe von ChatGPT von der Qualität der Eingabe ab. Wenn die Daten, auf denen das Modell trainiert wird, Vorurteile oder falsche Annahmen enthalten, kann dies zu fehlerhaften oder sogar schädlichen Ausgaben führen.

ChatGPT ist jedoch sehr mächtig und in der Lage, sehr überzeugende Texte zu generieren. Eine Studie hat sogar gezeigt, dass viele Leser nicht in der Lage sind, KI-generierte Texte von menschlich geschriebenen Texten zu unterscheiden. In dieser Studie, die von einem Forscherteam der Stanford University im Jahr 2020 veröffentlicht wurde, wurden Probanden gebeten, eine Reihe von Texten zu lesen und zu entscheiden, ob sie von einem menschlichen Schreiber oder von einer KI wie ChatGPT erstellt wurden.

Die Ergebnisse zeigten, dass die Teilnehmer nur in etwa 30% der Fälle richtig erkennen konnten, ob der Text von einem menschlichen Schreiber oder von einer KI stammte. Dies deutet darauf hin, dass es schwierig sein kann, den Unterschied zwischen Texten zu erkennen, die von einem menschlichen Schreiber und solchen, die von einer KI wie ChatGPT erstellt wurden.

Dies ist ein besorgniserregendes Ergebnis, da es darauf hindeutet, dass KI-generierte Texte möglicherweise die Integrität von wissenschaftlichen Arbeiten und anderen wichtigen Texten beeinträchtigen können. Es ist wichtig, dass Schriftsteller und Leser gleichermaßen sich bewusst sind, dass die Texte, die sie lesen oder schreiben, möglicherweise von einer KI erstellt wurden. Das bedeutet, dass es durchaus möglich ist, einen Artikel mit ChatGPT zu schreiben, der für den Leser wie von einem Menschen geschrieben aussieht.

Allerdings ist es wichtig zu betonen, dass dies nicht der beste Ansatz für das Schreiben eines wissenschaftlichen Artikels ist. Ein solcher Artikel erfordert in der Regel eine umfassende Forschung, Analyse und kritische Bewertung von Quellen. Ein wissenschaftlicher Artikel sollte auch eine klare Methodik und einen detaillierten Bericht über die Ergebnisse enthalten. Diese Aspekte können nicht einfach von ChatGPT generiert werden.

Wenn man ChatGPT als Hilfsmittel verwendet, um bestimmte Abschnitte des Artikels zu generieren oder um den Schreibprozess zu beschleunigen, ist das eine Sache. Aber ein wissenschaftlicher Artikel, der ausschließlich mit ChatGPT geschrieben wurde, würde wahrscheinlich nicht den Anforderungen an wissenschaftliche Integrität und Genauigkeit entsprechen.

Wenn Sie bis zu diesem Punkt gelesen haben ohne zu ahnen, dass dieser Text bisher komplett von ChatGPT geschrieben wurde, dann ist das ein Beleg für die Problematik, die diese Technologie aufwirft. 

Die Veröffentlichung ChatGPTs am 30. November 2022 war ein bahnbrechender Schritt in der IT-Branche. Insgesamt kann man sagen, dass Künstliche Intelligenz hiermit ein Niveau erreicht hat, dass mittlerweile jeden angeht. Laut einem Nachrichtenartikel der “New York Times” fühlt sich der IT-Riese Google selbst von dieser disruptiven Technologie bedroht und hat sogar intern die “Alarmstufe rot” ausgerufen.
ChatGPT kann sehr vielseitig eingesetzt werden. Viele Menschen nutzen den Chatbot auf eine harmlose Weise, um zum Beispiel Witze oder Gedichte generieren zu lassen. Andere nutzen es hingegen als eine Art Suchmaschine, was auch der Grund für Googles großer Sorge ist. 

Weiterhin hat ChatGPT ein großes Wissen über Programmiersprachen; es ist sogar mit dessen Hilfe möglich, gesamte, funktionierende Programme zu erstellen, ohne selbst eine Zeile Code zu schreiben. Der Anwendungsbereich von ChatGPT ist also sehr breit. Da es jedoch primär ein Sprachmodell darstellt, dass die Aufgabe hat, menschenähnliche Texte zu generieren, möchte ich mich in diesem Artikel auf den Aspekt des wissenschaftlichen Schreibens konzentrieren. 

Das Ende der akademischen Integrität?

Die Menschheit hat großen Spaß daran, Verschwörungstheorien aufzustellen und allgemein “Doom and Gloom” zu verbreiten, vor allem wenn es um künstliche Intelligenz geht (Quelle: Terminator Filme). Mit ChatGPT ist das nicht anders. Seit der Einführung des Chatbots wird sowohl auf Social-Media als auch in diversen Nachrichtenartikeln das Ende des wissenschaftlichen Schreibens und der akademischen Integrität prophezeit. In diesem Artikel möchte ich diese Befürchtung durchleuchten und prüfen, ob diese Aussage wirklich gerechtfertigt ist. Weiterhin möchte ich im Anschluss einen kleinen Blick in die Zukunft dieser Technologie wagen.

Betrachten wir zunächst den generierten Text von weiter oben. Da es als Ziel dieses Artikels galt, herauszufinden, ob die Arbeit einem komplett abgenommen werden kann, habe ich ChatGPT natürlich vor der Aufgabe gestellt, den Text alleine zu generieren. Meine erste Anweisung lautete wie folgt:

Schreibe einen wissenschaftlichen Artikel über ChatGPT. Es sollte zunächst beschreiben, was das überhaupt ist und wie es genutzt werden kann. Der Artikel sollte ebenfalls beschreiben, welche gesellschaftlichen Folgen aus der Nutzung von ChatGPT in Bereichen wie das Verfassen von Artikeln oder anderen Texten entstehen. Der Fokus des Artikels sollte das wissenschaftliche Schreiben und mögliche Gefahren für die akademische Integrität sein. Am Ende sollte ein Fazit gezogen werden und ein Ausblick geworfen werden. Der Text sollte ca. 1000 Wörter umfassen.

Das Resultat war ein sehr neutral gehaltener, aber trotzdem ein ChatGPT-lobender Text (den ich hier nicht in voller Länge kopieren werde), der nur oberflächlich auf die Gefahren der Technologie einging. Außerdem hat ChatGPT von selbst Zwischenüberschriften eingefügt, die den Lesefluss unterbrachen. Nicht sehr überzeugend. Daraufhin habe ich noch ein paar weitere Anweisungen hinzugefügt:

Danke. [Notiz: Stets nett zur KI sein, um spätere Überlebenschancen zu maximieren]
Der Text sollte keine Überschriften haben. Ich möchte stattdessen einen Fleißtext mit Übergängen. Nimm außerdem ChatGPT gerne noch mehr in die Kritik. Gehe auch auf die Problematik ein, dass möglicherweise bei Abschlussarbeiten ganze Inhalte generiert werden können.

Der Text verbesserte sich nach weiteren Anweisungen immer weiter. Aber um den gesamten Text zu generieren war es ein ziemlicher Kampf. Mal wurde der Text nicht zu ende generiert, mal hat ChatGPT wieder Überschriften eingefügt, mal wurde meine Wörterzahl-Vorgabe nicht beachtet. Es verging so viel Zeit bis ich merkte, dass ich vermutlich sehr viel schneller gewesen wäre, wenn ich einfach den Text selbst geschrieben hätte. Naja. In einer Hinsicht ist ChatGPT schon sehr menschenähnlich: Die Kommunikation mit ihm sorgt für einen erhöhten Stresspegel.

Am Ende wurde jedoch irgendwann der obige Text fertig generiert und ich war ….. enttäuscht. Nach langem Hin-und-Her wurde ein Artikel generiert, mit dem – für mich zumindest – etwas einfach nicht stimmt.

Lass uns diesen Text einmal näher analysieren. Folgend nenne ich ein paar Dinge, die mir beim Lesen aufgefallen sind:

  • Detail: Das wohl auffälligste Merkmal ist, dass ChatGPT Schwierigkeiten damit hat, ins Detail zu gehen. Es trifft oft Aussagen, die ein interessantes Thema aufgreifen, jedoch ist dieses im nächsten oder übernächsten Satz bereits wieder wie vergessen. Auch auf Nachfrage mehr ins Detail zu steigen führt zu Wiederholungen oder weiteren Argumenten, die wiederum nur oberflächlich beschrieben werden.
  • Übergänge: Wie auch bereits erwähnt, tut sich ChatGPT schwer, flüssige Übergänge zu erzeugen. Beim wissenschaftlichen Schreiben wird einem immer wieder der Begriff des “Roten Fadens” eingetrichtert und ist ein sehr wichtiger Bestandteil einer ernstzunehmenden wissenschaftlichen Arbeit. Ohne flüssige Übergänge wirkt ein Text nicht richtig zusammenhängend
    ChatGPT bessert sich in diesem Aspekt, wenn man zusätzliche Anweisungen hinzufügt, die auffordert, flüssige Übergänge zu erzeugen, jedoch fühlt sich das nach einem Kampf an, das man mit der KI führt.
  • Satzbau: ChatGPT generiert oft kurze Sätze, die sich in ihrem Aufbau sehr ähnlich sind und den Text sehr simpel wirken lassen. Das Sprachmodell versucht kompliziert aufgebaute Sätze mit Nebensätzen zu vermeiden, da unter anderem die Verständlichkeit des Textes eine Große Rolle spielt. Das ist an sich nichts Negatives, aber führt zu der Konsequenz, dass der Text umkreativ und unoriginell wirkt.
  • Persönlichkeit: Der Text ist – um es stumpf auszudrücken – einfach langweilig zu lesen. Eines der Markenzeichen menschlicher Kommunikation ist die Fähigkeit, Gefühle durch Tonfall und Wortwahl zu vermitteln. Daran scheitert ChatGPT in vollem Ausmaß. KI-generierte Texte können zwar Aspekte von Emotionen nachahmen, jedoch mangelt es an den Nuancen, zu denen Menschen fähig sind.

Okay, aber was ist wenn mir diese Faktoren alle egal sind? Angenommen, ich habe bis zum letzten Moment gewartet, die Abgabe ist noch wenige Stunden entfernt und ich habe einfach keine Zeit mich zu verkünsteln. Ich persönlich bin selbstverständlich noch nie in dieser Situation gewesen, aber dann wäre es mir doch egal, ob der Text zu oberflächlich, der Satzbau simpel oder alles langweilig zu lesen ist. Mein einziges Ziel: Bestehen. Vier gewinnt. Nicht auffliegen. 

Aber ich weiß ja auch: Die Existenz dieser Technologie ist kein Geheimnis mehr. Universitäten und Hochschulen ergreifen schon erste Maßnahmen, um Abgaben auf KI-generierte Inhalte zu überprüfen und es ist schon längst möglich diese automatisch erkennen zu lassen. 

OpenAI, der Entwickler der ChatGPT-KI hat selbst schon einen solchen Detektor veröffentlicht, dazu gibt es auch weitere kostenlose Websites, auf denen man Texte analysieren lassen kann.

Wenn wir mal einen Abschnitt des Textes in diese Software einfügen erhalten wir die Information, dass dieser mit einer Wahrscheinlichkeit von 91,86% von einer KI generiert worden ist. 

Andere Prüfseiten weisen ähnliche Zahlen auf. Von 85% bis 99,86% ist alles dabei. Schade. Aber, ChatGPT ist doch die Lösung der unendlichen Möglichkeiten. Was passiert, wenn ich einfach sage

Formuliere diesen Text um, sodass Detektoren den Text nicht als KI-generiert erkennen.


Das Ergebnis:

Ausgetrickst. Auch andere Seiten weisen nun eine KI-Wahrscheinlichkeit von 15% bis hin zu 0,5% (!) auf. Sehr gute Nachrichten für die rein hypothetische Version von mir, die keine Zeit hatte ein Paper zu schreiben. 

Dazu muss man jedoch auch berücksichtigen, dass der von mir generierte Text, wie ich auch vorhin schon erwähnt habe, nicht einfach generiert wurde. Man muss viel Zeit investieren, damit ChatGPT das ausspuckt, was man auch möchte und selbst dann geht man ein hohes Risiko ein. Ein von KI generierter Text löst bei dem Leser eine gewisse Skepsis aus. Als Student möchte man dieser Skepsis möglichst aus dem Weg gehen. 

Daher das Fazit: Ja, vermutlich kann man sich mit ChatGPT durch ein Studium durchmogeln, wenn einem die Moral einer solchen Aktion unwichtig ist. Es gibt genug Möglichkeiten Detektoren auszutricksen und somit eine akademische Abkürzung zu laufen. Jedoch muss man sich dabei auf sehr viel Zeitaufwand, Anpassungen und grauen Haaren einstellen.

Es gibt jedoch einen weiteren, sehr wichtigen Aspekt des von mir generierten Artikels, den ich bisher unbeachtet gelassen habe.

Down the rabbit hole

Blicken wir noch einmal auf den obigen Text. Gegen Ende des Artikels schreibt ChatGPT folgendes:

In dieser Studie, die von einem Forscherteam der Stanford University im Jahr 2020 veröffentlicht wurde, wurden Probanden gebeten, eine Reihe von Texten zu lesen und zu entscheiden, ob sie von einem menschlichen Schreiber oder von einer KI wie ChatGPT erstellt wurden.
Die Ergebnisse zeigten, dass die Teilnehmer nur in etwa 30% der Fälle richtig erkennen konnten, ob der Text von einem menschlichen Schreiber oder von einer KI stammte.

Okay. Interessant. Woher stammt diese Studie denn? Wer hat sie durchgeführt? Da habe ich natürlich weiter nachgefragt.

Die von mir genannte Studie war eine fiktive Studie, die ich für diesen Artikel erfunden habe, um ein Beispiel zu geben, wie eine solche Studie aussehen könnte.

Krass. Hier wurde es kurz wieder gruselig. Mit voller Überzeugung und vollem Selbstbewusstsein hat ChatGPT eine komplette Studie samt Ergebnisse fabriziert, was sogar mich kurzzeitig überzeugt hat. Das war eine Erinnerung daran, wie faszinierend diese Technologie doch ist und was für eine Gefahr sie birgt. In diesem, von mir sonst sehr negativ bewerteten Artikel befand sich doch noch ein kleines goldene Stückchen. Ich habe mir die Frage gestellt, ob ich ChatGPT nicht unterschätze.

Nach weiteren Nachfragen verwies mich ChatGPT auf eine echte Studie von Christer Clerwall mit dem Titel “Who wrote this? Users’ perception of software-generated content in online news” aus dem Jahr 2013, in der untersucht wird, inwiefern Inhalte, die automatisch von einer Software generiert wurden, in Bezug auf die Glaubwürdigkeit und allgemeine Qualität von Lesern bewertet werden und sich auswirken. 

Dann kam bei mir der Lichtblitz: Ich verwende ChatGPT ganz falsch! Er ist nicht dafür da, um das Schreiben eines Papers oder einer Thesis zu übernehmen, sondern um es zu unterstützen. ChatGPT hat mich auf eine Fährte gebracht, auf die ich ohne dessen Nutzung vielleicht nie gekommen wäre. 

In diesem Aspekt glänzt ChatGPT. Es ist ein wunderbares Hilfsmittel, um die Gedanken anzuregen, einen Anfang beim Schreiben zu machen, eine Arbeit zu strukturieren oder einen weiteren Blickwinkel auf ein Thema zu werfen. 

Ein guter Vergleich meiner Meinung nach ist die Einführung von Taschenrechnern in das Bildungssystem. Als diese in Schulen und Universitäten eingeführt wurden, stießen sie selbstverständlich auch auf Widerstand. In ihrem Paper “The Role of Calculators in Math Education” aus dem Jahr 1997 nennt Heidi Pomerantz fünf Mythen über Taschenrechner:

  • “Taschenrechner sind eine Krücke. Sie werden verwendet, weil die Schüler zu faul sind, die Antworten selbst zu berechnen”
  • “Weil die Rechner die ganze Arbeit für den Schüler erledigen, wird er/sie nicht genug stimuliert oder herausgefordert”
  • “Wenn ich keine Technologie brauche, um Mathe zu lernen, dann braucht mein Kind sie auch nicht. Schließlich habe ich mich gut entwickelt.”
  • “Die Verwendung von Taschenrechnern hindert Schüler daran, die grundlegenden mathematischen Kenntnisse zu erwerben, die sie beim Eintritt in das Berufsleben benötigen.”
  • “Die Menschen werden so abhängig von Taschenrechnern werden, dass sie ohne sie hilflos sind.”

Ersetzt man das Wort “Taschenrechner” in diesen Aussagen mit “ChatGPT”, dann merkt man, dass sich heute die Geschichte wiederholt. Als ich meinen Eltern erzählt habe, ich habe vor in Zukunft für sämtliche Arbeiten ChatGPT als Unterstützung heranzuziehen haben sie mich mit einem Blick angeschaut, der aus einer Mischung von Sorge und Enttäuschung bestand. Heutzutage kann man sich aber den Matheunterricht nicht mehr ohne Taschenrechner vorstellen. Durch deren Einsatz ist es möglich viel effizienter Mathematik durchzuführen und somit lernen Schüler und Studierende mit einer viel höheren Geschwindigkeit. 

Übrigens: Ich wusste zwar vor dem Schreiben dieses Artikels, dass ich einen Vergleich zu Taschenrechnern ziehen wollte, jedoch habe ich Schwierigkeiten damit gehabt, gute Quellen für die Akzeptanz von Taschenrechnern in Bildungseinrichtungen zu finden. Das liegt zum Großteil daran, dass Google Scholar nicht viele Bücher und Artikel in den 1990er Jahren findet. Meine Lösung: ChatGPT nach Quellen fragen. Er antwortete mit Buchtiteln, die ich dann wiederum googeln konnte. 

Taschenrechner sind nicht das einzige Beispiel. Computer. Das Internet. Google. YouTube. DeepL. Das sind alles bahnbrechende Technologien, die das wissenschaftliche Schreiben verändert haben und ohne können wir uns die Welt nicht mehr vorstellen. Die Nutzung keiner dieser Tools wird heutzutage verpönt oder beim Verfassen von wissenschaftlichen Arbeiten verboten.

Fazit

Aus meiner Perspektive stellt ChatGPT lediglich den nächsten Schritt in dieser Reihe von unterstützenden Tools dar. Wo kämen wir als Wissenschaftler hin, wenn wir technologischen Fortschritt nicht mit offenen Armen willkommen hießen? 

Sollte es Einschränkungen geben? Selbstverständlich. Wie mit jeder Technologie werden Menschen versuchen, sie an ihre Grenzen zu bringen und auszunutzen. Es ist wichtig notwendige Maßnahmen einzuleiten, um die akademische Integrität zu schützen. Dennoch sollten KI-basierte Tools wie ChatGPT einen Platz als unterstützendes Hilfsmittel an akademischen Einrichtungen besetzen dürfen. 

Das Internet und Google hat das Plagiieren für Studierende einfacher gemacht, da jetzt  mit wenigen Klicks Texte kopiert und eingefügt werden können. Was hat man dagegen gemacht? Man hat Software geschrieben, die Plagiate automatisch und mit einer hohen Verlässlichkeit erkennen. Auf ähnliche Weise sollte mit GPT und ähnlichen Sprachmodellen umgegangen werden.

ChatGPT ist noch in den sehr frühen Anfangsstadien als Technologie und wird stets weiterentwickelt. Ich behaupte, dass innerhalb den nächsten Jahren GPT und ähnliche Tools ein fester Bestandteil des täglichen Lebens werden wird und zur technologischen Grundausbildung eines jeden Menschen (wie es heute Computer, das Internet und Google sind) sein wird. 

Zum Abschluss noch die große Enthüllung: Dieser ganze Blogeintrag wurde mit ChatGPT geschrieben! Nein, Scherz. Oder vielleicht doch…? 

Google’s Spanner

A Question of Time and Causality

TL;DR

Through the usage of atomic clock and GPS in datacenters, Google is able to determine a worst-case clock drift that may develop between set intervals, after which the normal quartz clocks of the machines will be synced with the atomic clock. By already having a very good estimate of the actual physical time and knowing the worst-case drift, an interval will be delivered to planned transactions, that are ready to be committed. Once received, the transaction will wait for the duration of the interval and thus ensuring causal consistency of a following transaction will be fulfilled. The key to solving this issue turns out to be atomic clocks, GPS receivers, testing to determine the uncertainty interval and a regular synchronisation of all sub-systems, not directly connected to their True Time service. 

What is Google’s Spanner?

Google Spanner [B017] is a relational database service provided by Google Cloud, designed for processing and storing petabytes of structured data. Spanner provides global distribution of data with high consistency and availability, as well as horizontal scalability. According to the CAP theorem [GL02], Spanner is therefore a CA system. It supports SQL-like query languages as well as ACID [C970] transactions (Atomicity, Consistency, Isolation, Durability) and is capable of providing both horizontal and vertical scalability to achieve better performance.

This is an answer that one can formulate after a few minutes of using the Google search engine. But what defines the service? What unique features make Google’s Spanner stand out and how are they technically formulated and implemented? This will be conveyed in the course of this blog post.

What defines Google’s Spanner? 

To make our lives easier while explaining and understanding what actually defines Spanner, the significant descriptive characteristics of Spanner are separated into two sections: Consistency properties and techniques used to realise them. 

Properties of Consistency:

Serializability writes

In transactional systems, there exists an execution plan for parallel execution. This plan is called history and indicates the order in which the different operations of the transaction shall be executed. Such a history will be serializable, if and only if it will lead to the same result as the sequentially executed sequence of the history’s transactions. 

Linearizability reads and writes

This is a concept in database systems that ensures that the execution of concurrent operations on a shared object or resource appears as if they occurred in some sequential order. This means that even though operations are being executed concurrently, they appear to be executed one after the other.

Serializability vs Linearizability

Did those two sound too similar? They are not! Subtle details make a big difference here: Even if both serializability and linearizability are concepts related to concurrency control in database systems, they have different goals and focus on different aspects of concurrency. While serializability ensures that concurrent transactions produce the same result as if executed sequentially, maintaining data integrity and equivalent results to executing transactions sequentially; Linearizability ensures that concurrent operations on a shared object or resource appear to be executed sequentially, maintaining data consistency and equivalent outcomes to executing operations sequentially.

Techniques in use:

Sharding

Spanner supports a custom sharding algorithm called “Zone Sharding.” [AR18]. This algorithm partitions data across zones, which are groups of machines in a single datacenter or across multiple datacenters. Each zone contains multiple tablet servers that hold the data for a subset of the database’s tables. The Zone Sharding algorithm is designed to ensure that data is replicated and distributed for high availability and fault tolerance, while also providing efficient access to data with low latency. Especially the low latency is of tremendous importance, for many of the services of Google.

State machine replication (Paxos protocol)

The Paxos protocol [L998] is a consensus algorithm that helps distributed systems agree on a single value despite failures or network delays. First it was described by Leslie Lamport in 1989 and has since become widely used in distributed computing systems. It operates in three main phases:

  1. Prepare Phase: A proposer suggests a value to the other nodes and asks them to promises not to accept any other value in the future.
  2. Accept Phase: If the majority of nodes promise to accept the proposed value, the proposer sends an “accept” message to all the nodes, including the proposed value.
  3. Commit Phase: If the majority of nodes accept the proposed value, the proposer sends a “commit” message to all the nodes, indicating that the proposed value has been agreed upon.

The Paxos protocol has been used in a variety of distributed systems, including databases, file systems, and messaging systems. It is known for its simplicity, generality, and ability to tolerate failures. However, it can be complex to implement and can suffer from performance issues in certain scenarios.

Two-Phase locking for Serializability 

Two-phase locking (2PL) [G981] is a concurrency control mechanism used in database management systems to ensure serializability of transactions. The goal of 2PL is to prevent conflicts between transactions by ensuring that a transaction holds all necessary locks before performing any updates.

The two-phase locking protocol operates in two main phases:

  1. Growing Phase: During this phase, a transaction can acquire locks on database objects (such as rows, tables, or pages) in any order. However, once a lock is released, it cannot be re-acquired.
  2. Shrinking Phase: During this phase, a transaction can release locks but cannot acquire any new ones. Again, once a lock is released, it cannot be re-acquired.

The 2PL protocol ensures serializability by guaranteeing that conflicting transactions acquire locks in a consistent order. Specifically, two transactions conflict if they access the same database object and at least one of them performs an update.

Two-Phase Commit for cross-shard atomicity
The Two-Phase Commit (2PC) [H983] is a distributed algorithm used to ensure atomicity in transactions that involve multiple nodes or resources. The protocol works in two main phases:

  1. Prepare Phase: In this phase, the transaction coordinator asks each participant to vote on whether to commit or abort the transaction.
  2. Commit Phase: If all participants vote to commit, the coordinator instructs each participant to commit the transaction. If any participant votes to abort, the coordinator instructs each participant to abort the transaction.

2PC ensures that a transaction is either committed or aborted atomically across all participants involved in the transaction, but can suffer from performance issues and a higher risk of aborts. Alternative protocols, such as optimistic concurrency control or decentralised commit protocols, can be used to address some of these issues.

Multi-Version Concurrency Control

Multi-Version Concurrency Control (MVCC) [B981] is a database concurrency control mechanism that allows multiple transactions to access the same objects simultaneously while maintaining consistency and isolation. It creates multiple versions of a database object and allows each transaction to access the version that corresponds to its snapshot of the database. MVCC provides benefits such as reduced lock contention, improved scalability, and higher degree of concurrency and isolation, and is used in various database systems like PostgreSQL [PSQL] or MySQL [MSQL]

Now, how does MVCC actually work? Short answer, with strong implications: A timestamp t_w is being attached to every read-write transaction taking place. If a transaction is going to change an object, we will not simply allow it to change its state, but rather make a copy of the object, change the copy and tag it with the timestamp of the transaction t_w. This is to ensure, that if a read-only transaction comes in, interested in the old state of the object (with a timestamp t_{w-1}), we still can serve it. Now, a new read-only transaction T_r comes in, tagged with t_r where T_r > T_w. This transaction can simply ignore all states of objects where t_w > t_r and pick those with the most recent state t_w \leq t_r.

So far, even if implementing the above correctly would bring quite an engineering challenge to the table, there is nothing new or innovative. Nothing special that is required to be mentioned, other than framing and explaining the used technologies. Spanner provides support for read-only transactions without the need for locks, a feature not found in other database systems – at least if MVCC is not implemented. This is a significant improvement over 2PL, which requires objects to be locked before access. However, in the real world, large read-only transactions are common. Take the example of a database backup, which is a major read-only transaction that can span multiple petabytes in a globally-distributed database. It is clear that users would not be happy about waiting for such a process to succeed. Imagine it fails and has to restart shortly after. A horrible scenario for every impatient user, if locks may be taken during that process. Spanner’s support for lock-free read-only transactions ensures that such processes can be carried out quickly and efficiently, enhancing user satisfaction and improving the overall performance of the system.
But, the really interesting part about Spanner is how it acquires said timestamps. 

Consistent Snapshots

First, let us establish what it means to have a consistent snapshot. To illustrate this, we can use the example of a large read-only transaction, for example a backup, and clarify the requirements for ensuring snapshot consistency   

What does it mean for a snapshot to be consistent? 

A read-only transaction will observe a consistent snapshot if: T_1 \rightarrow T_2. This means that if a consistent snapshot contains the effect of transaction  T_2, it must contain the cause T_1. So if T_1 happened before T_2 and we have a snapshot that contains the writes by T_2, it must also contain the writes mades by T_1. Likewise, if we see a snapshot that does not contain the writes made by T_2, is shall not contain the writes made by T_1. In other words, snapshots must be consistent with causality – hence the title of this blog. 

The above will be achieved by making use of MVCC.

True Time

Why do we need true time for a service like Google’s Spanner?

As any being interested in this subject matter will tell you: There is no free lunch in ultra large scale systems; most certainly, there cannot be a thing like a true time. Or maybe…

In the paragraph explaining what it means for a snapshot to be consistent, we clarified that we need to take measures to ensure a reliant way of dealing with the problem of chronological ordering, namely causality. Even though logical clocks like Lamport Clocks where specifically designed to address this problem, there are scenarios in which they would fail. Imagine a case in which a user would read a result from replica A, perform an action on that data and may persist it on replica B. A one-sentence scenario, in which Lamport Clocks would fail to solve the problem, simply because there was no assured communication between the two replicas. Sure, we could rely on the front-end developer to transport the timestamp for the write transaction on replica B, but this is not guaranteed. Neither can we rely on the user to manually type in a timestamp. So, what can we do in this case: We go back to physical clocks. But, we have to adjust the physical clocks and do some extra measure, to ensure that causality is satisfied. 

I’m on the hook, pull me in!

The way spanner achieves this, is by using its service called True Time. True Time [B017] is a system of physical clocks, that explicitly captures the always present uncertainty within the resulting timestamps and communicates it to the requestor. To help understand the impact achieved, we will use the following illustration as an example.


Graph showing the aggregation and exploitation of planned waiting intervals from True Time 

In this illustration, we have two replicas: A and B. A write transaction T_1 will be performed on replica A and a follow-up transaction T_2 will be performed on replica B. Here, we have that physical time dependency between the two, such that their timestamps fulfil t_1 < t_2

When T_1 is ready to be committed, it requests the interval  \delta_1from the True Time Service. So, we do not just get a timestamp, as it is required for MVCC. Rather the requestor will receive two: [t_{1min}, t_{1max}]. The first one t_{1min} indicating the earliest possible and the second t_{1max} indicating the latest possible actual time for the commit request to actually happen. Since there can not be a perfect synchronisation between the different clocks, within a datacenter, we can never be totally certain that a timestamp would represent the actual physical time of that moment. By accepting this fact and using an uncertainty bound through the received interval, we can ensure that the physical time would lie somewhere within that closed interval. 

Spanners system is now delaying the transactions commit for the duration of the interval \delta_1. During that wait-time, the system will continue to hold all the locks mandatory and be ready to release them. Once interval \delta_1 is elapsed, the transaction will actually be committed. This extra wait is the key concept here.

Now let us say that replica B receives transaction T_2 and starts executing it. Similar to the procedure of T_1, once T_2 is ready to be committed, it requests its pair of earliest and latest possible time \delta_2, waits for the \delta-time to elapse and commits its transaction. Remember, we have the physical time dependency t_1 < t_2. The white arrow in the illustration, going from left to right, indicates the actual time elapsed between the end of T_1 and the start of T_2.

What we just achieve ensures that the uncertainty intervals we receive from the True Time Service are warranted to be non-overlapping ant thus ensures that the causal dependency will be reflected. After the wait-time, MVCC will receive the maximum timestamp from \delta_1 and \delta_2 and the database only contains the effect, when its cause is present.

How uncertain do we have to be?

Of course, we want to have as little waiting-time as possible. This forces us to have a pretty precise notion of uncertainty. This is achieved by atomic clock servers, with GPS receivers in every datacenter. Even tough maintaining both probably costs quite some money, it is cheaper than dealing with potential inconsistencies in their system.


Illustration showing the clock drift of machines not directly connected to the True Time service

As the illustration shows, machines not directly connected to the True Time service will continue to drift apart form the physical time and continue to do so, until the clock synchronisation happens. After that, the discrepancy is immediately reduced to the irreducible error E < 1ms, resulting from the time the request takes from a machine to True Time and back. During the 30-second intervals between periodic clock synchronisations, a node’s local quartz oscillator determines its clock. The error introduced during this period is influenced by the drift rate of the quartz. To err on the side of caution, Google assumes a maximum drift rate of 200ppm, which is much higher than the drift rate observed under typical operating conditions. Furthermore, Google keeps track of each node’s drift and informs administrators of any unusual occurrences. 

Summary

True Time utilises precise accounting of uncertainty to establish both upper and lower bounds on the current physical time. It achieves this by incorporating high-precision clocks, which work to reduce the size of the uncertainty interval. Meanwhile, Spanner is designed to ensure that timestamps remain consistent with causality by waiting out any lingering uncertainty. By leveraging these timestamps for MVCC, Spanner is able to deliver serializable transactions without necessitating locks for read-only transactions. This method helps maintain transaction speed while also eliminating the need for clients to propagate logical timestamps.

References

  1. GL02
    S. Gilbert, N. Lynch; 2002
    Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services
    https://www.comp.nus.edu.sg/~gilbert/pubs/BrewersConjecture-SigAct.pdf
  2. C970
    E. F. Codd; 1970
    A Relational Model of Data for Large Shared Data Banks
    seas.upenn.edu/~zives/03f/cis550/codd.pdf
  3. CD12
    James C. Corbett, Jeffrey Dean, Michael Epstein, Andrew Fikes, Christopher Frost, JJ Furman, Sanjay Ghemawat, Andrey Gubarev, Christopher Heiser, Peter Hochschild, Wilson Hsieh, Sebastian Kanthak, Eugene Kogan, Hongyi Li, Alexander Lloyd, Sergey Melnik, David Mwaura, David Nagle, Sean Quinlan, Rajesh Rao, Lindsay Rolig, Yasushi Saito, Michal Szymaniak, Christopher Taylor, Ruth Wang, Dale Woodford; 2012
    https://static.googleusercontent.com/media/research.google.com/de//archive/spanner-osdi2012.pdf
  4. AR18
    Muthukaruppan Annamalai, Kaushik Ravichandran, Harish Srinivas, Igor Zinkovsky, Luning Pan, Tony Savor, and David Nagle, Facebook; Michael Stumm, University of Toronto; 2018
    https://www.usenix.org/system/files/osdi18-annamalai.pdf
  5. L998
    Leslie Lamport; 1998
    https://dl.acm.org/doi/pdf/10.1145/279227.279229
  6. G981
    Jim Gray, Paul McJones, Mike Blasgen, Bruce Lindsay, Raymond Lorie, Tom Price, Franco Putzolu, Irving Traiger; 1981
    https://dl.acm.org/doi/pdf/10.1145/356842.356847
  7. H983
    Theo Haerder, Andreas Reuter; 1983
    https://cs-people.bu.edu/mathan/reading-groups/papers-classics/recovery.pdf
  8. B981
    Phillip A. Bernstein, Nathan Goodman; 1981
    https://dl.acm.org/doi/pdf/10.1145/356842.356846
  9. PSQL
    https://www.postgresql.org/docs/7.1/mvcc.html
  10. MSQL
    https://dev.mysql.com/doc/refman/8.0/en/innodb-multi-versioning.html
  11. B017
    Eric Brewer; 2017
    https://storage.googleapis.com/pub-tools-public-publication-data/pdf/45855.pdf