Failover en service gateway para servicios de inferencia no saludables

Un gateway de servicios puede conmutar el tráfico automáticamente monitorizando el estado de salud de cada canal interno de servicio de modelos, retirando del enrutamiento cualquier canal no saludable, enviando las peticiones a una ruta de fallback aprobada, registrando el evento de degradación y restableciendo el tráfico tras la recuperación. El diseño del gateway v3.2 de la fuente admite con exactitud este patrón operativo.

La principal ventaja arquitectónica reside en que los clientes continúan utilizando un único endpoint externo. El enrutamiento y la recuperación basados en la salud del servicio ocurren detrás de ese endpoint, por lo que la aplicación no necesita redesplegarse cada vez que cambia una instancia de inferencia o un canal de modelo.

¿Qué es un canal de servicio de modelos?

Un canal de servicio de modelos es una ruta de servicio interna hacia la cual el gateway unificado puede dirigir el tráfico. El diseño del gateway de la fuente expone una interfaz hacia el exterior y múltiples canales a nivel interno. Un canal puede representar un servicio de modelo aprobado o una ruta de inferencia, y el gateway administra si dicho canal es apto para recibir tráfico.

Esto sitúa al gateway como el punto de separación entre las aplicaciones cliente y las instancias en tiempo de ejecución. El cliente necesita un contrato de servicio estable, mientras que el gateway absorbe los cambios en el suministro interno.

¿Cómo sabe el gateway que un canal no está en buen estado?

La capa de instancias de modelos de la fuente realiza un seguimiento de los resultados de comprobación de salud y del estado de ejecución, permitiendo clasificar las instancias como Running, Degraded o Stopped. La capa de servicio también registra indicadores de éxito y de calidad.

La fuente no impone un algoritmo universal de comprobación de salud, por lo que cada despliegue puede emplear las señales adecuadas para su entorno de servicio. Lo esencial es que ese resultado sirva como parámetro de enrutamiento: un canal que la política de salud aprobada considere no saludable debe quedar excluido del nuevo tráfico de forma automática.

¿Qué implica la retirada automática?

La retirada automática significa que el gateway deja de seleccionar el canal no saludable para procesar nuevas solicitudes. La fuente describe esto como una retirada automática del canal, una medida mucho más segura que continuar enviando peticiones de producción a una ruta con fallos confirmados.

El canal no saludable puede seguir visible en la interfaz de operaciones mientras deja de recibir tráfico habitual. La exclusión del enrutamiento no equivale a eliminar el modelo ni a interrumpir el diagnóstico, ya que los operadores aún necesitan el historial de eventos y el estado de salud del canal para comprender lo sucedido.

¿Qué ocurre con el tráfico tras retirar el canal?

El tráfico sigue la política de enrutamiento o degradación configurada. El gateway de la fuente admite múltiples canales internos, enrutamiento ponderado, enrutamiento por capacidades, fallback y degradación.

Si existe otro canal aprobado y en buen estado capaz de asumir el servicio, el gateway puede dirigir las peticiones allí. Si el servicio carece de una alternativa aceptable, la política de degradación debe definir una respuesta predecible. La fuente no sostiene que todo servicio cuente siempre con un modelo secundario, y configurar un fallback solo para mantener un indicador de disponibilidad en verde constituye un error. La ruta alternativa debe cumplir con el contrato de servicio acordado.

¿Cuál es la diferencia entre failover y degradación?

El failover suele significar que el tráfico se traslada a otra ruta capaz de mantener el servicio con normalidad. La degradación implica que el servicio opera en un modo reducido o alternativo bajo una política aprobada, y la fuente emplea el término degradación para describir el comportamiento de fallback del gateway.

En la práctica, un canal alternativo y en buen estado puede actuar como failover, mientras que un canal aprobado con capacidades inferiores ofrece un servicio degradado. Cada organización debe fijar estas definiciones. El comportamiento que la fuente respalda es que el gateway centralice la decisión y deje constancia del evento.

¿Por qué debe configurarse el fallback antes de un incidente?

