A Google önfejlődő AI-ügynökökkel kezelné a felhős leállásokat

Az ügynök nemcsak tanácsot adna

A Google Developers Blog október 22-i bejegyzése szerint a nagy felhős rendszerekben a szorosan összekapcsolt mikroszolgáltatások hibái egymást erősítő leállásokhoz vezethetnek. Egy Black Friday típusú villámakció alatt az üzemeltetőknek másodpercek alatt kell értelmezniük a megosztott rendszerből érkező zajos telemetriát.

A Google szerint a hagyományos generatív AI-segédek felgyorsíthatják a kódírást és a naplók összefoglalását, de az éles üzemzavarok megbízható elhárítására korlátozottan alkalmasak. A Project Chrysalis célja egy olyan önfejlődő AI-rendszer, amely valós időben keresi meg a gyorsítótár- és adatbázisszintű okokat, futás közben javítóeszközöket készít, majd méri, melyik beavatkozása segített vagy rontott a helyzeten.

A rendszer a Google Cloud Key Management Service segítségével írja alá a létrehozott javításokat, a Binary Authorization pedig megakadályozza az ellenőrizetlen kód csatlakoztatását. A Model Armor a beérkező telemetria vizsgálatára szolgál, az Open Policy Agent Policy Controller SLA-korlátokat érvényesít, a végleges hierarchiamódosításokhoz pedig kétoldalú, ember által felügyelt jóváhagyás szükséges.

Egy gyorsítótárhiba okozza a láncreakciót

A bemutatott forgatókönyvben egy promóció hirtelen megnöveli a pénztárhoz intézett kérések számát. A Google Cloud Memorystore Redis a szigorú, legutóbb használt elemeket előnyben részesítő memóriahatár miatt eltávolítja a ritkábban használt kulcsokat, így a gyorsítótár találati aránya nullára esik. A kérések ezután közvetlenül a Google Cloud SQL felé terelődnek.

Az adatbázis PostgreSQL-kapcsolatkészlete telítődik, a lekérdezések pedig túllépik az időkorlátokat. A forrás szerint ilyenkor az emberi üzemeltetők és az egyszerűbb nyelvi modellek is könnyen a kapcsolatkészlet újraindításához nyúlhatnak. Ez a beavatkozás azonban tovább ronthatja a helyzetet: a kapcsolatok eldobása zárolhatja az adatbázismagot, megemelheti a késleltetést, és az üzemzavart teljes kiesés felé tolhatja.

A Chrysalis erre egy memóriában létrehozott, tokenvödör-alapú forgalomszabályozóval reagál. Az ügynök elkészíti a köztes szoftver javítását, ellenőrzi annak absztrakt szintaxisfáját, kriptográfiailag aláírja, majd a forrás szerint közvetlenül az API-átjáróba csatolja. A későbbi értékelésben bünteti a sikertelen újraindítási reflexet, és jutalmazza azt a forgalomszabályozót, amely megszüntette a szerverhibákat.

Három kutatási pillér adja az architektúra alapját

Az első pillér a Dream-RSI nevű szerver nélküli ellenpéldás szimuláció. A termelési kérések nyomvonalait a Google BigQuery-be exportálják, ahol több száz tokenvödör-beállítást futtatnak újra vektorizált, memórián belüli vizsgálatokkal. Így a szabályozási politikákat éles módosítás nélkül lehet összevetni.

A második pillér, az APEX, három időléptékre bontja a fejlődést. Az első a pillanatnyi, memóriabeli javítás, amely az aktív hibát állítja meg. A második az ellenőrzött elvek rögzítése, amelyek a későbbi riasztásoknál blokkolhatják az ellenjavallt műveleteket. A harmadik a többügynökös felépítés átstrukturálása, amelyben tartós specialistákat lehet beilleszteni az aktív irányított gráfba.

A harmadik pillér az AgentEvolver, amely Shapley-alapú hozzájárulást számol az egyes végrehajtási lépésekhez. A P99 késleltetés, az HTTP 5xx hibaarány és az adatbázis-kapcsolatkészlet telítettségének beavatkozás előtti és utáni változásait használja annak elkülönítésére, mely javítás volt hasznos és melyik okozott további problémát.

A Google által közölt szimulációs eredmények

A Google szerint a referenciaarchitektúra a szimulált Black Friday gyorsítótár-túlterheléseiben az első mérséklő beavatkozásig eltelt időt 15 és 45 percről 1,8 másodpercre csökkentette. A HTTP 5xx hibaarány 72,7 és 80,0 százalék közötti értékről 0,0 százalékra esett, a P99 késleltetés pedig 519,8 ezredpercről 18,2 ezredpercre mérséklődött.

A BigQueryben 400 ellenpéldás forgalomszabályozási politikát körülbelül 0,5 ezredmásodperc alatt értékeltek. A bemutató alkalmazás a Gemini platformon és az Agent Development Kit, vagyis az ADK segítségével készült. A forrásban ismertetett első fázisban egy 50 kérésből álló, 15 hideg készletkulcsot érintő terhelési csúcs után a Memorystore találati aránya 100 százalékról 0,0 százalékra zuhant, a Cloud SQL két aktív kapcsolatból álló készlete pedig teljesen telítődött.

A megoldás jelentősége a felhasználók és az üzemeltetők számára a Google által leírt működési modellben rejlik: az ügynök éles helyzetben is készíthet eszközt, de a módosításokat aláírások, szabályzatok és emberi jóváhagyás korlátozza. Így az önfejlődés a bemutatott architektúrában ellenőrzött folyamatként jelenik meg, nem felügyelet nélküli kódmódosításként.