Coûts cloud d'une marketplace en croissance : les quatre postes qui comptent vraiment

Pendant des mois, notre facture Google Cloud a tourné autour de 1 900 € par mois sans que personne s'en émeuve. Et pour cause : un crédit promotionnel la réglait à notre place.

C'est par là qu'il faut commencer, parce que c'est le scénario le plus courant. Un crédit ne fait pas baisser la dépense, il la rend invisible. Le jour où il s'épuise, on découvre une structure de coûts que personne n'a vraiment décidée : elle s'est construite décision raisonnable après décision raisonnable, prise par des gens qui ne voyaient jamais la facture.

En juillet, nous l'avons donc reprise ligne par ligne. Nos deux clusters font tourner nos propres produits et les plateformes clientes que nous hébergeons, dont une marketplace de transport. Le profil est celui de n'importe quelle marketplace qui grandit : une base de production, une douzaine de services, une copie de recette pour la plupart d'entre eux, l'intégration continue et quelques services managés en plus. En trois mois, près de la moitié de la dépense brute a disparu, sans qu'aucune fonctionnalité ne change.

Presque chaque euro économisé venait de quatre postes. Les voici, avec les chiffres. Viennent ensuite ce qu'il faut mesurer avant de toucher à quoi que ce soit, et les coupes que nous avons choisi de ne pas faire.

---

Pourquoi la facture va plus vite que le chiffre d'affaires

Sur une marketplace, le chiffre d'affaires suit le volume de transactions. La facture, elle, suit les décisions.

Chaque nouveau service reçoit une réservation de CPU et de mémoire le jour de sa mise en ligne, en général large, parce qu'un plantage par manque de mémoire la première semaine fait mauvais effet. Chaque option proposée par la console est activée : un clic suffit, et ça a l'air sérieux. Chaque environnement est créé pour une bonne raison, valable sur le moment. Et rien de tout cela n'est jamais réexaminé, puisque rien n'y oblige. La plateforme fonctionne, et la facture arrive chez quelqu'un qui n'est pas dans l'équipe technique.

Résultat, la dépense fonctionne comme un cliquet : elle monte à chaque ajout et ne redescend jamais d'elle-même. Les quatre postes qui suivent sont les endroits où ce cliquet s'accroche.

Premier poste : une capacité dimensionnée pour un pic révolu

Notre base de production tournait sur 4 vCPU et 32 Go de mémoire. Sur sept jours, elle utilisait 2 à 3 % de son CPU, avec un maximum de 8 connexions simultanées. Nous l'avons ramenée à 2 vCPU et 16 Go, soit environ 180 € d'économie par mois.

Deux précautions ont fait de ce changement une décision plutôt qu'un pari. La vraie contrainte était la mémoire, autour de 12,8 Go, soit 80 % de la nouvelle taille : nous avons donc gardé l'offre qui ajoute un cache de données, et surveillé la mémoire après coup. Par ailleurs, redimensionner une base managée la redémarre. Le changement a attendu une fenêtre de maintenance au lieu de partir l'après-midi même.

Le même schéma se répète un cran plus bas, dans Kubernetes, en moins visible. Un cluster ne se dimensionne pas sur ce que les pods consomment, mais sur ce qu'ils réservent. Certains de nos services réservaient 500 millicœurs de CPU pour en utiliser 11. Pour l'ordonnanceur, nos nœuds de production étaient remplis aux deux tiers alors qu'ils ne faisaient presque rien, et l'autoscaler n'avait donc aucune raison d'en retirer un. En réduisant les réservations, et seulement elles, sans toucher aux limites, nous avons libéré environ 775 millicœurs en production sans le moindre risque de plantage.

Attention, le redimensionnement marche dans les deux sens. L'un de nos services réservait 512 Mi de mémoire alors que sa consommation médiane était de 697 Mi. Il dépassait donc en permanence sa propre réservation, ce qui en faisait le premier candidat à l'éviction dès que le nœud manquait de mémoire. Nous l'avons remonté au 95e centile. Il ne s'agit pas de réduire les chiffres, mais de les aligner sur la réalité.

