Systemdesign eines Audio-Streaming-Dienstes

Das Systemdesign einer Audio-Streaming-App ist einzigartig, wie es mit idiosynkratischen Geschäftsbedürfnissen umgeht. Typischerweise erfordert Audio-Streaming eine große Menge an Daten, die innerhalb der begrenzten Bandbreite des Netzwerkkommunikationskanals übertragen werden müssen.

Ein erfolgreicher Audio-Streaming-Dienst muss Millionen von aktiven Nutzern und Tausende von Inhaltsanbietern aus verschiedenen geografischen Standorten verwalten. Verschiedene Geräte und Plattformen (Smartphone, Desktop, Smart Speaker) unterstützen möglicherweise unterschiedliche Audioformate wie MP3, FLAC, ALAC und so weiter.

In diesem Blogbeitrag werden wir die Nuancen des Designs eines solch komplexen Systems untersuchen, das funktionale und nicht-funktionale Anforderungen abdeckt.

Funktionale Anforderungen

Die funktionalen Anforderungen umfassen die Funktionen, die für die Inhaltsanbieter und Audio-Nutzer oder -Hörer erforderlich sind.

• Inhaltsverwaltung. Der Inhaltsanbieter kann Audio in jedem Format hochladen, löschen oder aktualisieren. Jede Audio-Datei sollte Metadaten wie Titel, Autor, Beschreibung, Kategorie und Metadaten-Tags enthalten.
• Benachrichtigung. Der Inhaltsanbieter erhält Benachrichtigungen über den Erfolg oder Misserfolg des hochgeladenen Audios. Der Audiohörer oder Nutzer erhält Benachrichtigungen über den erfolgreichen Upload von Audio.
• Nahtloses Streaming. Nutzer können Audio in ihrem gewünschten Format abspielen, pausieren, zurückspulen und herunterladen.
• Abonnieren. Benutzer sollten in der Lage sein, das Audio ihrer Wahl zu abonnieren, um Benachrichtigungen über neue oder aktualisierte Inhalte zu erhalten.
• Benutzeranmeldung. Inhalts-Ersteller müssen authentifiziert und autorisiert sein, um auf das System zuzugreifen. Benutzer können sich im System registrieren, um ihre Profile einzurichten.
• Suche. Benutzer sollten in der Lage sein, Audio basierend auf bestimmten Attributen oder Metadaten zu suchen.

Hinweis: Live-Streaming- und Zahlungsdienste sind nicht Gegenstand dieses Artikels.

Sequenzdiagramm des funktionalen Anwendungsfalls

Architektonisches Design

Definieren wir Servicekomponenten, um die funktionalen Anforderungen zu unterstützen.

Die erste funktionale Anforderung besteht darin, Audio in beliebigen Formaten wie MP3, FLAC, ALAC usw. hochzuladen. Diese Audiodateien können eine beeindruckende Menge an Daten enthalten. Der Audiocodec spielt eine entscheidende Rolle beim effizienten Speichern, Übertragen und Abspielen dieser Daten. Es gibt hauptsächlich zwei Arten von Codecs:

1. Verlustfreier Codec – komprimiert Audio, ohne Daten zu verlieren, und kann vollständig ohne Qualitätsverlust wiederhergestellt werden.
2. Verlustbehafteter Codec – entfernt einige Daten, was dazu beiträgt, die Größe erheblich zu reduzieren. Dies könnte die Klangqualität beeinträchtigen.

Der Inhaltsanbieter arbeitet in der Regel mit verlustfreien Formaten für Aufnahme und Bearbeitung. Dadurch wird sichergestellt, dass keine Qualität verloren geht, während sie den Ton bearbeiten, Effekte anwenden und das Endprodukt fertigstellen. Einfach ausgedrückt ist Audio-Mastering der letzte Schritt im Audio-Produktionsprozess.

Nachdem das endgültige Audio gemastert wurde, wird es in ein verlustbehaftetes Format für die allgemeine Verteilung umgewandelt. Mit einem verlustbehafteten Format wird die Größe stark reduziert, was das Streamen und Herunterladen erleichtert und beschleunigt.

