Webalkalmazások hibatűrő és gyors elérése

|

A mostani és a következő cikkünk az AWS Global Acceleratorról szól. A Global Accelerator 2018-ban indult el, azaz pont tíz évvel fiatalabb, mint az AWS CloudFront. És hogy miért pont a CloudFronthoz hasonlítjuk? Nos, azért, mert a két szolgáltatás első pillantásra pont ugyanarra való. Úgyhogy máris módosítjuk az első kijelentésünket: a mostani és a következő cikkünk a Global Acceleratorról szól, a CloudFronttal való szoros összehasonlításban.

Régiók és Edge Locationök

Ha a tisztelt olvasó tisztában van a fenti két fogalom AWS-beli jelentésével, ugorhat a következő címre. Ha nem, akkor maradjon velünk - értenie kell ezt a két fogalmat, hogy a Global Acceleratort igazán értékelni tudja.

Az AWS-ben a régió egy-egy város vagy ország nevét kapja. A mellékelt képen (forrás: infrastructure.aws) hét régió látszik, bár némi csalás is van rajta, lévén a cikk írásakor (2020 ősze) a spanyol régió még nincs kész. Az európai régiók mindegyike három, egymástól függetlenül működő adatközpontból áll, ezeket látjuk a képen kettős "gyöngysorokkal" összekapcsolva egy-egy sárga pötty körül. A régiók adatközpontjaiba helyezzük el az AWS-erőforrásainkat.

az AWS Európában

Az AWS azonban több olyan helyen is jelen van, ahol nincs régiója. Az ilyen jelenléti pontok egy részén (2020 januárja óta Budapesten is) úgynevezett Edge Locationt üzemeltet. Az Edge Locationök többféle szerepet is kapnak. Részint belépési pontokat jelentenek az AWS saját hálózatába (ezt a hálózatot jelképezik a képen a vastag gyöngysorok), részint egy-egy AWS-szolgáltatás felhasználó felé eső - és a felhasználóhoz közel eső - végpontjaiként szolgálnak. Az Edge Locationök számának növekedését jelzi, hogy 2018 márciusában, azaz tíz évvel az Edge Locationök legközismertebb felhasználási módjának, a már említett CloudFrontnak a bevezetését követően jelentik be a nyolcadikat, majd ugyanennek az évnek novemberében egyszerre hatot, decemberében újabb tízet, cikkünk írásakor pedig kétszázöt(!) van.

Hogyan tudunk többé-kevésbé hibatűrő webes alkalmazást készíteni AWS-ben?

Aki a címet olvasva arra gondol, hogy ez egy hosszabbacska téma, annak igaza van - ennek megfelelően nagyon magasról és meglehetősen futólag szemléljük a problémát.

A hibatűrés megvalósulhat egyetlen adatközpontban. Eggyel magasabb fokozat, ha régiószinten hibatűrő rendszert fejlesztünk, azaz, ha az egyik adatközpontunk kiesik, az ügyfeleinknek akkor is biztosítjuk a szolgáltatást - valamelyik másik adatközpontból. A hibatűrés harmadik szintjét a régiók közötti hibatűrés jelenti. Egész régió kiesése éppen nem mindennapos esemény, de azért van, aki szeret mindenre gondolni. Ilyen esetekben az erőforrásunk több régióban üzemel, amennyire csak lehet, egymástól függetlenül. Több régióban üzemelő szolgáltatás megvalósítása akkor is ésszerű követelmény lehet, ha nem számítunk arra, hogy egy egész régió egyszerre esik ki (nem is tudunk ilyen esetről), de szeretnénk közel lenni a felhasználóinkhoz.

Egy régión belül maradva viszonylag egyszerű a feladatunk. Az erőforrásaink magukban is lehetnek hibatűrőek, ha például felhőnatív alkalmazást fejlesztünk API-Gateway-re és Lambdára támaszkodva, vagy S3-vödörből szolgáljuk ki a statikus weboldalunkat. Ha valamilyen legacy alkalmazást költöztettünk AWS-be, vagy már ott készült, de figyelve arra, hogy szükség esetén ki tudjunk kecmeregni az AWS-ből, akkor viszont virtuális gépeken vagy konténerekben fut a terhelés. Ha ezek elé terheléselosztót teszünk, és autóskálázóval vigyázunk arra, hogy a kidőlő gépeink illetőleg konténereink helyett mindig legyen kéznél új, akkor lényegében megoldottuk a problémát. A terheléselosztó lehet egy DNS-bejegyzés célja. Ez esetben a felhasználóink praktikusan sosem veszik észre, hogy baj történt egy-egy erőforrással, a kiszolgálásuk lényegében folyamatos.

A régió kiesésére is felkészülő, vagy a felhasználóhoz való közelség miatt több régióba telepített szolgáltatás elé nem tudunk terheléselosztót tenni, a forgalom elosztásáról viszont gondoskodnunk kell. Az AWS DNS-szolgáltatása, a Route53 képes arra, hogy a felhasználó földrajzi helyétől függően egyik vagy másik régió felé terelje a forgalmat, és régió kiesése esetén képes a teljes adatforgalmat a másik (harmadik, negyedik ...) régióba irányítani.

Hogyan kerülünk közel a felhasználóinkhoz?

Annak megoldása, hogy az alkalmazásunk több régióban is egyszerre üzemelhessen, nem mindig kézenfekvő, bár a régiók közötti replikációt is megoldó Aurora menedzselt adatbázisaival már nem is végzetesen bonyolult. Ha azonban csak azért lenne rá szükségünk, mert a felhasználóinkhoz földrajzilag közeli, gyors alkalmazást szeretnénk, akkor alighanem olcsóbb és egyszerűbb lesz a CloudFront használata.

A CloudFront lényegében arra való, hogy a tartalmat az Edge Locationökön gyorsítótárazza. A Route53 a - végső soron a felhasználótól érkező - DNS-kérésre a legközelebbi Edge Location címét adja meg, a felhasználó azzal fog beszélgetni. Az Edge Location elhozza az alkalmazásunktól a tartalmat, és a második felhasználó már élvezi a gyorsítótárazás előnyeit. Megjegyezzük, hogy az Edge Locationök képesek a bemenő adatot is kezelni, azaz a felhasználó tud webes űrlapokat kitölteni vagy fájlokat feltölteni. Az adat az alkalmazásunk és az Edge Locationök között mindkét irányban az AWS saját hálózatán utazik és jellemzően gyorsabban, mint ha a publikus interneten próbálna odáig eljutni.

Nagyon hasonlóan dolgozik a Global Accelerator is. A felhasználó kap IP-címet a DNS-szervertől, belép az Edge Location-ön, végigszalad az AWS hálózaton, eljut a célrégióig, és hozzáfér a tartalomhoz.

Akkor miért van két szolgáltatás? Erre kapunk választ a következő cikkünkből.

[Vissza a bejegyzésekhez]