Ce qu'il faut chercher : toute base ou tout groupe de nœuds dont le pic sur sept jours reste sous le quart de sa taille, et tout service dont la réservation vaut dix fois la consommation, ou moins que celle-ci.

Deuxième poste : des compteurs que personne ne lit

Les plus grosses surprises ne venaient pas des grosses machines, mais de services facturés à l'unité qui produisaient en silence des résultats que rien n'exploitait.

• L'analyse de vulnérabilités des images de conteneurs : environ 169 € par mois. Chaque image poussée était analysée. Binary Authorization, la fonction qui aurait pu agir sur ces résultats, n'avait jamais été activée, et personne ne les lisait. Nous avons coupé l'analyse.
• Les métriques Prometheus activées par défaut : environ 48 € par mois. Les deux clusters collectaient la panoplie complète (kube-state, cAdvisor, kubelet, GPU), parce que c'est le réglage par défaut. Chaque échantillon est facturé, et nos alertes lisaient de toute façon d'autres métriques.
• Un relecteur de code par IA : l'essentiel d'une ligne de 400 € par mois. À chaque push sur une pull request, il régénérait toutes ses suggestions. La relecture complète reste lancée à l'ouverture de la pull request, et la passe coûteuse se déclenche désormais à la demande. La profondeur de relecture n'a pas bougé.
• Le registre d'images : environ 75 € par mois, en deux passes. Chaque build d'intégration continue pousse une image, et aucune règle de rétention n'existait : certains dépôts dépassaient 100 Go. À la seconde passe, le registre en contenait environ 580. Nous gardons désormais les dix derniers builds pour pouvoir revenir en arrière, et le reste expire.

Sur une marketplace, il faut ajouter à cette liste le trafic sortant. Diffusion des images aux acheteurs, trafic entre zones de disponibilité, appels entre services situés dans des régions différentes : tout cela se paie au gigaoctet, et presque personne ne l'estime au moment de la conception. Chez nous, ce n'était pas une ligne majeure. Sur une plateforme chargée en photos, ça peut le devenir.

Ce qu'il faut chercher : exportez les données de facturation et triez-les par SKU plutôt que par service, car un service cache plusieurs compteurs. Les surprises se nichent dans la longue traîne, ces lignes de 30 à 200 € que personne n'aurait validées si on lui avait posé la question.

Troisième poste : une base qui fait le travail des autres

Deux tableaux de bord de reporting internes n'avaient plus aucun utilisateur. Nous avons vérifié : zéro session sur l'un comme sur l'autre. Leur synchronisation de schéma et leur journalisation de requêtes, en tâche de fond, représentaient pourtant environ 19 % des transactions de la base principale et 17 % de ses connexions.

Les retirer a fait économiser à peu près 3 € par mois en coût direct. Ce n'était pas le but. Le but, c'était une base plus calme avant de la redimensionner : si nous l'avions taillée sur sa charge observée, nous aurions acheté de la capacité pour un cinquième de travail qui ne servait personne.

Sur les marketplaces en croissance, le schéma est le même, avec d'autres occupants. Une recherche qui interroge directement la base principale. Des exports et du reporting lancés sur la production en fin de mois. Des files de tâches et des sessions installées dans Postgres parce qu'il était déjà là. Chacun fait paraître la base plus sollicitée que le produit ne l'exige, et la réponse habituelle consiste à monter en gamme, chaque mois, pour une charge qui aurait dû vivre ailleurs, à moindre coût.

Ce qu'il faut chercher : la répartition des transactions et des connexions par base et par client, pas seulement le CPU total de l'instance. La bonne question n'est pas « la base est-elle chargée ? » mais « chargée de quoi ? ».

Quatrième poste : des environnements jamais éteints

Passer le groupe de nœuds de recette sur des VM Spot a fait économiser environ 120 € par mois. Une capacité Spot peut être reprise avec un préavis très court, ce que la recette supporte et que la production ne supporte pas. Toute la décision tient presque dans cette distinction.

Deux constats plus modestes comptent davantage pour les habitudes que pour les euros. Un produit qui n'était plus en développement actif avait encore toute sa copie de recette déployée, et ses trois services étaient la seule chose qui maintenait un second nœud de recette en vie. Quant au registre, avant la règle de rétention évoquée plus haut, personne ne lui avait jamais demandé d'oublier quoi que ce soit.