El equipo del servicio debe decidir qué resulta aceptable mientras el sistema funciona correctamente. El peor momento para descubrir si el Modelo B puede sustituir al Modelo A es en plena caída del servicio.

Una política de fallback debe identificar el canal primario, el canal alternativo aprobado, las condiciones de enrutamiento, las limitaciones del servicio, el comportamiento de recuperación y el responsable. La fuente contempla el fallback y el enrutamiento por capacidades del modelo, pero no define una regla universal de compatibilidad, por lo que el responsable del servicio debe aprobar la alternativa.

¿Cómo ayuda el enrutamiento ponderado al failover?

El enrutamiento ponderado brinda al gateway una forma controlada de distribuir el tráfico entre canales en buen estado. Antes de un incidente, es posible que varios canales ya procesen tráfico simultáneamente. Si uno de ellos falla, su peso se excluye del enrutamiento y los canales restantes asumen el tráfico admisible de acuerdo con la política establecida.

El enrutamiento ponderado también ayuda a validar una nueva ruta de fallback antes de depender de ella por completo. La fuente permite separar el tráfico canary y el enrutamiento ponderado, lo que hace posible enviar una pequeña proporción de tráfico al canal alternativo antes de designarlo como vía de recuperación definitiva.

¿Cómo mejora el despliegue canary la preparación para el failover?

Un fallback resulta más seguro cuando ya ha demostrado su eficacia con tráfico real controlado. El gateway de la fuente puede liberar tráfico de manera independiente hacia un canal canary, lo que permite al equipo evaluar salud, tasa de éxito, latencia, rendimiento de tokens y errores antes de depender de dicho canal en una contingencia. Esto resulta especialmente valioso para nuevas versiones de modelos y nuevos despliegues de inferencia.

Para profundizar en este concepto de control de cambios, el artículo sobre qué es el despliegue canary en operaciones de infraestructura y cómo reduce el riesgo operativo explica cómo una exposición inicial limitada mitiga los riesgos.

¿Qué evento debe registrarse cuando se produce un fallback?

La fuente establece explícitamente que las acciones de degradación se registran como eventos. Un evento útil identifica el servicio afectado, el canal no saludable, la marca temporal, el canal de fallback o estado de degradación, la acción de enrutamiento, el tiempo de recuperación y el resultado del restablecimiento.

La fuente no publica un esquema de eventos exhaustivo, pero el requisito operativo exige que la transición sea auditable. Un operador que investigue una variación en la latencia debe poder verificar que el servicio cambió de canal en ese momento exacto, ya que, sin ese registro, el failover puede provocar cambios de comportamiento difíciles de detectar.

¿Cómo debe comportarse la medición de tokens durante el failover?

La medición de tokens debe continuar en el gateway unificado utilizando las mismas reglas de atribución por proyecto, tenant y modelo. El gateway de la fuente y el modelo operativo de tokens comparten el mismo límite de servicio, de modo que un cambio de tráfico no genera vacíos en la contabilidad del consumo.

El registro de uso debe seguir identificando el proyecto, tenant, modelo, servicio, volumen de tokens y resultado de la invocación. Si el fallback recurre a un modelo diferente, el registro debe preservar la identidad de ese modelo concreto, lo que ayuda a justificar variaciones posteriores de coste o rendimiento.

En cuanto a la gobernanza del gateway, el artículo sobre cómo pueden las organizaciones gestionar claves API, límites de tasa, cuotas, enrutamiento y fallback para servicios de modelos de IA detalla cómo el enrutamiento y la medición se mantienen enlazados.

¿Cómo deben comportarse los límites de tasa durante el failover?

La política de límites de tasa y cuotas debe seguir siendo predecible cuando el servicio conmuta a un fallback. La fuente centraliza la limitación de tasa y las cuotas por tenant en el gateway, lo que supone una gran ventaja al no ligar la política a una única instancia de backend.

Si la ruta de fallback dispone de menor capacidad, la organización puede definir una política de degradación más restrictiva. La fuente no especifica un algoritmo de ajuste automático de límites de tasa, por lo que cualquier comportamiento de este tipo debe configurarse de forma explícita. El gateway nunca debe modificar de forma opaca el límite contractual u operativo de un tenant sin una regla previamente establecida.

