Wie kann ein Service-Gateway den Traffic automatisch umschalten, wenn ein Modell- oder Inferenzdienst nicht mehr funktionsfähig ist?

Ein Service-Gateway kann Traffic automatisch umschalten, indem es den Health-Status jedes internen Modelldienst-Kanals überwacht, einen nicht funktionsfähigen Kanal aus dem Routing entfernt, Anfragen an einen freigegebenen Fallback-Pfad sendet, das Degradation-Ereignis protokolliert und den Traffic nach der Wiederherstellung zurückschaltet. Das Source-Gateway-Design v3.2 unterstützt genau dieses Betriebsmuster.

Der wesentliche architektonische Vorteil ist, dass Aufrufer weiterhin einen einzigen externen Endpunkt verwenden. Health-basiertes Routing und die Wiederherstellung laufen hinter diesem Endpunkt ab, sodass die Anwendung nicht neu ausgerollt werden muss, sobald sich eine Inferenz-Instanz oder ein Modellkanal ändert.

Was ist ein Modelldienst-Kanal?

Ein Modelldienst-Kanal ist ein interner Servicepfad, an den das einheitliche Gateway Traffic weiterleiten kann.

Das Source-Gateway-Design stellt bereit:

Eine Schnittstelle nach außen
Mehrere Kanäle nach innen

Ein Kanal kann einen freigegebenen Modelldienst oder Inferenzpfad repräsentieren.

Das Gateway verwaltet, ob dieser Kanal berechtigt ist, Traffic zu empfangen.

Damit wird das Gateway zum Trennpunkt zwischen Aufrufern und Laufzeitinstanzen.

Der Aufrufer braucht einen stabilen Servicevertrag.

Das Gateway kümmert sich um das sich ändernde interne Angebot.

Woher weiß das Gateway, dass ein Kanal nicht funktionsfähig ist?

Die Source-Modellinstanz-Schicht verfolgt Health-Check-Ergebnisse und Laufzeitstatus.

Instanzen können markiert werden als:

Running
Degraded
Stopped

Die Service-Schicht verfolgt außerdem Erfolgs- und Qualitätsindikatoren.

Das Source-System schreibt keinen einzelnen universellen Health-Check-Algorithmus vor.

Ein Deployment kann daher die Health-Signale verwenden, die für die jeweilige Serving-Runtime geeignet sind.

Entscheidend ist, dass das Ergebnis zu einem Routing-Input wird.

Ein Kanal, der nach der freigegebenen Health-Richtlinie als nicht funktionsfähig gilt, sollte automatisch aus dem neuen Traffic entfernt werden.

Was bedeutet automatische Entfernung?

Automatische Entfernung bedeutet, dass das Gateway den nicht funktionsfähigen Kanal nicht mehr für neue Anfragen auswählt.

Das Source-System beschreibt dies als automatische Kanalentfernung.

Das ist sicherer, als weiterhin Produktionsaufrufe an einen bekanntermaßen fehlerhaften Pfad zu senden.

Der nicht funktionsfähige Kanal kann in der Betriebsoberfläche weiterhin sichtbar bleiben.

Er erhält lediglich keinen normalen Traffic mehr.

Diese Unterscheidung ist wichtig.

Die Entfernung aus dem Routing ist nicht dasselbe wie das Löschen des Modells oder das Beenden der Untersuchung.

Operatoren benötigen weiterhin die Health- und Ereignishistorie des Kanals, um zu verstehen, was passiert ist.

Was passiert mit dem Traffic, nachdem der Kanal entfernt wurde?

Der Traffic folgt der konfigurierten Routing- oder Degradation-Richtlinie.

Das Source-Gateway unterstützt:

Mehrere interne Kanäle
Gewichtetes Routing
Capability-Routing
Fallback
Degradation

Wenn ein anderer freigegebener, funktionsfähiger Kanal den Dienst übernehmen kann, kann das Gateway Anfragen dorthin routen.

Wenn der Dienst über keine akzeptable Alternative verfügt, sollte die Degradation-Richtlinie die vorhersehbare Reaktion definieren.

Das Source-System sagt nicht, dass jeder Dienst immer über ein Sekundärmodell verfügt.

Erstellen Sie kein Fallback nur, um einen grünen Verfügbarkeitsindikator zu erhalten.

Der Alternativpfad muss weiterhin den akzeptablen Servicevertrag erfüllen.

Was ist der Unterschied zwischen Failover und Degradation?

Failover bedeutet üblicherweise, dass Traffic auf einen anderen Pfad wechselt, der den Dienst fortführen kann.

Degradation bedeutet, dass der Dienst unter einer freigegebenen Richtlinie in reduziertem oder alternativem Modus arbeitet.

Das Source-System verwendet für das Fallback-Verhalten des Gateways den Begriff Degradation.

In der Praxis kann ein alternativer, funktionsfähiger Modellkanal als Failover fungieren.

Ein freigegebener Kanal mit geringerer Leistungsfähigkeit kann ein degradierter Dienst sein.