Ce qu'il faut chercher : chaque environnement et chaque déploiement qu'il contient, avec la date de dernière utilisation. Sur une marketplace, l'équivalent typique, ce sont les environnements de prévisualisation créés à chaque pull request et jamais détruits.

Ce qu'il faut mesurer avant de toucher à quoi que ce soit

Chacune de ces coupes est partie d'une mesure, jamais d'une intuition. Quatre étapes nous ont permis de faire le reste sans risque.

1. Activer l'allocation des coûts par charge de travail. Sur GKE, c'est un réglage du cluster qui répartit la dépense par namespace et par charge dans l'export de facturation. Sans lui, un cluster n'est qu'une ligne opaque.
2. Exporter la facturation vers BigQuery. Les graphiques de la console répondent aux questions que la console a prévues. L'export permet de trier par SKU, et c'est comme ça que le deuxième poste est apparu.
3. Fixer un budget avec des alertes à 50, 90 et 100 % de la dépense du mois précédent, plus une à 90 % de la prévision. C'est cette dernière qui compte : elle se déclenche quand le mois peut encore être rattrapé, pas une fois qu'il est trop tard.
4. Relever sept jours de consommation réelle par service, CPU et mémoire, médiane et 95e centile. On dimensionne les réservations sur le 95e centile, pas sur la médiane, et surtout pas sur un commentaire laissé dans la configuration il y a deux ans. L'un des nôtres annonçait une moyenne de 430 millicœurs pour un service dont le vrai pic était de 12.

Une réserve sur les étiquettes : si vous comptez séparer recette et production grâce à une étiquette d'environnement, vérifiez ce qu'elle laisse passer. Chez nous, elle ne comptait pas toutes les VM que GKE gère lui-même. Un budget unique pour tout le projet s'est révélé plus honnête que deux budgets d'apparence précise.

Ce qu'il ne faut pas faire

Les coupes que nous avons refusées nous ont autant appris que les autres.

Ne supprimez rien que vous ne sauriez restaurer. Pour les deux tableaux de bord, nous avons retiré les déploiements mais conservé les bases et les secrets : annuler un seul commit suffit à tout remettre en place. La suppression des bases fera l'objet d'un changement séparé, après une sauvegarde vérifiée, parce qu'une base supprimée ne se récupère pas.

Ne descendez pas sous le seuil où les services plantent. Nous aurions pu ramener la recette à un seul nœud en comprimant deux services sous leurs réservations sûres. Or ces services avaient déjà planté à des valeurs plus basses, et c'était documenté. La recette reste donc sur deux nœuds. Un nœud d'économie ne vaut pas un environnement de recette qui tombe en pleine démonstration.

Ne passez pas la production en Spot pour l'aligner sur la recette. L'économie est réelle, mais le préavis de reprise est court. Si la production paie le tarif à la demande, c'est pour une bonne raison.

Ne mobilisez pas des semaines d'ingénierie pour gagner 20 € par mois. L'essentiel de nos coupes relevait de la configuration : une gamme, une réservation, une option, une règle de rétention. Les optimisations qui obligent à réécrire un service sont parfois justifiées, mais elles ont leur place dans une feuille de route, avec un coût d'ingénierie en face, pas dans une revue de coûts. Un changement qui coûte plus en salaires qu'il ne rapporte en un an n'est pas une économie.

---

La plupart des économies cloud n'ont rien de brillant. Il s'agit de dresser la liste de ce qui était juste un jour et n'a jamais été revu, puis de mettre un chiffre en face de chaque ligne.

Si la facture de votre plateforme progresse plus vite que son chiffre d'affaires, le coût cloud fait partie des chantiers de notre sprint d'audit technique et de préparation à la croissance : consommation mesurée, liste chiffrée des changements et ordre dans lequel les faire. Et si le vrai problème, c'est que personne d'expérimenté ne porte ces décisions au fil des mois, la question relève plutôt d'un CTO à temps partagé.

À lire aussi : Kubernetes, c'est quoi ? et trouver le bon équilibre coût-efficacité pour les LLM en production.