Datenbanken nach tatsächlicher Nutzung abrechnen

Jede Mythex-App, die Daten speichern muss, bekommt ihre eigene Postgres-Datenbank, und der Datenbankverbrauch einer veröffentlichten App wird aus demselben Credit-Guthaben bezahlt wie das Bauen. Bis Ende September haben wir diesen Verbrauch aus der Laufzeit des Servers der App geschätzt. Die Schätzung erwies sich in einer Weise als falsch, die ins Gewicht fiel, also haben wir sie ersetzt: Jede Datenbank wird jetzt aus der Rechenleistung abgerechnet, die ihr Anbieter tatsächlich gemessen hat, eine abgeschlossene Stunde nach der anderen, und jede Stunde kann nur einmal berechnet werden.

So funktionieren die Datenbanken

Jede Datenbank läuft auf serverlosem Postgres, das auf null skaliert: Nach wenigen Minuten Leerlauf schläft sie ein und wacht bei der nächsten Abfrage wieder auf. Im wachen Zustand kann sie ihre Rechenleistung je nach Last hoch- und herunterskalieren. Das macht „eine Datenbank pro App“ bezahlbar, denn die meisten Apps sind die meiste Zeit ruhig, und eine schlafende Datenbank kostet praktisch nichts.

Daraus folgt aber auch, dass die Kosten einer Datenbank von zwei Dingen abhängen, die sich von außen nicht sehen lassen: wie lange sie wach war und wie groß sie dabei war.

Was an der Schätzung falsch war

Unser ursprünglicher Zähler traf eine Annahme: Für jede Stunde, in der der Server einer veröffentlichten App lief, wurde eine Datenbank in der kleinsten Rechenstufe berechnet.

Das war in drei Punkten falsch:

1. Die Größe stimmte nicht. Die Datenbanken liefen tatsächlich in einer größeren Standardstufe, als die Schätzung annahm.
2. Datenbanken skalieren automatisch. Unter Last wachsen sie, und die Schätzung bekam das nie mit.
3. Datenbanken folgen nicht dem App-Server. Eine Datenbank bleibt wach, sobald irgendetwas sie abfragt, die App, ein geplanter Job oder ein Skript, das sie abfragt, egal ob der Server der App läuft oder nicht.

Unter dem Strich berechnete die Schätzung den Nutzern grob die Hälfte dessen, was die Datenbanken tatsächlich kosteten. Das ist für uns nicht tragbar, und außerdem bedeuteten die Nutzungszahlen in der App nicht das, was Menschen darin vermuteten.

Messen statt raten

Unser Datenbankanbieter meldet für jedes Projekt die Recheneinheiten-Sekunden pro Stunde, also wie viel Rechenleistung tatsächlich verbraucht wurde, einschließlich Größe. Der Zähler arbeitet jetzt so:

1. Für jede veröffentlichte App mit Datenbank holen wir den gemessenen Verbrauch für jede abgeschlossene Stunde seit dem Livegang der App.
2. Wir rechnen den Verbrauch zum Preis des Anbieters in Kosten um, wenden den Satz des Tarifs an und buchen ihn von den Credits des App-Besitzers ab.
3. Bei jedem Lauf schauen wir bis zu einen Tag zurück, damit Stunden, die verpasst wurden, während unsere API neu gestartet wurde, später trotzdem abgerechnet werden.

Der Speicher wird separat nach Größe abgerechnet, weil er nicht von der Aktivität abhängt.

Nie eine Stunde zweimal berechnen

Ein Abrechnungszähler, der auf mehr als einem Server läuft und abstürzen und erneut versuchen kann, muss aufpassen, nichts doppelt zu berechnen. Jede Stunde jeder Datenbank wird in ihrer eigenen Datenbankzeile beansprucht, bevor sie berechnet wird, mit einer Eindeutigkeitsbedingung auf dem Paar (Datenbank, Stunde). Versuchen zwei Server oder ein Wiederholungsversuch dieselbe Stunde abzurechnen, gelingt nur einer der Ansprüche.

Für den seltenen Fehlerfall haben wir uns bewusst entschieden: Stürzt der Prozess zwischen dem Beanspruchen einer Stunde und ihrer Berechnung ab, bleibt diese Stunde beansprucht und unberechnet. Ein wenig Umsatz in einem seltenen Absturz zu verlieren ist besser, als jemanden doppelt zu belasten.

Und als die gemessene Abrechnung eingeschaltet wurde, begann sie mit der nächsten vollen Stunde. Die Stunden davor waren schon mit der alten Schätzung berechnet worden. Sie mit gemessenen Daten erneut abzurechnen hätte dieses Stück doppelt berechnet.

Was das für dich bedeutet, wenn du auf Mythex baust

• Deine Datenbankrechnung spiegelt wider, was deine Datenbank getan hat. Eine selten genutzte App kostet sehr wenig, eine App, die ihre Datenbank ständig abfragt, hält sie wach und kostet mehr.
• Der größte Hebel ist, wie deine App die Datenbank nutzt. Die Datenbank alle paar Sekunden abzufragen hält sie rund um die Uhr wach. Die KI Daten bei Bedarf abrufen zu lassen oder sie zwischenzuspeichern, lässt die Datenbank schlafen. Unser Leitfaden was eine Datenbank ist erklärt die Grundlagen.
• Pro-Tarife zahlen für Hosting, Datenbanken und Speicher die Hälfte des Free-Satzes. Die Details stehen in den Credit-Dokumenten.

Was wir daraus gelernt haben

• Schätzungen nutzungsabhängiger Kosten driften. Wenn der vorgelagerte Anbieter dir sagen kann, was verbraucht wurde, rechne aus diesen Daten ab.
• Mach die Abrechnung idempotent auf der kleinsten Einheit, die du berechnest. Bei uns ist das eine Datenbankstunde.
• Wenn du scheitern musst, scheitere zugunsten des Kunden.