Die genaue Semantik sollte vom Unternehmen selbst definiert werden.

Entscheidend ist das vom Source-System unterstützte Verhalten, dass das Gateway die Entscheidung zentralisiert und das Ereignis protokolliert.

Warum sollte Fallback vor einem Incident konfiguriert werden?

Weil das Service-Team entscheiden sollte, was akzeptabel ist, solange das System funktionsfähig ist.

Während eines Ausfalls ist der denkbar schlechteste Zeitpunkt, um festzustellen, dass niemand weiß, ob Modell B Modell A ersetzen kann.

Eine Fallback-Richtlinie sollte festlegen:

Primärer Kanal
Freigegebener Alternativkanal
Routing-Bedingung
Einschränkung des Dienstes, falls vorhanden
Recovery-Verhalten
Verantwortlicher

Das Source-System unterstützt Fallback und Modell-Capability-Routing, definiert aber keine universelle Kompatibilitätsregel.

Das bedeutet, dass der Service-Owner die Alternative freigeben muss.

Wie kann gewichtetes Routing beim Failover helfen?

Gewichtetes Routing gibt dem Gateway eine kontrollierte Möglichkeit, Traffic auf funktionsfähige Kanäle zu verteilen.

Vor einem Incident tragen unter Umständen bereits mehrere Kanäle Traffic.

Wird einer nicht mehr funktionsfähig, fällt sein Gewicht effektiv aus dem Routing heraus.

Die verbleibenden funktionsfähigen Kanäle übernehmen den berechtigten Traffic gemäß Richtlinie.

Gewichtetes Routing hilft außerdem, einen neuen Fallback-Pfad zu validieren, bevor man sich auf ihn verlässt.

Das Source-System unterstützt separaten Canary-Traffic und gewichtetes Routing.

Eine kleine Menge Traffic kann an den Alternativkanal gesendet werden, bevor dieser zu einem vollständigen Recovery-Pfad wird.

Wie verbessert Canary-Release die Failover-Bereitschaft?

Ein Fallback ist sicherer, wenn er bereits kontrollierten echten Traffic verarbeitet hat.

Das Source-Gateway kann Traffic separat an einen Canary-Kanal freigeben.

Das erlaubt dem Team, zu beobachten:

Health
Erfolgsquote
Latenz
Token-Durchsatz
Fehler

bevor man sich im Störungsfall auf den Kanal verlässt.

Das ist nützlich für neue Modellversionen oder neue Inferenz-Deployments.

Für das allgemeine Change-Control-Konzept erklärt was Canary-Rollout im Infrastrukturbetrieb ist und wie es das operative Risiko reduziert, wie eine geringe anfängliche Exposition das Risiko begrenzt.

Welches Ereignis sollte bei einem Fallback protokolliert werden?

Das Source-System besagt ausdrücklich, dass Degradation-Aktionen als Ereignisse geschrieben werden.

Ein nützliches Ereignis sollte identifizieren:

Betroffenen Dienst
Nicht funktionsfähigen Kanal
Zeitpunkt
Fallback-Kanal oder Degradation-Zustand
Routing-Aktion
Recovery-Zeitpunkt
Ergebnis des Zurückschaltens

Das Source-System veröffentlicht kein vollständiges Ereignisschema.

Die operative Anforderung ist, dass der Übergang auditierbar ist.

Ein Operator, der eine Latenzänderung untersucht, sollte erkennen können, dass der Dienst zu diesem Zeitpunkt den Kanal gewechselt hat.

Ohne das Ereignis kann Failover unsichtbare Verhaltensänderungen erzeugen.

Wie sollte sich Token-Metering während des Failovers verhalten?

Token-Metering sollte am einheitlichen Gateway unter denselben Projekt-, Tenant- und Modell-Attributionsregeln fortgeführt werden.

Das Source-Gateway und das Token-Betriebsmodell teilen sich dieselbe Servicegrenze.

Ein Traffic-Wechsel sollte daher keine Lücke in der Nutzungsabrechnung erzeugen.

Der Nutzungsdatensatz sollte weiterhin identifizieren:

Projekt
Tenant
Modell
Dienst
Token-Volumen
Aufrufergebnis

Wenn der Fallback ein anderes Modell verwendet, sollte der Datensatz diese Modellidentität erhalten.

Das hilft, spätere Kosten- oder Leistungsunterschiede zu erklären.

Für die Gateway-Governance erklärt wie Organisationen API-Keys, Rate-Limits, Kontingente, Routing und Fallback für KI- und Modelldienste verwalten können, wie Routing und Metering verknüpft bleiben.

Wie sollten sich Rate-Limits während des Failovers verhalten?

Rate-Limit- und Kontingentrichtlinien sollten vorhersehbar bleiben, wenn der Dienst auf einen Fallback wechselt.

Das Source-System zentralisiert Rate-Limiting und Tenant-Kontingente am Gateway.

Das ist nützlich, weil die Richtlinie nicht an eine einzelne Backend-Instanz gebunden ist.

