Skalieren von WebRTC - Ein serverloser Ansatz mit Azure

Dieser Artikel basiert auf einer während meines Studiums eingereichten Arbeit. (Steininger, 2024b)

Zusammenfassung

Die Skalierung von WebRTC-Anwendungen wie WaveNet8 //Send kann eine Herausforderung sein. Während es mehrere Methoden gibt, dies zu erreichen, konzentrieren wir uns hauptsächlich auf Cloud-Dienste. Nach der Analyse verschiedener Optionen haben wir uns für Azure entschieden, da es umfassende serverlose Dienste bietet, die sichere und hoch skalierbare Lösungen ermöglichen. Kein anderer Anbieter bot einen vergleichbaren serverlosen SignalR-Dienst an. Darüber hinaus bot Azure niedrige feste Kosten, was weitere wirtschaftliche Anreize schuf.

Wir werden die entwickelte Lösung demonstrieren und die verwendeten Dienste detailliert beschreiben. Eine kleine Anwendung mit Frontend- und Backend-Komponenten wird bereitgestellt, um die kontinuierliche Bereitstellung (CD) zu demonstrieren, wobei der Schwerpunkt auf der Bereitstellung ohne Tests liegt.

Die Cloud-Infrastruktur wird mit Terraform, einem Tool für Infrastructure as Code (IaC), reproduzierbar gemacht. Wir werden auch zeigen, wie die Cloud-Dienste und die Beispielanwendung mit den bereitgestellten Dateien eingerichtet werden.

Voraussetzungen

