Adatforgalmi korlátokon túl: Codex és Sora hozzáférés méretezése

Az elmúlt évben a Codex és a Sora is gyorsan elterjedt, és használatuk hamar túllépte az eredeti várakozásainkat. Egy következetes mintát figyeltünk meg: a felhasználók belevetik magukat, valódi értéket találnak, majd korlátokba ütköznek.

A sebességkorlátok segíthetnek kisimítani a keresletet és méltányos hozzáférést biztosítani; azonban, amikor a felhasználók értéket kapnak, egy hirtelen leállás frusztráló lehet. Olyan megoldást szerettünk volna, amely lehetővé teszi a felhasználóknak a folytatást, miközben megőrzi a rendszer teljesítményét és a felhasználók bizalmát a megközelítésünk iránt.

Ennek megoldására egy valós idejű hozzáférés-figyelő motort építettünk, amely a használatot méri. Az egyik funkció ebben a rendszerben a kreditek vásárlásának lehetősége. Amikor a felhasználók túllépik adatforgalmi korlátukat, a kreditek lehetővé teszik számukra, hogy továbbra is használják a termékeinket a kreditegyenlegük terhére.

Ez alatt egy összetett rendszer húzódik meg, amely egyetlen hozzáférési modellben egyesíti a korlátokat, a valós idejű használat követését és a kreditegyenlegeket. Ez a bejegyzés arról szól, hogy miért volt szükség a Codex és a Sora méretezésekor a hozzáférés-ellenőrzés újragondolására, hogyan kombinál egy bizonyíthatóan helyes, valós idejű rendszer kérésenkénti korlátokat és krediteket, és hogyan nyitja meg ez az alap most a további hozzáférést mindkét termékhez.

Ha távolabbról tekintünk rá, a hagyományos hozzáférési modellek általában választásra kényszerítenek:

• Az adatforgalmi korlátozások eleinte hasznosak lehetnek, de rossz felhasználói élményt okoznak, amikor kifogynak: „gyere vissza később”
• A használatalapú számlázás rugalmas, de a felhasználók már az első tokentől fizetnek—ez nem ideális a korai felfedezéshez

A Codex és a Sora esetében egyik sem volt önmagában elegendő. Ha csak megemelnénk a korlátokat, elveszítenénk a fontos keresletkiegyenlítési és méltányossági ellenőrzéseket, és kifogynánk a kapacitásból, hogy mindenkit ki tudjunk szolgálni. Ha teljesen az aszinkron használatalapú számlázásra támaszkodnánk, késleltetést, túllépéseket vagy egyeztetési problémákat okoznánk—éppen azokat a problémákat, amelyeket a felhasználók akkor vesznek észre, amikor a leginkább aktívak.

Ehelyett egyetlen hibrid rendszerre volt szükségünk, amely a valós idejű korlátokat használat alapú hozzáféréssel ötvözi:

A rendszernek a következőket kellett tennie:

• Érvényesítsd az adatforgalmi korlátokat addig, amíg el nem érik azokat
• Zökkenőmentesen válts át a kreditekre ugyanazon kérésen belül
• Ezt a döntést valós időben meghozni
• A kreditfelhasználás nyomon követése során szigorúan pontosnak és ellenőrizhetőnek kell lennie

Az egyik kulcsfontosságú koncepcionális váltás, amit végrehajtottunk, az volt, hogy a hozzáférést döntési waterfall modellként képzeltük el. Ahelyett, hogy azt kérdeznénk: „megengedett ez?”, azt kérdezzük: „mennyi megengedett, és honnan?” A használat számlálásakor a rendszer a következő sorrendet követi:

Ez a modell azt tükrözi, ahogyan a felhasználók valójában megtapasztalják a terméket. Az adatforgalmi korlátok, az ingyenes szintek, a kreditek, a promóciók és a vállalati jogosultságok mind ugyanannak a döntési láncnak a rétegei. A felhasználó szemszögéből nézve nem „rendszert váltanak”—továbbra is a Codexet és a Sorát használják. Ezért tűnnek láthatatlannak a kreditek: csak a waterfall egy újabb eleme.

