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.

Architektonisch hat das den Vorteil, 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 eine Schnittstelle nach außen und mehrere Kanäle nach innen bereit.

Ein Kanal kann einen freigegebenen Modelldienst oder Inferenzpfad repräsentieren, und das Gateway verwaltet, ob dieser Kanal Traffic empfangen darf. Damit trennt das Gateway die Aufrufer von den Laufzeitinstanzen: Der Aufrufer braucht einen stabilen Servicevertrag, und 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 als Running, Degraded oder Stopped markiert werden, und 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 in das Routing einfließt. 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, und es 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 und erhält lediglich keinen normalen Traffic mehr. Aus dem Routing entfernt heißt also weder, dass das Modell gelöscht wird, noch dass die Untersuchung beendet ist. 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 und Degradation.

Wenn ein anderer freigegebener, funktionsfähiger Kanal den Dienst übernehmen kann, kann das Gateway Anfragen dorthin routen. Hat der Dienst keine akzeptable Alternative, sollte die Degradation-Richtlinie eine 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, denn 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, während ein freigegebener Kanal mit geringerer Leistungsfähigkeit eher ein degradierter Dienst ist. Die genaue Semantik sollte das Unternehmen selbst definieren. Das Source-System sorgt dafür, dass das Gateway die Entscheidung zentral trifft 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 den primären Kanal, den freigegebenen Alternativkanal, die Routing-Bedingung, eine etwaige Einschränkung des Dienstes, das Recovery-Verhalten und den Verantwortlichen festlegen.

Das Source-System unterstützt Fallback und Modell-Capability-Routing, definiert aber keine universelle Kompatibilitätsregel. Der Service-Owner muss die Alternative also selbst freigeben.

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. Fällt einer aus, verschwindet sein Gewicht effektiv aus dem Routing, und 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, sodass eine kleine Menge Traffic an den Alternativkanal gehen kann, 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. So kann das Team Health, Erfolgsquote, Latenz, Token-Durchsatz und Fehler beobachten, bevor es sich im Störungsfall auf den Kanal verlässt. Das ist vor allem für neue Modellversionen oder neue Inferenz-Deployments nützlich.

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 nennt den betroffenen Dienst, den nicht funktionsfähigen Kanal, den Zeitpunkt, den Fallback-Kanal oder Degradation-Zustand, die Routing-Aktion, den Recovery-Zeitpunkt und das Ergebnis des Zurückschaltens.

Ein vollständiges Ereignisschema veröffentlicht das Source-System nicht. Operativ muss der Übergang auditierbar sein: 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 Verhaltensänderungen erzeugen, die niemand sieht.

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

Token-Metering sollte am einheitlichen Gateway unter denselben Projekt-, Tenant- und Modell-Attributionsregeln weiterlaufen. Das Source-Gateway und das Token-Betriebsmodell teilen sich dieselbe Servicegrenze, sodass ein Traffic-Wechsel keine Lücke in der Nutzungsabrechnung erzeugen sollte.

Der Nutzungsdatensatz sollte weiterhin Projekt, Tenant, Modell, Dienst, Token-Volumen und Aufrufergebnis enthalten. Wenn der Fallback ein anderes Modell verwendet, sollte der Datensatz diese Modellidentität erhalten. Damit lassen sich spätere Kosten- oder Leistungsunterschiede 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, und das hat den Vorteil, dass die Richtlinie nicht an eine einzelne Backend-Instanz gebunden ist.

Wenn der Fallback-Pfad weniger Kapazität hat, kann das Unternehmen eine restriktivere Degradation-Richtlinie definieren. Einen automatischen Rate-Limit-Anpassungsalgorithmus schreibt das Source-System nicht vor, also sollte ein solches Verhalten explizit konfiguriert werden. Das Gateway sollte das vertragliche oder operative Limit eines Tenants nicht unbemerkt und ohne bekannte Regel ändern.

Wie sollte das Gateway den Traffic zurückschalten?

Das Source-Gateway schaltet nach der Wiederherstellung automatisch zurück. Voraussetzung ist, dass der nicht funktionsfähige Kanal unter der eingesetzten Health-Check-Richtlinie wieder in den funktionsfähigen Zustand zurückkehrt.

Das Source-System legt nicht fest, wie viele erfolgreiche Checks erforderlich sind, wie lange der Kanal stabil bleiben muss oder ob der Traffic sofort oder schrittweise zurückkehrt. Das sind Implementierungsentscheidungen.

Ein vorsichtiges Design kann den Traffic schrittweise zurückführen, wenn der Dienst schon öfter instabil war. Wichtig ist, unkontrolliertes Hin- und Herwechseln zwischen Kanälen zu verhindern und das Recovery-Ereignis sichtbar zu halten.

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 und keine Retry-Anzahl vor. Es bietet health-basierte Entfernung, die Protokollierung von Degradation-Ereignissen, automatisches Zurückschalten bei Recovery und operatives Audit.

Ein wiederholt ausfallender Kanal sollte daher als wiederkehrendes Zuverlässigkeitsproblem sichtbar werden, statt hinter endlosem automatischem Umschalten zu verschwinden. 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 soll die Zuverlässigkeit des Dienstes schützen, daher sollte sein Erfolg am Service-SLO gemessen werden. Die Source-SRE-Schicht umfasst SLO-Zielwerte, Error-Budgets, Burn-Rate-Alarme und die 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 Health-Statusänderungen, Kanalentfernung, alternatives Routing, Nutzungs-Metering, Alarmerzeugung, das Degradation-Ereignis, die Recovery-Erkennung und das Zurückschalten prüfen.

Eine Testfrequenz schreibt das Source-System nicht vor; sie sollte sich nach der Kritikalität des Dienstes und der Change-Richtlinie richten. Ob ein konfigurierter Fallback wirklich funktioniert, weiß man erst, wenn er erprobt wurde.

Was sollte die Gateway-Betriebsansicht zeigen?

Eine nützliche Ansicht zeigt den externen Endpunkt, den primären und die alternativen Kanäle mit ihrem Health-Status, Routing-Gewicht und Canary-Status. Dazu kommen der aktuelle Degradation-Zustand, das letzte Fallback-Ereignis, Erfolgsquote, Token-Durchsatz, Rate-Limit-Richtlinie, Tenant-Kontingent und 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.