Cloudflare Workers vagy AWS Lambda: a várakozási idő írhatja át a számlát

Rövid, kevés erőforrást használó API-nál az AWS Lambda Event Functions lehet olcsóbb, hosszú külső válaszra váró hívásnál viszont a Cloudflare Workers. A választás azért fordulhat meg, mert a Workers az aktív CPU-időt, a Lambda Event Functions pedig a memóriával súlyozott futási időt számolja el a kérések mellett.

Ha egy feldolgozásnak sok memóriára van szüksége, előbb azt kell eldönteni, hogy egyáltalán futtatható-e a két környezetben. Az alábbi három, azonos havi forgalomra épülő példa feltételes költségszámítás, nem teljesítménymérés: ugyanaz a program a két platformon eltérő CPU-időt és válaszidőt érhet el.

Ugyanaz a kérés, más számlázási alap

A Cloudflare Workers díjszabása szerint a fizetős Standard modell havi 5 dolláros alapdíja 10 millió kérést és 30 millió CPU-milliszekundumot tartalmaz. E keretek fölött egymillió kérés 0,30 dollár, egymillió CPU-milliszekundum 0,02 dollár; a kérés teljes, várakozással együtt mért időtartamáért nincs külön díj. A hálózati válaszra váró Worker tehát továbbra is nyitva tarthatja a kérést anélkül, hogy maga a várakozás növelné a CPU-idő szerinti tételt.

Az AWS Lambda Event Functions árazása havi egymillió ingyenes hívást és 400 000 ingyenes GB-másodpercet tartalmaz; az AWS amerikai, x86-os árazási példáiban a további hívások díja egymilliónként 0,20 dollár, a számítás egységára 0,0000166667 dollár GB-másodpercenként. A GB-másodperc a beállított memória és a futási idő szorzata. Amíg az Event Function külső választ várva fut, ez a szorzat nő. A Lambda Web Functions más modell: ott az aktív CPU-idő mellett a futási környezet memóriahasználata is díjköteles, ezért az alábbi összegek kizárólag az Event Functions változatra vonatkoznak.

Mindhárom példa különálló terhelésként havi 5 millió HTTP-hívást feltételez, egyenletesen elosztva 30 napra. Mindegyik számítás a teljes Lambda ingyenes keretet és egy önálló Workers fizetős fiók keretét használja; a három összeget ezért nem szabad egy közös számlaként összeadni. Az összehasonlítás csak a függvény futtatását veszi figyelembe, amerikai dollárban. Az adatbázis, a külső API, a naplózás, az esetleges API Gateway, az adatforgalom, az adók és az árfolyam hatása külön tétel lehet.

Rövid API: a havi alapdíj dönt

Az első feltételes profilban egy kérés 2 ms CPU-időt használ, teljes futása 20 ms, és nem vár külső szolgáltatásra. A Workers havi fogyasztása 5 millió × 2 ms = 10 millió CPU-ms. A kérések és a CPU-idő egyaránt a fizetős kereten belül maradnak, így a számított havi Workers-díj 5 dollár. A forgalom napi átlaga meghaladná az ingyenes Workers csomag kéréskeretét, ezért itt a fizetős modell az összevetés alapja.

A Lambda esetében 128 MB, vagyis 0,125 GB beállított memóriával számolva a fogyasztás 5 millió × 0,020 s × 0,125 GB = 12 500 GB-másodperc. Ez az ingyenes számítási keretbe fér; az ingyenes egymillión felüli 4 millió hívás díja 0,80 dollár. Az árkülönbség feltétele, hogy a funkció ezen a memóriabeállításon valóban 20 ms alatt fusson. Ha a nagyobb memóriával járó többlet CPU lerövidíti a futást, a két tényezőt együtt kell számolni; a példában a beállítás és az idő rögzített.

Sok külső I/O: a várakozás fordít

A második feltételes profilban marad a havi 5 millió kérés és a kérésenkénti 2 ms aktív CPU-idő, de egy külső API válasza miatt a hívás teljes időtartama 2 másodperc. A Workers továbbra is 10 millió CPU-ms-t használ, ezért a számított havi függvénydíj változatlanul 5 dollár. A példa egyetlen külső válaszra váró kérést feltételez; a külső szolgáltatás díja egyik oldalon sem szerepel.

