WebAssembly: Das neue Docker und noch mehr?

If WASM+WASI existed in 2008, we wouldn’t have needed to created Docker. That’s how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let’s hope WASI is up to the task!

Tweet, Solomon Hykes (Erfinder von Docker), 2019

Dieser Tweet über WebAssembly (WASM) des Docker-Erfinders gibt einen Hinweis auf die mögliche Innovationskraft dieser Technologie. Der vorliegende Artikel vermittelt zunächst die wichtigsten technischen Grundlagen von WebAssembly, welche zum weiteren Verständnis notwendig sind. Anschließend wird der WASI-Standard näher beleuchtet, welcher die Brücke zur Containervirtualisierung schlägt. Schließlich betrachten wir mit Krustlet (Kubernetes) und wasmCloud zwei existierende Cloud-Technologien, die zentral auf WebAssembly basieren.

Continue reading

SLOG – Deterministische Datenbanksysteme die Lösung für alle* Probleme?

*zumindest im Bereich georeplizierter Datenbanken

Wir leben in einer globalisierten Welt, in welcher wir Anwendungen auf der ganzen Welt nutzen können. Egal wo wir gerade sind, können wir auf diese Programme und Daten zugreifen. Doch diese Möglichkeit stellt Softwaresysteme heutzutage vor große Herausforderungen. Nutzer möchten so schnell wie möglich auf Daten zugreifen und gehen davon aus, dass die Daten, die sie bekommen auch korrekt und auf dem richtigen Stand sind. Um die Verfügbarkeit der Daten für die Nutzer zu erhöhen, werden moderne Datenbank- und Softwaresysteme repliziert. Das heißt es werden Kopien derselben Daten hergestellt und regelmäßig abgeglichen, um die Daten auf dem gleichen Stand zu halten. Moderne Anwendungen replizieren Daten also über geografische Regionen hinweg. Jedoch zwingen bestehende Datenbanksysteme, welche geografische Replikationen unterstützen, die Nutzer auf mindestens eines der folgenden Merkmale zu verzichten, um eine hohe Verfügbarkeit zu erreichen:

  • Strict Serilizability: Bei strikter Serialisierbarkeit scheinen die Operationen in einer bestimmten Reihenfolge zu erscheinen, die mit der Echtzeit-Reihenfolge der Operationen übereinstimmen. Das heißt wenn zum Beispiel Operation A abgeschlossen ist, bevor Operation B beginnt, sollte A in der Serialisierungsreihenfolge vor B erscheinen. Die Serialisierbarkeit ist der Ausführungsplan für die parallele Ausführung mehrere Transaktionen. Es gibt die Reihenfolge vor, in welcher die einzelnen Operationen der Transaktion ausgeführt werden und es verhält sich wie ein System, das auf einer einzigen Maschine läuft und die Transaktionen sequenziell verarbeitet.
  • Low-latency writes: Um strikte Serialisierbarkeit zu erreichen muss auf Schreibvorgänge mit geringer Latenz verzichtet werden. Um die strenge Serialisierbarkeit in georeplizierten Datenspeichern zu garantieren, muss es mindestens ein Koordinationsprotokoll geben, um einen Schreibvorgang auf alle Replikate zu übertragen. Genau diese Koordination ermöglicht zwar die strikte Serialisierbarkeit, erhöht aber die Latenzzeit bei jedem Schreibvorgang. Je weiter die Regionen voneinander entfernt sind, desto länger dauert es einen Schreibvorgang abzuschließen.
  • High transaction throughput: Im Allgemeinen wird die Geschwindigkeit eines Datenbanksystems anhand des Transaktionsdurchsatzes gemessen, ausgedrückt als Anzahl der Transaktionen pro Sekunde. In replizierten Datenbanken kann es zu einer bereichsübergreifenden Koordinierung kommen, das heißt wenn bei Lese- und Schreibvorgängen auf eine weiter entfernte Region zugegriffen werden muss. Normalerweise sind die mit dem Nutzer verbunden Daten stark auf den physischen Standort des Nutzers ausgerichtet. Beliebige Transaktionen können jedoch auf mehrere Datenelemente zugreifen, wobei jedes Datenelement in einer anderen Region verwaltet wird. Hier muss schließlich wieder eine regionsübergreifende Koordinierung stattfinden, dies ist zeitaufwändig. Das Zeitfenster in den kollidierenden Transaktionen nicht ausgeführt werden können ist groß und der Transaktionsdurchsatz verringert. 

Um die Probleme zu lösen, die sich zur Erfüllung der genannten Eigenschaften ergeben, gibt es unterschiedliche Ansätze. Ein Ansatz ist Determinismus. Was das genau heißt und wie es genau funktioniert wollen wir an dem System „SLOG“ genauer betrachten. SLOG ist laut dem Paper von Run et al. „SLOG: Serializable, Low-Latency, Geo-Replicated Transactions“ der erste Systementwurf, welcher alle drei genannten Eigenschaften erfüllt.

Nachdem im Folgenden die Probleme georeplizierter Datenbanken noch einmal genauer betrachtet werden, wird der Begriff Determinismus vor allem im Kontext von modernen Datenbanksystemen geklärt und das Prinzip wird anhand des Systems SLOG noch einmal genauer erläutert.

Was ist das Problem?

Die Probleme, die uns in replizierten Datenbanken begegnen, erschließen sich bereits aus der vorangegangenen Erklärung der drei Eigenschaften moderner Anwendungen. Im Folgenden wird das Ganze noch einmal Schritt für Schritt genauer betrachten und es wird klar, warum es zu diesen Problemen kommt.

Single-Node-Datenbanken – Datenbanken, die für eine einzige Maschine konzipiert wurden – funktionieren sehr gut. Wenn Kunde 2 den Artikel 3 kaufen möchte, werden diese zwei Items gelocked und erst dann sind die Änderungen möglich (vgl. Abbildung 1). In einem einfachen Datenbanksystem ist die Serialisierbarkeit also ohne großes Zutun garantiert und über die anderen zwei Eigenschaften muss sich gar nicht gekümmert werden, da diese in diesem Kontext noch gar nicht wirklich relevant sind.

Abbildung 1: Single-Node-DB

Bei Multi-Node-Datenbanken wird das ganze schon etwas schwieriger und es braucht ein bisschen mehr Anstrengung. Man spricht hierbei auch von einem Scalability Problem. Die Kunden und die Artikel sind nicht mehr wie im Single-Node-Beispiel auf einer Maschine, sondern auf vier Maschinen aufgeteilt. Jede Maschine nutzt nur den Code welcher relevant für ihn ist. Jedoch muss es irgendeine Kommunikation zwischen beiden Maschinen geben, die den Maschinen gegenseitig bestätig, dass jede Maschine das getan hat, was sie auch tun soll. Jede Maschine muss ihren Part der Transaktion eigenständig durchführen. Diese Kommunikationsproblem kann durch Locking oder auch durch eine Two-Phase-Commit-Protokoll gelöst werden (vgl. Abbildung 2). Hierbei ergibt sich jedoch aufgrund dieser Protokolle wieder ein neues Problem. Durch das gesamte Protokoll muss gelockt werden. Dies führt zu einer Reduzierung der Geschwindigkeit unserer Transaktionen, da die Zeiträume, über die die Locks gehalten werden müssen, lange sind.

Abbildung 2: Multi-Node-DB

Wenn wir jetzt aber repliziere Datenbanken haben, also Kopien der Datenbank auf der ganzen Welt verteilt, müssen solche Locks noch viel länger gehalten werden, was noch mehr Zeit benötigt.     

