Eine Architektur für produktionsfertige Live-Audiotranskription mit Speech-to-Text

In diesem Leitfaden wird eine Architektur beschrieben, die hochverfügbare, robuste Live-Audiotranskriptionen mit Google Cloud-Technologien wie Speech-to-Text, Google Kubernetes Engine (GKE) und Memorystore bereitstellt. Dieser Leitfaden richtet sich an Entwickler und Architekten und setzt Grundkenntnisse in Kubernetes und GKE voraus. Eine kurze Einführung finden Sie in der Übersicht über GKE.

Informationen zum Arbeiten mit einer Implementierung dieser Architektur finden Sie in der zugehörigen Anleitung.

Einführung

Es gibt viele Anwendungsfälle für das Transkribieren eines Livestreams von Audio in Text. Medienunternehmen transkribieren Audioinhalte, um bei Liveübertragungen Untertitel zu generieren. Telefonanrufe oder Besprechungen können in Echtzeit transkribiert werden, um auch hörgeschädigte Teilnehmer einzubeziehen. Bei Konferenzen und Veranstaltungen können die Organisatoren einrichten, dass Reden live transkribiert werden, um den Teilnehmern Text anzuzeigen.

Viele der heute verwendeten Lösungen zur Livetranskription erfordern eine Kombination aus erfahrenen Mitarbeitern und spezieller Software. Da der Prozess auf menschlichen Mitarbeitern basiert, kann es schwierig sein, das Transkriptionsangebot zu skalieren. Das bedeutet, dass Transkriptionen normalerweise nur für eine kleine Anzahl von Liveübertragungen oder -ereignissen durchgeführt werden können.

Speech-to-Text unterstützt die Livetranskription. Sie können einen Audiostream an Speech-to-Text senden und einen Stream von Texttranskriptionen in Echtzeit zurückerhalten. Mit Speech-to-Text können Medienunternehmen ihre vorhandenen Transkriptionsprozesse automatisieren und erweitern, wodurch die Abhängigkeit von menschlichen Mitarbeitern reduziert und der Umfang der Transkriptionsaktivitäten erweitert wird.

Die Qualität, Latenz und Konsistenz der Bereitstellung sind für Nutzer, die von Transkriptionen abhängen, entscheidende Faktoren. Dies gilt insbesondere, wenn Transkriptionen in Liveübertragungen oder -veranstaltungen enthalten sind. Häufige Verzögerungen oder Ausfälle frustrieren Nutzer und führen zu Beschwerden. Daher muss jede Transkriptionslösung qualitativ hochwertige Texttranskriptionen ermöglichen. Sie muss aber auch hochverfügbar und stabil sein, damit Fehler und Ausfälle die Transkription nur minimal stören. In diesem Leitfaden wird eine Anwendungsarchitektur beschrieben, die die wichtigsten Anforderungen an eine Lösung für hochverfügbare, robuste Live-Audiotranskription erfüllt.

Architektur

Grafik: Architektur der Infrastruktur in Google Cloud für eine produktionsfertige Transkriptionsanwendung

Die Architektur umfasst die folgenden Features:

  • Drei Anwendungsmikrodienste:
    • Ingestor: Dieser Dienst verwendet den Quell-Audiostream.
    • Transcriber: Dieser Dienst ruft Speech-to-Text auf und gibt Transkriptionsergebnisse aus.
    • Reviewer: Dieser Dienst zeigt die Transkriptionen zur Überprüfung in einer Webanwendung an.
  • GKE, das die Anwendungsmikrodienste in einem regionalen GKE-Cluster hostet, der sich über mehrere Zonen erstreckt. Die Anwendungsmikrodienste werden zonenübergreifend bereitgestellt.
  • Memorystore for Redis, das als schneller Zwischenspeicher verwendet und in einer Hochverfügbarkeitskonfiguration bereitgestellt wird.
  • Load-Balancer, die Anwendungsfunktionen im Internet verfügbar machen, um Folgendes zu tun:
    • Eine IP-Adresse angeben, zu der der Quellaudiostream geleitet werden kann.
    • die Webanwendung für Prüfer bereitzustellen.

Zusammenfassung der Anforderungen und Empfehlungen

In diesem Abschnitt sind Beispielanforderungen an eine Anwendung aufgeführt, die eine Livetranskription bereitstellt, sowie Empfehlungen zur Umsetzung der Anforderungen. Sofern nicht anders angegeben, werden die Empfehlungen in späteren Abschnitten ausführlich erläutert.

