Google Cloud API Gateway unterstützt Streaming: Was Sie vor der Migration prüfen sollten

Ein Streaming-Backend hält die Verbindung offen und überträgt Daten in Teilen: SSE kann beispielsweise den Antworttext eines Modells während der Generierung senden, während WebSockets einen bidirektionalen Austausch ermöglichen. Am 22. Oktober 2026 kündigte Google die öffentliche Vorschau für Streaming in Cloud API Gateway an. Das Gateway kann solche Antworten weiterleiten und dabei die vertrauten Authentifizierungsregeln und Beobachtungsfunktionen auf Anfragen anwenden. Für Tests muss ein neues Gateway mit aktiviertem Streaming-Modus erstellt werden.

Die Google-Ankündigung führt SSE, HTTP-Response-Streaming und Chunked Transfer Encoding, WebSockets sowie serverseitiges und bidirektionales gRPC-Streaming auf. HTTP-Antworten werden beim Eintreffen vom Backend an den Client weitergegeben, auch im NDJSON-Format. So können Streaming-Routen hinter demselben API Gateway bleiben, das bereits gewöhnliche Anfragen verarbeitet.

Was sich an API und Infrastruktur ändert

Für Streaming-Vorgänge ist weder eine separate API-Beschreibung noch eine spezielle Erweiterung der Spezifikation erforderlich. In der Vorschau wird der Streaming-Modus beim Erstellen des Gateways mit dem Flag --enable-streaming festgelegt. Laut Google bleiben API-Key- und JWT-Prüfungen, die Backend-Authentifizierung über ein Dienstkonto, das Routing sowie die Integration mit Cloud Logging und Cloud Monitoring erhalten.

Die Vorschau führt außerdem einen vorhersehbaren Hostnamen ein, der auf der Gateway-ID, der Projektnummer und der Region basiert. Das Adressformat lautet beispielsweise GATEWAY_ID-PROJECT_NUMBER.REGION.gateway.dev. Sie können die Adresse vorab in der Client- oder CI-Konfiguration hinterlegen. Wird das Gateway mit derselben ID, demselben Projekt und derselben Region erneut erstellt, bleibt die Adresse erhalten.

Testen, ohne den Produktionsverkehr umzuleiten

1. Wählen Sie ein vorhandenes Backend aus. Beginnen Sie mit einem Endpunkt, der bereits SSE oder eine HTTP-Streaming-Antwort sendet. So lässt sich das Verhalten des Gateways von Änderungen an der Anwendung trennen.
2. Erstellen Sie ein separates Gateway. Das Aktivieren von Streaming wird beim Erstellen festgelegt; der Modus eines vorhandenen Gateways lässt sich nicht ändern. Verwenden Sie eine Test-ID und eine geeignete Region.
3. Konfigurieren Sie das Backend-Deadline. Für SSE und HTTP-Streaming beträgt die standardmäßige Anforderungsdauer 15 Sekunden. Der Stream wird geschlossen, sobald das festgelegte Limit erreicht ist. Legen Sie in der OpenAPI-Konfiguration für das Backend ein für Ihren Anwendungsfall passendes deadline fest. Für ein Streaming-Gateway erlaubt die Dokumentation einen Wert von bis zu 3600 Sekunden. Berücksichtigen Sie auch das eigene Timeout des Backends – Cloud Run kann die Verbindung beispielsweise früher schließen.
4. Prüfen Sie das Backend-Protokoll. Für gRPC ist HTTP/2 (h2) erforderlich, für WebSockets HTTP/1.1. SSE und HTTP-Streaming funktionieren mit HTTP/1.1 oder HTTP/2; Google empfiehlt für diese Anwendungsfälle HTTP/2.
5. Prüfen Sie den Eingang der Daten. Vergewissern Sie sich, dass der Client erste Ereignisse erhält, bevor die vollständige Antwort abgeschlossen ist. Prüfen Sie bei WebSockets den bidirektionalen Austausch und planen Sie ein erneutes Verbinden der Clients nach dem Ende der Verbindung ein.
6. Prüfen Sie Richtlinien und Messwerte. Kontrollieren Sie Authentifizierung, Protokolle und Anforderungsbeschränkungen auf der Streaming-Route. Der Messwert „request latency“ bildet die gesamte Dauer des Streams ab. Messen Sie daher clientseitig zusätzlich die Zeit bis zum ersten Ereignis und die Abstände zwischen den Ereignissen.

Für WebSockets und gRPC legt die Dokumentation standardmäßig ein Inaktivitätsintervall von 300 Sekunden fest. Bei WebSockets wird eine Dauer unter 300 Sekunden nicht angewendet; in jedem Fall endet die Verbindung spätestens nach 3600 Sekunden. Für SSE und HTTP-Streaming gilt das festgelegte Wall-Clock-Deadline. Ein hoher Wert für „request latency“ zeigt deshalb allein nicht, wie schnell Nutzerinnen und Nutzer das erste Datenfragment erhalten haben.

Einschränkungen der öffentlichen Vorschau

Zum Start lässt sich der Streaming-Modus weder über die Cloud Console noch über Terraform aktivieren. Außerdem sind Gateways mit aktiviertem Streaming nicht mit HTTP(S) Load Balancing und Serverless NEG kompatibel. Daher sind benutzerdefinierte Domains, die von dieser Konfiguration abhängen, nicht verfügbar. Google führt diese Funktionen als mögliche spätere Ergänzungen während der Vorschau auf. Prüfen Sie vor der Planung von Produktionsrouting und Automatisierung die Dokumentation zur Streaming-Konfiguration.

Als erster praktischer Schritt empfiehlt es sich, ein neues Gateway auf ein vorhandenes Streaming-Backend auszurichten, das Deadline ausdrücklich festzulegen und die direkte Verbindung mit der Route über das Gateway zu vergleichen. So kann das Team die Protokollkompatibilität, die Authentifizierung und die tatsächliche Zeit bis zum ersten Ereignis prüfen, ohne den API-Vertrag oder den Produktionsverkehr zu ändern.