Durch das Nutzen von replizierten Datenbanken an verschiedenen Locations wird Nähe zu den Nutzern erreicht und um dadurch die Verfügbarkeit zu steigern. Hierbei wird eine Transaktion erst in der eigentlichen Location durchgeführt und danach – genauer gesagt nach dem das Commit-Protokoll durchgeführt wird – wird die die Datenbank synchron in allen Locations auf der ganzen Welt repliziert (vgl. Abbildung 3). Das Problem ist hier, wie bereits erwähnt, dass die Locks sehr lange gehalten werden müssen, bis die Replikation abgeschlossen ist.

Abbildung 3: Georeplizierte DB

War es bei den Multi-Node-Datenbanken noch so, dass die Latenz vom Commit-Protokoll das Problem war, ist es bei replizierten Datenbanken nun die Latenz unseres Replikationsprotokolls. Beide Protokolle verursachen Latenzen durch das Halten von Locks.

Genau diese Herausforderung kann durch Determinismus gelöst werden.   

Was ist Determinismus im Kontext von Datenbanken?

Determinismus gibt es in allen möglichen Fachgebieten, wie z.B. der Linguistik, der Biologie oder auch der Theologie. Laut Wikipedia ist „der Determinismus (von lateinisch determinare ‚festlegen‘, ‚Grenzen setzen‘, ‚begrenzen‘) die Auffassung, dass alle – insbesondere auch zukünftige – Ereignisse durch Vorbedingungen eindeutig festgelegt sind.“ Diese Definition trifft es im Zusammenhang mit verteilten Datenbanksystemen eigentlich schon ganz gut. Denn das ist was versucht wird in deterministischen Systemen zu erreichen. Genauer gesagt, wenn zwei getrennte Kopien des Systems die gleiche Eingabe sehen, dann sind sie in der Lage diese Eingabe unabhängig voneinander zu verarbeiten und aufgrund des Determinismus garantiert die gleiche Ausgabe (den gleichen Endzustand) zu ergeben.

Lange war die stärkste Garantie in Datenbanksystemen die Serialisierbarkeit. Hierbei wird sichergestellt, dass der Endzustand des Datenbanksystems auch bei der gleichzeitigen Verarbeitung vieler Transaktionen, dem entspricht, als hätte es alle Transaktionen seriell verarbeitet. Jedoch wird hierbei keine Garantie übernommen, in welcher seriellen Reihenfolge die Transaktionen verarbeitetet werden. Bei deterministischen Systemen wird aber die Äquivalenz einer seriellen Reihenfolge garantiert. Es gibt also eine Verarbeitung von Transaktionen in einer einzigen vorbestimmten seriellen Reihenfolge. Dadurch gibt es nur einen möglichen Zustand, in dem sich das System befinden kann, trotz des Vorhandenseins von potenziell nicht-deterministischem Code in der Transaktionslogik.

Um nur einen möglichen Endzustand zu erreichen, müssen moderne deterministische Datenbanksysteme bei einem Anfangszustand und einer definierten Eingabe in das System, die Eingaben vorverarbeiten.

Normalerweise arbeiten verschiedene Kommunikations-Threads, die es in bestehenden nicht-deterministischen Datenbanksystemen gibt, unabhängig voneinander. Für deterministische Datenbanksysteme ist diese Architektur nicht praktikabel, da Determinismus nur garantiert werden kann wenn es eine klare, allgemeine vereinbarte Eingabe gibt. Um diese Garantie aber zu erfüllen, muss eine Aufzeichnung der Eingabe erstellt werden, nach der sich das gesamte System richten kann. In einer Ein-Maschinen-Architektur zum Beispiel kann dies erreicht werden, in dem alle Transaktionen durch einen Thread geleitet werden, der die Eingabetransaktionen in der Reihenfolge aufzeichnet, in der er sie beobachtet.

Für die Erstellung eines solchen deterministischen Ausführungsplans für mehrere replizierte Datenbanksysteme im Vergleich zu herkömmlichen nichtdeterministischen Systemen ist mehr Wissen über die Transaktion erforderlich, bevor sie verarbeitet werden kann. Vor allem aber muss die gesamte Transaktion während des Planungsprozesses vorhanden sein. Außerdem erfordert die Vorausplanung in der Regel Kenntnisse darüber, auf welche Daten eine Transaktion zugreifen wird. Dieses Wissen wird entweder statisch aus der Inspektion des Transaktionscodes abgeleitet, durch konservative Schätzungen vorgenommen oder es werden Teile der Transaktion spekulativ ausgeführt. In georeplizierten, hochskalierbaren Systemen kann dies zum Beispiel durch ein Protokoll wie Paxos geschehen. Hierbei werden alle Transaktionen vor der Verarbeitung durch dieses Protokoll geleitet, um einen Konsensus über das System hinweg zu erzielen. Dies hat jedoch den Nachteil, dass jede Transaktion die regionsübergreifende Latenzzeit für die Ausführung von Paxos über die Regionen hinweg bezahlen muss.

Jedes System sieht in einem deterministischen System durch ein Konsensus-Protokoll wie Paxos dieselbe Eingabetransaktion, und solange sie dieselbe Eingabe sehen, werden sie in denselben Endzustand gelangen. Die einzige Koordination, die in einem deterministischen Datenbanksystem noch stattfinden muss, ist die Kommunikation, die erforderlich ist, um sich über die Eingabe in das System zu einigen. Jegliche andere Kommunikation wie zum Beispiel Locking oder Two-Phase-Commit-Protokolle werden dann nicht mehr benötigt und Determinismus verringert dadurch die Latenzzeit und verbessert den Durchsatz.

Die einzige Latenz, die wir jetzt noch haben ist die des Konsensus-Protokolls. Dies kann mit dem System SLOG gelöst werden, welches noch diesen Schritt weiter geht und versucht die Latenz, verursacht durch das globale Konsensus-Protokoll, zu entfernen.

Wie funktioniert SLOG?

SLOG ist nicht der einzige deterministische Ansatz. Jedoch ist SLOG der einzige Ansatz, welcher den globalen Konsensus eliminiert und dadurch alle drei Eigenschaften garantieren kann. Dieses System entfernt den globalen Paxos-Prozess, um die Latenzzeit zu verringern. Im Folgenden wollen wir SLOG oberflächlich betrachten und sehen wie SLOG diesen Schritt im Vergleich zu herkömmlichen deterministischen Ansätzen weitergeht.

Wie schafft es SLOG nun dieses Konsensus-Protokoll abzuschaffen? SLOG verwendet eine Master-orientierte Architektur. Hierbei wird jedes Datenelement in einer sogenannten „Home“-Region oder Heimatregion verwaltet, was bedeutet, dass jeder Datensatz einen primären Speicherort besitzt. Schreib- und linearisierbare Lesevorgänge eines Datenelements müssen an seine Heimatregion gerichtet sein und am primären Speicherort verarbeitet werden. Eine Region in SLOG ist eine Gruppe von Servern, die über ein Netzwerk mit niedriger Latenz verbunden sind. Jede SLOG-Region enthält eine Reihe von Servern, auf die die in dieser Region gespeicherten Daten aufgeteilt (und repliziert) werden. Ein Teil dieser Daten wird von dieser Region beherrscht (sie ist die Heimatregion für diese Daten) und der Rest ist eine Kopie von Daten aus einer anderen Heimatregion. Jedes Datenelement hat also seine primäre Location (Heimatregion), was so viel bedeutet wie Nutzer in Berlin haben ihre primäre Location in Berlin, Nutzer in Sydney haben ihre primäre Location in Sydney. Wenn ich als Berliner nun Daten aus Sydney lesen möchte, muss ich die Daten auch aus der Region Sydney lesen, weil diese Up-to-date sind.