Anforderung Empfehlung
Die Architektur sollte flexibel und locker gekoppelt sein. Entwerfen Sie die Anwendung als einen Satz unabhängiger, containerisierter Mikrodienste. Verwenden Sie GKE zur Verwaltung und Orchestrierung der Mikrodienste.
Die Architektur muss innerhalb einer Region hochverfügbar sein. Verwenden Sie einen regionalen GKE-Cluster, um Anwendungsmikrodienste über Zonen hinweg redundant bereitzustellen.
Die Anwendung muss eine stabile IP-Adresse für die Aufnahme bereitstellen. Stellen Sie den Ingestor-Dienst als Kubernetes-Dienst vom Typ LoadBalancer bereit.
Die Anwendung muss einen Mechanismus enthalten, damit menschliche Mitarbeiter die Transkriptionen prüfen können. Stellen Sie eine Webanwendung bereit, die die Transkriptionen in Echtzeit anzeigt. (Diese Anforderung wird in diesem Dokument nicht ausführlich behandelt.)
Audio muss in Echtzeit transkribiert werden. Verwenden Sie Anfragen zur Streamingerkennung von Speech-to-Text.
Die Anwendung sollte eine einzige aktive Verbindung zu Speech-to-Text aufrechterhalten. Verwenden Sie Leader-Auswahl, um einen einzelnen Transcriber-Pod als primären Pod auszuwählen.
Die End-to-End-Transkription muss mit niedriger Latenz erfolgen. Verwenden Sie Memorystore for Redis für einen schnellen In-Memory-Zwischenspeicher.
Bei Transkriptionen sollte der Sprachkontext verstanden werden (z. B. bekanntes Domainvokabular). Verwenden Sie Sprachanpassung, um Wort- und Wortgruppenhinweise für Speech-to-Text bereitzustellen.
Die Anwendung sollte in der Lage sein, mehrere gleichzeitige Audioeingabestreams (Kanäle) zu verarbeiten. Stellen Sie separate Transcriber-Instanzen für jeden Kanal bereit. Ziehen Sie die kanalübergreifende gemeinsame Nutzung anderer Anwendungsressourcen in Betracht.
Die Anwendung sollte nach Ausfällen mit minimaler Unterbrechung der Transkriptionen wiederhergestellt werden. Verwenden Sie Leader-Auswahl, redundante Bereitstellungen und Load-Balancer, um die Ausfallsicherheit zu erhöhen. Testen Sie die Ausfallsicherheit Ihrer Anwendung, indem Sie Fehler einleiten.

Anwendung als einen Satz containerisierter Mikrodienste entwerfen

Eine Best Practice für die Architektur besteht darin, Ihre Anwendung als Satz locker gekoppelter, unabhängiger Komponenten oder Dienste zu entwerfen. Durch ein locker gekoppeltes Design können Sie den Lebenszyklus jedes Dienstes separat verwalten. Dienste können von verschiedenen Teams erstellt und verwaltet werden. Jedes Team kann die am besten geeigneten Technologien auswählen, ohne durch die Entscheidungen anderer Teams eingeschränkt zu sein. Diese Vorteile sind für das Architekturmuster der Mikrodienste von zentraler Bedeutung.

Mikrodienstarchitekturen verpacken Dienste häufig als Container. Container eignen sich optimal für dienstbasierte Anwendungen, da Sie bei jedem Container Systemdiagnosen durchführen, einzelne Dienste auf bestimmte Ressourcen begrenzen und sie unabhängig voneinander starten und stoppen können. Wenn Sie die Anwendung als Satz von Containern erstellen, verbessern Sie auch die Effizienz, Portabilität und Konsistenz.

Es kann eine komplexe Entscheidung sein, wie und wo Sie die Anwendung in Mikrodienste aufteilen möchten. Für diese Transkriptionsanwendung gibt es jedoch einige klare Zuständigkeiten, die in der folgenden Tabelle aufgeführt sind.

Mikrodienst Beschreibung
Ingestor Nutzt den Quell-Audiostream und schreibt ihn in den Zwischenspeicher.

Die Audiodaten werden möglicherweise mit Software von Drittanbietern und über domainspezifische Protokolle gesendet und könnten verschlüsselt sein. Daher ist es sinnvoll, die Aufnahmekomponente getrennt von der Transkriptionskomponente zu entwerfen und bereitzustellen.
Transcriber Nutzt die aufgenommenen Audiodaten, ruft Speech-to-Text auf und schreibt Transkriptionsergebnisse in den Zwischenspeicher.

Der Transcriber-Dienst ist das Herzstück der Anwendung. Er ist für die Verwaltung und Aufrechterhaltung von Verbindungen zu Speech-to-Text und für die Verarbeitung von Transkriptionsergebnissen zuständig.
Reviewer Nutzt die Transkriptionen und zeigt sie zur Überprüfung in einer Webanwendung an.

Normalerweise benötigen Medienunternehmen einen Mitarbeiter zur Kontrolle der generierten Transkriptionen. Um diese Anforderung zu erfüllen, bietet die Reviewer-Webanwendung ggf. die Möglichkeit, Transkriptionen zu ändern, bevor sie zur Übertragung freigegeben werden.

GKE zum Hosten der Anwendungsmikrodienste verwenden

GKE ist eine gute Wahl für das Hosten von Containeranwendungen. Erstens werden GKE-Cluster von Kubernetes unterstützt, was folgende Vorteile bietet:

  • Kubernetes bietet eine cloudnative Plattform für die Verwaltung und Orchestrierung locker gekoppelter, containerisierter Anwendungen.
  • Mit Kubernetes ist es möglich, Cluster deklarativ zu verwalten, damit die Einrichtung des Clusters der Versionskontrolle unterliegt und einfach zu replizieren ist.
  • Kubernetes ist Open-Source-Software und unterstützt Portabilität.

