3. szoftarch - felhő architektúrák, minták

Felhő architektúra kihívások (8)

• Rendelkezésre állás

• Adatkezelés

• Design VS implementation

• Üzenetkezelés

• Felügyelet

• Teljesítmény és skálázás

• Rugalmasság

• Biztonság

Backends for Frontends*

A.
Backends for Frontends (BFF)

B.
Olyan rendszerekben használjuk, ahol különböző típusú kliensek (web, mobil) különböző igényeket támasztanak ugyanazzal a backend szolgáltatással szemben.

C.
• A web és mobil kliensek eltérő képességűek
• A közös backend túl sok speciális elágazást tartalmaz
• Több fejlesztői csapat között konfliktusok, kompromisszumok
• Skálázás és optimalizálás nehéz, ha a frontendek igényei ütköznek

D.
• Külön backendeket hozunk létre minden frontend típushoz
• Mindegyik backend a frontend igényeihez optimalizált
• A logika nem keveredik, nem duplikálódik a kliensek között
• A központi backend csak az alap szolgáltatásokat nyújtja

E.
• Web backend
• Mobil backend
• Közös szolgáltatás backend
• Frontend alkalmazások

F.
• A frontend a hozzá tartozó BFF-hez fordul
• A BFF feldolgozza a speciális igényeket
• A BFF kommunikál a közös backenddel
• A válasz visszaérkezik a frontendhez

G.
• Kód duplikáció elkerülése
• Megfelelő rétegzés kialakítása
• Verziókezelés és API-k szinkronizálása
• Az eltérő backendek üzemeltetése és monitorozása

H.
• Nagyvállalati web–mobil rendszerek
• Microservice architektúrák
• Spotify, Netflix, Amazon által használt minta

I:

Előnyök	Hátrányok
Frontendhez igazított optimalizálás	Kód duplikáció veszélye
Gyorsabb fejlesztés külön csapatoknak	Ha a frontendek hasonló igényűek → overkill
Kevesebb kompromisszum	Üzemeltetési overhead
Jobb skálázás

Circuit Breaker*

A.
Circuit Breaker (megszakító)

B.
Elosztott rendszerekben a hibákat kezelni kell úgy, hogy ne terheljük túl a meghibásodott szolgáltatást.

C.
• A tranziens hibákat gyakran újrapróbálkozással kezeljük
• Ha a hiba nem tranziens, az újrapróbálások túlterhetik a szolgáltatást → láncreakció
• A kiesés nehezen áll helyre, ha folyamatosan terheljük

D.
• A hívások egy proxy rétegen mennek keresztül
• Három állapot:
– Closed: minden megy normálisan
– Open: túl sok hiba → blokkol minden új kérést
– Half-Open: tesztkérések alapján eldönti, visszatérhet-e closed állapotba
• Ez megakadályozza a túlterhelést és gyors hibadetektálást ad

E.
• Caller (hívó)
• Circuit Breaker
• Target service
• Monitoring / timeout logika

F.
• Hívások → ha sorban hibát jeleznek → breaker „open”
• Open állapotban a breaker azonnal visszadob hibát
• Idő letelte után half-open tesztkérések
• Siker esetén visszaáll closed-ba

G.
• Timeout és hibaráták meghatározása
• Logolás, metrikák kezelése
• Hibák értelmezése (melyik hiba okozzon open állapotot?)
• Integrálás a retry és fallback mechanizmusokkal

H.
• Netflix Hystrix
• AWS API Gateway
• Kubernetes service mesh (Istio)

I:

Előnyök	Hátrányok
Megakadályozza a túlterhelést	Lokális hívásoknál felesleges overhead
Gyors hibadetektálás	Bonyolultabb konfiguráció
Hibatűrőbb rendszer
Stabilabb szolgáltatás-helyreállítás

Static Content Hosting

A.
Static Content Hosting

B.
Webalkalmazások gyakran szolgálnak ki statikus fájlokat (HTML, CSS, képek), amelyek terhelik a webszervert.

C.
• A webszerver drága erőforrás
• A statikus fájlok kiszolgálása elvonja a kapacitást a dinamikus kérések elől
• Egyre nagyobb statikus tartalom mennyiséget kell kezelni

D.
• A statikus fájlokat külön szolgáltatásba szervezzük:
– CDN
– Blob storage
– Static file hosting szerver
• A webalkalmazás csak a hivatkozásokon keresztül utal ezekre
• A teljesítmény javul, a terhelés csökken

E.
• Webalkalmazás
• Static hosting service / CDN
• Deployment pipeline

F.
• A statikus fájlok feltöltése a hosting szolgáltatásba
• Az alkalmazás hivatkozásainak átállítása
• CDN terítés / gyorsítótárak frissítése
• Kliens a CDN-ről kapja a tartalmat

G.
• Egyező domain / HTTPS támogatás
• CDN invalidálás
• Deployment folyamat összehangolása
• Hozzáférésvédelem (pl. privát fájlok, tokenek)

H.
• AWS S3 + CloudFront
• Azure Blob + CDN
• Netlify, Vercel, GitHub Pages

I:

Előnyök	Hátrányok
Jelentősen tehermentesíti a webszervert	Lehet, hogy nem támogat saját domaint
Olcsóbb és gyorsabb statikus kiszolgálás	Privát fájlok védelmét külön kezelni kell
CDN miatt globálisan gyors	Deployment összetettebb
Jobb skálázás

Valet Key*

A.
Valet Key

B.
Olyan helyzetekben használjuk, amikor a kliens közvetlenül szeretne fájlokat tölteni fel/le egy háttértárba, de az alkalmazásszerver erőforrásait nem akarjuk terhelni, és meg kell őrizni a jogosultsági kontrollt.

C.
• Fájlfeltöltés/letöltés az alkalmazásszerver erőforrásait foglalja
• A közvetlen hozzáférés nem biztonságos
• A kliens nem kaphat tartós jogosultságot a tárhelyhez

D.
• A szerver időben korlátozott hozzáférési kulcsot generál (Valet Key)
• A kliens ezt használva közvetlenül kommunikálhat a tárhellyel
• A tárhely a kulcs alapján engedélyezi vagy tiltja a kérést
• A kulcs visszavonható, időzíthető, erőforráscsoportra is érvényes lehet

E.
• Application server
• Storage service (S3, Blob)
• Client
• Valet Key (token)

F.
• Kliens → alkalmazás: jogosultságot kér
• Szerver → létrehoz egy időkorlátos, limitált token-t
• Kliens ezzel közvetlenül a storage-ot hívja
• Storage ellenőrzi a tokent és végrehajtja a műveletet

G.
• Token formátuma, lejárata
• Titkosított csatorna szükséges
• Token visszavonása sikertelen művelet után
• Csak egy erőforrás-csoportra érvényes legyen

H.
• Azure Blob SAS token
• Amazon S3 presigned URL
• Google Cloud Storage signed URLs

I:

Előnyök	Hátrányok
Az alkalmazásszerver tehermentesítése	Ha az adatot validálni kell, kevésbé alkalmazható
Jobb skálázás	Meglévő appok utólagos átalakítása nehéz
Kisebb adatmozgatási költség	Főleg nagy fájlmennyiségnél előnyös
Rugalmas jogosultságkezelés