Facturer les bases de données selon leur utilisation réelle

Chaque application Mythex qui doit stocker des données obtient sa propre base de données 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 création. Jusqu'à la fin de 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 façon qui comptait, alors nous l'avons remplacée : chaque base de données est maintenant facturée selon le calcul mesuré par son fournisseur, une heure terminée à la fois, et chaque heure ne peut être facturée qu'une seule fois.

Comment fonctionnent les bases de données

Chaque base de données tourne sur Postgres sans serveur, qui se met à l'échelle à zéro : après quelques minutes d'inactivité, elle s'endort, puis elle se réveille à la prochaine requête. Lorsqu'elle est éveillée, elle peut augmenter ou réduire son calcul selon la charge. C'est ce qui rend « une base de données 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 son éveil.

Ce que l'estimation avait mal calculé

Notre compteur d'origine faisait une hypothèse : pour chaque heure pendant laquelle le serveur d'une application publiée tournait, facturer une base de données à 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 mettent à l'échelle 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 quelque chose l'interroge, l'application, une tâche planifiée, un script qui la consulte en boucle, que le serveur de l'application soit en marche ou non.

Effet net : l'estimation facturait aux utilisateurs environ la moitié de ce que coûtaient réellement les bases. Ce n'est pas soutenable pour nous, et cela faisait aussi que les chiffres d'utilisation dans l'application ne voulaient pas dire ce que les gens croyaient.

Mesurer plutôt que deviner

Notre fournisseur de bases de données rapporte, pour chaque projet, les secondes-unités de calcul par heure, c'est-à-dire la quantité de calcul réellement utilisée, taille comprise. Le compteur fonctionne donc maintenant ainsi :

1. Pour chaque application publiée qui a une base de données, récupérer l'utilisation mesurée pour chaque heure terminée depuis la mise en ligne de l'application.
2. Convertir cette utilisation en coût au prix du fournisseur, appliquer le tarif du forfait, et la facturer aux crédits du propriétaire de l'application.
3. Revenir jusqu'à une journée en arrière à chaque exécution, afin 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, parce qu'il ne dépend pas de l'activité.

Ne jamais facturer une heure deux fois

Un compteur de facturation qui s'exécute sur plusieurs serveurs, et qui peut planter puis réessayer, doit prendre soin de ne pas facturer deux fois. Chaque heure de chaque base de données est 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 de données, heure). Si deux serveurs, ou un nouvel essai, tentent 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 partie des revenus lors d'un plantage rare vaut mieux que facturer quelqu'un deux fois.

Et lorsque la facturation mesurée a été activée, elle a commencé à la prochaine heure complète. Les heures précédentes avaient déjà été facturées par l'ancienne estimation; les facturer de nouveau à 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 de données reflète maintenant ce que votre base a fait. Une application rarement utilisée coûte très peu; une application qui interroge sa base en permanence la garde éveillée et coûte davantage.
• Le levier principal est la façon dont votre application utilise la base. Interroger la base toutes les quelques secondes la garde é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 gratuit pour l'hébergement, les bases de données et le stockage. Les détails figurent dans la documentation sur les crédits.

Ce que nous en retenons

• Les estimations de coûts liés à l'utilisation dérivent. Lorsque le fournisseur en amont peut 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 de données.
• Lorsque vous devez échouer, échouez en faveur du client.