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

9. March 20239. March 2023 ~ Marilena Brink

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

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

Was passiert ist

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

Wie Ticketmaster sich auf den Ansturm vorbereitete

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

Thundering Herd stürmt das Ticketmaster System

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

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

Cascading Failure führt zu Systemfehlern und Abstürzen

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

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

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

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

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

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

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

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

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

1. Horizontales skalieren

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

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

Pre-Scaling über eine Kapazitätsplanung:

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

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

Auto-Scaling:

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

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

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

2. Bot Management

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

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

Rate Limiting

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

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

Anzeichen für Bot Traffic früh erkennen

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

3. Message Queues

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

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

4. Caching

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

5. Testen, Testen, Testen

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

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

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

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

Lessons Learned für Ticketmaster und Fazit

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

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

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

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

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

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

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

Hauptquellen:

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

How Riot Games created their own internet

7. March 20237. March 2023 ~ Fabian Reißer

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

The Problems

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

Buffering

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

ISPs

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

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

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

Routers

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

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

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

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

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

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

Riot Direct

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

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

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

The Results

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

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

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

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

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

Conclusion

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

References

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

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

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

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

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

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

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

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

AMD EPYC 9004 – a small scale supercomputer?

5. March 20235. March 2023 ~ Maximilian von Detten

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

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

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

What would such a possible max spec system look like?

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

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

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

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

But what can such performance even be used for?

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

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

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

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

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

Sources:

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

3. March 20234. March 2023 ~ Marvin Blessing

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

Introduction
Requiring compute beyond Moore’s Law
- Increase in AI computation
- The new Moore’s Law
Scaling AI computation
Conclusion and outlook
Sources

Introduction

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

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

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

Requiring compute beyond Moore’s Law

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

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

Increase in AI computation

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

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

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

The new Moore’s Law

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

Scaling AI computation

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

GPT-3 Example

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

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

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

Distributed training, but how?

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

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

The trend continues

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

Conclusion and outlook

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

Sources

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

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

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

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

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

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

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

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

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

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

Fog Computing: Solving the limitations of Cloud and Edge Computing

27. February 202327. February 2023 ~ Andreas Nicklaus ~ Leave a comment

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.

What is the Fog?
How does Fog Computing improve system architecture?
Smart Cities: An example for Fog Computing applications
Obstacles for the implementation of Fog Computing
Conclusion
Sources

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.

Pyramid graph showing edge devices on the bottom, fog nodes in the middle and cloud data centers at the top. — 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.

A table showing a comparison of the characteristics of Cloud, Fog and Edge. The attributes are latency, scalability, distance, data analysis, computing power and interoperability. The relevant content is described in the following paragraphs. — 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.

Sources

IBM Blog – What is fog computing?
https://www.ibm.com/blogs/cloud-computing/2014/08/25/fog-computing/
E-SPIN Group – The Examples of Application of Fog Computing
https://www.e-spincorp.com/the-examples-of-application-of-fog-computing/
TechTarget – What is fog computing?
https://www.techtarget.com/iotagenda/definition/fog-computing-fogging
YourTechDiet – Brief About The Challenges with Fog Computing
https://yourtechdiet.com/blogs/fog-computing-issues/
GeeksForGeeks – Difference Between Cloud Computing and Fog Computing
https://www.geeksforgeeks.org/difference-between-cloud-computing-and-fog-computing/
Sam Solutions – Fog Computing vs. Cloud Computing for IoT Projects
https://www.sam-solutions.com/blog/fog-computing-vs-cloud-computing-for-iot-projects/
AWS Documentation – Regions and Zones
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html
AWS Documentation – AWS Outposts Family
https://aws.amazon.com/outposts/
AWS Documentation – AWS Global Infrastructure
https://aws.amazon.com/about-aws/global-infrastructure/
Heavy.ai – Fog Computing Definition
https://www.heavy.ai/technical-glossary/fog-computing
Akamai – What is edge computing?
https://www.akamai.com/our-thinking/edge-computing
Cloudflare – What is edge computing?
https://www.cloudflare.com/learning/serverless/glossary/what-is-edge-computing/
Cloudcomputing Insider – Was ist Fog Computing?
https://www.cloudcomputing-insider.de/was-ist-fog-computing-a-736757/
CloudPing – AWS Latency Monitoring
https://www.cloudping.co/grid/p_50/timeframe/1W
Vercel – Edge Functions
https://vercel.com/features/edge-functions
SpiceWorks – What Is Fog Computing? Components, Examples, and Best Practices
https://www.spiceworks.com/tech/edge-computing/articles/what-is-fog-computing/
Welotec – Edge Computing, Fog Computing or both?
https://www.welotec.com/edge-computing-fog-computing-or-both/