Kiértékeltük a harmadik fél által kínált használatalapú számlázási és mérési platformokat a kreditfogyasztás kezelésére. Jól alkalmazhatók számlázásra és jelentéstételre, de nem feleltek meg két kritikus követelménynek:

Amikor egy felhasználó eléri a korlátot, és rendelkezésre állnak kreditek, a rendszernek azonnal értesülnie kell róla. A legjobb erőfeszítés vagy késleltetett számlálás váratlan blokkokként, következetlen egyenlegekként és hibás terhelésekként jelenik meg. Az interaktív termékek, mint a Codex és a Sora, esetében ezek a hibák láthatóvá és frusztrálóvá válnak.

Emellett minden eredményt átláthatóvá kellett tennünk:

• Miért lett egy kérés engedélyezve vagy blokkolva
• Mennyi használatot vett igénybe
• Milyen korlátokat vagy egyenlegeket alkalmaztak

Ezt a képességet szorosan integrálni kellett a döntéshozatali folyamatunkba, ahelyett, hogy egy különálló használatalapú számlázási platformon oldottuk volna meg, amely csak egy részét látta annak, ami történt. Ahhoz, hogy a felhasználók bizalomvesztés nélkül férhessenek hozzá termékeinkhez, teljes irányításra volt szükségünk a pontosság, az időzítés és a megfigyelhetőség felett. Ez egy házon belüli megoldás irányába terelt minket.

Ennek működtetésére egy elosztott használati és egyenlegkezelő rendszert hoztunk létre, amelyet kifejezetten a szinkron hozzáférési döntésekhez terveztünk.

Általános szinten a rendszer:

• Felhasználónként és funkciónként követi a használatot
• Fenntartja az adatforgalmi korlát ablakokat
• Valós idejű egyenlegeket tart fenn
• Idempotens módon terheli az egyenlegeket egy folyamatosan működő aszinkron feldolgozón keresztül

Minden kérés egyetlen értékelési útvonalon halad át, amely valós időben dönt arról, hogy mennyi használat engedélyezett azáltal, hogy szinkron módon fogyaszt az adatforgalmi korlátokból, és ha szükséges, ellenőrzi, hogy elegendő kredit áll-e rendelkezésre; majd egyetlen, végleges eredményt ad vissza, miközben az esetleges kreditlevonásokat aszinkron módon rendezi. Ez biztosítja a következetes működést a termékek között, és megszünteti a csapatok közötti duplikált logikát.

Ennek a rendszernek az egyik kulcsfontosságú tervezési alapelve, hogy képesek legyünk bizonyítani, hogy a számlázásunk pontos. Ez tükrözi kredittámogatásunk gyökereit, amelyek a vállalati ügyfeleknél kezdődtek. A fenti rendszerábrán három különálló adatkészlet található, amelyek mind összekapcsolódnak:

• Termékhasználati események: Amit a felhasználó valójában tett
• Bevételszerzési események: Azok az alkalmak, amikor a felhasználót a használatért terheljük
• Egyenlegfrissítések: Mennyivel módosítottuk a felhasználó egyenlegét, és miért

Ezek az adatkészletek nem csupán melléktermékek; valójában ezek működtetik a rendszert, és minden egyes adatkészlet a következőt indítja el. A történések, a kapcsolódó díjak és a terhelések szétválasztása lehetővé teszi, hogy minden réteget függetlenül auditáljunk, újrajátsszunk és egyeztessünk. Ez egy szándékos kompromisszum, amelyben a bizonyítható helyességet helyezzük előtérbe, annak árán, hogy a kreditegyenleg-frissítések kissé késnek. Hogyan értük el ezt:

• A termékhasználati események minden felhasználói tevékenység esetén közzétételre kerülnek, függetlenül attól, hogy az kreditfelhasználást eredményez-e vagy sem. Ez audit nyomvonalat biztosít a felhasználói tevékenységekről, és lehetővé teszi számunkra, hogy megmagyarázzuk, miért számítottunk fel vagy miért nem számítottunk fel krediteket.
• Minden esemény stabil idempotencia-kulccsal rendelkezik, így az újrapróbálkozások, újrajátszások vagy a dolgozók általi újraindítások soha nem terhelhetik meg kétszer az egyenleget, ami megakadályozza a dupla terhelést. Ez lehetővé teszi számunkra, hogy offline módon kötegelt egyeztetést hajtsunk végre a munkánk ellenőrzésére.
• Az auditnapló létrehozása érdekében szinkron frissítések helyett aszinkron (de továbbra is közel valós idejű) egyenlegfrissítéseket végzünk. Megtűrünk egy kis késést a felhasználó egyenlegének frissítésében, hogy bizonyíthassuk, a rendszer megfelelően működik, és biztosíthassuk felhasználóinkat arról, hogy nem számlázunk tévesen. Amikor egy rövid késés miatt túllépjük a felhasználó kredit-egyenlegét, automatikusan visszatérítjük azt; a bizonyítható helyességet és a felhasználói bizalmat választjuk a szigorú érvényesítéssel szemben.
• Egyetlen atomi adatbázis-tranzakció során csökkentjük a Kreditegyenleget, és beszúrunk egy Egyenlegfrissítés rekordot. Az egyenlegfrissítések fiókonként sorosan kerülnek feldolgozásra, így a párhuzamos kérések soha nem versenyezhetnek ugyanazon kreditek elköltéséért. Az Egyenlegfrissítés rekord tartalmazza mind a terhelési összeget, mind a frissítést kiváltó bevételszerzési eseményre való visszavezetést; ennek egyetlen adatbázis-tranzakcióba csomagolása garantálja, hogy minden kreditegyenleghez kapcsolódó kiigazításhoz rendelkezünk audit nyomvonallal.

Mindez a szigor egy célt szolgál: hogy a hozzáférés egyszerű és biztonságos legyen. Amikor az emberek alkotnak vagy kódolnak, nem kellene azon gondolkodniuk, hogy egy kérés átmegy-e, túlszámlázzák-e őket, vagy hogy pontos-e az egyenlegük. A használat, a számlázás és az egyenlegek bizonyítható helyessé tételével olyan rendszert adunk a felhasználóknak, amely nem vonja el a figyelmüket az élményről. Ez teszi lehetővé számunkra, hogy a kemény leállásokat folyamatos hozzáféréssel váltsuk fel—és ez az, ami a krediteket a valódi munka közben is használhatóvá teszi, nem csupán egy számlán.

Megközelítésünk vezérelve a felhasználói lendület megőrzése. Minden architekturális döntés egy felhasználó számára látható eredményhez vezet: a valós idejű egyenlegek elkerülik a szükségtelen megszakításokat, az atomi fogyasztás megakadályozza a dupla terhelést, és az egységes hozzáférési logika kiszámítható viselkedést biztosít. Ennek eredményeként az emberek hosszabb ideig dolgozhatnak, mélyebb kutatást végezhetnek, és tovább vihetik a projekteket anélkül, hogy szigorú határokba ütköznének vagy idő előtt módosítaniuk kellene a terveiket.

Amikor a felhasználók aktívak, a rendszernek segítenie kell őket a folytatásban, nem akadályoznia. A korlátok és a kreditek eltűnnek a háttérben.

Az élmény megteremtéséhez egyetlen rendszerként kellett újragondolni a hozzáférést, a használatot és a számlázást, és olyan infrastruktúrát kellett létrehozni, amely a pontosságot kiemelt termékfunkcióként kezeli. Ugyanez az alap idővel több termékre is kiterjeszthető; a Codex és a Sora csak a kezdet.