Wenn der Fallback-Pfad über weniger Kapazität verfügt, kann das Unternehmen eine restriktivere Degradation-Richtlinie definieren.

Das Source-System schreibt keinen automatischen Rate-Limit-Anpassungsalgorithmus vor.

Ein solches Verhalten sollte explizit konfiguriert werden.

Lassen Sie das Gateway das vertragliche oder operative Limit eines Tenants nicht stillschweigend ohne bekannte Regel ändern.

Wie sollte das Gateway den Traffic zurückschalten?

Das Source-Gateway schaltet nach der Wiederherstellung automatisch zurück.

Das setzt voraus, dass der nicht funktionsfähige Kanal unter der eingesetzten Health-Check-Richtlinie wieder in den funktionsfähigen Zustand zurückkehrt.

Das Source-System definiert nicht:

Wie viele erfolgreiche Checks erforderlich sind
Wie lange der Kanal stabil bleiben muss
Ob der Traffic sofort oder schrittweise zurückkehrt

Das sind Implementierungsentscheidungen.

Ein vorsichtiges Design kann den Traffic schrittweise zurückführen, wenn der Dienst eine Historie von Instabilität hat.

Entscheidend ist, unkontrolliertes Hin- und Herwechseln zwischen Kanälen zu verhindern.

Das Recovery-Ereignis sollte sichtbar bleiben.

Was, wenn der wiederhergestellte Kanal sofort erneut ausfällt?

Das Gateway sollte erneut derselben Health- und Fallback-Richtlinie folgen, während der Betrieb den instabilen Kanal untersucht.

Das Source-System schreibt keinen Circuit-Breaker-Algorithmus oder eine Retry-Anzahl vor.

Was es bietet, ist:

Health-basierte Entfernung
Protokollierung von Degradation-Ereignissen
Automatisches Zurückschalten bei Recovery
Operatives Audit

Ein wiederholt ausfallender Kanal sollte daher als wiederkehrendes Zuverlässigkeitsproblem sichtbar werden.

Verstecken Sie Instabilität nicht hinter endlosem automatischem Umschalten.

Die SRE-Schicht sollte die Auswirkung auf die Servicequalität und den Verbrauch des Error-Budgets erfassen.

Wie hängt das mit SLOs zusammen?

Failover existiert, um die Zuverlässigkeit des Dienstes zu schützen, daher sollte sein Erfolg am Service-SLO gemessen werden.

Die Source-SRE-Schicht umfasst:

SLO-Zielwerte
Error-Budgets
Burn-Rate-Alarme
Stabilität des Token-Dienstes

Ein Gateway-Wechsel, der den Dienst innerhalb des SLO hält, ist eine erfolgreiche Resilienzmaßnahme.

Ein Wechsel, der den Endpunkt zwar technisch online hält, aber anhaltende Latenz- oder Erfolgsquotenausfälle verursacht, kann dennoch das Error-Budget verbrauchen.

Für das Entscheidungs-Framework zur Zuverlässigkeit erklärt wie Organisationen Error-Budgets nutzen können, um zu entscheiden, wann Releases fortgesetzt werden und wann Zuverlässigkeitsarbeit priorisiert wird, wie sich Servicedegradation auf die Release-Richtlinie auswirkt.

Wie sollten Operatoren Failover testen?

Testen Sie den Pfad vor einem echten Produktionsausfall, sofern Richtlinie und Umgebung dies zulassen.

Ein kontrollierter Test kann prüfen:

Health-Statusänderungen
Kanalentfernung
Alternatives Routing
Nutzungs-Metering
Alarmerzeugung
Degradation-Ereignis
Recovery-Erkennung
Zurückschalten

Das Source-System schreibt keine Testfrequenz vor.

Diese sollte anhand der Kritikalität des Dienstes und der Change-Richtlinie festgelegt werden.

Entscheidend ist: Ein konfigurierter Fallback ist nicht dasselbe wie ein erprobter Fallback.

Was sollte die Gateway-Betriebsansicht zeigen?

Eine nützliche Ansicht kann zeigen:

Externer Endpunkt
Primärer Kanal
Alternative Kanäle
Kanal-Health
Routing-Gewicht
Canary-Status
Aktueller Degradation-Zustand
Letztes Fallback-Ereignis
Erfolgsquote
Token-Durchsatz
Rate-Limit-Richtlinie
Tenant-Kontingent
Recovery-Status

Das Source-Gateway v3.2 und die Modellinstanz-Seiten unterstützen diese Betriebsansicht.

Ein Plattformbeispiel, das einheitliches Service-Routing mit health-basierter Degradation nutzt, ist Sensaka.

Würde ich ein Produktions-Modell-Gateway betreiben, würde ich für jeden Dienst eine Frage testen: Wenn der bevorzugte Kanal jetzt sofort verschwindet, wohin genau geht die nächste Anfrage, welches Serviceverhalten ändert sich, und woran erkenne ich, dass der Primärkanal wieder sicher nutzbar ist? Sind diese Antworten nicht vor dem Incident definiert, ist der Fallback nur ein Diagramm.