Die Transaktionen in SLOG werden basierend auf dieser Aufteilung in Heimatregionen in zwei Kategorien eingeteilt:

  • Single-Home: Die Daten, auf die zugegriffen werden soll, haben ihr Home-Replika in derselben Region
  • Multi-Home: Die Daten, auf die zugegriffen werden soll, haben ihr Home-Replika in unterschiedlichen Regionen

Lese- und Schreibzugriffe auf nahe gelegene Daten erfolgen schnell und ohne regionsübergreifende Kommunikation. Für Lese- und Schreibvorgänge auf entfernte Daten sowie für Transaktionen, die auf Daten aus mehreren Regionen zugreifen, einer Multi-Home-Transaktion, fallen jedoch regionsübergreifende Kommunikationskosten an. Die Ausführung von Multi-Home-Transaktionen stellen auch das technisch schwierigste Problem bei der Entwicklung von SLOG dar. Das Ziel besteht darin, strenge Serialisierungsgarantien und einen hohen Durchsatz bei einer potenziell großen Anzahl von Multi-Home-Transaktionen aufrechtzuerhalten, auch wenn diese auf konkurrierende Daten zugreifen und eine Koordinierung über physisch entfernte Regionen hinweg erfordern.

Auch SLOG verwendet ein Koordinationsprotokoll, um denselben Endzustand zu erreichen und nutzt einen solchen deterministischen Ausführungsrahmen wie oben beschrieben, um Skalierbarkeits- und Durchsatzbeschränkungen zu überwinden. Jedoch ersetzt SLOG das globale Protokoll durch ein regionales Protokoll. In SLOG wird der globale, auf Paxos-basierte, Log entfernt und durch ein lokales Log-Protokoll, welches ebenfalls auf Paxos basiert, ersetzt. Jede Region unterhält ein lokales Eingabeprotokoll, das über Paxos auf ihren Servern implementiert wird. Dieses lokale Protokoll enthält nur Transaktionen, die voraussichtlich Daten verändern, die in dieser Region verwaltet werden. Dieses Eingabeprotokoll wird in Batches an alle anderen Regionen gesendet. Jeder Batch ist mit einer Sequenznummer gekennzeichnet und die anderen Regionen verwenden diese Sequenznummer, um sicherzustellen, dass sie keine Chargen aus dieser Region übersehen haben. Auf diese Weise ist jede Region schließlich in der Lage das vollständige lokale Protokoll von jeder anderen Region zu rekonstruieren

Angenommen wir haben eine Transaktion, welche nur auf Datenelemente aus einer Region zugreift (Single-Home-Transaktion), sieht das ganze wie in der folgenden Abbildung 4 aus:

Abbildung 4: SLOG-Single-Home-Transaction

Wenn nun eine Transaktion auf Datenelemente aus zwei verschieden Regionen auftritt (T3 und T5 in Abbildung 5), wird diese aufgeteilt. Man spricht dann von einer Multi-Home-Transaktion:

Abbildung 5: Multi-Home-Transaction

Das globale Paxos-Log, welches zuvor in anderen deterministischen Ansätzen für Multi-regionale Datenbanken vorhanden war, weicht einer lokalen Version eines solchen Paxos-Protokolls pro Region, welches nur noch asynchron an die anderen Regionen repliziert wird (vgl. Abbildung 6).

Abbildung 6: SLOGs lokale Protokolle

Die lokalen Protokolle werden in jede andere Region repliziert und sind unterschiedlich verschachtelt, was dazu führt, dass T3 zum Beispiel in jeder Region anders angeordnet ist (vgl. Abbildung 7), was aber nicht weiter problematisch ist, da die Daten disjunkt sind. 

Abbildung 7: SLOGs lokale Transaktionsreihenfolge

Die Regionen weichen nicht voneinander ab, da

  1. das globale Protokoll in jeder Region die ursprüngliche Reihenfolge der lokalen Protokolle, die es verschachtelt, beibehält.
  2. lokale Protokolle aus verschiedenen Regionen auf disjunkte Daten zugreifen.
  3. die deterministische Verarbeitungsmaschine sicherstellt, dass die Transaktionen so verarbeitet werden, dass das Endergebnis dem Ergebnis der Verarbeitung in der seriellen Reihenfolge entspricht, die im globalen Protokoll der jeweiligen Region vorliegt.

Single-Home-Transaktionen (T1, T2, T4) werden übertragen, sobald sie in ihrer Primärregion abgeschlossen sind.

Multi-Home-Transaktionen (T3, T5), die auf Daten in mehreren Regionen zugreifen, müssen auf die asynchrone Replikation des Eingabeprotokolls warten, bevor sie die Transaktion festschreiben können (sie müssen auf das Eintreffen des Protokolls warten). Die Transaktion wird verarbeitet, sobald die entsprechenden Protokollsätze in jeder lokalen Region vorhanden sind.

Durch die Aufteilung in Single-Home und Multi-Home wird realisiert, dass die meisten Transaktionen schnell sind (Single-Home). Auch wenn die Transaktionen in mehreren Regionen etwas langsamer sind, verschlechtern sich die Latenzen und der Durchsatz nicht so stark.

Fazit

Determinismus verringert die Latenzzeit und verbessert den Durchsatz, in dem es die Möglichkeit lokaler Deadlocks ausschließt und verteilte Commit-Protokolle wie z.B. Two-Phase-Commit reduziert, beziehungsweise gänzlich eliminiert. Experimente haben gezeigt, dass der Durchsatz bei deterministischen Systemen im Vergleich zu nicht-deterministischen Systemen bei zunehmender Konkurrenz deutlich besser performt (vgl. Abbildung 8).

Abbildung 8: Durchsatzvergleich deterministischer und nicht-deterministischer Systeme

Herkömmliche deterministische Systeme haben zwar weiterhin mit Latenzen (bzgl. des Konsensus-Protokolls) zu kämpfen, jedoch gibt es Systeme wie SLOG, die versprechen auch diese Latenz zu verringern oder sogar zu eliminieren, um alle drei in der Einleitung genannten Eigenschaften zu erfüllen.  

Für Datenbankreplikationen ist der offensichtlichste Vorteil deterministischer Datenbanksysteme die Gewährleistung, dass, solange alle Replikate denselben Input erhalten, diese nicht voneinander abweichen. Weitere Vorteile in der deterministischen Architektur sind auf jeden Fall die Skalierbarkeit, die Modularität und die Gleichzeitigkeit. Nicht-deterministische Ausfälle führen in einem deterministischen System nicht zu einem Transaktionsabbruch, da die Datenbank ihren Zustand zum Zeitpunkt des Absturzes immer wiederherstellen kann, was diese Systeme auch robuster gegen Fehler macht.

Auf den ersten Blick scheinen deterministische Architekturansätze in verteilten Datenbanken die Lösung für viele bekannte Probleme, doch leider ist dieser Ansatz nicht für alle Datenbankanwendungen praktikabel. Da für den Planungsprozess die gesamte Transaktion vorhanden sein muss, sind deterministische Datenbanksysteme schlecht geeignet für ORM-Tools und andere Anwendungen, die Transaktionen nur in Teilen an die Datenbank übermitteln.