¿Cómo debe el gateway restablecer el tráfico?

El gateway de la fuente conmuta automáticamente el tráfico de vuelta tras la recuperación, lo que exige que el canal no saludable regrese a un estado operativo normal bajo la política de comprobaciones desplegada. La fuente no estipula cuántas comprobaciones exitosas se requieren, cuánto tiempo debe permanecer estable el canal ni si el tráfico vuelve de forma instantánea o gradual. Esas son decisiones de implementación.

Un diseño prudente puede devolver el tráfico de forma progresiva cuando el servicio presenta un historial de inestabilidad. El propósito es evitar oscilaciones descontroladas entre canales, asegurando que el evento de recuperación permanezca debidamente registrado.

¿Qué sucede si el canal recuperado vuelve a fallar de inmediato?

El gateway debe aplicar nuevamente la misma política de salud y fallback mientras el equipo de operaciones investiga el canal inestable. La fuente no impone un algoritmo de circuit breaker ni un límite de reintentos. Lo que sí proporciona es exclusión basada en salud, registro de eventos de degradación, conmutación automática tras la recuperación y auditoría operativa.

Un canal que falla de forma reiterada debe hacerse visible como un problema recurrente de fiabilidad, en lugar de ocultarse tras continuas conmutaciones automáticas. La capa de SRE debe registrar el impacto sobre la calidad del servicio y el consumo del presupuesto de errores.

¿Cómo se relaciona esto con los SLO?

El failover existe para proteger la fiabilidad del servicio, por lo que su éxito debe medirse contra el SLO correspondiente. La capa de SRE de la fuente incluye objetivos de SLO, presupuestos de error, alertas de consumo acelerado y estabilidad del servicio de tokens.

Un cambio en el gateway que mantenga el servicio dentro de su SLO constituye una acción de resiliencia exitosa. Una conmutación que mantenga el endpoint técnicamente en línea pero provoque latencia prolongada o caídas en la tasa de éxito puede seguir agotando el presupuesto de errores.

Para profundizar en este marco de decisiones de fiabilidad, el artículo sobre cómo pueden las organizaciones usar presupuestos de error para decidir cuándo continuar con los lanzamientos y cuándo priorizar la fiabilidad aborda cómo la degradación del servicio incide en la política de despliegues.

¿Cómo deben los operadores probar el failover?

Conviene probar la ruta antes de que ocurra una falla real en producción, siempre que la política y el entorno lo permitan. Una prueba controlada permite verificar los cambios de estado de salud, la retirada del canal, el enrutamiento alternativo, la medición de consumo, la generación de alarmas, el evento de degradación, la detección de la recuperación y el restablecimiento del tráfico.

La fuente no establece una frecuencia fija para estas pruebas, la cual debe determinarse según la criticidad del servicio y la política de cambios. Un fallback configurado solo se convierte en una solución contrastada cuando ha sido probado en la práctica.

¿Qué debe mostrar la vista de operaciones del gateway?

Una vista útil puede incluir el endpoint externo, los canales primarios y alternativos, el estado de salud de cada canal, los pesos de enrutamiento, el estado canary, el estado actual de degradación, el evento de fallback más reciente, la tasa de éxito, el rendimiento de tokens, la política de límites de tasa, las cuotas por tenant y el estado de recuperación. Las páginas de gateway e instancias de modelos de la versión 3.2 de la fuente respaldan esta vista operativa.

Un ejemplo de plataforma que utiliza enrutamiento unificado de servicios con degradación basada en la salud es Sensaka.

Si estuviera gestionando un gateway de modelos en producción, pondría a prueba una sola pregunta para cada servicio: si el canal preferido desaparece en este instante, ¿a dónde irá exactamente la siguiente petición, qué comportamiento del servicio cambiará y cómo sabré cuándo el canal primario vuelve a ser seguro? Si esas respuestas no están definidas antes del incidente, el fallback es solo un diagrama en un papel.