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)
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…?
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:
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.
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.
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:
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.
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:
Prepare Phase: In this phase, the transaction coordinator asks each participant to vote on whether to commit or abort the transaction.
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 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 . This is to ensure, that if a read-only transaction comes in, interested in the old state of the object (with a timestamp ), we still can serve it. Now, a new read-only transaction comes in, tagged with where . This transaction can simply ignore all states of objects where and pick those with the most recent state .
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: . This means that if a consistent snapshot contains the effect of transaction , it must contain the cause . So if happened before and we have a snapshot that contains the writes by , it must also contain the writes mades by . Likewise, if we see a snapshot that does not contain the writes made by , is shall not contain the writes made by . 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 , perform an action on that data and may persist it on replica . 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 , 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: and . A write transaction will be performed on replica and a follow-up transaction will be performed on replica . Here, we have that physical time dependency between the two, such that their timestamps fulfil .
When is ready to be committed, it requests the interval from the True Time Service. So, we do not just get a timestamp, as it is required for MVCC. Rather the requestor will receive two: . The first one indicating the earliest possible and the second 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 . During that wait-time, the system will continue to hold all the locks mandatory and be ready to release them. Once interval is elapsed, the transaction will actually be committed. This extra wait is the key concept here.
Now let us say that replica receives transaction and starts executing it. Similar to the procedure of , once is ready to be committed, it requests its pair of earliest and latest possible time , waits for the -time to elapse and commits its transaction. Remember, we have the physical time dependency . The white arrow in the illustration, going from left to right, indicates the actual time elapsed between the end of and the start of .
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 and 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 , 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.
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
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
Fog computing offers a compromise between cloud and edge computing for real-time, scalable data analysis. Ideal for regional applications and IoT. However, authentication and privacy issues must be addressed.
Most Cloud Developers seem to agree that the best way to gain knowledge and optimize processes is to collect and store data in the cloud and to analyze the collected data after the fact or in almost-real-time. In a world where the number of users and devices is already almost uncountable, the name Big Data becomes more and more a euphemism for the vast landscape we call the internet. On the other hand, we can also execute data analysis tools on the devices locally in a network using edge computing. This allows developers to work on the data of single devices or single users-grade networks.
Apparently, we can either have all the data or only a little data, but either way is difficult to handle efficiently. This is where fog computing comes into play.
Architecture placing nodes in the fog between the data centers of the cloud and devices at the edge; from “Moving the Cloud to the Edge”; PubNub; 06.06.2017
What is the Fog?
When it comes to internet services like Internet of Things, web services, Infrastructure-as-a-service, or networking solutions, the limiting factors are latency, networking resources, data storage, and computing power. While most of these problems can be solved through more or faster hardware, there are problems that need analytical and clever solutions. More parallelization, e.g. load balancing multiple servers, and chaining of microservices, e.g. message queues, do not solve the logical problems of conflicting data or processes, e.g. database locking. It is simply physically impossible to manage all requests all the time.
In cloud computing, resources are distributed over the world and information is shared across that ominous, obscure cloud. This makes it possible to handle requests on devices that have availability, in order to handle requests with medium latency and high cumulative computing power. This makes it easy to scale the infrastructure, but makes the analysis of data very time and resource consuming and necessitates to store data permanently from time to time.
Whereas cloud computing handles all requests on a “synchronized” level, where we don’t know and don’t care about the location and type of device that handles a request, edge computing happens at the “edge to the internet”. That means that edge devices or edge networks process data either incoming or outgoing at or close to the user. This approach is often also referred to as “serverless” because no server is needed to handle any requests other than offering the code to create the interface (HTML, CSS etc.) and the code to be executed on edge devices.
With edge computing it is easy to pinpoint the physical and logical “location” and state and type of requests, data and devices. It is possible to handle those requests with extremely low latency, both network and compute, and a low need for computing power and resources. Although the need is low, scalability and access to data is very limited. This means that the calculations and processes done in edge computing are fast, but not always very rich or productive.
How does Fog Computing improve system architecture?
Fog computing places nodes between the edge, where the user with his private devices and networks resides, and the cloud, where nobody can identify any instance for sure, unless one asks the cloud providers themselves. The cloud stores and manages data in a somewhat manageable number of datacenters, and the edge completes processes on billions of devices. The fog on the other hand, consists of servers with numbers in the high thousands or few millions worldwide. This infrastructure allows developers and operators to make a compromise between cloud and edge computing. These servers are physically close to users’ networks.
Difference between Cloud, Fog and Edge Computing in IoT; Digiteum; 04.05.2022
The compromise has the following characteristics:
The shorter physical distance also implies a low network latency and low need for computing resources due to limited data amounts.
Data can be analyzed locally and in real time.
Nodes can be scaled flexibly in response to growing numbers of users in small networks and regions with a small priority of single nodes.
Nodes in the fog act as handlers between edge networks and the cloud. Urgent requests are forwarded to the cloud, and requests that can be processed locally are.
Connecting edge devices and the cloud through an independent actor allows for more and better control over the incoming and outgoing data. Information can be separated regionally and the usage of the cloud can be controlled in the fog. Forwarding requests is a concern because both the storage of sensitive information and the limitation of needed computing resources is detrimental to the overall quality of the cloud.
Data security and media rights management can be provided through those nodes on a regional basis. Sensitive information is stored locally on fog level and never forwarded to the cloud. The urgency of a request has to be determined on fog nodes. Under normal circumstances, networking bandwidth and computing resources are spared in the cloud by storing data locally whenever necessary and storing it in the cloud when the localization of data is no concern.
Smart Cities: An example for Fog Computing applications
One example for the use of fog nodes are smart cities, meaning independent traffic systems interacting to reduce traffic jams and incidents. Cars, traffic signals and road barriers are installed with sensors to collect data and send that data to a fog node. It is not necessary for a traffic light in New York to gain information about a car in Los Angeles, but the general gist of traffic optimization is the same. Fog computing allows real-time data analysis that enables traffic signals to rapidly change according to the traffic situation.
AI illustration of connected smart cities, Stabillity AI, 22.02.2023
To this end, it is more useful to connect every device in the city to a fog node that is only responsible for that city. That way, millions of fog nods are placed to control traffic in a city or wider city area with its own scaled infrastructure. For example, New York City will most likely need more resources per square mile than Austin, Texas.
This separation of fog nodes leads to a separation of private data, like location data, e.g. home addresses, from the cloud service providers, and between each fog node. Only essential data is forwarded to the cloud and used to generate predictions, update traffic models, and generate newer algorithms and usage analysis.
With this method, degrading performance due to high demand only affects one city. High loads can be forwarded to the cloud, where requests are distributed globally to free resources. This way, the averaged load of the cloud can be used to cushion the impact of high local demand.
Obstacles for the implementation of Fog Computing
Authentication and trust issues: Just like cloud service providers, fog service providers can be different parties with varying trust levels. One provider can pose as a trustworthy entity and manipulate the integrity of the fog for its connected end-users.
Privacy: Decentralizing data security and media rights management to the fog and outsourcing the responsibility to a third party instead of the cloud or edge devices endangers user’s privacy due to the number of fog nodes.
Security: Due to the number of devices connected to fog nodes, it is difficult to ensure the security of all gateways and the protection of personal information.
Node placement: The physical and logical location of fog nodes should be optimized to reach the maximum service quality. The data for the right placement has to be analyzed and chosen carefully.
Conclusion
Fog Computing places nodes logically between edge networks and devices and the cloud.
It provides 4 main advantages:
Network latency: Lower distance to the end-user and smaller data consumption leads to lower network delay and lower computing time.
Data analysis: Low data amounts allow for real-time data analysis and the limitation of cloud usage.
Security: Configuring fog nodes to the data protection needs ensures that cloud service providers only gain access to as much data as needed.
Cost reduction: The regional placement and subdivision can minimize the hardware and energy cost for the fog service providers.
Site Reliability Engineering (SRE) is an approach to designing, building, and running distributed systems that aim to improve their reliability, scalability, and performance. Monitoring is a key component of SRE, as it allows for the early detection of issues, the identification of potential bottlenecks and for maintaining the performance, reliability, and security of systems and applications.
This blog post provides an overview of the current state of the art in monitoring distributed systems in the context of SRE, including the various approaches and techniques that have been developed to address this challenge.
Finally, this blog post discusses the various challenges that arise in monitoring distributed systems and gives a conclusion.
In order to serve your app to your users, you need a server on which you can run your application. Traditionally, you had the option to either buy and run the server yourself in your own location, this is called on-premise hosting, or you could rent server resources from a cloud service provider (CSP) and host your application out of their data center [1]. Depending on the CSP you choose they might have several data center locations to choose from, in the case of Amazon Web Services (AWS) this could for example be us-east-2, which is in Ohio in the United States [2]. When accessing your web application, users all over the world would need to connect to your server in this one location. Due to the large distance to your server, users on different continents like Europe or Asia would experience high latency when accessing your app, resulting in a bad user experience [1].
To fix this issue you could consider scaling your application by either spending a lot of money on renting more servers around the world, or you could use a Content Delivery Network (CDN) like Cloudflare to cache static content like HTML and CSS files on servers located closer to the user [1 ]. With the latter approach, the Website would appear to load quicker for the user because they get the cached files from the CDN directly rather than from the far away data center [3]. This is great for static files, however, anytime your web application has to process data from the user, this needs to happen on your primary server, as the CDN traditionally does not provide compute resources [1 ][4].
Enter edge computing.
Unlike the conventional data center approach, where data is sent to a central location for processing, edge computing aims to reduce latency and increase bandwidth efficiency by processing data on devices at the “edge” of the network. This results in faster response times and better real-time processing capabilities [5]. You could compare edge computing to a CDN for executable programs / non-static applications [1].
So what is the edge? [insert U2 joke here]…
Unfortunately, there is no clear definition of what exactly the edge of a network is — and so-called “edge nodes”, the devices running on the network edge, can take many forms, from small IoT-devices to larger computer systems in regional data centers [4][5].
Fig. 1: Comparison of central data center vs. edge node topology
In this specific context, where user-devices communicate over the internet with an application hosted in large data centers (i.e. “the cloud”), edge nodes would refer to servers in smaller, local data centers, like those run by CDNs. The important distinction here is that edge nodes are geographically closer to user’s devices than cloud servers [5].
The benefits of Edge Computing
The obvious main benefit of edge computing is the improvement in latency and response times as data processing can take place closer to the source of the data, i.e. the user [5]. For someone living in Stuttgart, Germany who wants to access a web service on an edge node in Frankfurt, Germany rather than in a data center in Ohio, USA this can make a difference of 300 ms round-trip time per request (70 ms vs. 370 ms) [6].
Another benefit is improved usage of network infrastructure. Because data processing is spread all over the world, so is the traffic your application generates. Processing at the edge of the network allows data to be filtered and pre-processed before being transmitted to a central data center, reducing the amount of data that needs to be transmitted over large distances. This can result in cost savings, depending on what your CSP charges for network traffic to and from your server. In a world that is becoming ever more data driven it is necessary to manage and process data efficiently [5].
It can also improve the reliability and availability of your web application. Hosting your app in one single data center means that, if there is for example a network outage at that location, your entire user base is affected by this disruption. Whereas if just one edge node experiences an outage only the part of your user base that is close to that edge node is affected. And because there is this redundancy the users might not even experience a complete outage but rather higher latencies as they are connected to a different edge node. Though admittedly, CSPs like AWS have multiple so-called availability zones per region in order to prevent such an outage based on a single point of failure [2]. In the same way, edge computing improves availability through higher resiliency against Denial-of-Service attacks. Attackers will have a much harder time targeting hundreds of instances of an application as opposed to one.
The pitfalls of Edge Computing
So far, we’ve learned that edge nodes are basically just more data centers that are positioned closer to users than others. So CSPs just need to build more data centers in more locations, where is the catch?
The answer lies in the difference in compute, network and storage resources of the data centers. AWS has fewer full-blown data centers than Cloudflare has edge nodes but they are far more powerful and can handle larger workloads. Because edge nodes have limited resources they need to be used more efficiently. The solution edge computing platforms have opted for is to only offer running serverless applications and workloads on their systems. This limits your use cases for edge computing as you won’t be able to host any form of application with a long runtime [1]. One example would be cloud gaming, a use case which would really benefit from low latencies. Unfortunately games are played over an extended period of time and they are fairly hardware intensive making them unfeasible for edge computing.
Furthermore, in some cases, edge computing is not always faster than standard cloud computing. To illustrate this, let’s compare two scenarios, where your application needs to access a central database and perform multiple calls to complete a specific function. The user of your application is far away from that data center and experiences a round-trip latency of x milliseconds [1]:
Fig. 2: Visualization of the 2 different scenarios
In scenario one, your application is run in one data center, the same data center your DB is hosted in. When the user wants to complete the specific function, they call an endpoint on your application. It takes half of the round-trip time (½ x) for that call to reach the data center where the app runs. The app connects to the database multiple times, which doesn’t take long as it’s hosted in the same data center. Afterwards the response is sent back to the user, taking another half of the round-trip time (½ x). The overall latency was x, or one round-trip latency, plus some negligible latency for every DB access.
In the second scenario the application is run on the edge but the database is still in that far away data center. Now when the user calls an endpoint on the application, they experience negligible latency when making the call but when the application accesses the database it experiences the round-trip time x for every one of the multiple accesses. The resulting latency is the count of db calls per function times x plus the round-trip time from the user to their nearest edge node.
As a result, when you want to host an application on the edge you should make sure that the app was designed to be run this way, taking care that it doesn’t need to make multiple calls to a central resource to complete a task. Otherwise, and somewhat counter-intuitively, it might be a slower experience for the people far away from the central resource than if the app wasn’t hosted on the edge in the first place [1].
Another caveat is that the term “edge” is not really defined properly. Depending on the edge platform you choose, the edge nodes may be just as sporadically scattered as large CSP data centers. The edge computing service offered by Vercel heavily relies on AWS’s infrastructure, effectively making their edge as far away as the cloud [7].
A look at the industry
Let’s have a look at Cloudflare, a prominent example of what started as a simple CDN and internet security company that has since evolved into an edge computing platform. In 2017 the company introduced Cloudflare Workers, their serverless computing solution based on their content delivery network infrastructure [8]. Since then they have been building up their edge computing platform by introducing Workers KV, a simple key-value data store that can be accessed by the serverless workers, Queues a message queue system for Workers and D1 which is SQLite databases for Workers [9][10][11]. They also recently announced R2, a storage bucket service fully compatible with AWS’s S3 service API, that unlike S3 does not charge for egress traffic making it very competitive in terms of price-to-performance [12].
Cloudflare isn’t the only company expanding their business portfolio, other CDNs seem to have smelled the blood in the water. In 2022 Akamai, another leading CDN, acquired CSP Linode for $900 million dollars, with the goal of building out their own edge and cloud computing platform [13]. They now offer EdgeWorkers and EdgeKV a serverless compute platform and key-value store respectively [14]. The CDN Fastly also offers what they call Compute@Edge as a serverless compute platform based on their edge network [15].
Because of their main CDN business, these companies already have a lot of data centers around the world, which they can expand and invest in to provide these edge computing services.
And then there are the big CSPs like AWS, Google Cloud Project (GCP) and Microsoft Azure who haven’t been sleeping while the CDNs expanded their business. These Cloud Computing Platforms also offer edge computing services on their own edge network. Most offer serverless computing on their edge locations; some even offer large enough customers installation and maintenance of server hardware on their premises, effectively building a private edge node in the customer’s own location [16][17]. And their edge network isn’t necessarily any less dense than the CDN’s networks. In Germany AWS has edge data centers in 4 cities, which is just one less than Cloudflare’s 5 locations. In the US it’s 44 AWS locations versus 39 Cloudflare locations [18][19]. AWS’s edge network of over 400 cities total pales in comparison to Akamai’s network of over 1000 but trumps the network of Vercel’s 19 locations [18][20][7].
Use Cases
The question that now remains is: Who needs edge computing anyways?
The main target audience for edge platforms like Cloudflare or Vercel are web developers who use frameworks like Next.js, SvelteKit or React which are designed to run routes on serveless platforms [21]. While this use case doesn’t really require the lower latencies offered by edge computing, the overall user experience can definitely benefit from it.
Like briefly mentioned before, highly interactive use cases like cloud gaming or remote desktop workplaces would extremely benefit from the low latencies. When playing a fast paced game like a competitive shooter every millisecond makes a difference. However, these use cases require sustained high performance and are difficult to achieve on the serverless edge platforms.
You could also consider smart homes being a fitting use case that would benefit from edge computing. Though, ideally smart home devices shouldn’t need to communicate with any cloud at all, they should be able to process all data required to run the smart home locally in case of a network outage. Then again, because of the unclear definition of what counts as the edge, IoT-devices like sensors, cameras, etc. could be considered edge nodes – technically making what they do edge computing.
So as of today, it seems that the edge computing platforms the CDNs offer don’t really enable any new or groundbreaking use cases. The hybrid cloud approach provided by the likes of Google or AWS, where they install an edge node on the customers’ premises, allows for a little more flexibility as use cases are not limited to serverless applications. But the solution they are offering at this point is essentially just Hardware-as-a-Service.
However, just because there are no use cases that necessitate edge computing today, doesn’t mean the technology is pointless.
In the future smart cities could be powered by edge computing, with autonomous vehicles communicating with each other and traffic lights to create optimal traffic flow. Or artificial intelligence using real-time sensor data to answer questions with current information, like “How busy is the supermarket right now?”.
In conclusion …
Edge computing undoubtedly has benefits for cloud applications in terms of latency and efficiency but there are a lot of pitfalls developers need to be aware of, when deploying apps on the edge. The technology has the potential to be disruptive to the industry as even though it’s much more limited than standard cloud computing, it’s extremely good at one thing – the latency – and it’s a much cheaper solution for providers and customers alike. However, the ambiguity of the term “edge” and what it actually means, makes it, in my eyes, unclear whether people will adopt it because they truly understand the benefits of it or because it’s just another buzzword that sounds cool.
You all know racing games. From the realistic, simulated ones like Formula 1 or Forza Motorsport to the playful, arcade-heavy ones like Super Mario Kart or Need For Speed.
The range is large, but somehow pretty standard. So we want to take it a little crazier. After all, who says that it always has to be cars as vehicles? Why not a turbine? Or yes – directly a whole rocket engine? Yes! And the driver sits directly on the drive train! And players shoot each other down with hilarious and mean attacks and traps. Something like this:
I know it’s not strictly a racing game – more of a flying game, but from a technical point of view we have the same parameters per player such as the position or speed of the players and other objects on the track and the collisions of these objects with each other.
Ok, now that we have our crazy game idea, we also need to somehow ensure that our players can enjoy playing together on different devices.
But how are we gonna do this? What multiplayer architecture approaches are there? What are their pros and cons? What data do we need to exchange between players? And how do we trade different latencies to give every player a smooth, zero-latency gaming experience?
Exactly these questions are answered in this blog entry. Thus, this blog entry can be seen as the first starting point into the world of online multiplayer architecture.
Requirements
To narrow things down a bit, let’s first establish a few rules for our game:
Each race takes place on a closed race track / There is no open world
There are 10 different racetracks and 7 different vehicles.
A maximum of 10 players play together in a lobby or on a race track
The graphic representation takes place exclusively on the end device of the user
The gaming experience should take place in real time
Players are matched to a lobby
There is a global player ranking
Each player can accelerate, brake and steer
Each player can pick up items on the racetrack and use them to attack other players or place traps on the racetrack
Each player must be authenticated in order to play
The system should initially be able to trade around 250,000 users per hour and scale accordingly
The system should be operated as cheaply as possible; however, we also want to offer our players a smooth, fun and immersive gaming experience
As can be seen in the requirements, in this article we will focus exclusively on the pure racing game experience – for example driving, overtaking and collision between vehicles and objects. For the time being, we neglect the use of universally popular social functions such as managing friend lists or joining friend lobbies.
Architecture approaches
Now that we’ve defined some basic requirements, let’s first look at the most popular architectural paradigms that connect players around the world. Underlying these approaches is a common goal: to provide players with a synchronous, latency-free and fluid gaming experience in near real-time.
Hosted Peer-to-Peer (Hosted P2P)
In times when cloud solution is always touted as the all-purpose weapon, it is almost unbelievable that an old approach like peer-to-peer is still so widespread. But popular games like Demon’s Souls, Dark Souls, Bloodborne, GTA Online, Red Dead Online, Animal Crossing: New Horizons, Super Smash Bros. Ultimate or F1 2021 partly operate their online worlds via peer-to-peer networks 1.
The principle of a hosted P2P network seems simple at first: One player is the host of the game, i.e. the player’s computer acts as a “server”. The host inputs, as well as the inputs of the other players, arrive at the host. The current game events (state) are calculated and sent back to the players (Img.1).
So as a company, there is no need for a server at this point, so we gonna save these costs, which can be an enormous sum with a targeted utilization of 250,000 players. The scaling and the corresponding rush of incoming players can also be easily distributed among several host players. Unlike a dedicated server, thousands of games are not calculated on one machine, but on a selected player – the host – calculates exactly one game and transmits the results to the other players (in our example max. 10 players in a lobby, so 25,000 host players must be found with a planned load of 250,000 players).
Conversely, this also means that the other players in a lobby are dependent on the host in many ways. The host migration – which player is the best host? – is crucial. Because if the host has a miserable download or upload speed, this creates high latencies for the other players – delays and a bad gaming experience for these players are the consequences. One solution would be that the host is the player who has the lowest average ping time among all other participating players. Or only players who are geographically close to each other are assigned to a lobby. But what do we do if a player from Tokyo wants to play with a player in Berlin? In addition, the host user must provide enough free hardware resources such as CPU and RAM in order to be able to calculate the entire gameplay and display his own gameplay. But what if that’s not the case? Likewise, the host receives the results on his PC first – simply because of the short geographic and physical transmission path and the resulting lack of ping – so that this can also lead to asynchronous gameplay. This must also be prevented so that all players get a synchronous, simultaneous gaming experience.
Another challenge in a hosted P2P network is host cheating or host hacking. How can we trust the host and make sure they aren’t cheating and manipulating gameplay? Because all player events are calculated on his PC. To solve this requires a solution such as a separate authoritative server 2 .
In summary, there are the following reasons for or against a hosted peer-to-peer approach:
Advantages
Disadvantages
No / Low costs
Host performance affects other players’ gaming experience
Simple scaling through the computing power of the users
Host cheating / hacking
Load balancing across multiple players (not 1000 games on one server)
Host migration
Global distribution
In particular, the problem of the trustworthiness of the host poses a major challenge for the P2P approach. Another popular approach is the “dedicated server” architecture. This approach solves the trust problem through a central authority. Let’s take a closer look.
Dedicated Server
With a “dedicated server” architecture, all game events – the inputs of the players – are sent to a central server. The server calculates the resulting state for each player and sends this state back to the players (Img. 2). The server is neither part of the game nor a separate player as in the hosted P2P approach. A dedicated server is only responsible for calculating the gameplay. Other social functions such as matchmaking are usually outsourced to other servers, since a dedicated server and all its resources are only provided for this one task – calculating the current state. Accordingly, dedicated servers usually do not have a GPU, since a graphical game display is not necessary. Instead, they have a high number of CPUs and RAM, since game lobbies and their state have to be kept and calculated during the game. A large number of currently very popular multiplayer games such as Fortnite, Minecraft, Apex Legends, Rocket League, Among Us, Rainbow Six Seige, Ghost of Tsushima Legends or Roblox use this principle 1.
Img. 2: Dedicated server architecture
Compared to the hosted P2P approach, there are definitely costs associated with operating dedicated servers. Depending on the infrastructure and scaling pattern, this can result in different costs 3. Furthermore, scaling can also be a challenge if the servers are operated “on-premise”, because there must be enough servers available, they must be maintained and operated. And in addition, these servers are sometimes “dead capital” if they are not fully utilized.
On the other hand, there are advantages that eliminate some of the disadvantages of the hosted P2P approach: When operating a dedicated server, you can count on consistently high performance, because we know about the performance of our servers and know how many users can play on one unit at the same time. This is usually not the case with hosted P2P, since the performance and networking capability can vary greatly depending on the host’s end device. This also makes it easier to estimate and plan capacities. If we operate our servers using the cloud, we can relatively easily scale horizontally (more servers) and vertically (more resources per server) depending on the corresponding demand from the players. Operation in the cloud also ensures consistent global performance, since the servers are distributed around the world and are not in a central location. This is mostly not the case in the hosted P2P approach, since a gaming lobby is dependent on the performance and location of the host, which does not need to be close to the other players.
However, one of the biggest advantages of the dedicated server approach is the reliability and security of the game state, as it is calculated on an independent, secure instance, making it very difficult for players to cheat. While the hosted P2P approach allows a host to manipulate its position on the racetrack, for example, this is made significantly more difficult with approaches such as server-side reconciliation. Because the server always knows the last position of the player. If this delivers unrealistic values as input, the server can compare this with the value of the last frame and determine that there is an abnormal value and send adjustments to the player accordingly 4.
In summary, there are the following reasons for or against the dedicated server approach:
Advantages
Disadvantages
Security & Reliability (GameState is calculated on an independent authority)
High costs
Constant (high) performance
Scaling (on premise)
Plannable capacities
Easy scaling (cloud)
Global Distribution (Cloud)
Hybrid solutions & services
In addition to the approaches just mentioned, there are also mixed approaches. It is not uncommon for a dedicated server or hosted P2P architecture to be expanded by additional, separate game services. Such services are operated on standalone servers and deal with things like matchmaking, grouping up players and picking a dedicated server or (for peer to peer games) sharing IP addresses between players so they can connect together. They handle other things such as leaderboards, player progress, unlocks, chatting and friend lists etc. In this way, areas of responsibility are clearly separated and the load is distributed to different machines (Img. 3).
Well-known examples of such a solution are the games GTA Online, Warframe or Among us, whose players are connected to each other via a hosted P2P network, but the matchmaking runs on an own server. This model has been the subject of some criticism due to the potential for host cheating. However, the developers mostly has implemented several separate Measurement Services to prevent cheating in the game like Client-Side-Validation that includes checks for speed hacks, aimbots, and other forms of cheating and Activity- and System Monitoring that checks for suspicious activity on the player’s system like memory manipulation, injection attacks, and other forms of hacking 4.
Img. 3: Hosted P2P with gaming services (left), Dedicated Server with gaming services (right)
Game States: Racing World & Player Data
Now that we’ve gotten to know the common architecture approaches in online gaming, we have to ask the question of what data we have to exchange in order to determine the current state of the game. But before we get into the data, what exactly is the state anyway? To shed more light on this, let’s look at the multiplayer approach of one of the most well-known game engines – the Unreal Engine 5 – here for example, a distinction is made between three different units: GameMode, GameState and PlayerState 5 (see Figure 5). Other game engines like Unity use a similar approach, but the implementation varies 6.
Img. 4: GameMode, GameState and PlayerState in the example of a client-server architecture (dedicated server)5
Let’s explain the orange part of the image above (Img. 4) using our racing game 7:
The GameMode manages the global rules of a race. In our case these are for example:
The minimum number of players needed to start a race (min. 2)
The maximum number of players in a race (10 players)
The number of laps each player must complete to finish the race
The spawn location and order of players on the racetracks
The time of the countdown
The allowed weapons and traps
The GameState manages global information about the current gameplay that is relevant for all players, such as:
The number of currently connected players
The start and finish time of each individual player
The current ranking (based on each player’s current position)
The position of all players
The location and state of all fired weapons and traps
The position and state of each checkpoint on the track.
The PlayerState will exist for every player connected to the game on both the server and the clients. This class can be used for replicated properties that all clients, not just the owning client, are interested in like the current
car model
round on the race track
position of a player
speed of a player
direction of a player
steering angle of a player
down force of a player
amount of a specific collected item of a player
status of a specific collected item (fired or not and target player)
collisions of a player with another player or object
By continuously updating the game state and all player states based on these inputs, we can provide a seamless and engaging experience for all players involved.
In addition to identifying what data makes up the state, it is important to understand how the player state is computed taking into account different latencies so that all players feel like they are sharing a synchronous gaming experience with other players at all times. How this works is explained in the next section.
State Simulation
Almost all modern 3D online games have to face an essential challenge: How do we balance the latency of the client-server communication (or client-host player in P2P) so that each player can experience smooth, latency-free gameplay locally, but at the same time uses the current state of the server.
Client prediction
During a multiplayer online game, each player communicates with the server (dedicated server) or the host player (hosted P2P). This communication happens asynchronously so that the player can experience a smooth gaming experience: For example, the player sends his new position to the server. Instead of waiting until the answer comes back from the server and freezing the player’s screen for the response time (latency) of for example 300 ms (that would be synchronous), the next frame is rendered directly and the player (in our case the racing car) is located directly at the new position. This approach is known as client prediction. Assuming that the game world is deterministic, the player’s input can lead directly to the desired action locally (for exmaple a new position, an animation or a physics calculation) and this will in most cases also correspond to the state of the server 8,9.
Server reconciliation
Since in a racing game the communication between player and server should take place as quickly as possible, UDP is used as the network protocol in most online multiplayer games and frameworks 10,11. In contrast to TCP, the order of the incoming packets is not guaranteed with UDP. Depending on the latency between player and server, the responses from the server can sometimes arrive at the player at different times and in a different order, so that the position of the server no longer has to match the new local position of the player (because the player is already moving in the game, for example). Thus, the player game state and the server game state are desynchronized. However, since the server game state is the trusted game state 12, the game now has to process the new information from the server and make an adjustment, for example reset the player locally to the server’s position. However, since the player has already moved locally, this would lead to an unclean gaming experience (glitches) and breakes immersion – and we want to avoid that at all costs! So what do you do in such a case?
One solution to this problem is server reconciliation. A sequential number is added to each input sent by the player to the server to ensure the order of actions. This input is stored both on the player and on the server. If the player now receives a response from the server that matches the player state, the associated number can be removed locally and the next number follows in order. However, if the server’s answers follow in a different order, the player now knows locally that an answer to a specific number is still missing. However, since the player knows the answer to the actions before and after the missing answer, he can simulate the current state, which is then validated again by the server afterwards. This means that the server and player always synchronize with a slight delay in comparison to the next frame. However, this also ensures that the gameplay is represented graphically fluently 8.
Interpolation
Now that the simulated state between two states (the result of the server-side reconciliation) also graphically leads to a smooth transition movement, we use the concept of interpolation. Interpolation algorithms are part of every common game engine 14,15. There is linear interpolation to calculate states between two positions and spherical interpolation to calculate states between two degrees of rotation. This algorithm always requires two states (for example two positions on the race track) in order to calculate the positions in between and then display them in a fluid movement. In our case, these are the two positions that have been successfully validated and transmitted by the server before and after a certain input from the player. Based on these positions, the intermediate positions are now calculated, which are required for the execution of the graphic representation 13.
The combination of client-side prediction, server-side reconciliation and interpolation can help ensure a smooth and responsive online multiplayer game experience. By using these techniques, game developers can minimize network latency issues and keep players synchronized across multiple devices and network connections. To make these three approaches easier to understand, I will highly refer to a Live-Demo at this point.
Conclusion
With this article we took the first step into the world of online-multiplayer-architecture. We discussed architectural approaches for multiplayer games, got to know the game and player state and understood which data we have to exchange between our players. Finally, we looked at concepts that compensate the latencies between player and server by simulating an intermediate state.
When choosing a suitable architecture for an online game, it has been shown that P2P, dedicated servers or hybrid approaches are technical solutions that present developers with different challenges. As it turned out, hybrid solutions in particular are preferred in order to keep costs as low as possible while still being able to offer players an immersive and fun gaming experience through server-based, separate services such as match-making or activity monitoring. P2P solutions are ideal for small, unknown games with little to no budget, while games with predictable, stable sources of income have more money for their own server infrastructures. However, by using free tiers, smaller games with a few players at start can also take advantage of Dedicated Cloud Servers to launch their game in the first place 2,16.
In order to make a final decision regarding the architecture of our racing game, further research is required, such as a detailed cost comparison, comparison of different frameworks or cloud providers and implementation details.
Die “Cloud” ist ein Begriff, der in den letzten Jahren immens an Bedeutung gewonnen hat. Häufig wird sie für die Bereitstellung von Diensten und Services genutzt. Im Lauf der Zeit haben sich dabei verschiedene Architekturen entwickelt, die in der Cloud eingesetzt werden und unterschiedliche Ansätze für die Handhabung des Codes der Entwickler und die Anfragen von Nutzern haben. Eine davon ist die sogenannte Serverless-Architektur. Doch wie genau funktioniert dieser Ansatz, welche Vor- und Nachteile bietet er und handelt es sich dabei um die Zukunft der Cloud-Entwicklung?
Wie bereits erklärt handelt es sich bei Serverless (auf deutsch serverlos) um eine Architektur zur Entwicklung von Anwendungen in der Cloud. Der Name lässt vermuten, dass es bei diesem Ansatz darum geht, auf die Verwendung von Servern zu verzichten. Ganz ohne Server funktioniert es natürlich nicht, da die Anwendung und Services trotzdem über das Internet (und damit über irgendeine Art von Server) für die Nutzer erreichbar sein müssen.
Funktionsweise
Das “Serverlose” bezieht sich darauf, wie die Entwickler mit der Cloud umgehen und mit ihr interagieren. Denn im Gegensatz zum klassischen Cloud-Computing muss sich das Entwicklerteam hier keine Gedanken über die Bereitstellung der Anwendung für die Nutzer, die Skalierung oder die Verwaltung des Codes machen. Diese Aufgaben übernimmt alle der Cloud-Anbieter und folgt damit ein bisschen dem Prinzip “aus dem Auge aus dem Sinn”, da die Entwickler ihren Code nur hochladen müssen und sich danach keine, bzw. nur noch wenige Gedanken mehr machen müssen.
Man unterscheidet dabei zwischen BaaS (Backend-as-a-Service) und Faas (Function-as-a-Service). Die zwei Möglichkeiten differenzieren, was genau der Cloud-Anbieter bereitstellt. Bei BaaS kann man auf bereits vorhandene Dienste zurückgreifen, die der Cloud-Anbieter schon im Repertoir hat. AWS Amplify beispielsweise ermöglicht es den Entwicklern, einfach Datenbanken, Authentifizierung, etc. nach ihren Wünschen zu konfigurieren und einzubauen. Bei FaaS wird auf diese Art der Drittanbieter-Services verzichtet und die Entwickler schreiben ihre Logik und System selbst. Statt das Ganze dann auf einem eigenen Server laufen zu lassen, wird der Code bei dem Cloud-Anbieter hochgeladen, der diesen dann verwaltet. Je nach Bedarf wird dann durch Events der passende Code aufgerufen und ausgeführt, ohne dass der Entwickler dies manuell handhaben muss.
Abb. 1: Monolithische Architektur und Microservice-Architektur [4]
Zusammenfassend bietet Serverless also wie in Abbildung 1 dargestellt den Zugang zu vordefinierten Services, zu Möglichkeiten der Datenverwaltung, zu Monitoring über das System mit Metriken und Dashboards und natürlich eigene Zugangspunkte, die die Services und Funktionen der Entwickler ausführen.
Doch wie sieht der Code, beziehungsweise das gesamte System eigentlich aus, dass so ein Ansatz funktionieren kann? Im Grunde MUSS der Code keine besondere Struktur aufweisen. Serverless bezieht sich lediglich auf die Bereitstellung des Systems über einen Cloud-Anbieter, der sich um die Verwaltung dessen kümmert und diese Aufgabe von den Entwicklern abnimmt. Es hilft jedoch, das System in einzelne, kleinere Services oder sogar einzelne Funktionen zu unterteilen, die unabhängig voneinander funktionieren, um die Vorteile von Serverless besser nutzen zu können. Hier kommt der Vergleich zwischen der traditionellen, monolithischen Software-Architektur und der Microservice-Architektur ins Spiel.
Abb. 2: Monolithische Architektur und Microservice-Architektur [3]
Bei einer monolithischen Software-Architektur (Abbildung 2 links) wird das System klassischerweise in ein Frontend, Backend und die Datenbankanbindung unterteilt. Die drei Teile arbeiten eng zusammen und sind stark voneinander abhängig. Sie lassen sich kaum auseinanderziehen oder separieren. Im Gegensatz dazu nutzt die Microservice-Architektur (Abbildung 2 rechts) hinter dem Frontend mehrere, unabhängige Services (daher der Name). Diese können auch unterschiedliche Datenbanken verwenden. Mit diesem Ansatz wird die Logik des Backends in kleinere Teile aufgedröselt. Besonders wichtig ist dabei die angesprochene Unabhängigkeit. Die Services sind dazu in der Lage, ihre Aufgabe selbstständig zu erfüllen, können dazu auf ihre Datenbank zugreifen und müssen nicht andere Services hinzuziehen. Beispiele für solche Services könnten die Authentifizierung von Nutzern, das Suchen nach Produkten oder das Kaufen von Produkten sein.
Betrachtet man nun eine Microservice-Architektur und lässt diese Serverless in der Cloud betreiben, kann man den Nutzen von Serverless gut erkennen: Die einzelnen Services können separat voneinander gestartet und ausgeführt werden. Die Entwickler definieren eventbasierte Funktionen (siehe “Event-driven Computing”), um beim Eintreten eines Events den passenden Service zu starten und auszuführen. Wenn beispielsweise ein Nutzer nach einem Produkt auf unserer Webseite sucht, wird der Such-Service hochgefahren, dieser durchsucht die Datenbank nach passenden Treffern und gibt diese an das Frontend zurück. Nachdem der Service diese Aufgabe erledigt hat, wird er durch den Cloud-Anbieter wieder heruntergefahren, wenn keine weiteren Anfragen hinzukommen.
Zusammenfassend lässt sich zu der Funktionsweise von Serverless sagen, dass es sich dabei um eine Architektur oder ein Modell zur Verwaltung und Bereitstellung des Systems über einen Cloud-Anbieter handelt. Dieser übernimmt Funktionen, wie das Hoch- und Runterskalieren von Services/Funktionen nach Bedarf durch die Bereitstellung von passender Rechen- und Speicherkapazität, die Wartung der darunterliegenden Hardware und stellt bei Bedarf auch vordefinierte Services bereit.
Vorteile
Nun stellt sich die Frage, welche Vorteile der Serverless-Ansatz mit sich bringt und wann es Sinn macht, ihn einzusetzen:
Skalierbarkeit: Ein bereits angesprochener und auch einer der zentralsten Punkte ist die Skalierbarkeit. Es können je nach Bedarf neue Ressourcen für das System bereitgestellt und auch wieder zurückgenommen werden. Dadurch ist es möglich, die Anfragen an das System effektiv zu beantworten und gleichzeitig effizient mit den Ressourcen umzugehen.
Geringe Kosten: Das führt auch direkt zu dem zweiten Vorteil, nämlich den geringeren Kosten. Da die Rechenleistung nur dann verwendet wird, wenn sie auch wirklich benötigt wird, zahlt der Kunde des Cloud-Anbieters auch nur für die wirklich genutzten Ressourcen. Das bedeutet, dass wenn wenig Last vorhanden ist und dementsprechend auch nur wenig Rechenleistung benötigt wird, die Kosten für das System gering gehalten werden und man nicht beispielsweise einen eigenen Server, der dauerhaft erreichbar ist, bereitstellen muss.
Geringerer Aufwand: Für die Entwickler selbst verringert sich der Aufwand durch die wegfallenden Verwaltungs- und Wartungsaufgaben. Es muss keine Zeit für die Instandhaltung, Administration oder Konfiguration der Server aufgebracht werden, wodurch mehr Zeit in die eigentliche Entwicklung der Software gesteckt werden kann. Bei der Verwendung von BaaS lässt sich zudem auf bereits vorhandene Services des Anbieters zurückgreifen, wodurch noch mehr Zeit eingespart werden kann.
Sicherheit und Zuverlässigkeit: Die Cloud-Anbieter stellen Sicherheitsmaßnahmen zum Schutz des Systems und der Daten bereit. Nicht nur sind die Daten dadurch professionell geschützt, sondern auch hier sparen sich die Entwickler wieder Zeit, da sie sich nicht selbst um die Sicherheit und Zuverlässigkeit des Systems kümmern müssen, sondern diese durch den Anbieter umgesetzt werden.
Ihre Vorteile kann die Serverless-Architektur am Besten ausspielen, wenn die dafür genutzte Applikation auch auf die genannten Vorteile eingeht. So macht es beispielsweise Sinn, Serverless einzusetzen, wenn man mit sehr unterschiedlichem Verkehrsaufkommen rechnen muss. Hier kann Serverless durch die einfache Skalierbarkeit und auch die dadurch effizientere Kostenverteilung besonders hilfreich sein, da man bei geringem Verkehr nur wenig bezahlt und bei vielen Anfragen diese trotzdem schnell behandeln kann.
Nachteile
Natürlich hat Serverless auch seine Nachteile und Probleme, die in diesem Abschnitt aufgegriffen und erläutert werden.
Startzeit: Da die einzelnen Services/Funktionen erst ausgeführt werden, wenn sie auch wirklich gebraucht werden, müssen sie zu Beginn einer Anfrage und wenn noch kein anderer, freier Service derselben Art gerade läuft, erst gestartet werden. Dies wird als “Cold Start” bezeichnet. Das Starten eines solchen Services beinhaltet das Starten eines Containers mit dem passenden Code, das Laden der dazugehörigen Packages und die eigentliche Ausführung des Services. Bei Anwendungen, die auf Serverless verzichten, fällt dieser Cold Start weg, da das System ja bereits komplett läuft.
Weniger Kontrolle: Der größte Nachteil ist wahrscheinlich der Verlust von Kontrolle in vielerlei Hinsicht. Zum einen hat man keine Möglichkeit mehr, die Hardware selbst zu konfigurieren und zu managen. Darunter fällt auch die Macht zu entscheiden, welche Sicherheitsvorkehrungen genau implementiert werden, welche Updates und Versionen von Software benutzt werden und vieles mehr. Bei der Nutzung von BaaS ist man zudem an den Code des Cloud-Anbieters gebunden und kann keine eigenen Optimierungen oder Anpassungen vornehmen. Außerdem liegen die verwendeten Daten auch nicht mehr bei den Entwicklern selbst auf einem Server, sondern müssen dem Cloud-Anbieter anvertraut werden.
Abhängigkeit: Ein weiterer Nachteil ist die Abhängigkeit vom Cloud-Anbieter. Lässt man sich auf sein System ein und verwendet möglicherweise von ihm bereitgestellte Services und Funktionen, ist ein Wechsel zu einem anderen Anbieter schwierig und kompliziert, da dieser eventuell nicht dieselben Funktionen oder Workflows anbietet.
Evaluierung
Betrachtet man die genannten Vor- und Nachteile von Serverless, so lässt sich sagen, dass Serverless durchaus viele relevante Vorteile mit sich bringt, die es als die Cloud-Architektur der Zukunft rechtfertigen würde. Besonders die Einfachheit, die durch die automatische Skalierung ermöglicht wird und damit gleichzeitig das System kostengünstiger und einfacher bereitzustellen macht, sind wichtige Kriterien.
Natürlich muss man die Abhängigkeit vom Cloud-Anbieter und den Kontrollverlust in Betracht ziehen. Besonders letzteres schließt Serverless für manche Unternehmen aus, die den vollen Zugang zu den Servern benötigen und selbst an dem System aktiv arbeiten wollen. Für viele Unternehmen eröffnet Serverless jedoch eine Möglichkeit, sich voll und ganz auf die Entwicklung der Anwendung zu konzentrieren.
Wie bei vielen Aspekten ist Serverless ein Angebot für einen Tausch. Man bekommt Effizienz und Kostenersparnis, büßt dabei aber Kontrolle und Zugänglichkeit ein. Im Endeffekt muss jedes Unternehmen selbst entscheiden, mit welcher Architektur sie arbeiten wollen. Ich persönlich denke, dass der Ansatz besonders für kleine Unternehmen und Startups eine gute Möglichkeit bietet, ihr Produkt auf den Markt zu bringen, ohne sich über die Verwaltung der Server Gedanken machen zu müssen, sondern sich auf ihr Produkt selbst fokussieren zu können. Denn besonders für diese Unternehmen ist es sehr aufwändig und vor allem teuer, die benötigte Hardware bereitzustellen und auch funktionstüchtig und sicher zu halten. Fällt diese Komponente weg, so können mehr Entwickler das tun, was sie wirklich tun wollen und auch können, nämlich entwickeln und müssen sich nicht mehr um die Bereitstellung ihres Systems sorgen.
Dementsprechend halte ich Serverless durchaus für eine Architektur, die die Zukunft weiter mitgestalten wird.
Ausblick
Neben den angesprochenen Aspekten, warum Serverless vermutlich in der Zukunft weiterhin stark vertreten sein wird, sollte man sich auch etwas Gedanken über die nötige Weiterentwicklung machen. Meiner Ansicht nach ist Serverless besonders für die steigende Anzahl an IoT-Geräten und Applikationen eine optimale Lösung. Oft bieten diese nämlich genau das, was Serverless bereitstellt: Kleine Funktionen und Services, die schnell ausgeführt werden, die hochskaliert werden müssen und die dadurch dem Entwickler einen kostengünstigen Weg bieten, diese Aspekte umzusetzen.
Ich könnte mir vorstellen, dass viele Systeme aufgrund dieser Einfachheit in die Cloud verlegt werden. Dadurch könnte es möglich sein, dass in der Zukunft viele dieser Systeme sich auch untereinander vernetzen. Es entsteht quasi eine große Welt aus miteinander verknüpften Services und Diensten, die auch die Entwicklung neuer Systeme einfacher gestaltet. Denn Cloud-Anbieter werden ihr Repertoir kontinuierlich erweitern und eine immer größere Sandbox aus vordefinierten Services erstellen, mit der Entwickler ihre Ideen schnell und einfach umsetzen können.
In den letzten Jahren hat sich die Welt der künstlichen Intelligenz (KI) rasend schnell entwickelt. Eine der spannendsten Entwicklungen in diesem Bereich ist die Einführung von Sprachmodellen, die menschenähnliche Gespräche führen können. Eines der bekanntesten und leistungsfähigsten Sprachmodelle ist ChatGPT. ChatGPT basiert auf dem Modell GPT-3, das von der Firma OpenAI entwickelt wurde. Microsoft hat mehrere Milliarden in OpenAI investiert, um Zugang zu diesem und anderen KI-Modellen zu erhalten. In nur zwei Monaten seit seiner Veröffentlichung hat ChatGPT bereits 100 Millionen Benutzer erreicht, von denen die meisten regelmäßige Nutzer sind. Täglich nutzen etwa 13 Millionen Menschen ChatGPT. Diese Zahlen zeigen, wie schnell ChatGPT an Bedeutung gewinnt und wie nützlich es für die Entwicklung von KI-basierten Anwendungen sein kann.
Die Qualität der von ChatGPT generierten Texte ist besonders beeindruckend. Sie sind häufig kaum noch von menschengeschriebenen Texten zu unterscheiden. Der vorherige Abschnitt wurde zum Beispiel vollständig von ChatGPT geschrieben, was Ihnen vermutlich nicht aufgefallen ist. Neben dem Generieren von Texten kann ChatGPT auch für viele weitere Aufgaben genutzt werden. Zum Beispiel für die Beantwortung von Fragen, oder auch für das Schreiben und die Fehlersuche in Code. Es kann auch Bezug auf bereits generierte Texte genommen werden und ChatGPT kann diese umschreiben, übersetzen oder im Stil verändern. Bittet man ChatGPT z.B. darum, den oberen Abschnitt auf Englisch zu übersetzen und als Gedicht umzuformulieren, erhält man die folgende Ausgabe:
In the world of AI, advances are rife
Language models can now talk like human life
ChatGPT is one that's made a great leap
Built on GPT-3, OpenAI's star keep
Microsoft invested billions in the AI game
To access the power of models that became
ChatGPT, in particular, has made waves
In the workplace, where it helps to save
With conversations like a human touch
ChatGPT finds uses in tasks that clutch
Repetitive work, like customer support
It automates and saves time, that's its forte forte
So whether it's sales, marketing, or journalism too
ChatGPT can do it all, with responses anew
The future's bright, and there's more to come
From AI advancements, where possibilities hum.
ChatGPT kann als Meilenstein in der Entwicklung von Sprachmodellen und im Bereich Machine Learning generell gesehen werden, auch wenn die Texte, wie im Gedicht zu erkennen, noch nicht ganz fehlerfrei sind.
In den folgenden Kapiteln erklären wir die technischen Grundlagen, die zum Verständnis der Funktionsweise von ChatGPT nötig sind. Es wird das Konzept der Self-Attention erklärt, welches eine der relevantesten Entwicklung im Bereich von Sprachmodellen ist. Wir gehen auf das Fine-Tuning beim Training von ChatGPT ein. Zusätzlich wird ein Überblick über verschiedene GPT-Modelle gegeben. Da bei Sprachmodellen ein Trend zu immer größeren Modellen existiert, möchten wir auch auf die Skalierung großer Sprachmodelle eingehen und diesen Trend bewerten.
Grundlagen
Sprachmodelle
Das von ChatGPT genutzte Modell GPT-3 ist ein Sprachmodell. Sprachmodelle können für verschiedene Anwendungen eingesetzt werden, z.B. zur automatischen Vervollständigung von Sucheingaben oder zur Textgenerierung. Grundsätzlich werden unter Sprachmodellen Modelle verstanden, die mithilfe verschiedener probabilistischer Techniken Wahrscheinlichkeiten von Wortsequenzen in Sätzen bestimmen, indem sie Textdaten analysieren. Dabei lernt ein Modell Merkmale und Eigenschaften der Sprache und nutzt diese, um neue Sätze zu verstehen oder zu produzieren. Je nach Komplexität der Aufgabe werden unterschiedliche Modelltypen verwendet. GPT-3 ist zum Beispiel ein neuronales Sprachmodell. Diese repräsentieren Wörter als Vektoren auf Grundlage von Gewichten in neuronalen Netzen, diese Vektoren werden als Word-Embeddings bezeichnet. Word-Embeddings werden vor allem bei komplexen Modellen mit großen Datenmengen eingesetzt, hier existieren einzelne Wörter, die selten in Texten vorkommen. Bei einfachen probabilistischen Modelltypen kann es dabei zu Problemen kommen [1]. Da der Blog-Beitrag ChatGPT behandelt, beschäftigen wir uns nur mit neuronalen Sprachmodellen. Ein Überblick weiterer Modelltypen wird in [1] gegeben.
Wie bereits erwähnt, wird ChatGPT zur Textgenerierung eingesetzt. Dabei wird aus einer Sequenz von Word-Embeddings als Eingabe eine Wahrscheinlichkeitsverteilung über Ausgabewörter eines Textkorpus bestimmt. In Texten bestehen dabei zwischen den Word-Embeddings der Eingabesequenz Abhängigkeiten, weshalb Architekturen genutzt werden, die diese Abhängigkeiten berücksichtigen. In den ersten neuronalen Sprachmodellen wurden dafür z.B. rekurrente neuronale Netze (RNNs) verwendet. RNNs sind neuronale Netze, bei denen die Ausgabe eines Neurons im nächsten Zeitschritt Teil der Eingabe in dasselbe Neuron ist. Bei der Textverarbeitung bedeutet dies, dass zusätzlich alle vorherigen Wörter in die Berechnung der Ausgabe mit einfließen und das ein Wort pro Zeitschritt prozessiert wird. RNNs in Sprachmodellen besitzen jedoch zwei entscheidende Nachteile. Zum einen haben sie Schwierigkeiten, Informationen über Wörter, die am Anfang eines langen Textes stehen, in die Verarbeitung von Wörtern am Ende des Textes einzubeziehen. Zum anderen können RNNs nur sequenziell trainiert werden, weshalb kein effizienteres Training durch die Nutzung mehrerer GPUs ermöglicht werden kann.
Durch die Vorstellung einer weiteren Modellarchitektur in dem Paper „Attention is all you need“, wurde eine neue Architektur zur Berücksichtigung von Abhängigkeiten zwischen Eingaben eingeführt. Der als Transformer bezeichnete Modelltyp verwendet dabei sogenannte Self-Attention und gilt als Meilenstein im Bereich Natural Language Processing [2].
Self-Attention
Self-Attention bezeichnet eine Methode, mit der der Einfluss anderer Wörter auf das aktuell zu verarbeitende Wort berücksichtigt wird. Für den folgenden Beispielsatz:
„The animal didn't cross the street because it was too tired.“
Wird durch Self-Attention zum Beispiel der Einfluss der Wörter animal und street auf das Wort it gelernt, Self-Attention sollte dabei dafür sorgen, dass der Einfluss von animal größer ist als von street. Für einen Menschen scheint dies ein triviales Problem zu sein, während es für einen Algorithmus ein deutlich komplizierteres Problem ist. Bei Self-Attention werden für jedes Wort Attention-Koeffizienten zu allen anderen Eingabewörtern berechnet. Diese definieren die Beziehungsstärken zwischen den Word-Embeddings der Eingabewörter. In einem ersten Schritt werden mithilfe des Word-Embeddings eines Eingabewortes Query, Key und Value Matrizen berechnet. Dies erfolgt durch die Gewichtsmatrizen Wq, Wk und Wv. Die Parameter dieser Gewichtsmatrizen sind veränderbar und werden während des Trainingsprozesses gelernt.
Query, Key und Value haben dabei die folgenden Funktionen:
Query: Die Query qi der i-ten Eingabe wird verwendet, um den Einfluss aller Eingaben auf die Eingabe an Stelle i zu berechnen.
Key: Der Key kj wird von Queries qi genutzt, um den Einfluss des Elements an der Stelle j für das Element an der Stelle i zu bestimmen.
Value: Der Value vj wird für die Berechnung des Gesamtergebnisses zusammen mit dem Attention-Koeffizienten aij verwendet.
Es wird auch die Query auf einen Key der gleichen Eingabe angewandt, um für eine Eingabe den eigenen Einfluss zu bestimmen. Durch Betrachtung des oberen Beispiels wird deutlich, warum dies relevant ist. Bei Verarbeitung des Wortes it ist zum Beispiel der Einfluss von animal größer als das Wort it selbst.
Nach der Berechnung von Query, Key und Value werden die Attention-Koeffizienten aij durch das Skalarprodukt von Query qi und Key kj gebildet. Diese werden normalisiert, anschließend wird die Softmax-Aktivierungsfunktion darauf angewandt. Die Ausgabe yi bei Eingabe xi unter Berücksichtigung der restlichen Eingaben in der Sequenz kann dann durch die Linearkombination der Attention-Koeffizienten mit den jeweiligen Value-Werten berechnet werden [3].
In Abbildung 1 ist die Berechnung für die erste Eingabe abgebildet, dabei werden die Einflüsse aller weiterer Eingaben auf das erste Eingabeelement berücksichtigt.
Abbildung 1: Self-Attention in einem Single-Head eines Transformers [8]
In der obigen Abbildung wird eine sogenannte Single-Head Attention abgebildet. Das heißt, für jedes Paar von Eingaben wird ein einzelner Attention-Koeffizient berechnet. In Modellen wie GPT wird Multi-Head Attention verwendet. Das heißt, für Paare von Eingaben werden mehrere Attention-Koeffizienten in sogenannten Heads berechnet. In jedem Head werden dabei unterschiedliche Gewichtsmatrizen zur Berechnung von Query, Key und Value verwendet, wobei die Startgewichte zufällig initialisiert werden. Alle Ergebnisse der verschiedenen Heads werden verkettet und durch eine erneute lernbare Gewichtsmatrix auf ein Ergebnis projiziert. Die Verwendung von Multi-Head Attention bringt den Vorteil, dass für ein Paar von Eingaben unterschiedliche Gewichtsmatrizen für Query, Key und Value gelernt werden und somit mehrere Attention-Koeffizienten für gleiche Paare von Eingabewörtern gelernt werden können. Dies ist relevant, weil Wortpaare je nach Gesamtkontext eines Textes unterschiedliche Bedeutungen und damit unterschiedliche Beziehungsstärken haben können [3, 4].
Transformer
GPT steht für Generative Pretrained Transformer. Das heißt GPT beruht auf einem Transfomer in dem das Konzept Self-Attention umgesetzt wird. Ein Transformer besteht aus zwei Teilen, einem Encoder und Decoder-Teil. Diese beinhalten, wie in Abbildung 2 zu erkennen, mehrere Encoder- bzw. Decoder-Blöcke, welche neben Self-Attention Schichten auch Schichten zur Normalisierung und reguläre Feed-Forward Neural Networks enthalten. Die Eingabe in den Encoder-Teil eines Transformers sind Sequenzen von Word-Embeddings. In der Eingabe ist zusätzlich eine Information über die Position des Word-Embeddings in der Sequenz enthalten. Diese wird durch den Positional-Encoding Vektor repräsentiert, der auf die Eingabe addiert wird. Positional-Encoding Vektoren sind dabei so aufgebaut, dass weiter entfernte Eingaben eine höhere euklidische Distanz besitzen als benachbarte Eingaben. In den Decoder-Teil wird die Ausgabe des Decoders zum vorherigen Zeitpunkt als Eingabe gegeben. Encoder und Decoder sind über einen Encoder-Decoder Attention-Block verbunden. Die Eingabe in diesen Block sind die Keys und Values des letzten Encoder-Blocks sowie die Queries des vorangeschalteten Decoder-Layers [3].
Abbildung 2: Darstellung eines Transformers. Es wird ein Zeitpunkt während der Verarbeitung einer Eingabe zur Übersetzung abgebildet. (Angepasste Darstellung aus [3])
Durch die Umsetzung der Transformer, wie sie in „Attention is all you need“ vorgestellt wurden, konnten bessere Ergebnisse wie durch andere Modelle bei gängigen NLP-Aufgaben erzielt werden, wobei der Trainingsaufwand signifikant geringer war [4]. In vielen Sprachmodellen werden heutzutage Transformer verwendet, wobei diese zum Teil angepasst werden.
Generative Pre-Trained Transformer (GPT)
In den vorherigen Abschnitten sind wir bereits darauf eingegangen, was ein Sprachmodell ist und wie Transformer funktionieren und aufgebaut sind. Doch wie stehen diese im Zusammenhang mit Generativen Pre-Trained Transformern (GPTs)?
Die ersten GPT-Modelle wurden erstmals im Jahr 2018 von OpenAI als GPT-1 eingeführt [5]. Die Architektur der GPT-Modelle basiert dabei, wie bereits erwähnt, auf der der Transformer. Ein GPT nutzt dabei nur die Decoder-Struktur des Transformers, da nur dieser Teil relevant für die Erzeugung von Text ist. Alle GPT-Varianten stellen dabei sogenannte autoregressive Sprachmodelle dar. Diese sagen für eine Sequenz von Wörtern das nachfolgende Wort vorher. Für diese neue Sequenz wird dann wieder das Wort vorhergesagt, das am wahrscheinlichsten auf diese Sequenz folgt. Durch diese Funktionsweise sind GPT-Modelle für die Generierung von Texten oder jeder Art von Sequence-To-Sequence Transformationen wie Übersetzung, Text-to-Code, etc. geeignet. Sie werden deshalb auch generative Modelle genannt, da sie neuen Text generieren können. GPT-1 wird dabei, wie der Name es verrät, auf einer großen Menge an Daten vortrainiert und dann für jede spezifische Task, die das Modell erfüllen soll, Fine-Tuned (Gezielt abgestimmt). Daher haben GenerativePre-TrainedTransformer ihren Namen.
Das Pre-Training erfolgt dabei unüberwacht (unsupervised) und kann auf einer sehr großen Menge an Daten erfolgen, da für unüberwachtes Lernen keine gewünschten Ausgabedaten vorhanden sind. Bei GPT-1 hat sich gezeigt, dass ein umfangreiches Pre-Training auf einem großen Textkorpus die Leistung dieser Modelle in unterschiedlichen Aufgaben verbessert, selbst wenn der Korpus nicht speziell auf die Aufgaben zugeschnitten war. Diese Erkenntnis hat gezeigt, dass ein großer vielfältiger Textkorpus sehr wertvolle Informationen für die Modelle liefert. Für das überwachte Fine-Tuning, bei dem nun eine gewünschte Ausgabe vorhanden ist, benötigt man deshalb nur einen kleinen Datensatz, um das Modell speziell auf eine Aufgabe abzustimmen. In manchen Bereichen ist jedoch selbst die Beschaffung dieses kleinen Datensatzes nicht sonderlich einfach [5].
Diese Modelle wurde im Jahr 2019 mit GPT-2 [6] und 2020 mit GPT-3 [7] weiter verbessert. Ab GPT-2 wurde dabei das Prinzip des Multi-Task Learning (MTL) angewendet. In GPT-1 musste dabei für jede spezifische NLP-Aufgabe ein eigenes Modell trainiert werden. Im Multi-Task Learning dagegen wird nur ein einziges Sprachmodell für mehrere NLP-Aufgaben trainiert, indem die Trainingsdaten mit Task-spezifischen Beispielen oder Prompts erweitert werden. Da das Modell nicht für eine spezielle Aufgabe trainiert wurde, handelt es sich um ein Beispiel für Few-Shot-, One-Shot- oder Zero-Shot-Learning. Das Konzept der X-Shot-Ansätze ist in der folgenden Abbildung dargestellt.
Abbildung 3: X-Shot Learners [7]
Das Multi-Task Learning wird bei den X-Shot-Ansätzen dabei auf Datenebene integriert, indem, wie in der Abbildung dargestellt, der Eingabe („Cheese“) die Task-Beschreibung („Translate English to French“) hinzugefügt wurde. Beim Few-Shot-Learning werden dem Modell so einige Beispiele beigefügt, die genau die Aufgabe beschreiben. Um Multi-Task Learning / X-Shot-Learning anwenden zu können, muss das Modell natürlich immer noch mit einer sehr großen Menge an Daten vortrainiert werden. Dieser Ansatz hat gezeigt, dass immer größere Sprachmodelle, wie GPT-3, mit immer mehr Parametern eine sehr starke Leistung auf unterschiedlichen NLP-Aufgaben bieten. Die Tatsache, dass wir nun kein Fine-Tuning mehr benötigen, ist ein Schritt in Richtung der „allgemeinen Intelligenz“ [7, 8].
Die obige Tabelle zeigt deutlich, dass die GPT-Modelle im Laufe der Jahre immer größer geworden sind und GPT-3 im Vergleich zu GPT-2 auf deutlich mehr Daten vortrainiert wurde. Es war damals das größte öffentlich verfügbare Sprachmodell der Welt und die Qualität der generierten Texte so hoch, dass es für Menschen schwierig war, festzustellen, ob Texte von GPT-3 oder einem Menschen geschrieben wurden [9]. Obwohl GPT-3 große Fortschritte im Bereich der Verarbeitung natürlicher Sprache erzielt hatte, ist es nur begrenzt in der Lage, sich an den Absichten der Benutzer zu orientieren. So erzeugte GPT-3 Ausgaben die:
mangelnde Hilfsbereitschaft enthalten, d.h. sie befolgen nicht die ausdrücklichen Anweisungen des Nutzers.
Halluzinationen enthalten, die nichtexistierende oder falsche Fakten widerspiegeln.
nicht interpretierbar sind, sodass es für den Menschen schwierig ist, zu verstehen, wie das Modell zu einer bestimmten Entscheidung oder Vorhersage gekommen ist.
toxische oder voreingenommene Inhalte enthalten, die schädlich oder beleidigend sind und Fehlinformationen verbreiten [7, 10].
Um diesen Problemen von GPT-3 entgegenzuwirken, entwickelte OpenAI InstructGPT, welches im Januar 2022 veröffentlicht wurde. Dazu wurde GPT-3 als Basismodell mit den gleichen Pre-Training Datensätzen verwendet und das Modell durch einen neuartigen Ansatz zur Einbeziehung von menschlichem Feedback in den Trainingsprozess weiter verbessert. InstructGPT ist durch diesen Ansatz besser an die Absichten der Benutzer angepasst („aligned“) [11].
ChatGPT
Abbildung 4: Übersicht ChatGPT [12]
ChatGPT ist ein großes Sprachmodell, das darauf trainiert wurde, natürliche Sprache zu verstehen und auf verschiedene Arten von Fragen und Anfragen zu antworten. Es wurde am 30. November 2022 von OpenAI ins Leben gerufen. Der Dienst, mit einem ansprechenden Design und einfacher Benutzeroberfläche, ist bisher kostenlos für die Öffentlichkeit verfügbar. Im Januar 2023 erreichte ChatGPT über 100 Millionen Nutzer und war damit die am schnellsten wachsende Verbraucheranwendung überhaupt [12, 13].
ChatGPT stellt ein Geschwister-Modell von InstructGPT dar, welches darauf trainiert ist, einer Instruktion in einem Prompt zu folgen und eine detaillierte Antwort zu geben. Es wurde dabei auf einem Modell der GPT-3.5 Reihe trainiert, zu der InstructGPT zählt. Dabei wurde derselbe Ansatz wie bei InstructGPT gewählt, jedoch mit leichten Unterschieden in der Datenerhebung [14].
Zusätzlich dazu wurde eine Sicherheitsschicht hinzugefügt, um unangemessene und beleidigende Inhalte zu erkennen und herauszufiltern. Wenn ChatGPT eine unangemessene oder beleidigende Eingabe erhält, versucht es, das Thema zu wechseln oder den Benutzer höflich zu bitten, die Konversation fortzusetzen. Diese Sicherheitsmaßnahmen sind auf jeden Fall notwendig, da Sprachmodelle oft dazu neigen, auch unangemessene Antworten zu liefern.
Reinforcement Learning From Human Feedback
Der Ansatz, der bei InstructGPT dabei zum Einsatz kommt, heißt „Reinforcement Learning From Human Feedback“. Diese Technik nutzt die menschlichen Präferenzen als ein Reward-Signal, um das Modell damit zu verbessern. Dieser Ansatz wird im Folgenden mit dem InstructGPT Paper erklärt und besteht aus folgenden drei Schritten:
Abbildung 5: Reinforcement Learning From Human Feedback ChatGPT [14]
1. Supervised Fine-Tuning (SFT) Modell
Im ersten Schritt wird das GPT-3 Modell mithilfe von überwachten Lernen Fine-Tuned. Dazu wurden 40 Personen (Labeler) beauftragt, diesen Trainingsdatensatz zu erstellen, indem für jede Eingabe-Prompt eine Antwort erstellt wird. Die Eingabe-Prompts stammen dabei zum größten Teil aus tatsächlichen Benutzereingaben, die in der OpenAI API gesammelt wurden, aber auch zum Teil aus Eingaben, die die Labeler selbst erstellten, um Kategorien auszufüllen, in denen nur wenige tatsächliche Benutzereingaben vorhanden waren. Die Labeler schrieben dann für diese Eingabe-Prompts eine Antwort und erzeugten so eine Ausgabe für die zugehörige Eingabe. Diese Zusammenstellung der Eingabe-Prompts aus der OpenAI API und den selbsterstellten Prompts ergaben 13.000 Datensätze mit Eingabe und zugehöriger Ausgabe, die für das überwachte Fine-Tuning des Modells verwendet werden konnten [10, 11, 15].
In diesem Schritt wird eine sogenannte überwachte Policy (das SFT-Modell selbst) gelernt. Eine Policy stellt im Reinforcement Learning eine Strategie dar, die ein Agent verfolgt, um Ziele zu erreichen. Die Strategie sagt die Aktionen voraus, die der Agent in Abhängigkeit vom Zustand des Agenten und der Umgebung durchführt [16].
2. Reward Modell (RM)
Das resultierende SFT-Modell zeigte schon eine Verbesserung in Bezug auf die Benutzerabsichten, war jedoch noch nicht gut genug. Das Problem des überwachten Ansatzes aus dem vorherigen Schritt ist außerdem der langsame und kostspielige Prozess für die Erstellung des Datensatzes.
Deshalb wird in diesem Schritt ein sogenanntes Reward Modell trainiert. Dazu werden die Labeler gebeten, die Ausgaben des SFT-Modells (Antworten auf Prompts) zu bewerten. Diese Bewertung drückt aus, wie wünschenswert diese Ausgabe für den Menschen ist. Am Ende dieses Schrittes besitzt man dann ein Reward Modell, das die menschlichen Vorlieben nachahmen soll. Das funktioniert dabei folgendermaßen:
Eine Eingabe-Prompt wird ausgewählt und das SFT-Modell generiert mehrere Ausgaben (4-9) für diese Eingabe-Prompt.
Die Labeler sortieren die Ausgaben von der besten bis hin zur schlechtesten.
Das Ergebnis ist ein neuer Datensatz, bei dem das Ranking das Label darstellt. Dieser Datensatz wird verwendet, um das Reward Modell zu trainieren. Das Reward Modell nimmt dabei als Eingabe mehrere Ausgaben des SFT-Modells und ordnet diese nach der Reihenfolge der Präferenzen.
Da es für die Labeler viel einfacher ist, die Ergebnisse zu bewerten, als sie von Grund auf neu zu erstellen, lässt sich dieser Prozess viel effizienter skalieren [10, 11, 15].
3. Reinforcement Learning Modell
Im letzten Schritt wird das Reward Modell als Reward-Funktion verwendet und das SFT-Modell so Fine-Tuned, um diesen Reward zu maximieren. Dazu wird dem Modell eine zufällige Eingabe-Prompt übergeben und eine Ausgabe dazu vom Modell erzeugt. Diesem Paar an Eingabe und Ausgabe wird vom Reward Modell ein Reward-Wert zugeordnet. Dieser Reward fließt dann wieder in das Modell mit ein, um die Policy, also das Modell zu verbessern. Die Policy wird mit dem sogenannte Proximal Policy Optimization (PPO) Algorithmus angepasst. PPO ist dabei eine Methode, die bei der Aktualisierung der Policy verwendet wird. Er führt dabei einen sogenannten Clipping-Mechanismus ein, um sicherzustellen, dass die Aktualisierungen der Policy innerhalb einer Vertrauensregion liegen. Dadurch wird verhindert, dass die Policy zu stark verändert wird, indem zu viel vergessen wird. PPO verwendet außerdem eine sogenannte Value-Funktion (Reward Modell), um die Varianz der Policy-Gradienten zu verringern und die Lernleistung zu verbessern [10, 11, 15].
Evaluation des Modells
Die Bewertung des Modells erfolgt, indem während des Trainings ein Testdatensatz, den das Modell noch nie gesehen hat, beiseitegelegt wird. Anhand dieses Testdatensatzes wird dann eine Reihe von Bewertungen durchgeführt, um zu überprüfen, ob das Modell besser an die Absichten der Benutzer angepasst ist.
Das Modell wird dabei anhand von drei übergeordneten Kriterien bewertet:
Hilfsbereitschaft: Beurteilung der Fähigkeit des Modells, den Anweisungen des Benutzers zu folgen und Anweisungen abzuleiten.
Wahrheitsgehalt: Beurteilung der Neigung des Modells zu Halluzinationen (Erfinden von Fakten) bei Aufgaben in geschlossenen Bereichen.
Harmlosigkeit: die Fähigkeit des Modells, unangemessene, herabsetzende und verunglimpfende Inhalte zu vermeiden.
Dieser gesamte Ansatz hat natürlich auch gewisse Unzulänglichkeiten, die im InstructGPT Paper von OpenAI noch genauer aufgezählt werden [10, 11, 15].
Limitationen
Es gibt trotzdem noch gewisse Limitationen, die ChatGPT besitzt und die nicht unterschätzt werden dürfen. Dadurch, dass das Modell nur aus Sprache lernt, nimmt es dessen Eigenheiten an und wird so natürlich auch Fehlverhalten annehmen:
ChatGPT schreibt manchmal plausibel klingende, aber falsche oder unsinnige Antworten.
ChatGPT reagiert empfindlich auf Änderungen der Eingabeformulierung oder auf mehrfache Versuche mit der gleichen Frage.
Das Modell ist oft übermäßig wortreich und verwendet bestimmte Phrasen zu oft, wie z. B. den Hinweis, dass es sich um ein von OpenAI trainiertes Sprachmodell handelt.
Im Idealfall würde das Modell klärende Fragen stellen, wenn der Benutzer eine mehrdeutige Anfrage stellt. Stattdessen erraten aktuelle Modelle in der Regel, was der Benutzer beabsichtigt.
ChatGPT kann gelegentlich schädliche Anweisungen oder voreingenommene Inhalte produzieren.
Das Modell besitzt nur ein begrenztes Wissen über die Welt und Ereignisse, die nach 2021 passiert sind, da es auf Daten vor 2022 trainiert wurde.
Doch trotz der Limitationen, die bei ChatGPT bestehen, wurde ein riesiger Hype ausgelöst.
Hype von ChatGPT
ChatGPT ist von der technischen Sicht aus betrachtet keine neue bahnbrechende Erfindung. Die Methodiken, die zum Einsatz kommen, werden in der Forschung bereits in vielen anderen Modellen benutzt. Der Hype um ChatGPT kommt vor allem durch die öffentliche Bereitstellung des Modells für jedermann. Diese kostenlose Testphase mit einer einfachen und schönen Gestaltung des Dialogs macht ChatGPT so erfolgreich. Punkte, die ChatGPT selbst aufzählt, warum es so erfolgreich ist, sind:
24/7-Verfügbarkeit: Als KI benötige ich keine Pausen oder Ruhezeiten, sodass ich zu jeder Tages- und Nachtzeit zur Verfügung stehe, um Menschen bei ihren Fragen und Gesprächen zu helfen.
Erreichbarkeit: Die Menschen können mich von überall auf der Welt erreichen, solange sie eine Internetverbindung haben. Das macht es für die Menschen einfach, die benötigten Informationen zu erhalten, egal wo sie sich befinden.
Flexibel: Ich kann bei einem breiten Spektrum von Themen und Fragen helfen, von allgemeinem Wissen bis hin zu speziellen technischen Fragen. Das macht mich zu einem vielseitigen Werkzeug für die Menschen.
Schnelle Reaktionszeit: Ich kann Anfragen fast sofort bearbeiten und beantworten, was besonders hilfreich für Menschen ist, die schnelle Antworten brauchen.
Datenschutz: Als Sprachmodell benötige ich keine persönlichen Informationen der Nutzer. Das bedeutet, dass die Menschen mir Fragen stellen und Hilfe erhalten können, ohne sich Sorgen machen zu müssen, dass ihre Privatsphäre gefährdet wird.
Wenn ChatGPT bereits jetzt so große Wellen schlägt, stellt sich natürlich die Frage, wie es mit dem Nachfolger GPT-4 aussieht.
Ausblick GPT-4
GPT-4, die Weiterentwicklung der GPT-Serie, soll laut Gerüchten der New York Times sogar noch im Jahr 2023 erscheinen. Es soll sich dabei auf jeden Fall um ein noch mächtigeres Modell handeln als die bisherigen veröffentlichten Modelle. Die Gerüchte, dass es sich um ein Modell mit 100 Billionen Parametern handeln soll, wurden vom OpenAI CEO Sam Altman als völliger Blödsinn bezeichnet. Zu diesen Gerüchten sagte er: „Die GPT-4-Gerüchteküche ist eine lächerliche Sache. Ich weiß nicht, woher das alles kommt. Die Leute betteln darum, enttäuscht zu werden, und das werden sie auch.“ Somit kann man nur gespannt sein, wie gut GPT-4 sein wird und wann OpenAI das neue Modell veröffentlicht [17].
Es gab jedoch noch einige Veröffentlichungen von Konkurrenten zu ChatGPT, die ebenfalls neue Modelle ankündigten:
Google hat seinen Counterpart Bard veröffentlicht, der jedoch in einer Demo eine falsche Antwort lieferte und deshalb die Aktien des Mutterkonzerns einbrachen und 100 Milliarden Dollar Börsenwert kostete [18].
Das chinesische Unternehmen Baidu kündigte im Februar 2023 an, dass es im März 2023 einen ChatGPT-ähnlichen Dienst namens “Wenxin Yiyan” auf Chinesisch oder “Ernie Bot” auf Englisch auf den Markt bringen wird [19].
Die südkoreanische Suchmaschinenfirma Naver kündigte im Februar 2023 an, dass sie in der ersten Jahreshälfte 2023 einen ChatGPT-ähnlichen Dienst namens “SearchGPT” in koreanischer Sprache auf den Markt bringen werden [19].
Die Modelle, die in nächster Zeit veröffentlicht werden sollen, werden immer größer. Doch kann die Skalierung immer so weiter gehen und die Anzahl der Parameter immer vergrößert werden? Oder bringt das ganze letztendlich keine Verbesserung der Leistung dieser Modelle? Diese Frage werden wir im nächsten Kapitel klären.
Skalierung von Sprachmodellen
Wie wir festgestellt haben, ist die Anzahl der Parameter sowie die Menge der Trainingsdaten mit jeder Version von GPT angestiegen (siehe Tabelle 1). Zwar ist nicht bekannt, wie groß GPT-4 sein wird, es lässt sich aber vermuten, dass GPT-4 mehr Parameter enthalten wird, auch wenn der Anstieg unter Umständen nicht so stark sein wird wie zwischen vorherigen Versionen von GPT. Aufgrund des Trends zu immer größeren Modellen möchten wir nun auf die Skalierbarkeit von Sprachmodellen eingehen. OpenAI hat dabei in dem Paper „Scaling Laws for Neural Language Models“ selbst empirische Untersuchungen zur Skalierung in Sprachmodellen aufgestellt. Dabei werden Decoder-Only-Transformer als autoregressive Sprachmodelle evaluiert.
Es wurden Eigenschaften wie Parameteranzahl, Größe des verwendeten Trainingsdatensatzes und Trainingsaufwand sowie die Modellarchitektur untersucht. Die Erkenntnisse der Untersuchungen werden wir hier zusammenfassen.
Es lässt sich feststellen, dass die Performance in starkem Maße von der Skalierung der genannten Parameter abhängt. Das bedeutet, dass durch größere Modelle mit mehr Parametern und mehr Trainingsdaten sowie durch einen höheren Trainingsaufwand die Qualität von Sprachmodellen signifikant verbessert wird. Dieser Zusammenhang ist in Abbildung 6 abgebildet. Der Fehler auf den Testdaten nimmt bei Erhöhung der entsprechenden Größen ab.
Abbildung 6: Einfluss der Parameter Rechenleistung beim Training, Größe des Trainingsdatenset und Parameteranzahl auf den Test Loss [20]
Der Einfluss anderer Modelleigenschaften, wie etwa der Architektur z.B. in Bezug auf Anzahl der Layer hat einen deutlich geringeren Einfluss auf die Qualität des Modells. Bei Erhöhung der Parameteranzahl sollte zwar auch die Menge der Trainingsdaten erhöht werden, in den Experimenten von Open-AI hat sich dabei jedoch gezeigt, dass diese nicht im gleichen Maße erhöht werden müssen. Für eine Erhöhung der Parameteranzahl um den Faktor 8 ist nur eine Erhöhung der Menge der Trainingsdaten um den Faktor 5 nötig, um Overfitting zu vermeiden.
Durch die Experimente wurde auch festgestellt, dass bei größeren Modellen mit mehr Parametern weniger Trainingssamples prozessiert werden müssen, um die gleiche Qualität wie bei einem kleinen Modell zu erreichen (siehe Abbildung 7). Dadurch sollte der Trainingsaufwand größerer Modelle im Vergleich zu kleineren Modellen gering gehalten werden, da nur ein kürzeres Training nötig ist [20].
Abbildung 7: Test-Loss von Modellen verschiedener Größen nach prozessierten Trainingselementen (aus [20])
Dies ist auch bei Betrachtung von Abbildung 8 zu erkennen. Hier sind die gesamten Rechenaufwände verschiedener bekannter Modelle abgebildet. Die hervorgehobenen Modelle GPT-3 2.7B (2.65 Mrd. Parameter) und RoBERTa-Large (355 Mio. Parameter) sind beides Tansformer-Sprachmodelle. Trotz der deutlich höheren Parameteranzahl in GPT-3 2.7B sind die Gesamtkosten des Trainings im Vergleich zu RoBERTa-Large nicht wesentlich größer, was sich dadurch begründen lässt, dass zum Training von GPT-3 2.7B deutlich weniger Trainingselemente prozessiert werden müssen [7].
Abbildung 8: Vergleich des Trainingsaufwands verschiedener bekannter Transformer-Sprachmodelle (aus [7])
Größere Modelle mögen zwar eine bessere Qualität besitzen und nach der Evaluation von weniger Trainingssamples wird bereits die gleiche Qualität wie in kleinen Modellen erreicht, sie haben dennoch auch einige Nachteile. Der Trainingsprozess ist oft aufwendiger und erfordert mehr Speicherplatz. Das Training von Modellen wie GPT-3 ist nur durch verteiltes Training auf verschiedenen GPUs möglich. Grundsätzlich werden dabei die zwei Vorgehen Model-Parallelism und Data-Parallelism unterschieden. Beim Model-Parallelism erfolgt dabei eine Aufteilung des Modells, während beim Data-Parallelism eine Aufteilung der Daten erfolgt [21]. Wir werden in diesem Blog-Artikel nicht auf Details dazu eingehen, diese wurden bereits unter An overview of Large Scale Deep Learning erklärt.
Gerade das Training auf mehreren Grafikkarten führt zu sehr hohen Energiekosten. Bei GPT-3 werden die Energiekosten zum Pre-Training z.B. auf 1287 MWh. geschätzt, was einem Ausstoß von 552 Tonnen CO₂-Äquivalent entspricht [22].
Fazit
Generell sollte die Anzahl der Modellparameter sorgfältig abgewogen werden, eine höhere Anzahl von Parametern, die unter Umständen zu einer besseren Qualität führt, rechtfertigt nicht immer einen Mehraufwand. Eine einfache Nutzung des Sprachmodells als Anwendung z.B. über einen Chat-Bot wie bei ChatGPT ist für Nutzer ebenso relevant wie eine hohe Qualität der Sprachausgabe. GPT-3 ist im Vergleich mit vielen anderen Sprachmodellen nämlich bei Weitem nicht das größte Modell. Dennoch ist GPT-3 durch ChatGPT aktuell mit Abstand am stärksten im Fokus der Aufmerksamkeit. Die Ausgaben von ChatGPT sind bereits sehr gut. Neben einer Verbesserung durch ein größeres Sprachmodell wären vor allem auch Aspekte wie Verfügbarkeit der Anwendung für den Nutzer relevant, diese sollten nicht ignoriert werden.
Insgesamt lässt sich festhalten, dass die Entwicklung von Sprachmodellen wie ChatGPT in den letzten Jahren rasant vorangeschritten ist und die Modelle immer größer und leistungsfähiger geworden sind. Dabei wurde durch die Skalierung der Parameter auch immer wieder die Frage aufgeworfen, ob dies sinnvoll ist und ob es tatsächlich zu einer Verbesserung der Leistung führt. Die Forschungsergebnisse zeigen jedoch, dass eine Skalierung der Parameter tatsächlich zu einer deutlichen Steigerung der Leistungsfähigkeit von Sprachmodellen führen kann. ChatGPT und ähnliche Modelle sind in der Lage, erstaunlich komplexe Aufgaben zu lösen, wie zum Beispiel das Verfassen von Texten, die kaum von menschlicher Schreibweise zu unterscheiden sind.
Im Hinblick auf die Zukunft stehen jedoch noch zahlreiche Herausforderungen bevor, die es in den nächsten Jahren zu meistern gilt. Eine der wichtigsten Aufgaben ist es, die Modellinterpretierbarkeit zu verbessern, um sicherzustellen, dass Entscheidungen auf nachvollziehbare und transparente Weise getroffen werden können. Darüber hinaus müssen neue Methoden entwickelt werden, um die Rechenressourcen effizienter zu nutzen und den Energieverbrauch der Modelle zu reduzieren. Nichtsdestotrotz haben ChatGPT und ähnliche Modelle das Potenzial, die Art und Weise zu revolutionieren, wie wir mit Sprache interagieren und wie wir Informationen verarbeiten und kommunizieren. Angesichts der rasanten Entwicklung dieser Technologien bleibt es spannend zu beobachten, wie sich diese in Zukunft weiterentwickeln werden und welche Forschungsthemen sich ergeben.
A. Vaswani, N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones, A. N. Gomez, L. Kaiser und I. Polosukhin, „Attention Is All You Need,“ Open-AI, 2017. [Online]. Available: http://arxiv.org/abs/1706.03762.
T. B. Brown, B. Mann, N. Ryder, M. Subbiah und J. Kaplan, „Language Models are Few-Shot Learners,“ Open-AI, 28 Mai 2020. [Online]. Available: https://arxiv.org/abs/2005.14165.
L. Ouyang, J. Wu, X. Jiang, D. Almeida, C. L. Wainwright, P. Mishkin, C. Zhang, S. Agarwal, K. Slama, A. Ray, J. Schulman, J. Hilton, F. Kelton, L. Miller, M. Simens, A. Askell, P. Welinder, P. Christiano, J. Leike und R. Lowe, „Training language models to follow instructions with human feedback,“ 2022. [Online]. Available: https://arxiv.org/pdf/2203.02155.pdf.
[12]
Alan D. Thompson, „GPT-3.5 + ChatGPT: An illustrated overview – Dr Alan D. Thompson – Life Architect,“ 2022. [Online]. Available: https://lifearchitect.ai/chatgpt/.
J. Kaplan, T. Henighan, T. B. Brown, R. Child, S. Gray, A. Radford, J. Wu und D. Amodei, „Scaling Laws for Neural Language Models,“ Open-AI, 23 Januar 2020. [Online]. Available: https://arxiv.org/abs/2001.08361.
D. Patterson, J. Gonzalez, U. Hölzle, Q. Le und C. Liang, „The Carbon Footprint of Machine Learning Training Will Plateau, Then Shrink,“ 11 April 2022. [Online]. Available: https://arxiv.org/abs/2204.05149.
Ein Artikel von Michelle Albrandt, Leah Fischer und Rebecca Westhäußer.
Durch die Digitalisierung werden immer mehr Daten erzeugt. Dabei erreicht die Datenbasis durch Vernetzung von Mensch zu Mensch, sowie auch von Mensch zu Maschine, eine neue Dimension (Morgen et al., 2023, 6). Prognosen für das Jahr 2025 zeigen, dass in Zukunft ein erhebliches Datenwachstum zu erwarten ist, wobei insgesamt 181 Zettabyte an Daten erzeugt oder repliziert werden sollen (Tenzer, 2022). Aber nicht nur in Zukunft muss mit Herausforderungen gerechnet werden. Dies zeigt ein Vorfall des Erdbeobachtungsprogramms “Sentinel”.Das Earth Observation Center (EOC) verwaltet und archiviert die Daten der Satelliten und hat im Januar 2019 die maximale Speicherkapazität überschritten, wobei erstmals der Wert von 10 Petabyte überschritten wurde, was 10 Millionen Gigabyte entspricht(Earth Observation Center – 10 000 000 Gigabyte Sentinel Am EOC, 2019).
Mit der Zunahme der hohen Datenmengen steigt demnach auch die Nachfrage nach Datenspeicherlösungen mit großer Kapazität. Herkömmliche Speichermedien müssen aufgrund ihrer kurzen Lebensdauer regelmäßig ausgetauscht werden (Welzel et al., 2023, 1). Beispielsweise beträgt die Lebensdauer für Festplatten 10 Jahre und für Magnetbänder 30 Jahre. Zusätzlich haben solche Medien eine begrenzte maximale Informationsdichte von etwa 10³ GB pro mm³, wie beispielsweise bei Festplattenlaufwerken (Konitzer, 2021, 4). Durch Häufigkeit der Schreib- oder Lesezugriffe kann sich die Lebenszeit sogar verkürzen. Lesezugriffe sind zur Überprüfung der Datenintegrität jedoch notwendig (Potthoff et al., 2014, 14).
Ein langfristiges Speichermedium muss aber nicht neu entwickelt werden. Das beste Beispiel für Datenspeicherung, die nahezu ewig anhält, ist eines der allerersten Speichermedien überhaupt, die DNA. DNA kann sehr lange bestehen. So war es möglich, 2015 das Genom eines Wollmammut zu sequenzieren. Dies gelang den Forschern, obwohl der gefundene Knochen 4000 Jahre alt war (Konitzer, 2021, 4). Informationen nicht nur zu extrahieren, sondern auch in der DNA zu speichern, hatten Forscher bereits in den 60er Jahren vor. 50 Jahre später ist es in zwei unterschiedlichen Gruppen gelungen, Daten in Größe von einem Megabyte in der DNA zu speichern. Nach erfolgreichen Errungenschaften, wie ein robustes DNA-Datenspeicherung System durch Fehlerkorrektur und dem Nachweis einer hohen Informationsdichte (2 Bit pro Nukleotid), wurde im Jahr 2018 eine Speicherkapazität von ca. 200 Megabyte erreicht, wodurch das Potenzial dieser Vision immer realistischer wurde (Shamorony & Heckel, 2022, 4).
Datenspeicherung auf der DNA
Um zu verstehen, wie Informationen auf der DNA gespeichert, konserviert und wieder ausgelesen werden können, muss zunächst die Struktur der DNA angesehen werden. Die Desoxyribonukleinsäure, kurz DNA, besteht aus Basen, Desoxyribose (Zucker) und einer Phosphatgruppe und ist Träger der genetischen Information des Menschen. Es gibt vier verschiedene Basen: Adenine, Guanine, Cytosine und Thymine. Eine Base bildet zusammen mit einem Phosphat und einer Desoxyribose ein Nukleotid. Mehrere Nukleotide aneinandergereiht bilden einen DNA-Strang. Die bekannte Doppelsträngige Helixform der DNA wird durch die Verbindung der komplementären Basen Adenin und Thymin sowie Guanin und Cytosin gebildet. Die Abfolge der Basen stellt die codierte Information dar. Dies ermöglicht die Speicherung von Daten auf der DNA, indem diese in den genetischen Code übersetzt werden (De Silva & Ganegoda, 2016, 2-3). Infolgedessen muss DNA geschrieben und wieder ausgelesen werden. Dieser Vorgang wird als Synthese und Sequenzierung bezeichnet (Hughes & Ellington, 2017, 1).
Kodierung
Es gibt bereits viele verschiedene Methoden zur Kodierung der Daten. Im Allgemeinen funktionieren sie jedoch alle nach dem gleichen Schema. Zunächst wird der Binärcode der Dateien in quaternäre Zahlen aufgeteilt. Das bedeutet, dass jeweils vier aufeinanderfolgende Nullen und Einsen des Binärcodes zusammengefasst werden. Jede Base entspricht einer quaternären Zahl, wodurch der binäre Code in den genetischen Code übersetzt werden kann. Dieser Schritt wird als Source Coding bezeichnet. Zur Kodierung von Textdateien können zum Beispiel folgende Methoden verwendet werden: arithmetische Kodierung, Wörterbuch-Kodierung oder Huffman-Kodierung. Von den genannten Beispielen ist die Huffman-Kodierung sehr populär in der Anwendung. Hier werden häufig vorkommende Symbole mit einer kurzen Codierung und selten vorkommende Symbole mit einer längeren Codierung versehen. Dadurch wird die durchschnittliche Länge des Codes für den zu speichernden Text reduziert. Auf diese Weise wird gleichzeitig die zu speichernde Datenmenge komprimiert, was einen weiteren Vorteil darstellt. Darüber hinaus sind alle Sonderzeichen in der Kodierung enthalten (Dong et al., 2020, 1096-1098).
Informationsfluss in der DNA-basierten Informationsspeicherung (In Anlehnung an (Dong et al., 2020, 1096))
Die Kanalcodierung wird verwendet, um die Informationen vor Verzerrungen während der Übertragung zu schützen. Solche Verzerrungen können beispielsweise bei der Synthese oder der Sequenzierung auftreten. Um die Informationen vollständig wiederherstellen zu können, wird Redundanz erzeugt. Die Redundanz kann entweder physisch oder logisch sein. Physikalische Redundanz entsteht durch die Anfertigung von Kopien desselben DNA-Strangs, so dass es mehrere Kopien mit der gleichen Information gibt. Bei der logischen Redundanz hingegen werden sogenannte Prüfzeichen hinzugefügt, um Fehler erkennen und korrigieren zu können. Mit der Basenfolge, in der die Informationen enthalten sind, kann nun eine synthetische DNA erstellt werden, die demzufolge ebenfalls die zuvor kodierte Information enthält (Dong et al., 2020, 1096-1098).
Lagerung/Speicherung
Da DNA zum Beispiel durch UV-Strahlung, Wasser oder Enzyme zersetzt wird, muss sie geschützt werden, damit die auf ihr gespeicherten Daten nicht verloren gehen. Während die Halbwertszeit der DNA in Fossilien und unter perfekten Bedingungen mehrere 100 oder gar 1000 Jahre beträgt, verschlechtert sich dieser Wert drastisch, wenn die DNA Feuchtigkeit ausgesetzt wird (DNA DATA STORAGE ALLIANCE, 2021, 27). Synthetisierte DNA kann in vivo oder in vitro gelagert werden (Dong et al., 2020, 1096). Der Begriff “in vivo” kommt aus dem Lateinischen und bedeutet “an einem lebenden Objekt”, während “in vitro” “im Gefäß” bedeutet. Daraus folgt, dass bei der in vivo DNA-Speicherung die DNA in einem lebenden Organismus enthalten ist. Bei der in vitro DNA-Speicherung wird die DNA außerhalb eines Organismus gespeichert (Elder, 1999 & von Reininghaus, 1999).
Als eine der besten Varianten für die Speicherung von DNA gelten Sporen (Cox, 2001, 247). Sporen sind einzellige Fortpflanzungsorgane und -einheiten in Pflanzen und Pilzen (Sporen – Lexikon der Biologie, n.d.). Sie werden als eine sehr gute Möglichkeit angesehen, da sie auch unter sehr lebensfeindlichen Bedingungen überleben können und daher auch nach mehreren Millionen Jahren noch abrufbar wären. Außerdem vermehren sich die Sporen selbst weiter und erzeugen so automatisch Kopien der gespeicherten Daten. Für zusätzlichen Schutz können die Sporen in Bernstein eingeschlossen werden (Cox, 2001, 247).
Zu den möglichen in vitro Methoden für die längerfristige Lagerung von DNA gehören der molekulare und der makroskopische Schutz. Bei der so genannten chemischen Verkapselung wird der molekulare Ansatz verwendet. Dabei werden die einzelnen DNA-Moleküle in ein Matrixmaterial eingebettet, das die Diffusion von Wasser und Sauerstoff zu den einzelnen DNA-Molekülen verhindern soll. In den meisten Fällen bestehen die Matrizen aus anorganischen Materialien wie Glas. Beim makroskopischen Ansatz wird die DNA getrocknet und in Gegenwart eines reaktionsträgen Gases, beispielsweise in einer Metallkapsel, gelagert. Dieses Verfahren wird auch als physikalische Verkapselung bezeichnet. Solange die Unversehrtheit des Behälters gewährleistet werden kann, lassen sich chemische Reaktionen der DNA-Moleküle vermeiden (DNA DATA STORAGE ALLIANCE, 2021, 28).
Vor- und Nachteile
Die Datenspeicherung in der DNA hat viele Vorteile, die die DNA zur Zukunft der Datenspeicherung machen. Der größte Vorteil ist die parallele Berechnung. Mit der DNA können viele Operationen gleichzeitig ausgeführt werden, was bedeutet, dass die Leistungsrate sehr hoch ist. Hinzu kommt die effiziente Nutzung von Speicher und dem verfügbaren Platz. Beispielsweise passen rund 10 Billionen DNA-Moleküle auf einen Kubikzentimeter, was theoretisch einem Computer mit 10 Terabyte Speicherplatz entspricht (El-Seoud & Ghoniemy, 2017). Ein weiterer positiver Aspekt sind die geringen Energiekosten für die korrekte Lagerung im Vergleich zu herkömmlichen Speichermedien. Sie kann Jahrtausende lang überleben und ist zudem wesentlich umweltfreundlicher, da sie biologisch abbaubar ist und für die Erzeugung keine Schwermetalle oder seltene Elemente verwendet werden (Zhirnov et al., 2016).
Neben den genannten Vorteilen gibt es auch Nachteile, die die Nutzung der DNA mit sich bringt. Zum einen ist die Arbeit mit massiven Datensätzen ein Nachteil, da hierbei die Fehlerwahrscheinlichkeit exponentiell ansteigt. Zudem stellt die Analyse der Ergebnisse Schwierigkeiten dar, da es sich um Milliarden von Molekülen handelt, die miteinander interagieren (Akram et al., 2018). Der Durchsatz beim Lesen und Schreiben von Daten ist ein weiterer Nachteil sowie die Kosten für die Speicherung, welche derzeit zwischen 800$ und 5000$ liegen (Meiser et al., 2022). Ein weiterer wichtiger Aspekt sind die anfallenden Kosten für die Labore und die biologischen Experimente, die durchgeführt werden müssen, um die Speicherung der DNA überhaupt zu ermöglichen. Der größte Vorteil ist zugleich auch ein Nachteil, da die parallelen Berechnungen extrem viel Zeit in Anspruch nehmen (El-Seoud & Ghoniemy, 2017).
Anwendungen
Es gibt zahlreiche Möglichkeiten, wie die DNA in Zukunft für Daten eingesetzt werden kann. Die Forschungen hierfür gehen in verschiedenste Richtungen, aber der relevanteste Aspekt ist die Speicherung von Daten. Erste Studien haben Daten mit einer Größe von 200 Megabyte auf der DNA gespeichert. Weitere Forschungen haben beispielsweise 2000 Bilder als Kunstwerk oder ein Musikalbum auf der DNA kodiert. Anfängliche Berechnungen der Forschungen zeigen, dass alle Informationen, die in einem Jahr global erzeugt werden, auf ca. 4g von DNA gespeichert werden könnten, was den Vorteil der optimalen Nutzung von Speicher und Platz der DNA verdeutlicht (Boyle & Bergamin, 2020 & 2018).
Eine Einsatzmöglichkeit von DNA als Informationsträger ist das Barcoding bzw. das sogenannte Product Tagging. Bisher sind Barcodes auf Produkten oder auch QR-Codes bekannt, allerdings können diese Codes beispielsweise nicht für Tabletten oder Textilien verwendet werden. Hierfür bietet die DNA die Lösung der molekularen Barcodes. Das ist eine feste Menge an DNA, die den Bausteinen von Substanzen hinzugefügt wird. Diese müssen über den ganzen Lebenszyklus des Produktes intakt bleiben und ungiftig sein. Anhand der molekularen Barcodes kann Information zu einem Objekt hinzugefügt werden, ohne dass es für das menschliche Auge sichtbar ist (Meiser et al., 2022).
Die Erweiterung des Barcoding und der Datenspeicherung ist die DNA of Things (DoT), was sich von “Internet of Things” ableitet. DoT ist eine Mischung der beiden Ansätze und kann beispielsweise für das Labeling von medizinischen Produkten genutzt werden oder auch für Materialien, die eine Produktkontrolle benötigen. Für die Kontrolle wird die Tatsache genutzt, dass die Information nicht sichtbar ist (Koch et al., 2020).
Weitere Einsatzmöglichkeiten der DNA sind beispielsweise ein Random Number Generator oder die Kryptografie, wobei versucht wird, eine Nachricht in der DNA zu verschlüsseln. Hier wird momentan an einem Ansatz geforscht, wo menschliche DNA mit der Nachrichten-DNA gemischt wird, um die Nachricht zu verschleiern. Jedoch hat auch dieser Ansatz sehr lange Lesezeiten, was momentan noch ein generelles Problem bei der Nutzung von DNA ist (Meiser et al., 2022).
Aktuelle Entwicklungen und Ausblick
Wissenschaftler, wie auch Unternehmen, sind sehr daran interessiert, diese Technologie zu perfektionieren und an den Markt zu bringen. Seit 2020 gibt es die DNA Data Storage Alliance (DDSA), welche sich dieser Disziplin stellt. Gründer sind Unternehmen wie Illumina, Microsoft, Twist Bioscience und Western Digital. Ziel des Bündnisses ist es, auf Basis von DNA als Speichermedium ein interoperables Speichersystem zu schaffen und dieses auch zu fördern. Dazu gehören Spezifikationen und Standards in Bezug auf Kodierung, physische Schnittstellen, Aufbewahrung und Dateisysteme, die im Rahmen der Forschung entstehen sollen (DNA DATA STORAGE ALLIANCE, 2021, 5).
Im Oktober 2022 veröffentlichte die DDSA konkrete Anwendungsfälle für Fahrerassistenzsysteme (ADAS). Potential sieht die Allianz daher, weil Fahrerassistenzsysteme durch Sensorik Unmengen an Daten produzieren. Hohe Raten sorgen dafür, dass autonome Fahrzeuge bei Spitzenauslastung etwa 15.000 Gigabyte in einem Zeitraum von acht Stunden erzeugen. Bei steigenden Autoverkäufen wird vermutet, dass im Jahr 2025 mindestens 400 Millionen vernetzte Personenkraftwagen unterwegs sein werden. Daraus entsteht ein monatlicher Datenverkehr von zehn Exabyte. In Zukunft wird die Geschwindigkeit der Datenerzeugung ebenso durch steigende Automatisierung und zusätzliche Sensorik beschleunigt. Gründe, die laut DDSA, für die Nutzung von DNA-Speichersystemen sprechen, ist der Bedarf an hochparallel Berechnungen zum Beispiel für eine Suche oder Musterabgleich, trotz langsamer Leselatenz. Andere Archivierungsanforderungen für ADAS wie eine hohe Kapazität, belastbare und unveränderbare Speicherung mit niedrigem Total Cost of Ownership sprechen ebenfalls dafür (DNA DATA STORAGE ALLIANCE, 2022, 6-13).
Es ist sicher, dass die Speicherung von Daten auf der DNA ein großes Potenzial aufweist. Jedoch müssen für den alltäglichen Gebrauch noch einige Hindernisse überwunden werden. Vor allem die Kosten für die DNA Synthese und Sequenzierung sind große Faktoren, welche die aktuelle Nutzung verzögern. Prognosen zufolge sollen die Kosten für die Datenspeicherung in der DNA schon im Jahr 2030 auf 1 Dollar pro Terabyte sinken. Daher wird weiter an Methoden zur Verbesserung dieser Technologien geforscht (DNA DATA STORAGE ALLIANCE, 2021, 32).
Es bleibt abzuwarten, ob das Potenzial ausgeschöpft wird.
Quellen
Akram, F., Haq, I. U., Ali, H., & Laghat, A. T. (2018). Trends to store digital data in DNA: an overview. Molecular biology reports (Vol. 45).
Bergamin, F. (2018, April 20). Entire music album to be stored on DNA. ETH Zürich. Retrieved February 13, 2023, from https://ethz.ch/en/news-and-events/eth-news/news/2018/04/entire-music-album-to-be-stored-on-DNA.html
Boyle, A. (2020, February 24). Artist pays tribute to DNA pioneer Rosalind Franklin with DNA-laced paint and DNA-coded images. GeekWire. Retrieved February 13, 2023, from https://www.geekwire.com/2020/artist-dna-pioneer-rosalind-franklin/
Cox, J. P.L. (2001, July). Long-term data storage in DNA. TRENDS in Biotechnology, 19(7).
De Silva, P. Y., & Ganegoda, G. U. (2016). New Trends of Digital Data Storage in DNA. BioMed research international. https://doi.org/10.1155/2016/8072463
DNA-Aeon provides flexible arithmetic coding for constraint adherence and error correction in DNA storage. (2023, February 06). Nature Communications, (2023) 14:628. https://doi.org/10.1038/s41467-023-36297-3
DNA DATA STORAGE ALLIANCE. (2021). Preserving our digital legancy: An introduction to DNA data storage.
DNA DATA STORAGE ALLIANCE. (2022, October). Archival Storage Usage Analysis, Requirements, and Use Cases: Part 1 – Advanced Driver Assistance Systems.
Dong, Y., Sun, F., Ping, Z., Ouyang, Q., & Qian, L. (2020). DNA storage: research landscape and future prospects. National Science Review, 7(6). https://doi.org/10.1093/nsr/nwaa007
Earth Observation Center – 10 000 000 Gigabyte Sentinel am EOC. (2019, February 12). DLR. Retrieved February 10, 2023, from https://www.dlr.de/eoc/desktopdefault.aspx/tabid-13247/23165_read-54030/
Elder, K. (1999). in vitro – Lexikon der Biologie. Spektrum der Wissenschaft. Retrieved February 11, 2023, from https://www.spektrum.de/lexikon/biologie/in-vitro/34443
El-Seoud, S., & Ghoniemy, S. (2017). DNA Computing: Challenges and Application. International Journal of Interactive Mobile Technologies (iJIM). 10.3991/ijim.v11i2.6564
Hughes, R. A., & Ellington, A. D. (2017). Synthetic DNA Synthesis and Assembly: Putting the Synthetic in Synthetic Biology. Cold Spring Harbor perspectives in biology, 9(1). http://dx.doi.org/10.1101/cshperspect.a023812
Koch, J., Gantenbein, S., Masania, K., Stark, W. J., Erlich, Y., & Grass, R. N. (2020). A DNA-of-things storage architecture to create materials with embedded memory. Nature biotechnology.
Konitzer, F. (2021, Janary). Daten speichern mit DNA. zfv 1/2021. 10.12902/zfv-0338-2020
Meiser, L., Nguyen, B., Chen, Y., Nivala, J., Strauss, K., Ceze, L., & Grass, R. (2022). Synthetic DNA applications in information technology. https://doi.org/10.1038/s41467-021-27846-9
Nguyen, M., Morgen, J., Kleinaltenkamp, M., & Gabriel, L. (Eds.). (2023). Marketing und Innovation in disruptiven Zeiten. Springer Fachmedien Wiesbaden GmbH.
Potthoff, J., Wezel, J. V., Razum, M., & Walk, M. (2014, January). Anforderungen eines nachhaltigen, disziplinübergreifenden Forschungsdaten-Repositoriums.
Shamorony, I., & Heckel, R. (2022). Information-Theoretic Foundations of DNA Data Storage. In Foundations and Trends in Communications and Information Theory: Vol. 19 (19th ed.). 10.1561/0100000117
Sporen – Lexikon der Biologie. (n.d.). Spektrum der Wissenschaft. Retrieved February 11, 2023, from https://www.spektrum.de/lexikon/biologie/sporen/62944
Tenzer, F. (2022, 05 09). Prognose zum weltweit generierten Datenvolumen 2025. statista. https://de.statista.com/statistik/daten/studie/267974/umfrage/prognose-zum-weltweit-generierten-datenvolumen/
von Reininghaus, A. (1999). in vivo – Lexikon der Biologie. Spektrum der Wissenschaft. Retrieved February 11, 2023, from https://www.spektrum.de/lexikon/biologie/in-vivo/34453
Zhirnov, V., Zadegan, R. M., Sandhu, G. S., Church, G. M., & Hughes, W. L. (2016). Nucleic acid memory.
You must be logged in to post a comment.