Facturer les bases de données selon ce qu'elles utilisent réellement

Chaque application Mythex qui doit stocker des données reçoit sa propre base Postgres, et l'utilisation de la base d'une application publiée est prélevée sur le même solde de crédits que la construction. Jusqu'à fin septembre, nous estimions cette utilisation à partir de la durée de fonctionnement du serveur de l'application. L'estimation s'est révélée fausse d'une manière qui comptait, nous l'avons donc remplacée : chaque base est désormais facturée d'après le calcul que son fournisseur a réellement mesuré, une heure terminée à la fois, et chaque heure ne peut être facturée qu'une seule fois.

Comment fonctionnent les bases

Chaque base tourne sur un Postgres serverless qui se met à zéro : après quelques minutes d'inactivité, elle s'endort, et elle se réveille à la prochaine requête. Lorsqu'elle est éveillée, elle peut augmenter ou réduire sa puissance de calcul selon la charge. C'est ce qui rend « une base par application » abordable : la plupart des applications sont calmes la plupart du temps, et une base endormie coûte presque rien.

Cela signifie aussi que le coût d'une base dépend de deux choses que nous ne voyons pas de l'extérieur : combien de temps elle est restée éveillée et quelle était sa taille pendant ce temps.

Ce que l'estimation avait mal calculé

Notre compteur d'origine faisait une hypothèse : pour chaque heure où le serveur d'une application publiée tournait, il facturait une base à la plus petite taille de calcul.

C'était faux de trois façons :

1. La taille était fausse. Les bases tournaient en réalité à une taille par défaut plus grande que celle supposée par l'estimation.
2. Les bases se redimensionnent automatiquement. Sous charge, elles grossissent, et l'estimation ne le voyait jamais.
3. Les bases ne suivent pas le serveur de l'application. Une base reste éveillée dès que quoi que ce soit l'interroge — l'application, une tâche planifiée, un script qui la sonde — que le serveur de l'application soit en marche ou non.

En bilan, l'estimation facturait aux utilisateurs environ la moitié de ce que coûtaient réellement les bases. Ce n'est pas tenable pour nous, et cela signifiait aussi que les chiffres d'utilisation affichés dans l'application ne voulaient pas dire ce que les gens croyaient.

Mesurer au lieu de deviner

Notre fournisseur de bases indique pour chaque projet ses unités de calcul-seconde par heure — la quantité de calcul réellement utilisée, taille comprise. Le compteur fonctionne donc désormais ainsi :

1. Pour chaque application publiée disposant d'une base, récupérer l'usage mesuré de chaque heure terminée depuis la mise en ligne de l'application.
2. Convertir cet usage en coût au tarif du fournisseur, appliquer le tarif du forfait, et le débiter du solde de crédits du propriétaire de l'application.
3. Revenir en arrière jusqu'à un jour à chaque passage, pour que les heures manquées pendant un redémarrage de notre API soient quand même facturées plus tard.

Le stockage est facturé séparément, selon sa taille, car il ne dépend pas de l'activité.

Ne jamais facturer une heure deux fois

Un compteur de facturation qui tourne sur plusieurs serveurs — et qui peut planter puis réessayer — doit prendre soin de ne pas facturer deux fois. Chaque heure de chaque base est d'abord réservée dans sa propre ligne de base de données avant d'être facturée, avec une contrainte d'unicité sur le couple (base, heure). Si deux serveurs, ou une nouvelle tentative, essaient de facturer la même heure, une seule réservation réussit.

Nous avons aussi fait un choix délibéré pour le cas d'échec rare : si le processus plante entre la réservation d'une heure et sa facturation, cette heure reste réservée et non facturée. Perdre une petite part de revenus lors d'un plantage rare vaut mieux que de facturer quelqu'un deux fois.

Et lorsque la facturation mesurée a été activée, elle a commencé à partir de la prochaine heure complète. Les heures précédentes avaient déjà été facturées par l'ancienne estimation ; les refacturer à partir des données mesurées aurait fait payer deux fois cette tranche.

Ce que cela signifie si vous construisez sur Mythex

• Votre facture de base reflète désormais ce que votre base a fait. Une application peu utilisée coûte très peu ; une application qui interroge sa base en permanence la gardera éveillée et coûtera davantage.
• Le levier principal est la façon dont votre application utilise la base. Interroger la base toutes les quelques secondes la maintient éveillée en permanence. Demander à l'IA de récupérer les données à la demande, ou les mettre en cache, permet à la base de dormir. Notre guide sur ce qu'est une base de données couvre les bases.
• Les forfaits Pro paient la moitié du tarif Free pour l'hébergement, les bases et le stockage. Les détails figurent dans la documentation des crédits.

Ce que nous en retenons

• Les estimations de coûts liés à l'usage dérivent. Lorsque le fournisseur en amont peut vous dire ce qui a été utilisé, facturez à partir de cela.
• Rendez la facturation idempotente à la plus petite unité facturée. Pour nous, c'est une heure de base.
• Quand vous devez échouer, échouez au bénéfice du client.