The Fun and Easy Way to Understand Monitoring

Keeping an Eye on the system by Danial Eshete

27. February 20234. March 2023 ~ Danial Eshete

Abstract

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.

Continue reading →

Pages: 1 2 3

How Edge Computing is moving the Cloud closer to the User

27. February 20232. March 2023 ~ Nikolai Thees

Did you know clouds have sharp edges?

What is Edge Computing?

Let’s say you want to deploy a web application.

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.

Written by: Nikolai Thees

Sources

[1] Fireship – Is “edge” computing really faster?
https://www.youtube.com/watch?v=yOP5-3_WFus

[2] AWS Documentation – Regions and Zones – AWS EC2
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html

[3] IONOS Digital Guilde – What is a CDN (Content Delviery Network)?
https://www.ionos.com/digitalguide/hosting/technical-matters/what-is-a-cdn-content-delivery-network/

[4] Akamai – How Does Edge Computing Work
https://www.akamai.com/our-thinking/edge-computing

[5] Cloudflare – What is edge computing?
https://www.cloudflare.com/learning/serverless/glossary/what-is-edge-computing/

[6] CloudPing – AWS Latency Monitoring
https://www.cloudping.co/grid/p_98/timeframe/1Y

[7] Vercel Documentation – Supported Regions for the Edge Network
https://vercel.com/docs/concepts/edge-network/regions

[8] Cloudflare Blog – Introducing Cloudflare Workers
https://blog.cloudflare.com/introducing-cloudflare-workers/

[9] Cloudflare Blog – Building With Workers KV, a Fast Distributed Key-Value Store
https://blog.cloudflare.com/building-with-workers-kv/

[10] Cloudflare Blog – Cloudflare Queues: globally distributed queues without the egress fees
https://blog.cloudflare.com/introducing-cloudflare-queues/

[11] Cloudflare Blog – Announcing D1: our first SQL database
https://blog.cloudflare.com/introducing-d1/

[12] Cloudflare Blog – Announcing Cloudflare R2 Storage: Rapid and Reliable Object Storage, minus the egress fees
https://blog.cloudflare.com/introducing-r2-object-storage/

[13] TechCrunch – Akamai reaches for the cloud
https://techcrunch.com/2023/02/13/akamai-reaches-for-the-cloud/

[14] Akamai – Edge Compute Solutions
https://www.akamai.com/solutions/edge

[15] Fastly – Serverless compute environment
https://www.fastly.com/products/edge-compute

[16] AWS – On Premises Private Cloud
https://aws.amazon.com/outposts/

[17] Google Cloud – Google Distributed Cloud Edge overview
https://cloud.google.com/distributed-cloud/edge/latest/docs/overview

[18] AWS – Global Infrastructure
https://aws.amazon.com/about-aws/global-infrastructure/

[19] Cloudflare – Cloudflare Global Network
https://www.cloudflare.com/network/

[20] Akamai – Connected Cloud Computing Services
https://www.akamai.com/why-akamai

[21] Vercel – Edge Functions
https://vercel.com/features/edge-functions

Die Zukunft ist Serverless?

26. February 202326. February 2023 ~ Michael Partes

Überblick

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.

Quellen

[1] What is serverless? https://www.redhat.com/en/topics/cloud-native-apps/what-is-serverless

[2] What is Function-as-a-Service (FaaS)? https://www.redhat.com/en/topics/cloud-native-apps/what-is-faas

[3] The Pros and Cons of a Monolithic Application Vs. Microservices, https://www.openlegacy.com/blog/monolithic-application

[4] Serverless Architecture – The What, When and Why https://www.cloudnowtech.com/blog/serverless-architecture-the-what-when-and-why/

[5] Serverless vs Microservices: What Should You Choose For Your Product? https://www.ideamotive.co/blog/serverless-vs-microservices-architecture

[6] Was ist Serverless Computing? https://www.vodafone.de/business/featured/technologie/was-ist-serverless-computing/

[7] Introduction to Serverless Services https://blog.camelot-group.com/2022/05/introduction-to-serverless-services/

[8] Why Serverless Is the Future of Application Development https://www.arvato-systems.com/blog/why-serverless-is-the-future-of-application-development

[9] Serverless Computing: Deswegen sind Server nicht die Zukunft https://t3n.de/news/serverless-computing-deswegen-sind-server-nicht-die-zukunft-849986/

Gigantische Datenmengen auf der DNA

14. February 202314. February 2023 ~ Rebecca Westhäußer

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.