Amit senki sem mond el a Microsoft Fabric kapacitás-túllépés kezeléséről

A Microsoft beárazta, mennyibe kerül, ha nem akarunk throttlingot: a pay-as-you-go díj háromszorosába. Az új funkció neve capacity overage, previewban érhető el, és opt-in: compute-tüske idején a Fabric nem lassítja vagy utasítja el a műveleteket, hanem automatikusan kiszámlázza a túllépést, egy általunk megadott limitig. Hogy ebből biztonsági szelep lesz vagy lassan szivárgó lyuk a felhőbüdzsén, az olyan döntéseken múlik, amelyeknek nem sok közük van a technológiához.

Mit csinál pontosan a capacity overage

A Fabric-kapacitások eddig is több mechanizmussal kezelték a terhelésingadozást: bursting, smoothing, és ha a tartós igény túlnő a megvásárolt kereten, throttling. A fájdalom ez utóbbinál jelentkezik, mert a műveletek késnek vagy elutasítást kapnak, a refreshek sorban állnak, a felhasználók pedig észreveszik.

A capacity overage átrendezi ezt az alkut. A kapacitásadmin kapacitásonként kapcsolhatja be, és limitet ad meg arra, mennyi túllépést hajlandó elviselni egy 24 órás ablakon belül. Amikor a workloadok túllépik a megvásárolt kapacitást, a Fabric throttling helyett valós időben „kifizeti” a felhalmozott compute-adósságot és kiszámlázza; egyetlen job sem áll le és nem szakad meg. A mért díj a pay-as-you-go háromszorosa, és a bejelentés egyértelműen fogalmaz: ez alkalmi tüskékre való. Tartós túlhasználatra a kimondott ajánlás a további optimalizálás vagy az eggyel nagyobb kapacitásméret.

Van még egy fontos részlet. Amikor a kiszámlázott túllépés eléri a beállított limitet, a Fabric visszaáll a normál throttlingra, késésekkel vagy elutasított jobokkal, amíg az ablak nem indul újra, vagy meg nem emeljük a limitet.

Pénzügyes szemmel ez máshogy csapódik le

A pénzügyi workloadok természetüknél fogva tüskések. A zárási naptár néhány munkanapba sűríti a szemantikus modellek refreshét, a rekonsziliációs pipeline-okat, az allokációs futásokat és a riportfogyasztást, miközben a hónap többi részében a kapacitás nagy része áll. Ha a csúcsra méretezünk, egész évben fizetjük a havonta néhány napra kellő tartalékot; ha az átlagra, akkor pont akkor jön a throttling, amikor mindenki a számokat nézi. Egyik opció sem volt jó, és a legtöbb csapat csendben a másodikkal élt együtt. A capacity overage pontosan ezt a rést célozza, és átmeneti felárat fizetni azért, hogy a zárási naptár tartható maradjon, könnyebben megírható üzleti eset, mint egy tartósan nagyobb kapacitás.

A zárás második munkanapján lefojtott refresh nem infrastruktúra-metrikaként jelenik meg. Késésben lévő vezetői riportcsomagként jelenik meg, és egy kontrollerként, akinek magyarázkodnia kell.

A költségkontrollingban és költségallokációban töltött évek után viszont van egy reflexem: minden automatikusan ketyegő tételnek név szerint megnevezett gazdája kell legyen. Erről lentebb.

A limit nem szünteti meg a hibamódot, csak arrébb tolja

A 24 órás limit elérésekor visszakerülünk a throttlingba, adott esetben zárás közepén, miután a 3x felárat már kifizettük. Az eredeti kérdés, hogy „mi történik, ha elfogy a kapacitás”, egyszerűen átalakul azzá, hogy „mi történik, ha elfogy a túllépési keret”.

Két beállítást érdemes elkerülni. A túl alacsony limit néhány zökkenőmentes órát vásárol, aztán háromszoros áron szállítja ugyanazt a throttlingot, ami elől menekültünk. A túl magas limit egy elszabadult Spark notebookot vagy egy félrekonfigurált refresh-ciklust olyan költési eseménnyé változtat, amelyet csak egy olyan szám fékez, amit soha senki nem gondolt át komolyan. A limit megszakítóként viselkedik, és úgy is kell méretezni: elég magasra, hogy elnyelje a tüskét, ami ellen biztosítást kötünk, és elég alacsonyra, hogy a kioldása jelezzen valamit, amire érdemes ránézni.

A 3x szorzó iránymutatás, nem csak ár

A háromszoros szorzó egyértelmű árazási üzenet. Azt mondja, hogy ez biztosítás, és a bejelentés meg is erősíti: tartós túlhasználatnál optimalizálni kell vagy nagyobb kapacitást venni. Egy tipikus középvállalati pénzügyi csapatnál a minták nagyjából így rendeződnek:

A mérőórának gazda kell

A bekapcsolás kapacitásonként történik, és a Fabric kapacitásadminok kezében van, vagyis egy mérnöki szerepkör hoz meg egy lényegét tekintve költési döntést. A kontroller szótárában az overage-limit jóváhagyási küszöb. Jár hozzá megnevezett gazda, egyeztetett felülvizsgálati ritmus, és egy sor a havi eltéréselemzésben, mint bármely más fogyasztásalapú felhőköltségnek. Ha valaki incidens közben emeli meg a limitet, hogy a jobok tovább fussanak, annak a változtatásnak ugyanolyan utólagos felülvizsgálat jár, mint egy manuális könyvelési tételnek. Semmi egzotikus nincs ebben; ugyanaz a fegyelem, amit a pénzügy minden más mért kötelezettségvállalásra már alkalmaz, kiterjesztve még egy mérőórára.

A láthatóságról: a bejelentés szerint hamarosan frissül a capacity metrics app, hogy az overage-számlázás kihasználtsága látható legyen, az információ pedig már most elérhető a real-time hub capacity eventjein keresztül. A preview alatt az átláthatóság tehát ezeken az eventeken áll vagy bukik; jobb még a szélesebb bekapcsolás előtt bekötni őket a már működő riasztásokba, mint az első meglepő számla után.

A Syngentánál egy Fabric lakehouse-on dolgozva azt látom, hogy a kevésbé látványos eszközök (a refresh-ütemezés, és annak fegyelme, hogy mi kerülhet egyáltalán közös kapacitásra) többet tesznek a mozgástérért, mint bármilyen számlázási funkció. Az overage egy réteg, amit erre a munkára érdemes ráépíteni, nem helyette.

Hogyan érdemes bekapcsolni

Érdemes szűken indítani. Az overage-et a zárás-kritikus workloadokat kiszolgáló kapacitáson érdemes bekapcsolni, szándékosan konzervatív limittel, és végigvinni egy teljes zárási cikluson, miközben figyeljük a capacity eventeket. Utána a tényleges költést ugyanazzal a szigorral kell átnézni, mint bármely eltérést: a nulla költés olcsó biztosítást jelent; a visszatérő minta pedig azt, hogy a bejelentés saját tanácsa érvényes, és ideje optimalizálni vagy átméretezni.

A teljes bejelentés, az Introducing capacity overage: Flexibility when you need it most, a Microsoft Fabric blogon olvasható, a dokumentációra mutató hivatkozással együtt. A preview részletei változni fognak; az a szokás, hogy minden mért költésnek gazdát adunk, ne változzon.