Zweitens ist GKE ein vollständig verwalteter Dienst, der erweiterte Features zur Clusterverwaltung bietet, darunter:

  • Autoscaling der Anzahl der Knoteninstanzen im Cluster.
  • Automatische Upgrades für die Knotensoftware des Clusters.
  • Enge Integration mit anderen Google Cloud-Diensten, einschließlich Load-Balancern, VPC-Netzwerken, Datenbanken sowie Logging und Monitoring.
  • Regionale Cluster, die zonenübergreifende Redundanz bieten und so die Verfügbarkeit verbessern.

Weitere Informationen zur Verwendung von GKE in der Produktion finden Sie im Leitfaden GKE-Umgebung für die Produktion vorbereiten.

Anwendungsmikrodienste für erhöhte Verfügbarkeit redundant bereitstellen

Abbrüche und Aussetzer bei der Übermittlung von Transkriptionen frustrieren Nutzer, die von ihnen abhängen. Für eine zuverlässige Transkriptionsübermittlung muss die Anwendung Fehlern oder Ausfällen standhalten können.

Die Verfügbarkeit ist ein Maß für die Betriebszeit eines Systems. In Google Cloud wird Hochverfügbarkeit normalerweise durch redundante Bereitstellung von Anwendungsdiensten in mehreren Zonen erreicht. Wenn ein Dienst in mehreren Zonen vorhanden ist, kann er Dienstunterbrechungen in einer bestimmten Zone besser standhalten.

Die Bereitstellung einer Anwendung in mehreren Regionen erlaubt möglicherweise eine bessere Verfügbarkeit als die Bereitstellung in einer einzelnen Region. Multiregionale Anwendungen bringen jedoch zusätzliche Einschränkungen mit sich, z. B. ist die Datenreplikation erforderlich. Sie erfordern unter Umständen aber auch eine hohe Sorgfalt bei Design und Verwaltung. Für diese Transkriptionsanwendung bietet die Bereitstellung der Anwendung in mehreren Zonen innerhalb einer einzelnen Region wahrscheinlich eine ausreichende Verfügbarkeit.

Regionale GKE-Clusterkonfiguration verwenden

GKE bietet Optionen für die Verteilung des Clusters auf die Zonen in einer Region. Folgende Optionen sind verfügbar:

  • Cluster mit einer Zone: Alle Clusterknoten befinden sich in einer einzigen Zone. In derselben Zone wird eine einzelne Steuerungsebene (Kubernetes-Master) ausgeführt. Ein Cluster mit einer einzelnen Zone ist für die Transkriptionsanwendung nicht geeignet, da die Anwendung zonenübergreifend verfügbar sein soll.
  • Cluster mit mehreren Zonen: Clusterknoten werden auf zwei oder mehr Zonen innerhalb einer Region verteilt. In der primären Zone wird eine einzelne Kubernetes-Steuerungsebene ausgeführt.
  • Regionale Cluster: Clusterknoten werden auf zwei oder mehr Zonen innerhalb einer Region verteilt. Ein regionaler Cluster verfügt über mehrere Replikate der Steuerungsebene, die in mehreren Zonen in der Region ausgeführt werden.

Der Transcriber-Dienst verwendet Leader-Auswahl (weiter unten erläutert) in Kubernetes, um die Verwaltung der Kommunikation mit Speech-to-Text zu erleichtern. Leader-Auswahl erfordert Interaktion mit der Kubernetes-Steuerungsebene. Um die Effektivität des Leader-Auswahlprozesses zu maximieren, ist es wichtig, dass die Steuerungsebene in mehreren Zonen verfügbar ist. Daher ist ein regionaler Cluster eine sinnvolle Wahl für die Transkriptionsanwendung.

Anwendungsmikrodienste zonenübergreifend bereitstellen

Ein regionaler GKE-Cluster enthält Rechenknoten und Replikate der Steuerungsebene, die in mehreren Zonen einer bestimmten Region ausgeführt werden. Mit dem Deployment-Objekt von Kubernetes können Sie mehrere Replikate Ihrer Mikrodienste redundant bereitstellen. Kubernetes versucht standardmäßig, die Replikate gleichmäßig auf die Knoten in den einzelnen Zonen zu verteilen.

In einem Deployment sind mehrere identische Pods zusammengefasst. Deployments werden vom Kubernetes-Deployment-Controller verwaltet. Wenn ein Replikat ausfällt oder nicht mehr reagiert, wird es vom Controller automatisch ersetzt. Auf diese Weise sorgen Deployments dafür, dass eine oder mehrere Instanzen Ihrer Anwendungsmikrodienste für Anfragen verfügbar sind.

Sie können Deployments mit mindestens zwei Replikaten für jeden einzelnen Mikrodienst erstellen: Ingestor, Transcriber und Reviewer. Auf diese Weise ist jeder Mikrodienst redundant in mehreren Zonen verfügbar.

Stabile IP-Adresse für die Audiodatenaufnahme mit einem Load-Balancing-Dienst angeben

Der Quell-Audiostream stammt möglicherweise aus einer lokalen Infrastruktur, die spezielle Hardware und Software enthält. Die Transkriptionsanwendung sollte eine stabile Ziel-IP-Adresse bereitstellen, an die die Audiodaten gesendet werden können, damit die Quellinfrastruktur nicht häufig neu konfiguriert werden muss. Die Pods in einem Deployment wechseln jedoch häufig und ihre IP-Adressen ändern sich. Wenn Sie einem Deployment eine stabile IP-Adresse zuweisen möchten, müssen Sie einen Kubernetes-Dienst erstellen.