Deterministische Datenbanksysteme haben sich als vielversprechender Weg zur Verbesserung der Skalierbarkeit, Modularität, des Durchsatzes und der Replikation von transaktionalen Datenbanksystemen erwiesen. Leider bieten alle neueren Implementierungen nur begrenzte oder gar keine Unterstützung für interaktive Transaktionen, so dass sie in vielen bestehenden Implementierungen bisher nicht eingesetzt werden können.

Quellen

Abadi, Daniel J. „SLOG: Serializable, Low-Latency, Geo-Replicated Transactions“. Gehalten auf der CMU Database Group – Vaccination Database Tech Talks (2021), CARNEGIE MELLON UNIVERSITY, 1. Februar 2021. https://www.youtube.com/watch?v=TAdiilOOvNI&t=645s.

„Determinismus“. In Wikipedia, 25. Dezember 2021. https://de.wikipedia.org/w/index.php?title=Determinismus&oldid=218485694.

Faleiro, Daniel J. Abadi, Jose M. „An Overview of Deterministic Database Systems“. Zugegriffen 15. März 2022. https://cacm.acm.org/magazines/2018/9/230601-an-overview-of-deterministic-database-systems/fulltext.

Ren, Kun, Dennis Li, und Daniel J. Abadi. „SLOG: Serializable, Low-Latency, Geo-Replicated Transactions“. Proceedings of the VLDB Endowment 12, Nr. 11 (Juli 2019): 1747–61. https://doi.org/10.14778/3342263.3342647.

„Strict Serializability“. Zugegriffen 23. März 2022. https://jepsen.io/consistency/models/strict-serializable.

„Transaction throughput“. Zugegriffen 23. März 2022. https://docs.oracle.com/cd/E17276_01/html/programmer_reference/transapp_throughput.html.

Featured image: https://www.keysight.com/content/dam/keysight/en/img/prd/ixia-homepage-redirect/network-visibility-and-network-test-products/Network-Monitoring.jpg

Games aus der Cloud, wo sind wir und wohin geht die Reise?

Cloud Gaming – flüssiges Zocken auch mit schlechter Grafikkarte? (esports.com)

Was genau ist Cloud Gaming?

Cloud Gaming lässt sich mit Remote Desktops, Cloud Computing und Video on Demand Diensten vergleichen. Im Grunde beinhaltet Cloud Gaming das Streamen von Videospielen aus der Cloud zum Endkunden. Dabei erfasst und überträgt der Client seine Nutzereingaben (bspw. Maus, Tastatur, Controller) an den Server. Während dieser wiederum die Gesamtspielweltberechnung sowie Nutzereingaben-Auswertung bewältigt. Der Client stellt lediglich die Kapazität bereit, die Frames in der gewünschten Qualität gestreamt zu bekommen. Wesentliche Vorteile ergeben sich für leistungsschwache Geräte, während der offenkundige Nachteil in der Notwendigkeit einer gut ausgebauten Dateninfrastruktur liegt.

Neben Game Streaming gehört zum Cloud Gaming auch das Hosten von Serverinstanzen für Onlinespiele, sowie das Bereitstellen von Plattformdiensten (bspw. Bestenlisten, Chatsysteme, Authentifizierung etc.). Wesentlicher Bestandteil ist des Weiteren das Angebot von leistungsfähigen Downloadservern.

Plattformdienste und etablierte Nutzung der Cloud

Plattform- oder Onlinedienste bieten Schnittstellen, welche Spielemetadaten zur Verfügung stellen. Diese Dienste Umfassen in der Regel Funktionalitäten wie Bestenlisten, Chat- und Gruppensysteme sowie Onlinelobbys, aber auch Metadienste wie Authentifizierung, Analyse, Zuordnung von Spieleridentitäten und Matchmaking. Hierbei können Dienste sowohl öffentlich im Internet als auch intern für andere Dienste zur Verfügung stehen. Während diese Systeme zu Beginn ihres Aufkommens noch als einzelne Monolithen bereitgestellt wurden, bieten heutige Cloudbetreiber solche Dienste als Microservices an. Dies sorgt dafür, dass sich die hohe Skalierbarkeit der Cloud auf die Plattformdienste übertragen lässt. Diese Skalierbarkeit ist vor allem deshalb wichtig geworden, da der Spielemarkt in den letzten Jahren stark gewachsen ist und auch die Spiele selbst immer ressourcenintensiver geworden sind. Als gutes Beispiel kann man hierfür eine der größten Spieleplattformen hernehmen: Steam. Steam integriert viele der angebotenen Spiele in die eigenen Plattformdienste. Dies umfasst Beispielsweise eine Freundesliste, Chatsysteme, Matchmaking und Verbindungssysteme. Zusätzlich wird auch die dahinter liegende Infrastruktur für die Vermarktung der Spiele von Steam gestemmt. Dies umfasst einen Webshop und Downloadserver.

Der große Aufwand und die Nachfrage nach diesen Diensten zeigen sich anhand des weltweiten Datenverkehrs von Steam. So kommt zum Zeitpunkt dieses Blogeintrags allein der deutsche Datenverkehr auf über 35 Petabyte innerhalb der letzten 7 Tage. Und dies wiederum entspricht lediglich ca. 4,3% des weltweiten Datenvolumens.

Aufnahme der Steam Statistiken am 16.03.2022 um 14.48 Uhr – Steam: Game and Player Statistics (steampowered.com)

Diese Zahlen steigen vor allem dann rasant an, wenn es zu speziellen Aktionen kommt, wie etwa dem Release eines neuen, stark erwarteten Spieles oder Sale-Aktionen vergleichbar mit einem Black-Friday für Games. Hierbei kommt es dazu, dass teilweise Millionen von Spielern gleichzeitig das neue Produkt erwerben und herunterladen wollen.

Diese starke Belastung spüren aber nicht nur Shop- und Downloadserver, sondern natürlich auch die klassischen dedizierten Spieleserver selbst. Gerade beim Release eines neuen Massive Multiplayer Onlinespiels (MMO) oder einer neuen großen Inhaltserweiterung versuchen sich gleichzeitig mehrere tausende Spieler auf den Spieleservern einzuloggen, während es zum Normalbetrieb meist nur ein Bruchteil der User ist. Auch hier hilft die hohe Skalierbarkeit der Cloud. Da solche Ereignisse normalerweise zu dem Betreiber bewussten und geplanten Zeiten auftreten können allerdings im Vorfeld schon Ressourcen reserviert und bereitgestellt werden.

Technische Herausforderungen des Game Streaming

Während Plattform- oder Onlinedienste auf die heute weit verbreiteten und gut etablierten Microservice Strukturen und Architektur zurückgreifen, eröffnen sich mit Games as a Service oder Game Streaming ganz neue Herausforderungen. Die Simulation des eigentlichen Spiels kann noch problemlos in einer emulierten Umgebung ablaufen und seine Inputs von außen beziehen, sowie das berechnete Resultat nach außen über einen Video stream abgeben. Das wahre Problem liegt allerdings in der Latenz. Bei Games handelt es sich im Gegensatz zu den meisten anderen Medien um ein interaktives Medium. Das heißt auf eine Aktion des Nutzers muss idealerweise eine unmittelbare Reaktion des Mediums erfolgen. Bei Game Streaming sind die Ansprüche daran besonders hoch, wenn es mit anderen interaktiven Medien wie einem Livestream mit Live Chat verglichen wird. Hier sind Verzögerungen von bis zu 1 Sekunde noch akzeptabel. Bei Spielen hingegen wird eine Latenz von wenigen Millisekunden erwartet. In dieser Zeit muss also die Eingabe beim Client registriert, an den Server geschickt, dort verarbeitet und ein neues Bild an den Client zurückgeschickt, decodiert und angezeigt werden.