Das komprimierte Audio muss mit der unterstützten Netzwerkbandbreite an das Gerät des Zuhörers übertragen werden. Die Bandbreite kann sich dynamisch ändern, wobei die Netzwerklast je nach Anzahl der verbundenen Benutzer oder je nachdem, ob der Benutzer beim Zuhören des Audios von einer Netzwerkzone in eine andere wechselt, variieren kann. 

Um diese sich ändernde Netzwerkbandbreite zu unterstützen, könnte der Codec den Mechanismus der „adaptiven Bitrate“ verwenden. Adaptives Bitraten-Streaming erkennt die Bandbreite der Benutzer in Echtzeit und passt den Stream entsprechend an. Es kann dynamisch die Bitratenanpassung basierend auf der aktuellen Bandbreite des Benutzers vornehmen. Dadurch gibt es nur wenig Pufferung, schnellere Startzeiten und eine gute Erfahrung sowohl für High-End- als auch für Low-End-Verbindungen.

Der Encoder kodiert die einzelne Quelle der Audiodatei in mehreren Bitraten. Diese Byte-Ströme werden verpackt und im Objektspeicher gespeichert, um dem Zuhörer zur Verfügung zu stehen. Sobald das Audio erfolgreich hochgeladen wurde, sendet der Benachrichtigungsdienst eine Benachrichtigung an den Inhaltsanbieter.

 

Der Inhalteersteller stellt zusätzlich Metadaten bereit, während er darum bittet, den Audioinhalt hochzuladen, der direkt in einer NoSQL-Datenbank über den Audio-Datendienst gespeichert werden kann. Diese Daten werden indexiert, um dem Audiohörer eine bessere Suchfunktion zu bieten.

Das Audiosystem benötigt einen Authentifizierungs- und Autorisierungsdienst, um die Registrierung neuer Benutzer, das Einloggen mit den Benutzeranmeldeinformationen und die Autorisierung basierend auf den Rollen der Benutzer (Hörer und Inhalteanbieter) zu verwalten. Ein API-Gateway-Dienst, der die Authentifizierung und Autorisierung zentral verwalten kann. Dieser Dienst kann für die Anfrage-Routing und Prozessflussorchestrierung von der Front-End- zur Back-End-Dienst verwendet werden.

Der Audio-Benutzer (Hörer) könnte nach Audioinhalten suchen, die an den Audio-Datendienst weitergeleitet werden, um den Speicherort der relevanten Audio(s) zurückzugeben und Informationen aus dem Audiodatenmetadatenspeicher abzurufen. Der Benutzer klickt auf den Link, und es werden die Audiodaten bytes verpackt und gespeichert durch den Paketdienst.

Der Benutzerprofil-Dienst verwaltet Benutzervorlieben, Follower und Abonnements.

Das obige Diagramm zeigt den grundlegenden Ablauf des „Audio hochladen“-Prozesses, der vom Inhalteanbieter ausgelöst wird, und den „Audio anhören“-Prozess, der vom Audio-Benutzer/Hörer ausgelöst wird.

Das Pipeline- und Filter-Designmuster mit Message-Queuing wird verwendet, um den Datenfluss zwischen Diensten zu unterstützen, um den Prozess effizient mit Parallelität und Fehlertoleranz zu skalieren.

Jetzt gehen wir zu den nicht-funktionalen Anforderungen über.

Nicht-funktionale Anforderungen

• Skalierbarkeit. Das System sollte Tausende gleichzeitiger Benutzer unterstützen und in der Lage sein, zu wachsen und zu schrumpfen.
• Fehlertoleranz. Das System sollte fehlertolerant sein, normalerweise mit redundanten Daten und geringer Ausfallzeit.
• Leistung. Das System sollte eine geringe Latenz und hohe Reaktionsfähigkeit während der Wiedergabe von Inhalten haben.
• Sicherheit. Das System muss vor unberechtigtem Zugriff oder schädlichen Angriffen wie DDoS geschützt sein.