Der Kubernetes-Dienst bietet als Objekt eine Möglichkeit, einen Satz an Pods als einzelne Ressource verfügbar zu machen. Ein Dienst erhält eine einzelne stabile IP-Adresse, über die Clients auf die Pods zugreifen können. Der Diensttyp steuert, wie der Dienst für internem und externem Traffic verfügbar ist. Wenn Sie beispielsweise einen Dienst vom Typ LoadBalancer erstellen, erstellt GKE automatisch einen zugeordneten Google Cloud-Load-Balancer in Ihrem Projekt. Informationen zur Verwendung der verschiedenen Arten von Load-Balancing mit Ihren Diensten finden Sie in der GKE-Netzwerkübersicht.

Die Anwendung wird in einer einzelnen Region bereitgestellt und muss möglicherweise Audiostreams unterstützen, die über ein anderes Protokoll als HTTP bereitgestellt werden. Daher scheint ein externer regionaler TCP/UDP-Netzwerk-Load-Balancer ein guter Ausgangspunkt für den Ingestor-Dienst zu sein. Dieser Load-Balancer hat eine stabile externe IP-Adresse, die über das Internet zugänglich ist, und kann den Traffic auf die verfügbaren Ingestor-Pods verteilen.

Audioinhalte mithilfe der Streamingerkennung in Echtzeit transkribieren

Speech-to-Text unterstützt die Livetranskription mithilfe einer Anfrage zur Streamingerkennung. Bei der Streamingerkennung wird ein bidirektionaler gRPC-Stream mit Speech-to-Text eingerichtet. Audiodaten werden im Anfragestream gesendet und Sie erhalten dann asynchron Transkriptionsergebnisse im Antwortstream.

Die folgenden Richtlinien helfen dabei, mit Speech-to-Text optimale Ergebnisse zu erzielen:

  • Verwenden Sie eine Clientbibliothek, die die Interaktion mit Speech-to-Text vereinfacht. Die Clientbibliotheken fassen beispielsweise die gRPC-Kommunikation zusammen, sodass Sie sich auf Ihre Geschäftslogik konzentrieren können.
  • Befolgen Sie die Best Practices und den Optimierungsleitfaden, um Details zum Sampling und zur Codierung der Quell-Audiodaten zu erhalten.
  • Setzen Sie das Flag interim_results. Daraufhin gibt Speech-to-Text vorläufige Transkriptionen zurück, sobald sie verfügbar sind, anstatt auf ein endgültiges Ergebnis zu warten. Dies ist nützlich, wenn Sie einen kontinuierlichen Audiostream haben.
  • Experimentieren Sie mit anderen Konfigurationsoptionen, die für Ihren Anwendungsfall relevant sein könnten. Beispielsweise können Features wie automatische Satzzeichen, Konfidenz auf Wortebene und Sprecherbestimmung zusätzliche nützliche Ergebnisse liefern. (Diese Features sind nicht für alle Sprachen verfügbar. Informationen dazu, ob ein Feature für Ihre Sprache verfügbar ist, finden Sie auf der Seite Sprachunterstützung.)

Leader-Auswahl für eine zustandsorientierte Interaktion mit Speech-to-Text und einen effizienten Failover verwenden

Die bidirektionale Streamingverbindung zu Speech-to-Text ist zustandsorientiert, da sich die von Speech-to-Text zurückgegebenen Zwischenergebnisse der Transkription sich nach Eintreffen nachfolgender Audioblöcke noch ändern können. Daher sollten die Audiodaten über eine einzige langlebige Verbindung gesendet werden.

Zur Erhöhung der Verfügbarkeit werden die Pods des Transcriber-Dienstes jedoch redundant in mehreren Zonen in der Region bereitgestellt. Daher benötigen Sie einen robusten Mechanismus, einen der Pods als primären Pod oder auch Leader festzulegen. Nur der Leader Pod nutzt Audiodaten aus der Warteschlange und sendet sie an Speech-to-Text. Die anderen Pods fungieren als Hot-Standby für Failover. Dies wird als das Muster der Leader-Auswahl bezeichnet.

Der Go-Client von Kubernetes bietet eine Implementierung zur Leader-Auswahl sowie ein Beispiel zur Veranschaulichung der Verwendung. Die Kandidatenprozesse konkurrieren um eine Sperre, die von der Kubernetes-Steuerungsebene verwaltet wird. Ein Prozess erhält die Sperre und wird für einen bestimmten Zeitraum als Leader ausgewählt. Der Leader sendet ständig Heartbeats, um seine Position als Leader zu erneuern, und die anderen Kandidaten starten immer wieder neue Versuche, zum Leader zu werden. Wenn der Leader seine Position nicht innerhalb eines festgelegten Zeitrahmens erneuert, wird einer der anderen Kandidaten als Leader ausgewählt und erhält die Sperre.

Durch die Verwendung der Leader-Auswahl in dieser Anwendung können Verzögerungen bei der Auslieferung von Transkriptionen bei Fehlern oder Ausfällen minimiert werden. Wenn Sie die Leader-Auswahl verwenden, warten andere Pods darauf, die Transkriptionen fortzusetzen, wenn der aktuelle Leader fehlschlägt. Sie müssen also nicht warten, bis Kubernetes einen neuen Pod bereitgestellt hat.