• Vertrautheit mit dem Azure-Dashboard
• Grundkenntnisse in HTML, JavaScript und .NET (C#)
• Zugriff auf das GitHub-Repository
• Terraform-Kenntnisse

Wir empfehlen, sicherzustellen, dass Sie mit diesen Themen vertraut sind, bevor Sie fortfahren.

Cloud-Architektur

Einleitung

Eine Architektur zu entwickeln, die skalierbar, sicher und kostengünstig ist, ist eine Herausforderung. Wir glauben, eine Lösung gefunden zu haben, die es uns ermöglicht, WaveNet8 //Send für jedes Nachfrageniveau zu skalieren. Aufgrund von Vertraulichkeit werden wir die Bereitstellung mit einer einfachen Chat-App anstelle des tatsächlichen Codes für WaveNet8 demonstrieren.

Um die Kosten im Griff zu behalten, konzentrieren wir uns auf Nordamerika und Europa.

Ziele

Das Ziel ist es, eine Cloud-Architektur zu entwickeln, die nahtlos auf jede vorhersehbare Nachfrage skaliert, hochverfügbar und sicher ist und niedrige Kosten verursacht. Zusätzlich sollte eine kontinuierliche Bereitstellung (CD) mit Azure Pipelines aus unserem Azure DevOps-Repository möglich sein.

Wir streben nicht an, ein eigenes TURN-Server-Netzwerk zu hosten und zu warten, da dies mit hohem Aufwand und hohen festen Kosten verbunden ist.

Die Architektur

Die entwickelte Architektur ist unten dargestellt. Sie umfasst alle Dienste, die an der Bereitstellung der Funktionalität für den Benutzer beteiligt sind und die Sicherheit des Dienstes gewährleisten.

Das obige Bild zeigt eine klare Unterscheidung zwischen Frontend- und Backend-Komponenten. Die statischen Web-Apps liefern die Frontend-Dateien, während der SignalR-Dienst und der Hub die Geschäftslogik und die TURN-Anmeldeinformationen verwalten. Der KeyVault speichert Geheimnisse und gewährt autorisierten Diensten und Prozessen Zugriff. Die Datenbank speichert anonymisierte Statistiken zur Nutzung von WaveNet8 //Send. Wir verlassen uns auf Google und Metered TURN für TURN- und STUN-Server.

Die daraus resultierende Infrastruktur enthält die wichtigsten Komponenten und ermöglicht die im Sequenzdiagramm dargestellten Interaktionen.

Verwendete Azure-Dienste

• Azure Functions: Bietet serverlose Rechenleistung für Backend-Logik.
• Azure SignalR-Dienst: Ermöglicht Echtzeitkommunikation.
• Azure Static Web Apps: Hosten statische Dateien für das Frontend.
• Azure Key Vault: Verwalten und speichern Geheimnisse sicher.
• Azure SQL DB: Speichern anonymisierte Nutzungsstatistiken.
• Metered TURN-Dienste: Bieten TURN-Server-Funktionalität für WebRTC.

Installation

Es wird davon ausgegangen, dass Sie bereits ein Azure-Konto, ein Metered-Konto, ein Azure DevOps-Projekt (mit drei Repositories: Frontend, Backend, Terraform) und Terraform eingerichtet haben.

• Rufen Sie den Metered-Schlüssel aus dem Entwicklerbereich im Metered-Dashboard ab.
• Führen Sie terraform plan -var “metered_key=” -out ./myplan gefolgt von terraform apply “myplan” aus. Überprüfen Sie Ihr Azure-Dashboard, um sicherzustellen, dass alle Dienste fehlerfrei erstellt wurden.

Wenn das Terraform-Skript ohne Fehler ausgeführt wurde, fahren Sie mit der Einrichtung der Azure-Pipelines fort.

• Erstellen Sie die Pipelines mit den Dateien im Repository.
• Verbinden Sie sich über Dienstverbindungen mit Azure (Project settings -> Service connections).
• Wählen Sie Azure Resource Manager und dann Service principal (automatic).
• Wählen Sie Ihre Subscription, Resource group und benennen Sie die Verbindung.
• Wechseln Sie zu Azure und suchen Sie nach App registrations.
• Benennen Sie die Verbindung um und fügen Sie sie der AzurePipelinesPrincipal-Gruppe hinzu. (Hinweis: Dadurch kann die Pipeline als ADMIN auf die Datenbank zugreifen, um andere SQL-Benutzer usw. einzurichten.)

Als Nächstes richten Sie die Pipeline-Variablen ein, um die Bereitstellung auf unsere generierten Ressourcen zu ermöglichen.

• Kopieren Sie das StaticWebApp-Token und setzen Sie es als Variable in der Frontend-Pipeline.
• Richten Sie die Bereitstellung des Backends ein. Kopieren Sie die FunctionApp-URL und fügen Sie sie in die main.js (apiBaseUrl) ein.
• Setzen Sie die richtigen Werte für die Backend-Pipeline-Variablen.
• Wenn Sie die Pipeline zum ersten Mal ausführen, werden Sie aufgefordert, die Berechtigung zur Bereitstellung zu erteilen.

Nach Abschluss dieser Installationsanweisungen sollte die Bereitstellung funktionieren und Benutzer sollten auf die Chat-App (oder jede andere Anwendung, die Sie bereitstellen möchten) zugreifen können.

Verfügbarkeit

Bei der Berechnung der Verfügbarkeit des Dienstes gehen wir von der statistischen Unabhängigkeit aller Variablen aus, was zur minimal erwarteten Verfügbarkeit führt.

• SignalR-Dienst rSigR > 99,9% (Microsoft, 2024, S. 79)
• Azure Functions App rFApp > 99,95% (Microsoft, 2024, S. 53)
• Speicherkonto rStAc > 99,95% (Microsoft, 2024, S. 85)
• Metered rMet > 99,999% (nicht bindend) (Metered, 2024)
• Schlüssel-Tresor rKeyV > 99,9% (Microsoft, 2024, S. 59)
• Statische WebApp rStWeb > 99,95% (Microsoft, 2024, S. 84)

rSigR * rFApp * rStAc * rMet * rKeyV * rStWe < rWaveNet8Send
rWaveNet8Send > 99.7%

Wir haben unser Ziel der hohen Verfügbarkeit von >99,9% nicht erreicht.

Sicherheit

Der KeyVault in Kombination mit der Verwendung von KeyVault-Referenzen in den App-Einstellungen erhöht die Sicherheit. Die Verwendung von RBAC reduziert die notwendigen Schlüssel und erhöht die Sicherheit. Die Firewall-Konfiguration erlaubt nur vertrauenswürdigen Quellen die Verbindung.

Um CD zu erreichen, waren jedoch einige Kompromisse erforderlich. Um die Notwendigkeit einer manuellen SQL Server-Konfiguration zu beseitigen, wurde die DBAdmin-Gruppe dem Pipelines-Prinzipal zugewiesen. Es wird empfohlen, den Prinzipal nach der ersten Bereitstellung aus dieser Rolle zu entfernen, um Manipulationen an der Datenbank durch Entwickler mit Pipeline-Zugriff zu verhindern.

Abgerechnete Dienste haben bestimmte Risiken aufgrund schlechter Sicherheitskonformität. Verbesserungen ihrer Sicherheit sind notwendig, um Ausbeutung zu verhindern (Steininger, 2024b).

IaC

Die Infrastructure as Code (IaC)-Datei im Repository enthält Variablen und Kommentare zur Anpassung.

Beispielsweise bietet sie Suffixe zur Identifizierung von Versionen und ermöglicht mehrere Bereitstellungen. SKU-Variablen sind verfügbar, um die SKU für Produktions- und Entwicklungsumgebungen zu ändern.

Für Updates stellen Sie sicher, dass die Variable azure_key_vault_id gesetzt ist, damit das Skript Schlüssel aus dem Tresor laden kann.

Wirtschaftlichkeit

Das folgende Bild schätzt die Kosten jedes Dienstes pro Klick und die Gesamtkosten des Betriebs. Der TURN-Dienst ist der größte Kostenfaktor, abhängig von den durchschnittlichen Datenübertragungen der Benutzer. Mit mehr Statistiken können Kostenprognosen präziser werden.

Da der TURN-Dienst ein so signifikanter Kostenfaktor ist, würde eine Reduzierung der zweitgrößten Kostenposition um die Hälfte nur zu einer 10%igen Verringerung der Betriebskosten führen.

Das Hosten eines eigenen TURN-Dienstes ist aufgrund des hohen Verkehrsaufkommens und der globalen Verteilung eine Herausforderung und führt zu hohen Personal- und Materialkosten, die nur ratsam sind, wenn wir den Dienst erheblich skalieren.

Eine reine werbefinanzierte Stufe ist ohne Abonnements nicht tragbar.

Ergebnis

Wenn Sie die Anwendung aus dem Repository bereitgestellt haben, sollten Sie eine Anmeldeseite sehen. Geben Sie einen beliebigen Namen ein und starten Sie den Chat. Beachten Sie, dass wir WebRTC nicht verwenden und Nachrichten unverschlüsselt über die AzureFunctionsApp senden. Der Fokus lag auf der Bereitstellung, nicht auf der WebApp.

Diskussion

Wir haben unser Ziel der hohen Verfügbarkeit nicht erreicht. Angenommen, die von Microsoft angebotenen Zahlen (SLAs), liegt die kombinierte Verfügbarkeit (unter Berücksichtigung wesentlicher Dienste) bei nur 99,7%.

Dieser Ansatz bietet eine hoch skalierbare Lösung, ermöglicht jedoch Angreifern, durch Generierung von Traffic, für den Sie bezahlen, Mittel zu entziehen. Dasselbe Risiko gilt für den TURN-Server aufgrund unzureichender Maßnahmen gegen die Ausbeutung von TURN-Server-Anmeldeinformationen (TSCE) (Steininger, 2024a).

Diese Architektur wird unsere Wahl sein, wenn wir WaveNet8 //Send über die Kapazitäten unserer aktuellen Infrastruktur hinaus skalieren müssen. Es ist jedoch weitere Forschung erforderlich, um den Dienst gegen TSCE und Missbrauch zu sichern, der darauf abzielt, hohe Gebühren zu erzeugen. Zusätzlich sollte die angenommene Unabhängigkeit der Verfügbarkeitszahlen überprüft werden, um sicherzustellen, dass die tatsächliche Verfügbarkeit höher ist als das Produkt der Verfügbarkeiten ihrer Komponenten.

lg Sebastian Steininger

Literatur

• Microsoft. (2024). OnlineSvcsConsolidatedSLA(WW)(April2024)(CR). https://wwlpdocu- mentsearch.blob.core.windows.net/prodv2/OnlineSvcsConsolidatedSLA(WW)(Eng- lish)(April2024)(CR).docx
• (Steininger, 2024a) Steininger Sebastian, Mai 15 2024 - Metered TURN Server Credential Exploitation - A Case Study
• Steininger, S. (2024b). Portfolio Cloud-Programming.

Danke an Open AI, dass sie ChatGPT 4 online anbieten, es hat dieses Artikel übersetzt und auf basis eines groben Entwurfs erstellt.

© WaveNet8 2024-08-04