Ugyanez a profil 128 MB memóriával futó Lambda Event Functionként 5 millió × 2 s × 0,125 GB = 1 250 000 GB-másodpercet eredményez. A 400 000 ingyenes GB-másodperc levonása után 850 000 számlázható GB-másodperc körülbelül 14,17 dollár; a hívások 0,80 dolláros díjával együtt az összeg mintegy 14,97 dollár. A 20 ms-os első profilhoz képest a futási idő és a számított GB-másodperc pontosan százszorosára nő, miközben a feltételezett aktív CPU-idő nem változik. Ebben a konkrét modellben tehát a várakozás írja át a sorrendet.

Ez az eredmény arra a megvalósításra érvényes, amely a külső válaszig nyitva tartja a hívást. Ha a munka külön eseményekre bontható, vagy a külső API gyorsabban válaszol, a Lambda számlázott futási ideje és a két összeg távolsága is csökkenhet. A válaszidőt sem lehet pusztán a futtatás helyéből levezetni: ha a peremen futó kód távoli régióban tárolt adatot kér le, az adatforrásig vezető út továbbra is része a felhasználó várakozásának.

Memóriaigényes feladat: előbb a futtathatóság

A harmadik feltételes feladat egyetlen hívás során 1 GB memóriát igényel, és 300 ms alatt fejeződik be. A Workers erőforráskorlátai az ingyenes és a fizetős csomagban is 128 MB memóriát adnak egy Workernek; az ingyenes csomag kérésenként 10 ms CPU-időt és napi 100 000 kérést enged. A fizetős HTTP Worker alapértelmezett CPU-határa 30 másodperc, legfeljebb 5 percre emelhető, a hálózati várakozás pedig nem fogyaszt CPU-időt. Az 1 GB-ot egyidejűleg memóriában tartó változat mégis meghaladja a Workers memóriakorlátját, így ehhez a változathoz nincs összevethető Workers-futtatási ár.

A Lambda konfigurációs korlátai megengedik az 1 GB memória beállítását, a szokásos függvényhívás időkorlátja pedig 15 perc. A feltételezett terhelés 5 millió × 0,300 s × 1 GB = 1 500 000 GB-másodperc. Az ingyenes keret után 1 100 000 GB-másodperc körülbelül 18,33 dollár, a hívásokkal együtt mintegy 19,13 dollár. A Lambda több beállított memóriához több CPU-erőforrást is rendel, ezért a 300 ms-os futást valódi alkalmazásnál mérni kell. Ha a feldolgozás adatfolyamként vagy kisebb egységekre bontva megoldható, az már más feladat és új költségszámítás.

Hidegindítás és ökoszisztéma

A költségképlet nem mondja meg, milyen gyorsan kap választ egy ritkán hívott függvény. Egy publikált szerver nélküli mérésben az AWS Lambda futási környezete körülbelül 300–360 másodpercnyi tétlenségig maradt életben; a kutatók a hidegindítás valószínűségét a hívások közötti szünet alapján vizsgálták. Ez a vizsgált környezet megfigyelése, nem garantált élettartam. Az egyenletes havi forgalom ráadásul önmagában nem árulja el, hogy egy konkrét függvény milyen gyakran marad tétlen, vagy hány új futási környezet kell egy forgalmi csúcs alatt.

Az alkalmazás meglévő szolgáltatásai is számítanak. Ha az események és az adatok már AWS-szolgáltatásokban vannak, az integráció és a hálózati útvonal többet nyomhat a latban, mint a rövid API példájának néhány dolláros különbsége. Peremhálózati HTTP-feladatnál a Workers CPU-alapú elszámolása különösen a hosszú külső várakozás mellett kedvező; nagy memóriát egyetlen hívásban igénylő munkánál viszont a dokumentált erőforráskorlát előbb eldönti a választást, mint az ár.

Olvassa el ezt is:

• GitHub Actions vagy GitLab CI: a csapatlétszám fordíthatja meg a számlát
• LangSmith, Phoenix vagy Langfuse: nem ugyanazt méri mindhárom
• Billingo vagy Számlázz.hu: az API és a számlamennyiség dönti el