Die Konfiguration für die Leader-Auswahl nutzt mehr Clusterressourcen als eine Konfiguration für einen einzelnen Pod, da die Pods, die nicht Leader sind, normalerweise inaktiv sind. Für eine latenzabhängige Transkriptionsanwendung sind diese zusätzlichen Kosten jedoch gerechtfertigt.

Die Auswahllogik für den Leader kann als Sidecar-Container in jedem Transcriber-Pod bereitgestellt werden. Dadurch wird die Trennung zwischen der Logik der Leader-Auswahl und der grundlegenden Transkriptionslogik aufrechterhalten.

Weitere Informationen zur Auswahl von Leadern mit Kubernetes finden Sie im Kubernetes-Blog unter Simple leader election with Kubernetes and Docker.

Memorystore für einen schnellen Zwischenspeicher verwenden

Durch die Bereitstellung der Anwendung als Satz von locker gekoppelten Mikrodiensten wird die Architektur flexibler. Dies bedeutet jedoch auch, dass Sie einen Mechanismus benötigen, um Daten von einer Ebene an eine andere zu übergeben.

Für einen Anwendungsfall der Livetranskription sind die Latenz und die Reihenfolge der Verarbeitung die wichtigsten Voraussetzungen. Da die Transkription in Echtzeit erfolgt, ist es wichtig, Daten schnell durch die Anwendung zu bewegen und Vorgänge zu minimieren, die die Transkriptionslatenz erhöhen könnten. Außerdem ist es wichtig, dass die Audioblöcke in der richtigen Reihenfolge verarbeitet werden, da die Transkription sonst möglicherweise unvollständig oder ungenau ist.

Memorystore for Redis bietet einen schnellen In-Memory-Speicher für Anwendungsfälle, die eine Datenverarbeitung in Echtzeit erfordern. Memorystore ist aus folgenden Gründen eine gute Wahl für die Transkriptionsanwendung:

  • Schnell: Daten werden im Arbeitsspeicher und nicht auf dem Laufwerk gespeichert. Die Interaktion mit dem Arbeitsspeicher ist viel effizienter als die Interaktion mit einem Laufwerk.
  • Flexibel: Redis bietet nützliche Datenstrukturen und Befehle zum Speichern und Verarbeiten von Daten. Außerdem gibt es eine Vielzahl von Redis-Clientbibliotheken.
  • Offen: Memorystore for Redis ist vollständig mit Open Source Redis kompatibel.
  • Vollständig verwaltet: Memorystore ist vollständig verwaltet, sodass Sie sich auf Ihre Anwendung statt auf die Infrastrukturverwaltung konzentrieren können.
  • Hochverfügbar: Memorystore for Redis-Instanzen der Standardstufe werden automatisch zonenübergreifend repliziert und auf Integrität überwacht. Außerdem haben sie einen schnellen automatischen Failover. Weitere Informationen finden Sie in der Dokumentation zu Hochverfügbarkeit.

Memorystore for Redis als zuverlässige Warteschlange verwenden

Redis-Listen werden häufig als sortierte Warteschlange verwendet. Gehen Sie für diese Transkriptionsanwendung davon aus, dass die Quell-Audiodaten der Reihe nach empfangen werden. Daher kann der Ingestor-Dienst die Audiodaten in eine benannte Warteschlange schreiben und der Transcriber-Dienst Daten aus der Warteschlange nutzen. Redis bietet Befehle, mit denen der Transcriber-Dienst effizient blockiert werden kann, bis sich Daten in der Warteschlange befinden.

Da Speech-to-Text Streamingergebnisse asynchron zurückgibt, müssen Sie darauf achten, den Transkriptionsverlust im Falle eines Ausfalls zu minimieren. Sie können beispielsweise eine zweite Redis-Warteschlange verwenden, um die letzten N Sekunden an Audio, das an Speech-to-Text gesendet wurde, vorübergehend zu duplizieren. Wenn ein Ausfall eintritt und ein neuer Transcriber-Pod als Leader ausgewählt wird, kann dieser die zweite Warteschlange auslesen und die zuvor empfangenen Audiodaten noch einmal an Speech-to-Text senden, bevor er mit der Verarbeitung aus der Hauptwarteschlange beginnt. Der Redis-Befehl BRPOPLPUSH bietet eine kleinteilige Möglichkeit, aus einer Liste zu lesen und Daten einer anderen Liste hinzuzufügen. Er wird häufig für solche zuverlässigen Warteschlangen verwendet. Beachten Sie, dass dieser Ansatz zu doppelten Transkriptionsfragmenten führen kann. Nachgelagerte Consumer der Transkriptionen müssen mit potenziellen Duplikaten umgehen. (Das Verwalten potenzieller Duplikate wird in diesem Dokument nicht behandelt.)

Pub/Sub als Alternative zu Memorystore verwenden

Pub/Sub ist ein skalierbares, hochverfügbares und langlebiges System zur Aufnahme und Bereitstellung von Ereignissen. Pub/Sub bietet asynchrones Messaging mit niedriger Latenz, das Absender und Empfänger entkoppelt. Pub/Sub wird häufig verwendet, um Ereignisse und Daten von einem Teil einer Anwendung an einen anderen zu übergeben.

