Teljesítmény, biztonság és költség: kompromisszumok
Célok
A lecke végére meg tudod mutatni konkrét példán, hogy a teljesítmény, a biztonság és a költség célja hol erősíti és hol gyengíti egymást, ismered a döntés négy nézőpontját, és tudod, hogyan lehet egy döntést mérhető követelménnyé és rövid indoklássá alakítani.
Három cél, egy rendszer
Egy időpontfoglaló rendszernél könnyű kimondani, hogy az oldal legyen gyors, biztonságos és olcsó. A három szó azonban nem ugyanazt jelenti, és nem mindig erősítik egymást.
A teljesítmény a felhasználó szemszögéből azt jelenti, hogy az oldal gyorsan megjelenik, a gombnyomásra hamar reagál, a fontos művelet nem késik bizonytalanul (9.4); rendszerszinten azt is, hogy sok egyidejű kérés mellett se romoljon elfogadhatatlanul a válaszidő (10.3).
A biztonság azt jelenti, hogy a rendszer a megfelelő személynek a megfelelő adatot és műveletet engedi, miközben ellenáll a hibáknak és támadásoknak (8. fejezet).
A költség nem csak a havi felhőszámla: a fejlesztők ideje, a bonyolultság fenntartása, a monitorozás, az ügyfélszolgálat, az incidensek kezelése, a külső szolgáltatások díja és a hibák üzleti vagy társadalmi kára is.
flowchart TD
D[Tervezési döntés] --> P[Teljesítmény]
D --> B[Biztonság]
D --> K[Költség]
P --> U[Felhasználói feladat]
B --> U
K --> U
Mikor erősítik egymást, és mikor kell választani?
Nem minden döntés kényszerít választásra. A felesleges képek tömörítése például gyorsítja az oldalt, és költséget is csökkent (kevesebb adatforgalom). Sok helyzetben viszont az egyik cél javítása erőforrást kér a másiktól. Négy mért példa a kurzus eddigi leckéiből:
1. Jelszótárolás: a biztonság szándékos lassúsága
A 8.6 lecke mérése szerint a lassú jelszó-hash (scrypt) egy belépésnél kb. 173 ms processzoridőt kér egy magon (3457 ms / 20 próba), míg a gyors SHA-256 mikroszekundumokat. Ez a lassúság a védelem lényege: a támadónak is ennyi jut egy tippre. De a szervernek is: 100 belépés/s esetén ez kb. 17 mag folyamatos terhelése, vagyis hardver (költség), és a belépéskori válaszidő (teljesítmény) is nő. A biztonsági nyereségért itt tudatosan fizetünk teljesítménnyel és költséggel; a belépési korlát (10.5) pedig a költséget is védi a tömeges próbálkozástól.
2. Titkosítás: a HTTPS ára
A 4.5 lecke mérése szerint a TLS-kézfogás kb. 17 ms-ot adott a kapcsolatfelépítéshez egy közeli szerverrel. Ez kicsi, és az újrahasznált kapcsolat (4.2) a második kéréstől már nem fizeti meg. Cserébe a forgalom titkos és hitelesített (4.3). Ez az az eset, ahol a biztonság ára elenyésző a védelem értékéhez képest.
3. Gyorsítótár: sebesség és költség, de adatvédelmi kockázat
A 10.4 lecke szerint a gyorsítótár csökkenti a válaszidőt és a szerverterhelést (a 304 olcsó), és ezzel költséget is spórol. A rosszul beállított megosztott gyorsítótár viszont Béla képernyőjére tette Anna adatait. Itt a teljesítmény és a költség nyeresége a biztonságot és az adatvédelmet kockáztatja, ha a szabály pontatlan: a gyorsítótár nem „bekapcsolandó gyorsítás”, hanem szabályokkal körülírt döntés: mit, kinek, mennyi ideig szabad újra felhasználni?
4. CDN: közelség, terhelés és szerződés
A felhasználókhoz közeli CDN rövidebb késleltetést adhat (4.6), és a csúcsot is jobban elviseli (10.5). Cserébe a szolgáltatás drágább és szerződésileg összetettebb lehet; érzékeny adatnál meg kell érteni, melyik fél mit kezel, milyen régióban, milyen jogalappal (9.6). Nem az a kérdés, hogy a CDN „jó-e”, hanem hogy a nyilvános képekhez, videókhoz és szoftverfájlokhoz indokolt-e, és milyen adatot nem szabad általa kiszolgálni.
Egy döntés négy nézőpontja
Hasznos, ha egy tervezési kérdésnél ugyanazt a négy kérdést tesszük fel:
Mi a felhasználói hatás? Mennyi várakozás vagy plusz lépés elfogadható? Kinek okoz különösen nagy kárt egy hiba?
Mi a védendő érték és a fenyegetés? Személyes adat, pénz, vizsgaeredmény, jogosultság vagy nyilvános tartalom? Ki élhet vissza vele? (8.1)
Mi a terhelési és üzemeltetési helyzet? Állandó vagy időszakos forgalom? Van-e kiszámítható csúcs (kurzusfelvétel, jegyértékesítés)? (10.3, 10.5)
Mennyibe kerül a teljes életciklus? Nem csak az indulás, hanem az ellenőrzés, javítás, megfigyelés és későbbi módosítás is.
Ez a gondolkodás segít elkerülni a hangzatos, de üres válaszokat: „tegyünk mindent felhőbe”, „legyen mikroszolgáltatás”, „titkosítsunk mindent” vagy „legyen nagyon gyors”. Ezeknek a mondatoknak csak akkor van értelmük, ha megmondjuk: pontosan mit, miért, milyen fenyegetés ellen, milyen felhasználói elvárással és milyen költséggel.
Funkciónként különböző döntés: terméklista és fizetés
Egy webáruház terméklistája sok ember számára azonos információ: terméknév, kép, rövid leírás. Az ilyen oldal jól gyorsítótárazható és CDN-en át kiszolgálható (10.4); a gyors betöltés csökkenti a szerverterhelést, így a teljesítmény és a költség célja együtt javulhat. A fizetési folyamat más természetű: itt felhasználóhoz kötött kosár, cím, fizetési állapot és megrendelés szerepel (Cache-Control: no-store vagy private, 10.4). Nem fogadható el, hogy egy „rendelés sikeres” oldal egy korábban tárolt válaszból érkezzen. A fizetésnél fontosabb, hogy minden kérés érvényesítve, naplózhatóan és egyértelmű eredménnyel fusson le (10.2: idempotenciakulcs), még ha ez több adatbázis-műveletet és valamivel hosszabb válaszidőt jelent is.
A jó tervezés tehát nem az egész rendszerre választ egyetlen szintet: funkciónként különböztet. A nyilvános, ritkán változó tartalom agresszívebben gyorsítható; a személyes és visszafordíthatatlan műveletek szigorúbb ellenőrzést kapnak.
Biztonság, amely nem csak lassítás
Gyakori félreértés, hogy a biztonság szükségszerűen lassítja a rendszert. Van költsége (titkosított kapcsolat, bemenet-ellenőrzés, jogosultság, naplózás), de ez általában elenyésző egy adatvédelmi incidens vagy jogosulatlan tranzakció helyreállításához képest. A biztonságos kialakítás néha a teljesítményt is javítja: a jól meghatározott jogosultsági határok és az adatminimalizálás csökkenthetik, mennyi adatot kell egy válaszban elküldeni; a megfelelően méretezett sebességkorlátozás (10.5) megvédi a szolgáltatást a hibás vagy rosszindulatú forgalomtól, így a valódi felhasználók elérhetőségét javítja. A cél nem a védelem elhagyása a gyorsaságért, hanem a kockázathoz illő védelem.
Költség: az olcsó nem mindig takarékos
Egy kis egyetemi projektnek túlzás lehet a több régióban működő, automatikusan skálázódó infrastruktúra: sok pénz, tanulás és karbantartás, miközben az oldalt naponta néhány tucat ember használja. Egy egyszerűbb, megbízhatóan mentett és megfigyelt szolgáltatás gyakran jobb döntés. Fordítva: ha egy vizsgajelentkezés pontos időpontban több ezer hallgatót vonz, az alulméretezett rendszer olcsósága látszólagos. A leállás ügyfélszolgálati terhelést, bizalomvesztést, méltányossági problémát és rendkívüli munkát okoz; a költségbecslésnek az elmaradt szolgáltatás árát is tartalmaznia kell (10.1: hibakeret).
Az egyszerűség is érték. Minden új komponens (külön adatbázis, üzenetsor, gyorsítótár-réteg, külső identitásszolgáltató) megold egy problémát, de új hibalehetőséget, függőséget és tudásigényt hoz. Nem az a cél, hogy kevés technológia legyen, hanem hogy minden technológiának világos oka és gazdája legyen.
Hogyan születik védhető döntés?
Egy rövid döntési jegyzet sokat ér. Például: „A nyilvános eseménylista válaszait öt percig gyorsítótárazzuk (public, max-age=300), mert az adat nem személyes, ritkán változik, és a regisztráció megnyitásakor csúcsforgalom várható. A foglalási és fiókoldalakat nem osztott gyorsítótárból szolgáljuk ki (private), mert személyes, gyorsan változó adatot tartalmaznak.” Ez megnevezi a döntést, a célt, a kockázatot és a határt.
Végigvezetett példa: a Kurzuspont döntési táblázata
Funkció
Teljesítmény
Biztonság
Költség
Döntés
Kurzusleírások (nyilvános)
Gyors, CDN-ről
Nem személyes
Alacsony (statikus)
SSG + CDN, public, max-age=300 (6.4, 10.4)
Belépés
Lassú hash: ~170 ms
Erős védelem
Több processzoridő
Marad; belépési korlát és külön kapacitás (10.5)
Jelentkezés
Szerver dönt, no-store
Szándékellenőrzés (CSRF), jogosultság
Több adatbázis-művelet
Nem gyorsítjuk meg a helyesség rovására (8.4)
Szabad helyek száma
Élő adat, rövid cache
Nem érzékeny
Magas terhelés nyitáskor
Pár másodperces cache vagy SSE (5.5)
Státuszoldal
Külön infrastruktúra
Nyilvános
Kicsi
Igen, a fő rendszertől függetlenül (10.2)
Látható: a döntés funkciónként más, és mindegyik mögött kimondott indoklás van.
Gyakori tévhitek
Állítás
Pontosítás
„A leggyorsabb megoldás mindig a legjobb.”
A gyors, de hibás, rosszul védett vagy drága megoldás nem jó szolgáltatás.
„A biztonság a biztonsági csapat feladata.”
A jogosultságok, adatátadás és alapértelmezések a tervezési döntésekben dőlnek el.
„A felhő automatikusan megoldja a terhelést.”
Rugalmas kapacitást adhat, de a hibás lekérdezést, a rossz cache-szabályt vagy a végtelen újrapróbálkozást nem javítja meg; a kapacitás költséget termel.
„A cache csak teljesítményoptimalizálás.”
Adatkezelési szabály: a helyességet és az adatvédelmet is érinti.
„A kompromisszum lemondást jelent valamelyik célról.”
Gyakran csak azt, hogy a védelem vagy a gyorsítás a megfelelő helyre kerül, nem mindenhol azonos erővel.
Röviden
A teljesítmény, a biztonság és a költség néha erősíti, néha gyengíti egymást: a kipróbált példák (jelszó-hash, TLS, gyorsítótár, CDN) mutatják, hol.
A döntés négy nézőpontja: felhasználói hatás, védendő érték és fenyegetés, terhelési helyzet, életciklus-költség.
Funkciónként különböző döntés kell: a nyilvános tartalom gyorsítható, a személyes és visszafordíthatatlan művelet szigorúbb.
A célt mérhető követelménnyé és rövid indoklássá kell fordítani.
Ellenőrző kérdések
Miért „éri meg” a jelszó-hash lassúsága, és mibe kerül ez a szervernek?
Mikor előnyös egyszerre a teljesítményre és a költségre a gyorsítótár, és mikor kockázatos?
Melyik négy kérdést tesszük fel egy tervezési döntésnél?
Teljesítmény, biztonság és költség: kompromisszumok
Célok
A lecke végére meg tudod mutatni konkrét példán, hogy a teljesítmény, a biztonság és a költség célja hol erősíti és hol gyengíti egymást, ismered a döntés négy nézőpontját, és tudod, hogyan lehet egy döntést mérhető követelménnyé és rövid indoklássá alakítani.
Három cél, egy rendszer
Egy időpontfoglaló rendszernél könnyű kimondani, hogy az oldal legyen gyors, biztonságos és olcsó. A három szó azonban nem ugyanazt jelenti, és nem mindig erősítik egymást.
flowchart TD D[Tervezési döntés] --> P[Teljesítmény] D --> B[Biztonság] D --> K[Költség] P --> U[Felhasználói feladat] B --> U K --> UMikor erősítik egymást, és mikor kell választani?
Nem minden döntés kényszerít választásra. A felesleges képek tömörítése például gyorsítja az oldalt, és költséget is csökkent (kevesebb adatforgalom). Sok helyzetben viszont az egyik cél javítása erőforrást kér a másiktól. Négy mért példa a kurzus eddigi leckéiből:
1. Jelszótárolás: a biztonság szándékos lassúsága
A 8.6 lecke mérése szerint a lassú jelszó-hash (scrypt) egy belépésnél kb. 173 ms processzoridőt kér egy magon (3457 ms / 20 próba), míg a gyors SHA-256 mikroszekundumokat. Ez a lassúság a védelem lényege: a támadónak is ennyi jut egy tippre. De a szervernek is: 100 belépés/s esetén ez kb. 17 mag folyamatos terhelése, vagyis hardver (költség), és a belépéskori válaszidő (teljesítmény) is nő. A biztonsági nyereségért itt tudatosan fizetünk teljesítménnyel és költséggel; a belépési korlát (10.5) pedig a költséget is védi a tömeges próbálkozástól.
2. Titkosítás: a HTTPS ára
A 4.5 lecke mérése szerint a TLS-kézfogás kb. 17 ms-ot adott a kapcsolatfelépítéshez egy közeli szerverrel. Ez kicsi, és az újrahasznált kapcsolat (4.2) a második kéréstől már nem fizeti meg. Cserébe a forgalom titkos és hitelesített (4.3). Ez az az eset, ahol a biztonság ára elenyésző a védelem értékéhez képest.
3. Gyorsítótár: sebesség és költség, de adatvédelmi kockázat
A 10.4 lecke szerint a gyorsítótár csökkenti a válaszidőt és a szerverterhelést (a
304olcsó), és ezzel költséget is spórol. A rosszul beállított megosztott gyorsítótár viszont Béla képernyőjére tette Anna adatait. Itt a teljesítmény és a költség nyeresége a biztonságot és az adatvédelmet kockáztatja, ha a szabály pontatlan: a gyorsítótár nem „bekapcsolandó gyorsítás”, hanem szabályokkal körülírt döntés: mit, kinek, mennyi ideig szabad újra felhasználni?4. CDN: közelség, terhelés és szerződés
A felhasználókhoz közeli CDN rövidebb késleltetést adhat (4.6), és a csúcsot is jobban elviseli (10.5). Cserébe a szolgáltatás drágább és szerződésileg összetettebb lehet; érzékeny adatnál meg kell érteni, melyik fél mit kezel, milyen régióban, milyen jogalappal (9.6). Nem az a kérdés, hogy a CDN „jó-e”, hanem hogy a nyilvános képekhez, videókhoz és szoftverfájlokhoz indokolt-e, és milyen adatot nem szabad általa kiszolgálni.
Egy döntés négy nézőpontja
Hasznos, ha egy tervezési kérdésnél ugyanazt a négy kérdést tesszük fel:
Ez a gondolkodás segít elkerülni a hangzatos, de üres válaszokat: „tegyünk mindent felhőbe”, „legyen mikroszolgáltatás”, „titkosítsunk mindent” vagy „legyen nagyon gyors”. Ezeknek a mondatoknak csak akkor van értelmük, ha megmondjuk: pontosan mit, miért, milyen fenyegetés ellen, milyen felhasználói elvárással és milyen költséggel.
Funkciónként különböző döntés: terméklista és fizetés
Egy webáruház terméklistája sok ember számára azonos információ: terméknév, kép, rövid leírás. Az ilyen oldal jól gyorsítótárazható és CDN-en át kiszolgálható (10.4); a gyors betöltés csökkenti a szerverterhelést, így a teljesítmény és a költség célja együtt javulhat. A fizetési folyamat más természetű: itt felhasználóhoz kötött kosár, cím, fizetési állapot és megrendelés szerepel (
Cache-Control: no-storevagyprivate, 10.4). Nem fogadható el, hogy egy „rendelés sikeres” oldal egy korábban tárolt válaszból érkezzen. A fizetésnél fontosabb, hogy minden kérés érvényesítve, naplózhatóan és egyértelmű eredménnyel fusson le (10.2: idempotenciakulcs), még ha ez több adatbázis-műveletet és valamivel hosszabb válaszidőt jelent is.A jó tervezés tehát nem az egész rendszerre választ egyetlen szintet: funkciónként különböztet. A nyilvános, ritkán változó tartalom agresszívebben gyorsítható; a személyes és visszafordíthatatlan műveletek szigorúbb ellenőrzést kapnak.
Biztonság, amely nem csak lassítás
Gyakori félreértés, hogy a biztonság szükségszerűen lassítja a rendszert. Van költsége (titkosított kapcsolat, bemenet-ellenőrzés, jogosultság, naplózás), de ez általában elenyésző egy adatvédelmi incidens vagy jogosulatlan tranzakció helyreállításához képest. A biztonságos kialakítás néha a teljesítményt is javítja: a jól meghatározott jogosultsági határok és az adatminimalizálás csökkenthetik, mennyi adatot kell egy válaszban elküldeni; a megfelelően méretezett sebességkorlátozás (10.5) megvédi a szolgáltatást a hibás vagy rosszindulatú forgalomtól, így a valódi felhasználók elérhetőségét javítja. A cél nem a védelem elhagyása a gyorsaságért, hanem a kockázathoz illő védelem.
Költség: az olcsó nem mindig takarékos
Egy kis egyetemi projektnek túlzás lehet a több régióban működő, automatikusan skálázódó infrastruktúra: sok pénz, tanulás és karbantartás, miközben az oldalt naponta néhány tucat ember használja. Egy egyszerűbb, megbízhatóan mentett és megfigyelt szolgáltatás gyakran jobb döntés. Fordítva: ha egy vizsgajelentkezés pontos időpontban több ezer hallgatót vonz, az alulméretezett rendszer olcsósága látszólagos. A leállás ügyfélszolgálati terhelést, bizalomvesztést, méltányossági problémát és rendkívüli munkát okoz; a költségbecslésnek az elmaradt szolgáltatás árát is tartalmaznia kell (10.1: hibakeret).
Az egyszerűség is érték. Minden új komponens (külön adatbázis, üzenetsor, gyorsítótár-réteg, külső identitásszolgáltató) megold egy problémát, de új hibalehetőséget, függőséget és tudásigényt hoz. Nem az a cél, hogy kevés technológia legyen, hanem hogy minden technológiának világos oka és gazdája legyen.
Hogyan születik védhető döntés?
Egy rövid döntési jegyzet sokat ér. Például: „A nyilvános eseménylista válaszait öt percig gyorsítótárazzuk (
public, max-age=300), mert az adat nem személyes, ritkán változik, és a regisztráció megnyitásakor csúcsforgalom várható. A foglalási és fiókoldalakat nem osztott gyorsítótárból szolgáljuk ki (private), mert személyes, gyorsan változó adatot tartalmaznak.” Ez megnevezi a döntést, a célt, a kockázatot és a határt.Végigvezetett példa: a Kurzuspont döntési táblázata
public, max-age=300(6.4, 10.4)no-storeLátható: a döntés funkciónként más, és mindegyik mögött kimondott indoklás van.
Gyakori tévhitek
Röviden
Ellenőrző kérdések
Tanulási források