Fakturering af databaser efter hvad de faktisk bruger

Hver Mythex-app, der har brug for at gemme data, får sin egen Postgres-database, og en publiceret apps databaseforbrug kommer fra den samme creditsaldo som byggeriet. Indtil slutningen af september estimerede vi det forbrug ud fra, hvor længe appens server kørte. Estimatet viste sig at være forkert på en måde, der betød noget, så vi erstattede det: hver database faktureres nu ud fra den beregningskraft, dens udbyder faktisk målte, én afsluttet time ad gangen, og hver time kan kun nogensinde opkræves én gang.

Sådan fungerer databaserne

Hver database kører på serverless Postgres, der skaleres til nul: efter nogle få minutters inaktivitet sover den, og den vågner ved næste forespørgsel. Mens den er vågen, kan den skalere sin beregningskraft op og ned efter belastning. Det er det, der gør »en database pr. app« overkommelig — de fleste apps er stille det meste af tiden, og en sovende database koster næsten intet.

Det betyder også, at omkostningen for en database afhænger af to ting, vi ikke kan se udefra: hvor længe den var vågen og hvor stor den var, mens den var vågen.

Hvad estimatet tog fejl af

Vores oprindelige måler lavede en antagelse: for hver time en publiceret apps server kørte, opkræv en database i den mindste beregningsstørrelse.

Det var forkert på tre måder:

1. Størrelsen var forkert. Databaserne kørte faktisk på en større standardstørrelse, end estimatet antog.
2. Databaserne skalerer automatisk. Under belastning vokser de, og estimatet så det aldrig.
3. Databaserne følger ikke appserveren. En database forbliver vågen, når noget som helst forespørger den — appen, et planlagt job, et script der poller den — uanset om appens server var oppe.

Nettoeffekten: estimatet opkrævede brugerne cirka halvdelen af, hvad databaserne faktisk kostede. Det er ikke bæredygtigt for os, og det betød også, at forbrugstal i appen ikke betød det, folk troede.

Måling i stedet for gætteri

Vores databaseudbyder rapporterer hvert projekts compute-unit-sekunder pr. time — hvor meget beregning det faktisk brugte, størrelse inklusive. Så målingen fungerer nu sådan her:

1. For hver publiceret app med en database hentes det målte forbrug for hver afsluttet time siden appen gik live.
2. Forbruget omregnes til omkostning til udbyderens pris, planens sats anvendes, og det opkræves fra app-ejerens credits.
3. Den ser op til et døgn tilbage hver gang, så timer, der blev misset, mens vores API genstartede, stadig faktureres senere.

Lagring faktureres separat, efter størrelse, fordi den ikke afhænger af aktivitet.

Aldrig at opkræve en time to gange

En faktureringsmåler, der kører på mere end én server — og kan gå ned og forsøge igen — skal være forsigtig med ikke at opkræve dobbelt. Hver time for hver database claimes i sin egen databaserække, før den opkræves, med en unikhedsbegrænsning på parret (database, time). Hvis to servere, eller et nyt forsøg, prøver at fakturere den samme time, lykkes kun ét claim.

Vi har også truffet et bevidst valg for den sjældne fejlsituation: hvis processen går ned mellem at claime en time og opkræve den, forbliver timen claimet og uopkrævet. At tabe en lille smule omsætning ved et sjældent nedbrud er bedre end nogensinde at opkræve nogen to gange.

Og da målt fakturering blev slået til, startede den fra den næste hele time. De timer før havde allerede været opkrævet af det gamle estimat; at opkræve dem igen ud fra målte data ville have opkrævet det stykke to gange.

Hvad det betyder, hvis du bygger på Mythex

• Din databaseregning afspejler, hvad din database gjorde. En app, der sjældent bruges, koster meget lidt; en app, der konstant forespørger sin database, holder den vågen og koster mere.
• Det største håndtag er, hvordan din app bruger databasen. At poll'e databasen hvert par sekund holder den vågen hele døgnet. At bede AI'en hente data efter behov, eller cache dem, lader databasen sove. Vores guide til hvad en database er dækker det grundlæggende.
• Pro-planer betaler halvdelen af Free-satsen for hosting, databaser og lager. Detaljerne står i credits-dokumentationen.

Det vi lærte

• Estimater af forbrugsbaserede omkostninger driver væk fra virkeligheden. Når den upstream-udbyder kan fortælle dig, hvad der blev brugt, så fakturér ud fra det.
• Gør fakturering idempotent på den mindste enhed, du opkræver. For os er det én database-time.
• Når du må fejle, så fejl til kundens fordel.