Sie können Pub/Sub als Alternative zu Memorystore für die Transkriptionsanwendung verwenden. Anstatt die aufgenommenen Audiodaten beispielsweise in Redis zu speichern, wo sie dann vom Transcriber-Dienst gelesen werden, können Sie die Audiodaten mit Pub/Sub in einem Abo veröffentlichen, das vom Transcriber-Dienst genutzt wird.

Pub/Sub bietet die folgenden Features:

  • Globale Verfügbarkeit
  • Sehr hohe Skalierbarkeit
  • Einfache Nachrichtenwiedergabe über die Suchfunktion, die für die Anwendungswiederherstellung nützlich ist
  • Die Bereitstellung erfolgt serverlos, das heißt, Sie zahlen nur für die tatsächliche Nutzung.

Für Pub/Sub gelten jedoch auch die folgenden Einschränkungen:

  • Die Reihenfolge der Nachrichtenzustellung ist nicht garantiert.
  • Das Pub/Sub-Feature der mindestens einmaligen Zustellung kann eine Nachricht mehrmals zustellen, sodass Duplikate auftreten können.
  • Pub/Sub schreibt Nachrichten in den Speicher, was die Latenz erhöhen kann.

Je nach Anwendungsfall können Sie die Einschränkungen in der vorherigen Liste ignorieren oder umgehen. Pub/Sub bietet dann möglicherweise eine höhere Effizienz. Sie sollten beide Technologien in Betracht ziehen, um zu ermitteln, welche am besten zu Ihrem Szenario passt.

Sprachanpassung zum Bereitstellen von Transkriptionshinweisen für Speech-to-Text verwenden

Wenn Sie die in diesem Dokument aufgeführten Richtlinien befolgen, helfen Sie Speech-to-Text dabei, genaue Ergebnisse zu liefern. Zur weiteren Verbesserung der Transkriptionsgenauigkeit können Sie mithilfe von Sprachanpassung zusätzliche Kontextinformationen für Speech-to-Text bereitstellen.

Wenn Sie bei der Sprachanpassung eine Transkriptionsanfrage an Speech-to-Text senden, fügen Sie eine Liste von Wörtern und Wortgruppen hinzu, die als Hinweise dienen sollen. Diese Hinweise helfen Speech-to-Text, die angegebenen Wortgruppen in den Audiodaten zu erkennen. Wenn der Live-Audiostream beispielsweise von jemandem stammt, der über das Wetter spricht, kann die Transkriptionsgenauigkeit durch gebräuchliche auf das Wetter bezogene Wörter verbessert werden.

Für einen Produktionsanwendungsfall können Sie Wörterbücher mit Hinweisen erstellen, die bei Bedarf abgerufen werden können. Wenn Ihre Anwendung beispielsweise automatische Untertitel für einen TV-Wetterbericht bereitstellt, kann sie das Wörterbuch mit Wetterbegriffen abrufen, das Sie zuvor erstellt haben. Wenn sich die Übertragung jedoch auf Golf bezieht, kann die Anwendung ein Wörterbuch mit Golfbegriffen und Spielernamen abrufen.

Bei einem fortgeschrittenen Anwendungsfall kann das Wörterbuch in Echtzeit aktualisiert werden. Ein geschulter Prüfer kann die Ausgabetranskriptionen überwachen und direkt Änderungen am Wörterbuch vornehmen. Der Transcriber-Dienst kann auf eine Ereignisbenachrichtigung über Änderungen am Wörterbuch warten und das aktualisierte Wörterbuch für nachfolgende Verbindungen zu Speech-to-Text abrufen und verwenden.

Für jeden Quell-Audiostream eine separates Transcriber-Deployment erstellen

Sender betreiben in der Regel mehr als einen Kanal und möchten möglicherweise Transkriptionen für mehrere Kanäle generieren. Jeder Kanal stellt einen eigenen Quell-Audiostream dar. Ihre Anwendung muss für jeden zu transkribierenden Kanal eine separate Verbindung zu Speech-to-Text haben. Dafür gibt es mehrere Ansätze.

Ein Ansatz besteht darin, die Gruppe von Kanälen direkt in der Transcriber-Logik zu verwalten. Mit diesem Ansatz bleibt der GKE-Cluster einfach, da Sie nur ein einziges Transcriber-Deployment im Cluster haben. Dieser Ansatz erhöht jedoch die Komplexität der Transkriptionslogik, da eine Reihe aktiver Kanäle und Verbindungen aufrechterhalten und verwaltet werden muss. Dieser Ansatz erschwert außerdem die Verwendung unterschiedlicher Konfigurationen für die einzelnen Kanäle (z. B. unterschiedliche Hinweiswörterbücher oder unterschiedliche Prioritäten), da alle Kanäle in einem einzelnen Deployment verarbeitet werden.

Ein besserer Ansatz kann darin bestehen, für jeden Kanal ein eigenes Transcriber-Deployment zu erstellen. Dies vereinfacht die Anwendungslogik, da jede Transcriber-Instanz eine einzelne Streamingverbindung zu Speech-to-Text verwaltet. Dieser Ansatz bietet folgende zusätzliche Vorteile:

  • Flexibilität: Sie können Deployments mit unterschiedlichen Konfigurationen für jeden Kanal erstellen. Einem Premiumkanal können beispielsweise mehr Clusterressourcen zugesichert werden als einem Standardkanal.
  • Isolierung: Sie können jeden Transkriptionskanal als separate Einheit behandeln.
  • Ressourceneffizienz: Kubernetes kann mehrere kleinere Transcriber-Deployments besser auf die Clusterressourcen verteilen als ein einzelnes großes Deployment.

