Baze de date facturate după ce folosesc cu adevărat

Fiecare aplicație Mythex care trebuie să stocheze date primește propria bază de date Postgres, iar consumul unei aplicații publicate se scade din același sold de credite ca și construirea. Până la sfârșitul lui septembrie estimam acest consum după cât timp a rulat serverul aplicației. Estimarea s-a dovedit greșită într-un mod care conta, așa că am înlocuit-o: fiecare bază de date este acum facturată după compute-ul măsurat efectiv de furnizorul ei, o oră terminată pe rând, iar fiecare oră poate fi taxată o singură dată.

Cum funcționează bazele de date

Fiecare bază de date rulează pe Postgres serverless care se scalează la zero: după câteva minute de inactivitate adoarme și se trezește la următoarea interogare. Cât timp este trează, își poate ajusta compute-ul în sus și în jos, în funcție de încărcare. Asta face ca „o bază de date per aplicație” să fie accesibilă — majoritatea aplicațiilor sunt liniștite cea mai mare parte a timpului, iar o bază de date adormită costă aproape nimic.

Înseamnă și că prețul unei baze de date depinde de două lucruri pe care nu le vedem din exterior: cât timp a fost trează și cât de mare a fost cât timp a fost trează.

Ce greșea estimarea

Modelul nostru inițial făcea o presupunere: pentru fiecare oră în care serverul unei aplicații publicate rula, se factura o bază de date la cea mai mică dimensiune de compute.

Asta era greșit în trei feluri:

1. Dimensiunea era greșită. Bazele de date rulau de fapt la o dimensiune implicită mai mare decât presupunea estimarea.
2. Bazele de date se autoscalează. Sub sarcină cresc, iar estimarea nu le vedea niciodată creșterea.
3. Bazele de date nu urmează serverul aplicației. O bază de date rămâne trează ori de câte ori ceva o interoghează — aplicația, un job programat, un script care o tot verifică — indiferent dacă serverul aplicației era pornit.

Efectul net: estimarea făcea să se factureze utilizatorilor cam jumătate din ce costau de fapt bazele de date. Asta nu este sustenabil pentru noi și făcea ca cifrele de utilizare din aplicație să nu însemne ce credeau oamenii că înseamnă.

Măsurăm în loc să ghicim

Furnizorul nostru de baze de date raportează pentru fiecare proiect secundele-unitate de compute pe oră — cât compute a folosit efectiv, dimensiunea inclusă. Așa funcționează acum măsurătoarea:

1. Pentru fiecare aplicație publicată cu o bază de date, aducem consumul măsurat pentru fiecare oră terminată de când aplicația a fost lansată.
2. Transformăm consumul în cost la prețul furnizorului, aplicăm tariful planului și îl trecem pe creditele proprietarului aplicației.
3. Privim înapoi până la o zi de fiecare dată, astfel încât orele ratate cât timp API-ul nostru era repornit să fie facturate ulterior.

Stocarea se facturează separat, după dimensiune, pentru că nu depinde de activitate.

Să nu facturăm niciodată o oră de două ori

Un contor de facturare care rulează pe mai multe servere — și care poate cădea și reîncerca — trebuie să fie atent să nu factureze dublu. Fiecare oră din fiecare bază de date este revendicată în propriul rând din baza de date înainte de a fi facturată, cu o constrângere de unicitate pe perechea (bază de date, oră). Dacă două servere, sau o reîncercare, încearcă să factureze aceeași oră, doar o revendicare reușește.

Am luat și o decizie deliberată pentru cazul rar de eșec: dacă procesul se oprește între revendicarea unei ore și facturarea ei, ora rămâne revendicată și nefacturată. Pierderea unei fracțiuni de venit într-un crash rar este mai bună decât a factura pe cineva de două ori.

Și când facturarea pe baza măsurătorilor a fost pornită, a început de la următoarea oră întreagă. Orele dinainte fuseseră deja facturate de vechea estimare; a le factura din nou pe baza datelor măsurate ar fi taxat acel interval de două ori.

Ce înseamnă asta dacă construiești pe Mythex

• Factura ta pentru baza de date reflectă ce a făcut baza ta de date. O aplicație rar folosită costă foarte puțin; o aplicație care interoghează constant baza de date o ține trează și costă mai mult.
• Cea mai mare pârghie este felul în care aplicația ta folosește baza de date. Interogarea bazei de date la fiecare câteva secunde o ține trează non-stop. Cererea AI-ului să aducă datele la cerere, sau să le pună în cache, lasă baza de date să adoarmă. Ghidul nostru despre ce este o bază de date explică noțiunile de bază.
• Planurile Pro plătesc jumătate din tariful Free pentru hosting, baze de date și stocare. Detaliile sunt în documentația despre credite.

Ce am învățat

• Estimările costurilor bazate pe utilizare se îndepărtează de realitate. Când furnizorul din amonte îți poate spune ce s-a folosit, facturează pe baza acelor date.
• Fă facturarea idempotentă la cea mai mică unitate pe care o taxezi. Pentru noi, asta este o oră de bază de date.
• Când trebuie să greșești, greșește în favoarea clientului.