De la place pour tous ceux qui arrivent en même temps

Notre service web tourne sur Cloud Run. Deux réglages décident de ce qu’il peut servir à la fois : combien de requêtes un conteneur traite en parallèle, et combien de conteneurs peuvent tourner côte à côte. Leur produit donne le plafond du site entier. Le nôtre était de 4 fois 3 : douze requêtes au même instant.

Douze paraît généreux jusqu’à ce qu’on compte le coût d’une visite. Chaque page de notre site est rendue sur le serveur, et une page pleine de liens de navigation charge à l’avance plusieurs des pages derrière eux, pour qu’elles s’ouvrent instantanément au clic. Une seule page vue se démultiplie en 8 à 16 requêtes. Deux ou trois personnes qui ouvrent une page dans la même seconde peuvent épuiser toute la capacité, et une fois celle-ci pleine, la plateforme refuse aussitôt la requête suivante au lieu de la mettre en file.

Nous voulions qu’aucun visiteur ne rencontre jamais cette limite.

Nous avons changé trois chiffres, chacun pour une raison claire :

• la concurrence de 4 à 20 : le levier qui ne coûte rien, puisqu’il utilise les conteneurs déjà en marche
• le maximum de conteneurs de 3 à 10 : de quoi absorber un vrai pic
• le délai d’une requête d’une heure à deux minutes : rien sur la partie web n’a besoin de plus, puisque les rendus tournent dans des tâches séparées et que notre point d’accès MCP se limite à 60 secondes, et une requête bloquée ne doit jamais garder une place pendant une heure

Le plafond est passé de 12 requêtes simultanées à 200. Ce que l’on paie quand le site est calme, c’est le nombre minimal de conteneurs, et il n’a pas bougé. Plus de marge, le même coût au repos.

Ce genre de réglage cache un piège discret. Notre étape de mise en ligne les transmet à la plateforme à chaque déploiement : une valeur changée à la main sur le service en marche est remise à l’ancienne par la version suivante.

Les nouveaux chiffres vivent donc dans le processus de mise en ligne lui-même, à côté du code, relus comme le code et appliqués à chaque version. Un réglage de capacité que la mise en ligne ignore est un essai, pas une correction. Depuis ce jour, chaque version emporte avec elle la vraie capacité du site.

Augmenter le nombre de conteneurs change aussi autre chose : la charge sur la base de données. Chaque conteneur garde un petit groupe de connexions ouvertes à la base. La taille par défaut de ce groupe dépend de la machine : cinq par conteneur chez nous. Avec trois conteneurs, cela faisait 15. Avec dix, cela ferait 50, et notre base en accepte 25.

Nous avons donc fixé la taille du groupe au lieu de la laisser à une arithmétique que personne ne fait. Deux connexions par conteneur, fois dix conteneurs, font vingt, ce qui laisse de la place pour les tâches de rendu, la vérification du schéma que chaque conteneur fait au démarrage et une personne qui a besoin d’ouvrir une console sur la base. La limite est posée dans le code plutôt qu’inscrite dans la chaîne de connexion stockée, car l’identifiant et la taille du groupe sont deux choses différentes : l’un est un secret, l’autre une propriété du programme qui s’en sert. Une valeur de configuration peut toujours la remplacer.

Nous avons vérifié le résultat sur le vrai service en envoyant 40 requêtes exactement au même moment. Les 40 ont reçu une réponse, avec des pages en 180 à 340 millisecondes. C’est plus de trois fois l’ancien plafond d’un coup, avec de la marge.

Nous avons aussi noté ce que nous avons appris, à côté du code et dans nos notes de projet :

1. 1chaque chiffre de capacité est un produit : la concurrence fois les conteneurs donne le plafond du site, la taille du groupe fois les conteneurs donne la charge de la base
2. 2changez un facteur, puis recalculez chaque produit où il apparaît
3. 3sur un site où chaque page est rendue sur le serveur, le préchargement des liens multiplie le trafic, et quiconque ajoute un menu de liens doit savoir ce qu’il coûte

D’autres chapitres sur la plateforme derrière les films sont sur le blog.