Skalierbarkeit

Das Audiosystem sollte Tausende aktiver Inhaltsersteller unterstützen können. Um die Last zu bewältigen, umfasst das Design das Ausführen mehrerer Instanzen des API Gateway-Dienstes, des App Web-Dienstes und des Audio-Daten-Dienstes, die von Lastausgleichern unterstützt werden.

Allerdings wird dies nicht skalierbar sein mit der Zunahme der Anzahl von Inhaltserstellern. Die Audiodateien sind in der Regel groß, was beim Durchlaufen mehrerer Dienstkomponenten hohe Netzwerk- und Rechenleistung benötigt. Um die Nutzung der Systemressourcen zu optimieren, kann eine signierte URL (auch als vorab signierte URL bezeichnet) verwendet werden, um zeitlich begrenzten Zugriff auf das Objektspeicher zum direkten Hochladen von Audiodateien bereitzustellen. Dies eliminiert die Notwendigkeit, den Verkehr über das API Gateway und den API Web-Service zu leiten. Die signierten URLs können mit feingranularen Berechtigungen und Ablaufregeln für eine bessere Sicherheit konfiguriert werden.

Dies umfasst die Skalierbarkeitsanforderung für das Hochladen von Audiodateien durch Inhaltsanbieter.

Millionen von Suchanfragen von den Hörern könnten das System treffen und dazu führen, dass der Audiodatendienst überlastet wird. Um das System zu skalieren, das diese massive Suchoperation unterstützt, kann das Designmuster der Inhaltsabfrageverantwortungstrennung (CQRS) verwendet werden. Die Lese- und Schreibvorgänge von/zur Datenspeicher können unabhängig voneinander verwaltet werden, um unterschiedliche Latenz-, Skalierbarkeits- und Sicherheitsanforderungen zu unterstützen.

 

Fehlertoleranz

Es gibt verschiedene Dimensionen des Fehlerverträglichkeitsdesigns. Einige von ihnen sind bereits im Design enthalten.

• Verwendung mehrerer Instanzen des Dienstes für Skalierbarkeit und Fehlerverträglichkeit
• Nachrichtenwarteschlangen mit Pipeline-Verarbeitung zur Unterstützung der Fehlerverträglichkeit auf der Datenflussebene
• Trennung des Transcodierdienstes und des Verpackungsdienstes
• Mehrere DB-Instanzen mit Replikation
• Verfügbarkeitszonen, die geografischen Regionen wie den US-Osten, den US-Westen und den asiatisch-pazifischen Raum entsprechen, für die Bereitstellung des gesamten Systems zur Unterstützung einer spezifischen Region und Benutzerbasis.

Leistung

Ein Content Delivery Network (CDN) ist ein verteiltes Netzwerk von Servern, die zusammengefasst sind, um Inhalte wie Audiodateien und Videodateien schneller und effizienter zu übermitteln. Es speichert den Inhalt am Edge-Server, um eine bessere Leistung mit geringer Latenz zu bieten. 

Sicherheit

CDNs verbessern auch die Sicherheit, indem sie DDoS-Minderungsmaßnahmen und einige weitere Sicherheitsmaßnahmen bereitstellen.

Der Paketdienst wird die Audiodateien an CDNs verteilen, um sie an den Edge-Servern zwischengespeichert zu werden. Der Audiodatendienst wird den Standort des CDNs in seinen Metadaten aktualisieren, die dann an den Suchdienst weitergeleitet werden, um von Benutzern abgefragt zu werden.

 

Das obige Diagramm zeigt die High-Level-Komponentenarchitektur eines typischen Audiosystems.

Zusammenfassung

Im Zentrum eines guten Audiosystems stehen Skalierbarkeit, Leistung und Fehlertoleranz, um den Benutzern eine gute Benutzererfahrung mit minimaler Verzerrung, geringer Latenz und Zuverlässigkeit zu bieten.