A Modal 80 milliszekundummal csökkentette a Function Call késleltetését
A Modal minden Function hívását az új I/O-rétegre állította át, amely regionálisan kezeli a bemeneteket és kimeneteket. A vállalat szerint a végponttól végpontig mért késleltetés p50 értéken nagyjából 80 milliszekundummal csökkent.
- A Modal minden Functiont az új I/O-rétegre állított át.
- A végponttól végpontig mért késleltetés p50 értéken nagyjából 80 ms-mal csökkent.
- A routing_region beállítással legalább négy régió közül lehet választani.
- A 2 MiB-nál nagyobb bemenetek blobtárhelyet is igénybe vesznek.
- A regionális útvonal és a kötegelt feldolgozás csökkentheti a hálózati többletet.
A korábbi rendszer minden adatot az us-east régión át továbbított
A Modal ügyfelei eddig megadhatták, melyik régióban fussanak a konténereik, a Function hívások bemenetei és kimenetei azonban mindig a vállalat us-east régióban működő I/O-szerverein haladtak át. Ez a hívó és a konténer régiójától függően akár néhány száz milliszekundummal is növelhette a hálózati késleltetést.
A Modal egy példával érzékelteti a problémát. Egy RAG-alkalmazásban futó, kisméretű beágyazási modell (embedding model) következtetési ideje 50 milliszekundum alatt maradhat, miközben az európai felhasználók esetében az us-east régióba és onnan vissza irányuló, körülbelül 200 milliszekundumos hálózati út dominálja a teljes időt. Ez akkor is előfordulhat, ha az adatrezidencia miatt a feldolgozás európai konténerekben zajlik.
Regionális I/O-réteg és Go alapú szerverek
Az elmúlt hónapokban a Modal földrajzilag elosztott I/O-réteget fejlesztett. A rendszer legalább négy régióban érhető el, és a routing_region Function-beállítással adható meg, melyik régión keresztül haladjanak a függvény bemenetei és kimenetei. A konténerek régiója ettől külön is beállítható. A Modal ezen a héten fejezte be minden, a platformon futó Function átállítását az új, us-east régióban működő I/O-rétegre.
A rendszer áttervezése során a nem kritikus műveletek, például az automatikus skálázási statisztikáinak frissítése és a műszerfal eseményeinek közzététele, háttérben, aszinkron módon futnak. A hívás kritikus útvonalán csökkentették a megosztott tárhellyel folytatott interakciókat, a kliens pedig gyorsabb hitelesítéshez JWT-ket kap és frissít.
A szerverréteget teljes egészében Go nyelven írták újra. A Modal indoklása szerint a Go könnyű párhuzamossági modellje előnyös a nagy konkurenciájú gRPC-szervereknél. A vállalat a Redis OSS és a Valkey használatát is újraértékelte. A Valkey a Redis 7.2-ből elágazott projekt, amely a bemeneti és kimeneti műveletek egy részét külön szálakra helyezi. A Modal bemeneti sorai Redis streamre épülnek, és a terhelési tesztek tapasztalatai alapján Redis 7.1 mellett maradtak.
Mit tehetnek a Modal felhasználói?
A Modal Function hívásakor a kliens szerializálja a bemenetet, elküldi az I/O-rétegnek, majd lekérdezésekkel várja a szerializált kimenetet. Az I/O-réteg a bemenetet Redisben tárolja és sorba állítja, a szabad kapacitással rendelkező konténerek pedig feldolgozásra átveszik. Hiba esetén, például szerver-, konténer- vagy újrapróbálható felhasználói kódhiba miatt, a kliens gyorsan értesülhet és automatikusan újrapróbálhatja a bemenetet.
A hálózati többlet csökkentéséhez a Modal azt javasolja, hogy a felhasználók a hívóikhoz legközelebbi routing_region értéket válasszák. A konténerek régiója is korlátozható ehhez közeli területre, ez azonban hatással lehet az elérhető kapacitásra és a költségekre.
A 2 MiB-nál nagyobb bemeneteket a kliens először blobtárhelyre tölti fel, majd a hasznos adat helyett annak azonosítóját küldi tovább. Teljesítményérzékeny feladatoknál ezért a bemenetet és a kimenetet érdemes 2 MiB alatt tartani. Sok kicsi és gyors bemenet esetén a kliensoldali kötegelt feldolgozás is csökkentheti a konténerhez vezető hálózati ugrások számát.