Labels oder Namespaces zum Gruppieren von Ressourcen nach Kanal verwenden

Kubernetes bietet einige Features zum Gruppieren verwandter Ressourcen. Sie können diese Features verwenden, um Clusterressourcen für die einzelnen Kanäle zu trennen:

  • Labels sind Schlüssel/Wert-Paare, die Objekten im Kubernetes-Cluster wie Pods angehängt sind. Mithilfe von Labels können Sie Untergruppen von Objekten organisieren und auswählen.
  • Namespaces sind eine Möglichkeit, Clusterressourcen zu unterteilen. Sie können sich einen Namespace als virtuellen Cluster in Ihrem Kubernetes-Cluster vorstellen. Sie können mehrere Namespaces in einem einzelnen Kubernetes-Cluster haben, die alle logisch voneinander getrennt sind.

Mithilfe von Labels und Namespaces können Sie separate Transcriber-Instanzen bereitstellen, die für einen bestimmten Kanal konfiguriert sind. Mithilfe von Labels können Sie Ressourcen schnell und einfach gruppieren. Namespaces bieten eine formellere Trennung. Sie sind eine gute Wahl, wenn Sie die von den einzelnen Kanälen genutzten Clusterressourcen steuern möchten oder wenn die Kanäle von verschiedenen Teams verwaltet werden.

Ressourcen mit mehreren Quell-Audiostreams gemeinsam nutzen

Das Erstellen einer separaten Transcriber-Instanz für jeden Quell-Audiokanal, wie im vorherigen Abschnitt beschrieben, hat Vorteile. Abhängig von den Anforderungen an die Transkriptionsanwendung können Sie auch separate Ingestor-und Reviewer-Deployments für jeden Kanal erstellen. Dieser Ansatz kann sinnvoll sein, wenn eine der folgenden Einschränkungen zutrifft:

  • Sie benötigen ein hohes Maß an Isolation für jeden Kanal in der gesamten Anwendung. Beispielsweise wird jeder Kanal von einem separaten Team verwaltet.
  • Der Ingestor-Dienst verwendet Software von Drittanbietern, die mehrere Streams nicht problemlos verarbeiten kann.
  • Für die Reviewer-Anwendung ist für jeden Kanal ein benutzerdefiniertes Verhalten definiert.

Einer der Vorteile einer locker miteinander verbundenen Architektur ist jedoch die Möglichkeit, für jeden Dienst unterschiedliche Skalierungs- und Bereitstellungsstrategien auszuwählen. Wenn die Einschränkungen in der obigen Liste nicht zutreffen, kann die gemeinsame Nutzung von Ingestor- oder Reviewer-Diensten durch mehrere Kanäle effizienter sein. Zu den Vorteilen der Verarbeitung mehrerer Kanäle in einzelnen Deployments gehören beispielsweise folgende:

  • Ein Kubernetes-Dienst kann mehrere Ports verfügbar machen und jeder Kanal kann einen anderen Port als Ziel haben. Der Ingestor- und der Reviewer-Dienst können dann jeweils einen einzigen Load-Balancer und somit eine einzige externe IP-Adresse bereitstellen, die kanalübergreifend verwendet wird. Dies trägt dazu bei, Kosten und Verwaltungsaufwand zu reduzieren.
  • Ebenso empfiehlt es sich, die Anzahl der externen IP-Adressen zu minimieren, die von Ihrer Anwendung bereitgestellt werden.
  • Sie können Autoscaling verwenden, um die Deployments zu skalieren, sobald Kanäle online und offline gehen.

Memorystore for Redis gemeinsam nutzen

Dieselben Überlegungen für die gemeinsame Nutzung von Ressourcen gelten auch für Memorystore for Redis. Wenn Sie für jeden Kanal eine separate Memorystore-Instanz erstellen, bleiben die Kanäle getrennt. Dies kann jedoch zu höheren Kosten und mehr Verwaltungsaufwand führen.

Redis wurde speziell für hohen Durchsatz entwickelt. Daher ist die Erstellung einer dedizierten Memorystore-Instanz für jeden Kanal möglicherweise keine effiziente Ressourcennutzung. Wenn Sie eine saubere Trennung der Kanäle benötigen, können Sie Redis als Alternative zu Memorystore im GKE-Cluster ausführen. Bei diesem Ansatz erstellen Sie ein Redis-Deployment für jeden Kanal im Cluster. Allerdings sind Sie dann selbst für die Verwaltung von Redis verantwortlich und es kann schwierig sein, Redis in einer Hochverfügbarkeitskonfiguration zu betreiben. Weitere Informationen zum Ausführen von Redis in Kubernetes finden Sie unter Example: Deploying PHP Guestbook application with Redis.