Eine abstrahierte, allgemeine Darstellung der Abläufe eine Game Streaming Dienstes – CloudRetroPicture.png (787×492) (webrtchacks.com)

Was kann Cloud Gaming?

Viele Vorteile aus Cloud Computing und Video on Demand Diensten können sich direkt auf Game Streaming übertragen lassen.

  • Für das Spielen von Games aus der Cloud wird keine teure, eigene Hardware benötigt. Der Streamingdienst Betreiber stellt die nötige Hardware zur Verfügung, um das gewünschte Spiel auf einer maximalen Qualitätsstufe darstellen zu können.
  • Um die Wartung, Instandhaltung und Modernisierung der Hardwaresysteme kümmert sich der Streaming Anbieter. Für den Endkunden fallen dadurch keine hohen Einzelkosten an.
  • Spiele stehen jederzeit und überall auf vielen verschiedenen Endgeräten zur Verfügung. Auch leistungsschwache Geräte wie Smartphones, Smart TVs oder einfache Laptops können somit zum Spielen Hardwareintensiver Titel verwendet werden
  • Das Manipulieren und Betrügen in Online- und Singleplayerspielen wird durch das Streaming erheblich erschwert. Dies resultiert direkt aus der Begrenzung der Interaktionspunkte mit dem Spiel. Lediglich die Bildausgabe und die Nutzereingabe finden auf dem lokalen Gerät statt. Jegliche weitere Informationsverarbeitung, wie beispielsweise die Position eines Mitspielers bleiben dem Nutzer verborgen.

Neben den Vorteilen gibt es jedoch auch einige Nachteile:

  • Für Gamestreaming ist zwingend eine durchgehende, leistungsstarke Internetverbindung von Nöten. Denn im Gegensatz beispielsweise zum Video on demand kann bei Game Streaming kein Buffering verwendet werden. Dies ist bei Spielen allerdings nicht möglich, da der weitere Verlauf des Spieles direkt von den Eingaben des Spielers abhängig ist. Ein Verbindungsverlust führt somit zwangsläufig zu einer abrupten Unterbrechung der Spielsession.
  • Schwankungen in der Bandbreite führen zu einer Drosselung der Bildqualität und mindern damit das Spielerlebnis.
  • Das Übertragen bereits in Besitz befindlicher Spiele werden von vielen Anbietern nicht unterstützt. Dies kann dazu führen, dass Spiele entweder nicht zur Verfügung stehen oder nochmals auf der Streaming Plattform gekauft werden müssen.
  • Das Modifizieren der eigenen Spieldaten wird unterbunden, da nicht lokal auf die Spielinhalte zugegriffen werden kann. Dies verhindert, dass Spieler Modifikationen erstellen und ihr Spielerlebnis bei Bedarf individuell anpassen können.
  • Der Anbieter entscheidet welche Publisher und Franchise in seinem Portfolie aufgenommen werden. Dies erschwert vor allem kleine Studios oder Indie Entwickler sich auf dem Markt zu etablieren.
  • Spiele stehen zusätzlich nur solange zur Verfügung so lange sie sich im Angebot des Streamingdienst befinden oder dieser die Lizenzen hierfür besitzt.

Fazit

Cloud Gaming umfasst mehr als nur Game Streaming. Es ist bereits fester Bestandteil der heutigen Infrastruktur, da ein Großteil der Spiele auf Cloud-Dienste zurückgreift oder durch Plattformen wie bspw. Steam in diese integriert wird. Zwar steht Game Streaming an sich gerade erst in den Startlöchern, doch es würde mich nicht verwundern, wenn immer mehr Nutzer umsteigen oder zumindest teilweise auf dessen Vorteile zugreifen würden. Meiner Meinung nach wird es in absehbarer Zeit kein kompletter Ersatz für alle Spieler werden. Allerdings bin ich der Überzeugung, dass Game Streaming zum Netflix der Spieler wird, da es aufgrund der vorhandenen Technologien, Infrastruktur und Kunden über ein hohes Potential verfügt. Die Entwicklung der Streaming Ttechnologien steht allerdings erst an ihrem Anfang. Eine Weiterverfolgung wird sich in jedem Fall lohnen.

Quellen

Überblick über die Cloud-Gaming-Infrastruktur  |  Cloud Architecture Center  |  Google Cloud
Microservices – Wikipedia
Unreal Pixel Streaming in Azure – Azure Gaming | Microsoft Docs
Azure for Gaming – Azure Gaming | Microsoft Docs
Cloud-Gaming: Die besten Anbieter im Vergleich | heise Download
Cloud-Gaming im Vergleich: Die besten Spiele-Streamingdienste | NETZWELT
Cloud Gaming – flüssiges Zocken auch mit schlechter Grafikkarte? (esports.com)
Cloud gaming – Wikipedia
Xbox Cloud Gaming – Wikipedia
What is cloud gaming and how does it work? – Dot Esports
How Cloud Gaming and Streaming Games on Stadia and xCloud Works (makeuseof.com)
Open Source Cloud Gaming with WebRTC – webrtcHacks
Youtube: Google WebRTC project update & Stadia review

Optimizing Practical Byzantine Fault Tolerance in Wireless IoT Blockchain Networks

Don’t we all appreciate a little help in our everyday lives? “Alexa, turn on the lights in the living room.”
Voice assistants, smart lights and other smart home devices are all part of the Internet of Things (IoT). Those and other possible applications of IoT devices increase continuously and with it the overall number of connected devices. According to IoT Analytics Research, there are already over 12.3 billion connected IoT devices around the world, whereas most of them are wireless.

But how can we guarantee security, trust and liveliness in such networks?

