Résumé

  • La RFC 10053 permet à CATS de choisir un point de contact visible du client à partir d’informations réseau et de calcul. Ce contact peut desservir une ou plusieurs instances internes ; le choix ne dit donc pas, à lui seul, laquelle a finalement traité la requête.
  • Les métriques d’un contact peuvent agréger plusieurs instances de service, et un agent de métriques peut aussi agréger plusieurs contacts. Le chemin retenu ou une moyenne rassurante décrit la surface de pilotage, pas l’exécution d’une requête ni la qualité du résultat rendu.

La porte d’entrée est visible ; le service reste derrière

Prenons une requête de transcription audio. Le client envoie un flux à un identifiant de service ; le système compare alors deux sites, dont l’un offre un trajet réseau plus court et l’autre davantage de capacité de calcul. Il choisit un contact de service joignable et y achemine la requête. Pour le client, ce contact est l’entrée du service. Il peut traiter la demande lui-même ou décider quelle instance interne l’exécutera.

La RFC 10053 distingue ces rôles précisément. Une instance de service est un ensemble de ressources en fonctionnement qui applique la logique du fournisseur. Un contact de service est une fonction tournée vers le client qui reçoit une requête et peut desservir une ou plusieurs instances. Il peut redistribuer le travail en aval, comme le ferait un répartiteur. La RFC précise que le pilotage au-delà de ce contact est caché aux clients comme aux composants CATS.

Cette définition borne ce que signifie « CATS a choisi le service ». Le sélecteur de chemin CATS, ou C-PS, exploite les informations des agents de métriques de service et de réseau pour choisir un routeur de sortie CATS, éventuellement un contact, ainsi qu’un chemin. Il choisit où la requête entre dans l’architecture du fournisseur. Cela n’identifie pas, en soi, l’instance interne qui réalise le traitement.

Une métrique a un périmètre, qui peut s’élargir

La RFC avertit explicitement que le choix peut ne pas révéler l’instance réellement appelée, notamment dans une architecture hiérarchique ou récursive. Les métriques du contact peuvent donc agréger plusieurs instances de service. La section 4.2 autorise également un agent de métriques de service à agréger les métriques de plusieurs contacts, à les conserver séparément, ou à faire les deux. Il s’agit de deux niveaux différents : l’un peut réunir les états de plusieurs instances derrière un contact ; l’autre peut réunir les états de plusieurs contacts avant de les transmettre au sélecteur.

Cela ne signifie pas qu’une agrégation rend la métrique fausse. Cela signifie que son périmètre doit être connu. Une moyenne au niveau du contact peut aider à choisir une entrée tout en disant peu de choses sur les requêtes les plus lentes, l’instance attribuée à une demande donnée ou le résultat obtenu. Une moyenne au niveau du site peut faciliter le passage à l’échelle sans devenir une mesure de chaque contact. La RFC laisse ces choix de déploiement au fournisseur et ne prescrit aucun algorithme de sélection unique.

Le classificateur CATS peut maintenir les paquets d’une requête sur le contact sélectionné. La section 4.4 décrit cette affinité : les paquets d’un flux restent attachés au même contact et au même chemin afin de limiter le réordonnancement et les variations imprévisibles de latence. C’est une propriété de transfert utile, mais elle ne rend pas visible le dispatch interne du contact. Le cadre ne définit pas de journal reliant chaque décision CATS à l’instance backend et au résultat de la requête.

Imaginons un contact qui répartit des segments audio entre plusieurs moteurs de reconnaissance vocale. Si la charge ralentit l’un d’eux, la métrique agrégée du contact peut encore sembler correcte. CATS peut continuer à choisir ce contact sans voir le déséquilibre ni savoir quelles requêtes l’ont subi. C’est une conséquence possible de la frontière de visibilité décrite par la RFC, pas un incident observé ni un résultat mesuré chez un opérateur.

Cette séparation est volontaire. La RFC 10053 indique que le fournisseur conserve la maîtrise de ses ressources internes et de sa logique de service ; l’organisation de son service reste hors du périmètre de CATS. Le cadre combine l’état du réseau et les capacités de calcul pour orienter le trafic, mais ne spécifie pas l’inspection de l’ordonnanceur backend du fournisseur. Le réseau ne devrait pas déduire plus que ce que montrent les signaux ; le fournisseur ne devrait pas présenter un contact choisi comme preuve du résultat d’une requête particulière.

La RFC 10054 élargit le problème CATS et ses exigences, mais la question traitée ici est plus ciblée : que sait-on après l’arrivée du trafic au contact retenu ? La réponse dépend des traces et métriques que le fournisseur choisit d’exposer en complément. Les RFC ne rendent obligatoire ni une API universelle de dispatch interne, ni une trace par requête, ni un reçu de résultat. Un déploiement peut ajouter ces contrôles ; il faut alors établir leur présence séparément.

Sans preuve supplémentaire, la chaîne s’arrête au contact

Pour l’exploitation, la distinction compte lorsqu’un changement de pilotage semble améliorer la latence alors que l’équipe applicative constate des résultats inégaux. La route et le contact retenu expliquent où les paquets ont été envoyés. Sans éléments côté fournisseur, ils ne disent pas quelle instance interne a traité la demande, si elle dépendait d’un composant dégradé, ni si sa réponse respectait l’objectif de service.

Un compte rendu précis peut dire : « CATS a choisi ce contact sur la base de ces métriques et de ce périmètre. » Affirmer « ce backend a correctement servi la requête » exige une preuve côté service. Affirmer « le service s’est amélioré » demande une mesure du résultat liée à la requête ou à la cohorte pertinente. Ce sont trois propositions distinctes, même si un système d’observabilité les rapproche ensuite.

La RFC 10053 est un cadre architectural limité au cas d’un fournisseur unique. Elle laisse ouverts l’algorithme exact de sélection et le fonctionnement interne du service. Elle décrit donc la frontière du pilotage, sans promettre qu’un contact choisi dévoile toutes les décisions prises en aval.

Sources et statut