Megújul az AWS Resilience Hub: itt az AI-alapú előrejelzés
A DevOps és SRE világ egyik legrégibb fájdalma nem a leállás maga, hanem az, hogy a leállás mindig meglepetés. Nem azért, mert senki sem figyelt, hanem azért, mert a rendszerek közötti függőségek olyan szövevényessé váltak, hogy egy ember vagy akár egy egész csapat sem képes azt mindig fejben tartani.
Aki dolgozott már éles környezetben futó, több száz mikroszolgáltatásból álló alkalmazáson, az pontosan tudja ezt az érzést: valami leáll, és az első tíz perc azzal megy el, hogy egyáltalán megértsük, melyik ponton lehet a hiba.
Az AWS most érdemi frissítést adott ki a Resilience Hub következő generációjaként, és ez nem kozmetikai változás. Az eszköz eddig is segített mérni és értékelni az alkalmazások megbízhatóságát, de lényegében passzívan dolgozott: megmondta, hol állsz, és javasolt. Az új verzió aktívabb szerepet vesz fel.
Mi változott valójában?
Az első komolyabb változás a moduláris resilience policy. Korábban előre definiált sablonból kellett választani. Most a csapatok összerakhatják a saját elvárásrendszerüket: meghatározhatják például, hogy az alkalmazás 99,95%-os rendelkezésre állást kell teljesítsen, 15 perces RTO-val és 5 perces RPO-val, multi-region disaster recovery konfigurációval.
Ezt a policy-t aztán újra felhasználhatják több alkalmazáson is, ami nagyvállalati környezetben különösen hasznos.
A második változás az üzleti modell alapú szervezés. Az Resilience Hub most nem csak AWS-erőforrásokat lát, hanem üzleti logikát is próbál leképezni. Egy System egy teljes üzleti alkalmazást jelent, a „user journey”-k a kritikus üzleti folyamatokat írják le, a service-ek pedig ezeket alkotó telepíthető egységek. Ez az absztrakciós szint közelebb hozza az eszközt a valós döntési folyamatokhoz.
A harmadik, és valószínűleg a legfontosabb: a generatív AI-alapú „failure mode assessment”. Az elemzés nem csak az AWS Well-Architected keretrendszer elleőrzőlistáját futtatja le. A rendszer az alkalmazás topológiáját és a megadott házirendet figyelembe véve azonosítja a lehetséges hibamódokat, és konkrét, az adott service-re szabott javaslatokat ad. Ez az a pont, ahol az eszköz valóban új szintet jelent.
A negyedik az automatikus dependency discovery. A legtöbb csapat ezt manuálisan próbálja karbantartani, rendszerint sikertelenül. Az Resilience Hub a VPC DNS lekérdezési bejegyzéseket elemzi, és feltérképezi, hogy az alkalmazás valójában mitől függ: belső végpontoktól, más AWS szolgáltatásoktől, vagy éppen külső, harmadik fél által üzemeltetett végpontoktól. Azokat a cross-region hívásokat is megtalálja, amelyekről a csapat esetleg nem is tudott.
Miért érdekes ez SRE szempontból?
Az SRE-munka nagy részét az teszi nehézzé, hogy a megbízhatóság nem egy esemény, hanem egy folyamat. Folyamatosan változó rendszerekben folyamatosan kell tudni, hogy az elvárásokhoz képest hol tartunk. Erre eddig nem volt jó, skálázható eszköz AWS-en belül.
Az AWS Organizations integráció ezt a problémát oldja meg nagyvállalati szinten. Egy delegált administrator account-ból az összes szervezeti account resilience posture-je áttekinthető egyszerre, anélkül, hogy minden egyes fiókba be kellene lépni és külön riportokat kellene összefésülni. Száz alkalmazás esetén ez nem kényelmi funkció, hanem napi munkát érintő változás.
Hogy jobban értsük
Képzeld el, hogy egy pénzügyi alkalmazást üzemeltetsz AWS-en, több régióban. A payment service kommunikál egy külső banki API-val és egy belső fraud detection service-szel. A csapda ebben a helyzetben az, hogy a külső banki API-t senki sem monitorozza aktívan függőségként, mert egyszer valaki azt mondta, hogy az megbízható. Aztán az API elkezd belassulni, nő a válaszidő, a fraud detection service timeout-ot kap, a payment service hibát dob – és az ügyeletes kolléga egy olyan riasztást kap, amelyből nem derül ki egyértelműen, hogy mi a valódi ok.
A Resilience Hub a DNS naplókból azonosítja ezt a függőséget, és a hibaelemzés során felszínre hozza, hogy egy kritikus külső végpont nincs monitorozva. A javaslat konkrét: legyen megfelelő korlát beépítve, figyeljenek a válaszidőre, és határozzanak meg tartalék viselkedést arra az esetre, ha a külső szolgáltatás nem elérhető.
Ezt is érdemes tudni
Az Resilience Hub nem helyettesíti a Chaos Engineering eszközöket, és nem váltja le a részletes monitoring konfigurációt. Megmutatja, hogy hol vannak a gyenge pontok és mit kellene tenni, de a tényleges tesztelést, a kontrollált hibaszimulációt és a fokozatos verzióváltást ettől még a csapatnak kell elvégeznie.
Ez egy elemző és irányító eszköz, nem öngyógyító rendszer.
Az árazás is változott. Az új modell szolgáltatásonként számol, és havonta két ingyenes hibaelemzést tartalmaz minden egyes szolgáltatáshoz. A függőségtérkép automatikus feltérképezése opcionális, és külön kerül számlázásra.
Mikor hasznos valójában?
Azoknak, akik most találkoznak először az eszközzel: az Resilience Hub akkor éri meg megismerkedni, amikor az infrastruktúra már kellően komplex ahhoz, hogy a fejben tartott függőségi térkép megbízhatatlanná vált. Ahol SRE-szerep van, ahol van külön csapat a megbízhatóságért, ahol AWS Organizations-t használnak – ott ez az eszköz valódi értéket adhat.
Az, hogy generatív AI-t ültetnek bele az ilyen elemző folyamatokba, nem meglepő irány. Az viszont figyelemre méltó, hogy az AWS itt nem egy kísérleti feature-t dobott be, hanem egy meglévő, éles eszköz alapvető értékelési logikáját cserélte le AI-ra.