Wie bereits erwähnt, ist Memorystore for Redis auf hohe Leistung ausgelegt und eine einzelne Instanz sollte mehrere gleichzeitige Kanäle verarbeiten können. Beachten Sie auch, dass Memorystore for Redis skaliert werden kann, um bei Bedarf Kapazitäten hinzuzufügen oder zu entfernen. Auf diese Weise können Sie eine einzelne Memorystore-Instanz kanalübergreifend nutzen und nach Bedarf vergrößern oder verkleinern. Wenn Sie eine Memorystore-Instanz für mehrere Kanäle nutzen, können Sie die Kanal-ID als Präfix für die Redis-Schlüssel verwenden.

Ausfallsicherheit von Anwendungen durch Einleiten von Fehlern testen

Ausfallsicherheit ist eine wichtige Voraussetzung für eine Transkriptionsanwendung in der Produktionsumgebung. Im Falle eines Ausfalls oder Aussetzers sollte die Anwendung die Transkriptionen schnell und mit minimalem Transkriptionsverlust fortsetzen.

Die in diesem Dokument beschriebene Architektur enthält mehrere Features zur Verbesserung der Ausfallsicherheit:

  • Der Transcriber-Dienst verwendet Leader-Auswahl, um einen Failover auf einen Hot-Standby-Pod durchzuführen, wenn der aktuelle Leader ausfällt.
  • Die Anwendung verwendet die Redis-Features für zuverlässige Warteschlangen, um den Datenverlust bei Ausfällen zu minimieren.
  • Die Architektur umfasst Kubernetes-Dienste mit zugeordneten Load-Balancern. Google Cloud-Load-Balancer enthalten Systemdiagnosen, um zu prüfen, ob die zugrunde liegenden Rechenknoten fehlerfrei sind.
  • Die Anwendungsdienste werden redundant über Zonen bereitgestellt, um gegen zonale Ausfälle geschützt zu sein.
  • Jeder Anwendungsdienst ist ein Kubernetes-Deployment mit der gewünschten Anzahl von Pod-Replikaten. Wenn ein Pod abstürzt oder gelöscht wird, erstellt Kubernetes ihn automatisch neu, sodass die konfigurierte Anzahl von Replikaten erhalten bleibt.
  • Memorystore for Redis-Instanzen der Standardstufe werden automatisch zonenübergreifend repliziert und auf ihre Integrität überwacht. Außerdem haben sie einen schnellen automatischen Failover.

Es ist nicht möglich, alle möglichen Fehler oder Ausfälle zu testen, aber Sie können dennoch viel über Ihre Anwendung erfahren, indem Sie Fehler einleiten und die Ergebnisse untersuchen. Beim Testen von Ausfallsicherheit und Wiederherstellung ist es wichtig, Ihre Ziele und Erwartungen zu formulieren. Für bestimmte Anwendungsfälle kann ein gewisser Transkriptionsverlust akzeptabel sein. In anderen Anwendungsfällen ist es möglicherweise erforderlich, den Transkriptionsverlust zu minimieren. Wenn Sie Ihre Wiederherstellungsziele im Voraus formulieren, können Sie den Fortschritt im Hinblick auf diese Ziele messen.

Eine ausführliche Beschreibung der Fehlerarten wird in diesem Dokument nicht behandelt. In den folgenden Abschnitten werden einige Basistests beschrieben, mit denen Sie die Ausfallsicherheit der Anwendung einschätzen können.

Kubernetes-Pods löschen

Eine Möglichkeit, Fehler in die Anwendung einzuleiten, besteht darin, Kubernetes-Pods aus dem GKE-Cluster zu löschen. Dies ist eine Form von Chaos Engineering. Ein einfacher Ansatz besteht darin, ein benutzerdefiniertes Skript zu schreiben, das Pods in einem bestimmten Intervall zufällig löscht. Alternativ gibt es viele Drittanbietertools, mit denen Sie in Kubernetes-Clustern einen Chaostest durchführen können. Sie sollten das Verhalten jedes Anwendungsdienstes beim Löschen von Pods systematisch testen.

Manuellen Failover von Memorystore durchführen

Memorystore for Redis-Instanzen der Standardstufe bieten eine hohe Verfügbarkeit durch Replikation und automatischen Failover. Die primäre Instanz und das Replikat befinden sich in unterschiedlichen Zonen innerhalb derselben Region, um zonale Ausfälle tolerieren zu können. Ein Failover tritt auf, wenn die primäre Redis-Instanz ausfällt.

Ein Memorystore-Failover wirkt sich folgendermaßen auf die Anwendung aus:

  • Wenn eine primäre Instanz einen Failover auf das Replikat durchführt, werden alle bestehenden Verbindungen zu Memorystore for Redis unterbrochen. Wenn die Anwendung die Verbindung jedoch wiederherstellt, wird sie automatisch über den gleichen Verbindungsstring oder die gleiche IP-Adresse an die neue primäre Instanz weitergeleitet.
  • Während der Memorystore for Redis-Dienst das Replikat auf die primäre Instanz hochstuft, ist die Memorystore for Redis-Instanz vorübergehend nicht verfügbar.

Wenn Sie testen möchten, wie sich die Anwendung unter diesen Bedingungen verhält, können Sie einen manuellen Failover auslösen. Ein Failover führt in der Regel zu einem gewissen Datenverlust. Sie sollten den Verlustgrad messen und entscheiden, wie Sie ihn für Ihren Anwendungsfall am besten handhaben.

Nächste Schritte