Global IoT Market Forecast From IoT Analytics Research (https://iot-analytics.com/product/state-of-iot-summer-2021/ / https://iot-analytics.com/number-connected-iot-devices/)

Today, we will gain an insight into how byzantine fault tolerance can be achieved in wireless IoT networks. In particular, we will look at an analytical modeling framework by Onreti et al. for applying the Practical Byzantine Fault Tolerance (PBFT) algorithm to such networks. Furthermore, we will see which restrictions apply and how the viable area for these networks can be obtained. For more details, take a look at the original paper “On the Viable Area of Wireless Practical Byzantine Fault Tolerance (PBFT) Blockchain Networks” by Onreti et al. [2].

IoT and Blockchain

All devices (or nodes) in a fully autonomous IoT network communicate in a distributed way. However, this communication style is not an easy task as nodes need to agree on the validity of communicated data. The approach, for achieving the necessary level of security and trust, is to apply an appropriate consensus method. As the principle of agreeing on new data is the same as in blockchain, its consensus methods can also be applied to IoT networks. However, commonly used methods such as proof of work and proof of stake rely on computational power – a limited resource for most IoT devices. This is where wireless PBFT protocol comes in handy.

Practical Byzantine Fault Tolerance (PBFT)

Here, (wireless) PBFT refers to a blockchain consensus method with low computational complexity and power suited for asynchronous IoT environments.

The protocol consists of the following three phases

  • pre-prepare
  • prepare
  • commit

during which nodes communicate via wireless channels. Phase one is triggered as soon as a client node’s IoT request is received. The node receiving said request is referred to as header node, whereas all other nodes in the network are called replica nodes. In other words, a PBFT network is composed of several replicas and one leader, whereby the leader is reselected when it turns faulty or breaks down.
The protocol guarantees liveliness and safety as long as no more than (n-1)/3 of n replica nodes are faulty: f ≤ (n-1)/3.

The Protocol

Diagram: communication procedure for a client’s transaction or exchange of information [1],[2]

The following steps describe the procedure from a request to a new block on the blockchain:

  1. request: A client device sends a request to the header node of the network.
  2. pre-prepare phase: The header node receives said request and broadcasts a pre-prepare message to the replica nodes.
  3. prepare phase:  When a replica accepts a pre-prepare message, it enters the prepare stage. In this stage the replica broadcasts a prepare message to the network (including itself).
    Before entering the next phase, a node needs to receive 2f prepare messages from different (but not necessarily other) nodes. In addition, those messages need to match the previous pre-prepare message.
  4. commit phase: After receiving the necessary messages, a node will furthermore broadcast a commit message (including to itself).
    Before leaving the commit phase, a node needs to receive 2f+1 matching commit messages from different nodes. Those 2f+1 messages usually contain a message from itself and the header.
  5. reply: As soon as a node meets the previously mentioned condition, it will send a reply to the client.
  6. consensus & record: The client receives replies from the other nodes and proceeds as soon as the network reaches consensus in the form of f+1 matching reply messages. Lastly, the client records the transaction on the blockchain.

For more details of the original algorithm from 1999, take a look at “Practical byzantine fault tolerance” by M. Castro and B. Liskov [1].

Wireless PBFT: Assumptions & Restrictions

Onreti et al. [2] make the following assumptions about the PBFT network:

  • Replica nodes are evenly distributed inside a circular area with radius R. Henceforth, λ denotes the density of n replicas inside this network area.
  • The wireless network is noise limited: all replica nodes have equal receiver sensitivity, denoted by β1

Based on the those assumptions, a header or replica node’s coverage radius Ri is defined by:

Ri = d0 [PiK/β1]1/γ ,

with:

  • do: reference distance for antenna far field
  • Pi: node’s transmit power
  • β1: receiver sensitivity
  • K: unit-less constant, dependent on antenna characteristics
  • γ: pathloss exponent.

This formula highlights the main restrictions of the network’s nodes. Besides that, most IoT devices are further restricted by limited bandwidth and battery power. For this reason, the nodes’ workload should be kept as small as possible.

Based on the PBFT algorithm, there are further restrictions:

  1. The header node’s coverage area A1 needs to contain at least 3f+1 replicas:
    A1λ ≥ 3f + 1
  2. For a non-faulty replica node, the coverage area A2 needs to overlap with the header node’s area A1. This intersection must contain at least 2f-1 other replica nodes:
    A2λ ≥ 2f − 1
  3. Furthermore, a client’s coverage area A3 (while overlapping with A1), needs to contain at least f+1 replicas:
    A3λ ≥ f + 1

The third constraint guarantees a successful reply to the client.
Constraints 1 and 2 guarantee the security and liveliness of the protocol and its three phases. Those constraints define the needed minimum of nodes for wireless PBFT. For a fixed number of faulty replicas f, additional nodes decrease the performance, as there are more messages (to be processed) as the protocol needs.

Viable Area

The viable area describes that (sub-)area of the network that fulfills all the constraints of wireless PBFT. This means, the number of nodes (and their placement in the area) need to be given such that:

  1. the header node can reach a minimum of 3f+1 replica nodes; where f denotes the number of faulty nodes
  2. a minimum number of matching messages (sent by different nodes) in the prepare (2f) and commit phase (2f+1) is achievable. This leads to:
    Every single replica needs to be reachable by a minimum of 2f-1 other replicas.
  3. a client node (located in- or outside of the network) can receive a minimum of f+1 matching replies

Furthermore, the concept of viable area is defined for a given view, which is determined by its specific header node. In other words, the view changes as soon as another node takes the turn in leading the network. A change of view happens at the latest when the current header fails or breaks down. Thereby the choice of header is well-defined by the view number v and the number of nodes n by i = v (mod n), where i denotes the index of the node in the network.

By determining the viable area, we can minimize the activation of nodes in the network. The smaller the nodes’ broadcast radius, the less nodes are activated. Thus, by minimizing the nodes’ coverage radius, we save energy and improve the performance.

All things considered, the viable area is dependent on:

  • the number of replicas nodes n in the network
  • the number of faulty replicas nodes f in the network
  • the transmit power of header/replica nodes
  • nodes’ receiver sensitivity
  • pathloss components

(Mathematical) Approach for Determining the Viable Area

In order to find a minimum, the mathematical approach is to solve an objective function.
In this case, we are searching for the minimal coverage radius of the header and replica nodes. As the pathloss exponent γ and receiver sensitivity β1 can be considered fixed, this is the same as minimizing the nodes’ transmit powers Pi. Thus, the objective function is:

minimize P1 + P2

whereby P1 is the header’s transmit power and P2 is the transmit power of a typical replica node, that is at the very edge of the area.
Based on the header’s placement, and therefore the shape of the areas A1 and A2, the terms describing the protocol’s first two constraints differ. There are two different cases as depicted below:

Case 1: Viable area of PBFT network with the header located at the origin. [2]
Case 2: Viable area of PBFT network with randomly located header node. [2]

,,: all nodes of the network (area)

,: nodes inside header node’s coverage area

: nodes inside replica node’s coverage area

In case 1, the header is located at (or near) the origin and has a circular coverage area A1 dependent on its coverage radius. In the second case, A1 is no longer circular but rather an intersection of two circular areas; i.e. A1 is additionally dependent on the header’s distance to the origin and the radius R of the network. In this case, the reference “replica on the edge” for the second constraint is located at an intersection point (h1 or h2), which represents the minimal possible A2.
In both cases, we adjust the coverage radiuses Ri (respectively the transmit power Pi) such that the areas fulfill the first two constraints of the protocol.

Solving for Pi

So far, we have an objective function with two constraints. In order to find reasonable results, we furthermore restrict the searched parameters:

In this case this means that the transmit powers Pi need to be limited. We set the header node maximum transmit power P1max, such that the header can still reach every node in the network, if needed. Furthermore, we set the maximum of P2 such that P2max = αP1max , with α > 1, i.e. P2max is greater than P1max.
As a consequence, we restrict P1 and P2 by:
0 ≤ P1 ≤ P1max
0 ≤ P2 ≤ P2max

With this additional constraint, we can solve the objective function using a classic method and denote its result as P1* and P2*.

Up to this point, the third constraint for wireless PBFT has been ignored. This constraint focuses on the last step in the protocol: the reply to the client. Thus, we need a coverage area A3 (dependent on the given P1*), such that at least f+1 replicas can reach the client. Based on the client’s receiver sensitivity β2 and its distance to the header node, we can use a linear search method for determining the transmit power Pc of a replica needed for replying to the client.

Illustration of the minimum broadcast transmit power required
by the replicas when responding to the client (IoT device). [2]

Numerical Results

Effect of the number of faulty nodes on the header and replica nodes transmit power,
λ = 1/(π1000) nodes/m2. [2]
Effect of the number of faulty nodes on the header and replica nodes transmit power,
λ = N/(π10002) nodes/m2, N = 811, 1000. [2]

The previous diagrams show the transmit powers of header and replica nodes in relation to the number of faulty nodes. The values have been determined for a view with the header at the origin. Further system parameters for these results can be found in [2].

Both diagrams show that the transmit power of header and replica nodes increases with the number of faulty nodes. That is because their coverage areas need to include more nodes.
Furthermore, the right diagram shows two more important points. First, a higher node density reduces the needed transmit power. Second, we can see the restrictions of the transmit power: it is not only restricted by (n-1)/3, but also by the maximal transmit power P1max resp. P2max.

Effect of the number of faulty nodes on the replica transmit
power during the reply phase, λ = 1/(π1000) nodes/m2. [2]

Last but not least, the diagram to the left shows the increase of transmit powers with increasing number of faulty nodes f. As expected, the needed replica’s transmit power Pc increases with the distance d1 of the client to the header; but in particular, we can also see that it really ramps up with an increase in faulty nodes f.

Critique: Advantages and Drawbacks of Wireless PBFT

Applying PBFT to IoT blockchain networks has clearly benefits over other methods, as it needs less resources. But how applicable is this approach to an existing network? It seems rather questionable, whether an existing network can fulfill the required assumptions. When the nodes are not evenly distributed, this approach for determining the viable area can not be applied. Furthermore, the needed noise limitation might not be given. However, when the assumptions are met, the constraints for A1 and A2 of the viable area can also be used to check whether a transaction is indeed successful [2].

The last point seems rather important. If anything in the network changes, it probably has an impact on the viable area and thus on the needed transmit powers. The PBFT algorithm has some mechanism in place to change the view, if needed – but Onreti et al. do not address what exactly happens when nodes crash or have exhausted their battery.

Besides verifying successful transactions, constraints 1 and 2 of the viable area can be used in the design for a new network – in particular for determining the radius R. [2] We might say we have a trade-off between energy savings (per node) and the overall number of nodes for a network. When we add additional nodes – to an otherwise similar network – we increase the node density. If the number of faulty nodes stays the same, this leads to energy savings. However, there is no guarantee that the rate of faulty nodes does not increase with the number of overall devices; and even though a higher node density decreases the needed transmit power, additional nodes bring other costs with them (e.g. maintaining the network).

Open Questions

Some questions persist: Who keeps track of the number of nodes n? Can the number of nodes change? When nodes turn off due to an exhausted battery, do we just consider them faulty or remove them (i.e. n reduces and node’s indices change)? Removing nodes from the network, would at least mess with the assumed node distribution. For that reason, it seems likely that we just consider exhausted nodes faulty. That brings us to the next question: Who keeps track of the number of faulty nodes? How big is the resource consumption for determining the number of faulty nodes? Who calculates the minimal transmit powers and how often are they recalculated? And what happens if the noise increases?

I would like to see a direct comparison of the power consumption of a test PBFT network, with the same network using another consensus method. Furthermore, numerical results for the case of a header at the edge of the network (worst case of case 2) would be interesting; as well as some sort of ratio of possible views in a network in relation to the header placement (i.e. case 1: case 2).

Last words

Actually, researchers have done a fair amount of work surrounding pBFT/PBFT in the past 2 years, further optimizing the original consensus method. Some of the work, namely SHBFT [3] and G-PBFT [4], (even though not specifically focusing on wireless) also address blockchain IoT networks explicitly. Even though PBFT has already been elaborately examined in 1999, the current research further emphasizes that byzantine fault tolerance is still not that easy to achieve.

On a final note I would like to say: Consensus methods often have such easy rules – in theory – as long as you don’t have to implement them.


Sources

[1] M. Castro and B. Liskov, “Practical byzantine fault tolerance”, Third Symposium on Operating Systems Design and Implementation, New Orleans, USA, Feb. 1999
[2] https://ieeexplore.ieee.org/abstract/document/9013778
O. Onireti, L. Zhang and M. A. Imran, “On the Viable Area of Wireless Practical Byzantine Fault Tolerance (PBFT) Blockchain Networks,” 2019 IEEE Global Communications Conference (GLOBECOM), pp. 1-6, doi: 10.1109/GLOBECOM38437.2019.9013778, 2019
[3] https://doi.org/10.1007/s12083-021-01103-8
Li, Y., Qiao, L. & Lv, Z. “An Optimized Byzantine Fault Tolerance Algorithm for Consortium Blockchain”, Peer-to-Peer Netw. Appl. 14, 2826–2839, 2021 https://doi.org/10.1007/s12083-021-01103-8
[4] Lao L, Dai X, Xiao B, Guo S,” G-PBFT: a location-based and scalable consensus protocol for IOT-Blockchain applications”, 2020 IEEE International parallel and distributed processing symposium (IPDPS). IEEE, pp 664–673, 2020

Security Strategies and Best Practices for Microservices Architecture

Microservices architectures seem to be the new trend in the approach to application development. However, one should always keep in mind that microservices architectures are always closely associated with a specific environment: Companies want to develop faster and faster, but resources are also becoming more limited, so they now want to use multiple languages and approaches. Therefore, it is difficult to evaluate a microservice architecture without reference to the environmental conditions. However, if you separate these external factors, you can still see that a microservice architecture offers much more isolation than other architectures – and can also handle security measures better than, for example, monolithic approaches due to today’s techniques and tools.

Continue reading

Logging im großen Maßstab mit Grafana Loki

Heutzutage erzeugen die meisten Systeme und Anwendungen Logging-Daten die für Sicherheits- und Überwachungszwecke nützlich sind, z. B. für die Fehlersuche bei Programmierfehlern, die Überprüfung des Systemstatus und die Erkennung von Konfigurationsproblemen oder sogar Angriffen. Treten Ereignisse innerhalb einer Anwendung auf, werden diese von integrierten Protokollierungsfunktionen erfasst und mit zusätzlichen Metadaten aufgezeichnet. Mit dem Wachstum von Microservice-Anwendungen ist die Protokollierung für die Überwachung und Fehlerbehebung dieser Systeme wichtiger als je zuvor. 

Besitzt man beispielsweise nur einen kleinen Webserver, ist es evtl. noch möglich die erzeugten Logs täglich zu kontrollieren. Nur wie sieht es aus wenn mitten in der Nacht etwas passiert? Oder beim Betrieb eines großen verteilten Systems? Wie können diese Daten zentral gesammelt und sinnvoll genutzt werden? Hier kommen Log-Aggregation-Systeme ins Spiel, welche bei den Anforderungen an die Beobachtbarkeit und den Betrieb jedes großen, verteilten Systems unterstützen.

In diesem Blogpost möchte ich auf den relativ neuen und immer populärer werdenden Logging-Stack Grafana Loki eingehen. Wie ist es aufgebaut? Wo sind die Unterschiede zu beispielsweise ELK (Elasticsearch, Logstash und Kibana). Was macht es so besonders und warum ist es für große Firmen wie Red Hat interessant, welche in ihrer neuesten Version OpenShift 4.10 Grafana Loki Support anbieten werden?

Continue reading

Um die Technik kümmern sich die Anderen…

Das Phänomen von ‘sozio-technischen Systemen’ und ‘Ökosystemen’

Mammut aus Gras von Christopher Alvarenga – [4]

Wenn wir uns als technisch begeisterte Computer Science Studierenden ein zu Deutsch “Ultra Großes, Skaliertes System” vorstellen… Was stellen wir uns dann wirklich vor? Naja wir denken wahrscheinlich erstmal an viele Zeilen Code, Unmengen von Server-Hardware und ellenlange Kabel. Das allein macht ein Ultra Large Scaled System (ULS) aber noch lange nicht aus.

Continue reading

Cascading failures in large-scale distributed systems

Internet service providers face the challenge of growing rapidly while managing increasing system distribution. Although the reliable operation of services is of great importance to companies such as Google, Amazon and Co., their systems fail time and again, resulting in extensive outages and a poor customer experience. This has already affected Gmail (2012) [1], AWS DynamoDB (2015) [2], and recently Facebook (2021) [3], to name just a few examples. In this context, one often encounters so-called cascading failures causing undesirable complications that go beyond ordinary system malfunctions. But how is it that even the big players in the online business cannot completely avoid such breakdowns, given their budgets and technical knowledge? And what are practical approaches to risk mitigation that you can use for your own system?

With that said, the goal of this blog article is to learn how to increase the resilience of your large distributed system by preventing the propagation of failures.

Continue reading

Discord Monitoring System with Amplify and EC2

Abstract

Discord was once just a tool for gamers to communicate and socialize with each other, but since the pandemic started, discord gained a lot of popularity and is now used by so many other people, me included, who don’t necessarily have any interest in video gaming. So after exploring the various channels on discord, I found that most of them have some kind of rules that users have to adhere to. But with channels that have more than 100 members, moderating becomes really tedious. The idea behind this project, which is a part of the lecture Software Development for Cloud Computing, is to automate this process by creating a discord monitoring system.

Features

With this system, an admin can add words that they want to be prohibited in the chat. These words are then used to delete messages that don’t adhere to the rules or to flag these messages for an admin to review when the system is not 100% certain that the message contains harmful content.

Architecture

Frontend

The client side is fairly simple, it is built with React.js and only has two sections. The first is flagged messages, where a moderator is able to review messages the system has flagged.

The second is where a moderator can add or remove censored words as shown below.

Backend

The server side of this monitoring system is built using express.js. The library discord.js was used to communicate with the discord api, and for the database I used dynamoDB.

The main part of the app is the following code:

discord.client.on("ready", () => {
  console.log(`Logged in as ${discord.client.user?.tag}!`);
  discord.client.on("message", (msg) => {
    const status = monitorSys.getScannedMessageStatus(msg.content);
    if (status === "FLAG") {
      flaggedMessagesController.addFlaggedMessage(msg);
    } else if (status === "HARMFUL") {
      messagesController.deleteHarmfulMessage(msg.id);
    } else {
      console.log("SAFE");
    }
  });
});
start();
discord.client.login(process.env.DISCORD_KEY);

Here the bot goes online and starts scanning every message that goes into the chat. With a helper method the system then either flags a message or deletes it right away if it contains harmful content.

EC2

The backend is deployed on an ec2 instance that is based on an Amazon Linux image. When creating this instance we add a script, as shown below, to install the CodeDeploy Agent that we are going to use later for the CI/CD.

#!/bin/bash
sudo yum -y update
sudo yum -y install ruby
sudo yum -y install wget
cd /home/ec2-user
wget https://aws-codedeploy-us-east-1.s3.amazonaws.com/latest/install
sudo chmod +x ./install
sudo ./install auto

Then we need to add these rules as shown below. The one with port 80 is necessary to be able to download data from the internet and the one with port 3000 is for the client to have access to our server.

CI/CD

Frontend

CI/CD On the frontend was done using GitHub actions and amplify. With GitHub I created an action that runs whenever a branch gets pushed. This pipeline runs our tests first and checks if all succeed. If one or more tests fail, this branch can’t be merged to main. This restrictions can be activated directly from the settings of our repository on GitHub. To create this action, create a file ./.github/workflows/tests.yml with the following:

name: Node.js CI
on:
  pull_request:
    branches: [ main ]
jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [16.x]
    steps:
    - uses: actions/checkout@v2
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v1
      with:
        node-version: ${{ matrix.node-version }}
    - run: npm ci
    - run: npm install
    - run: npm test

After a branch gets merged with main, Amplify builds the new version and deploys the app when the build is ready. Amplify provides a really straightforward way to deploy a React app. We just have to create a new app on Amplify and connects it with a specific branch on GitHub.

Amplify then detects the Javascript library that’s being used e.g. React, Vue or Angular and adjust the settings accordingly. Environments variables can be added directly on Amplify.

Backend

Here I used CodeDeploy to deploy the newest version of our backend whenever it’s pushed to the main branch. To achieve this, we need to first create a pipeline on CodeDeploy and connect it to our repository on GitHub, which is similar to what we did on Amplify. After that we need to add some scripts to our project for CodeDeploy. These files should be stored inside of ./scripts.

The first script file we need is called before_install.sh

#!/bin/bash

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh | bash
. ~/.nvm/nvm.sh
nvm install node

DIR="/home/ec2-user/discord-monitoring-server"
if [ -d "$DIR" ]; then
  echo "${DIR} exists"
else
  echo "Creating ${DIR} directory"
  mkdir ${DIR}
fi

With that we first download node and npm and then we create a working directory if it does not already exist.

Then we create a file called application_start.sh

#!/bin/bash
#give permission for everything in the discord-monitoring-server directory
sudo chmod -R 777 /home/ec2-user/discord-monitoring-server
#navigate into our working directory where we have all our github files
cd /home/ec2-user/discord-monitoring-server
#add npm and node to path
export NVM_DIR="$HOME/.nvm" 
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # loads nvm 
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # loads nvm bash_completion (node is in path now)
#install node modules
npm install
#start our node app in the background
npm start > app.out.log 2> app.err.log < /dev/null &

And lastly, we have application_stop.sh:

#!/bin/bash
#Stopping existing node servers
echo "Stopping any existing node servers"
pkill node

After creating these scripts we also need to add the appspec.yml file, which specifies the target folder in our ec2 instance and 3 hooks, each with its respective script file we created earlier.

version: 0.0
os: linux
files:
  - source: /
    destination: /home/ec2-user/discord-monitoring-server
hooks:
  ApplicationStop:
    - location: scripts/application_stop.sh
      timeout: 300
      runas: ec2-user
  BeforeInstall:
    - location: scripts/before_install.sh
      timeout: 300
      runas: ec2-user
  ApplicationStart:
    - location: scripts/application_start.sh
      timeout: 300
      runas: ec2-user

Conclusion

During the Software Development for Cloud Computing lecture, we learned a lot of theory about cloud computing and the different services Amazon and IBM provides. We also got to see some examples on the different subjects that were discussed during the semester. But with this project I was only able to implement and work on some of these topics. The first and main one was deploying the app on Amplify and EC2 and the second, which I personally found very interesting, is continuous integration and continuous delivery. This lecture gave me a really good overview on what can be achieved with cloud computing and I am hoping to learn way more about the topic in the near future.

“Himbeer Tarte und harte Fakten”: Im Interview mit Ansible, k3s, Infrastructure as Code und Raspberry Pi

Why so serious? – Ein Artikel von Sarah Schwab und Aliena Leonhard im Rahmen der Vorlesung Systems Engineering and Management.

Die Idee, ein fiktives Interview zu erstellen, entstammt daraus komplexe Sachverhalte unterhaltsam und verständlich zu machen.

Raspberry Fruit

Wir sind heute zu Gast in der Tech-Sendung “Himbeer Tarte und harte Fakten”.  Heute geht es unter Anderem um die Themen “Raspberry Pi”, “Infrastructure as Code” und “Ansible”. Vier Experten haben wir zu einer Diskussionsrunde eingeladen. Herzlich Willkommen, Frau Ann Sibel, Herr Kah Dreis, Herr Archie Tex-Ture und Frau Infra Struc-Ture. 

Continue reading