Exploiter

Une plateforme d’API se choisit sur des fonctions et se juge sur son exploitation. La gateway est le seul composant que tous les appels traversent : ce qu’elle ne sait pas faire un dimanche à trois heures du matin décide de la valeur de tout le reste.

Cette page traite la gateway elle-même. La survie de la chaîne quand un backend se dégrade est un autre sujet, celui de la résilience.

Sa disponibilité est une propriété d’architecture

Une gateway à instance unique fait de la plateforme un point de panne unique, et c’est la configuration de départ de presque tous les projets. Le passage à une configuration tenable demande trois propriétés, dans cet ordre.

Plusieurs instances, réparties sur plusieurs zones. Deux instances dans la même zone protègent d’une panne de processus, pas d’une panne d’infrastructure. Le dimensionnement vise la perte d’une zone entière sans perte de capacité au trafic de pointe. Cela revient à porter en permanence une réserve qu’on paie sans l’utiliser.

La survie à la perte du control plane. Une gateway doit continuer à servir avec sa dernière configuration connue quand le control plane est arrêté. C’est la propriété que l’on éprouve en le coupant une journée, décrite dans le control plane, et elle est plus souvent absente qu’on ne le croit.

Le sort des dépendances sur le chemin. Le fournisseur d’identité et le magasin de compteurs sont appelés pendant le traitement. Décidez explicitement ce qui se passe quand ils ne répondent pas : servir en dégradé sur le dernier état connu, ou refuser. Les deux réponses se défendent, l’absence de réponse se paie en incident.

Ce que les instances partagent, et le piège du quota

C’est le défaut de configuration le plus répandu, et il est invisible en recette.

Une gateway répliquée sur cinq instances, dont chacune compte les appels dans sa propre mémoire, applique cinq fois le quota annoncé. Le consommateur limité à cent appels par minute en passe cinq cents, et personne ne le remarque tant que le backend tient. Le jour où il ne tient plus, le quota est accusé de ne pas avoir joué son rôle, alors qu’il a joué celui qu’on lui avait donné.

Trois éléments d’état se posent donc explicitement.

Le partage a un coût : un aller-retour vers un magasin partagé sur le chemin de l’appel, et un mode de panne de plus. La réponse courante est le compromis : compteur local pour la protection à la seconde, compteur partagé pour le quota contractuel à la journée. Le choix se fait consommateur par consommateur, jamais globalement.

Dimensionner, et la mesure qui ment

Une gateway se dimensionne par la mesure, et la mesure se rate presque toujours de la même façon : on éprouve une route vide, sans policy, avec des charges utiles minuscules. Le chiffre obtenu est celui du proxy, pas celui de la plateforme.

Une mesure utile respecte quatre conditions. La chaîne de policies réelle est activée, puisque c’est elle qui coûte. Les charges utiles ont la taille des vraies. La montée en charge dure assez longtemps pour déclencher les pauses du moteur d’exécution et les renouvellements de connexion, ce qu’un tir de deux minutes ne fait jamais. Et l’indicateur retenu est le centile 99 de la latence propre, pas le débit maximal : une gateway saturée répond encore, de plus en plus lentement.

Le réflexe qui économise des mois de soupçon est de mesurer le coût policy par policy, en environnement d’essai, avant de les empiler en production. Une demi-journée suffit, et le résultat sert ensuite à chaque discussion sur la latence.

Monter de version sans coupure

C’est l’opération qui reviendra plusieurs fois par an, et la question à poser à l’éditeur avant l’achat. Quatre points décident si elle se passe bien.

Le retrait progressif des instances. Une instance qu’on arrête doit cesser de recevoir de nouvelles requêtes, puis terminer celles qu’elle traite, avant de s’éteindre. Sans ce délai, chaque déploiement produit des erreurs chez les consommateurs, en petit nombre, ce qui les rend faciles à ignorer et impossibles à expliquer.

Les connexions longues. Un flux SSE, un WebSocket ou un flux gRPC ne se termine pas tout seul : il dure des heures. Le retrait progressif ne les draine pas, il attend. Décidez si vous les coupez, et dans ce cas le client doit savoir se reconnecter, ce qui se vérifie avant la première montée de version, pas pendant.

L’ordre entre control plane et data plane. Les deux ne montent pas ensemble, et la compatibilité entre versions voisines est une propriété du produit. La question exacte à poser : quelles versions du data plane un control plane donné sait piloter, et pendant combien de temps.

Le retour arrière. Il doit être possible sans restaurer une sauvegarde, donc sans migration irréversible du format de configuration. Une montée de version qui transforme la base de configuration sans chemin retour n’est pas une montée de version, c’est une migration.

Conduire un incident

Le diagnostic d’une plateforme d’API revient toujours à la même question : où le temps passe-t-il, ou qui refuse. Quatre suspects, dans l’ordre des fréquences.

1. Le backend. Le cas majoritaire, et le moins regardé, parce que la gateway offre un coupable plus commode.
2. Les connexions sortantes. La gateway attend une connexion disponible avant même d’envoyer la requête. Le backend affiche des temps normaux, le client mesure le double.
3. Le fournisseur d’identité. Cache de clés expiré, introspection synchrone, quota atteint. Symptôme typique : une latence en marches d’escalier.
4. Un seul consommateur. La moyenne monte parce qu’un appelant s’est mis à envoyer des requêtes pathologiques. La ventilation par consommateur le désigne en une requête.

Un seul artefact rend ce tri possible, et il se prépare avant l’incident : la décomposition du temps d’un appel en segments mesurés, réseau entrant, traitement de la gateway, attente de connexion, backend, retour. Si la plateforme sait donner ces cinq chiffres pour un appel donné, l’incident s’oriente en minutes. Sinon il se règle par accusation réciproque entre équipes, et c’est le signe que l’observabilité s’est arrêtée aux tableaux de bord de volumétrie.

Ce qui rend l’exploitation supportable

Trois choses, aucune n’est un produit.

Une astreinte à quatre personnes au moins, faute de quoi elle repose sur une ou deux et s’effondre au premier départ. Une configuration versionnée et publiée par une chaîne, puisque la modification en console sans historique se retrouve au point de départ de la plupart des incidents évitables, sujet entier d’industrialiser. Et un temps de traversée publié par l’équipe plateforme elle-même, en centiles, par API : c’est ce qui transforme la première minute d’un incident en diagnostic plutôt qu’en procès.