Adatbázisok számlázása a valódi használat szerint

Minden Mythex-app, amelynek adatokat kell tárolnia, saját Postgres-adatbázist kap, a publikált app adatbázis-használata pedig ugyanabból a kreditegyenlegből fizetődik, mint az építés. Szeptember végéig ezt a használatot abból becsültük, hogy mennyi ideig futott az app szervere. A becslés olyan módon volt téves, ami számított, ezért lecseréltük: most minden adatbázist az általa mért számítási kapacitás alapján számlázunk, befejezett óránként, és minden óra csak egyszer számlázható.

Hogyan működnek az adatbázisok

Minden adatbázis szerver nélküli Postgres-en fut, amely nullára skálázódik: néhány tétlen perc után elalszik, és a következő lekérdezésre felébred. Ébren a számítási kapacitását a terheléshez igazítja. Ez teszi megfizethetővé az „adatbázis apponként” megoldást — a legtöbb app a legtöbb időben csendes, és egy alvó adatbázis szinte semmibe nem kerül.

Ezt az is jelenti, hogy az adatbázis költsége két dologtól függ, amelyet kívülről nem látunk: mennyi ideig volt ébren, és mekkora volt ébren.

Mit tévedett a becslés

Az eredeti mérőnk egy feltételezéssel élt: egy publikált app szervere minden futó órájára az adatbázis legkisebb számítási méretét számlázta.

Ez három módon volt téves:

1. A méret volt rossz. Az adatbázisok valójában nagyobb alapértelmezett méreten futottak, mint amit a becslés feltételezett.
2. Az adatbázisok automatikusan skálázódnak. Terhelés alatt nőnek, amit a becslés sosem látott.
3. Az adatbázisok nem az app szerverét követik. Az adatbázis mindig ébren marad, valahányszor bármi lekérdezi — az app, egy ütemezett feladat, egy szkript, amely lekérdezi —, függetlenül attól, fut-e az app szervere.

A végeredmény: a becslés a felhasználóknak nagyjából a tényleges adatbázisköltség felét számlázta. Ez nem fenntartható számunkra, és azt is jelentette, hogy az appban látható használati számok nem azt jelentették, amit az emberek gondoltak.

Mérés találgatás helyett

Az adatbázis-szolgáltatónk projektenként jelenti a számítási egység másodperceit óránként — vagyis azt, mennyi számítást használt ténylegesen, a méretet is beleértve. A mérő így működik most:

1. Minden olyan publikált appra, amelynek van adatbázisa, lekéri a mért használatot minden befejezett órára, amióta az app élő.
2. A használatot a szolgáltató árán költségre váltja, alkalmazza a csomag díjszabását, és ezt terheli az app tulajdonosának kreditjeiből.
3. Minden alkalommal legfeljebb egy napra visszanéz, így az API újraindulása alatt kihagyott órákat később is elszámolja.

A tárhelyet külön, méret alapján számlázzuk, mert az nem függ az aktivitástól.

Soha ne számlázz egy órát kétszer

Egy több szerveren futó és összeomolhatóan újrapróbálkozó számlázási mérőnek vigyáznia kell a duplázásra. Minden adatbázis minden óráját egy saját adatbázissorban foglaljuk le, mielőtt elszámolnánk, egyedi megkötéssel a (adatbázis, óra) párra. Ha két szerver vagy egy újrapróbálkozás ugyanazt az órát próbálja számlázni, csak az egyik foglalás sikerül.

A ritka hibaesetről tudatos döntést hoztunk: ha a folyamat összeomlik a foglalás és a számlázás között, az az óra foglalt és számlázatlan marad. Egy kis bevétel elvesztése egy ritka összeomlásnál jobb, mint valakit kétszer terhelni.

Amikor a mért számlázás bekapcsolt, az következő teljes órától indult. Az azelőtti órákat a régi becslés már elszámolta; ha azokat a mért adatok alapján újra számláztuk volna, az a szakasz kétszer lett volna terhelve.

Mit jelent ez, ha Mythexen építesz

• Az adatbázis-számlád most azt tükrözi, mit csinált az adatbázisod. Egy ritkán használt app nagyon keveset kerül; egy app, amely folyamatosan lekérdezi az adatbázisát, ébren tartja, és többe kerül.
• A legnagyobb tényező az, hogyan használja az app az adatbázist. Ha néhány másodpercenként lekérdezed az adatbázist, az egész nap ébren marad. Ha az AI igény szerint hozza le az adatokat, vagy gyorsítótárazza azokat, az adatbázis alhat. Az adatbázis fogalmáról szóló útmutatónk az alapokat tárgyalja.
• A Pro csomagok a hosting, az adatbázisok és a tárhely után a Free díj felét fizetik. A részletek a kredites dokumentációban vannak.

Amit ebből tanultunk

• A használatalapú költségek becslései elcsúsznak. Ha a szolgáltató meg tudja mondani, mi volt a használat, abból számlázz.
• Tedd a számlázást idempotenssé a legkisebb számlázott egységen. Nálunk ez egy adatbázis-óra.
• Ha muszáj hibáznod, a vevő javára hibázz.