A lecke végére meg tudod magyarázni, miért súlyosbodik magától a túlterhelés, ismered a védekezés eszközeit (sebességkorlátozás, várakozási sor, fokozatos szolgáltatáscsökkentés), és el tudod különíteni a megfigyelhetőség három jelét: a naplót, a metrikát és a trace-t.
Miért nem elég „több szervert indítani”?
Egy webáruház normál hétköznapon másodpercenként néhány tucat kérést fogad. Akció kezdetekor vagy egy népszerű koncert jegyértékesítésekor azonban néhány perc alatt ezrek próbálhatják ugyanazt a műveletet elvégezni. Nemcsak az oldalletöltések száma nő: sokan frissítenek, bejelentkeznek, kosárba tesznek, fizetést indítanak. A rendszer különböző részei másként reagálnak. A 10.3 leckében láttuk, hogy a kapacitás közelében a válaszidő térdszerűen romlik. Most azt vizsgáljuk, mit tehetünk akkor, ha a terhelés mégis eléri vagy túllépi a határt.
Csúcsforgalom: miért súlyosbodik magától a hiba?
Egy lassú oldalra a felhasználó gyakran újra rákattint vagy frissít. Egy kliens automatikusan újrapróbálhat egy sikertelen kérést. Ez érthető viselkedés, de egy már túlterhelt rendszert tovább terhel. Ha a háttérszolgáltatás lassú, az alkalmazásszerver több megnyitott kérést tart életben, több memóriát fogyaszt, és végül más, még működő funkciók is lelassulnak.
flowchart LR
U[Sok egyidejű kérés] --> G[Belépési korlát]
G --> Q[Várakozási sor]
Q --> S[Elsődleges művelet]
S --> M[Mérőszámok és naplók]
M --> D[Döntés a kapacitásról]
Sebességkorlátozás (rate limit)
A sebességkorlátozás (rate limit) azt szabályozza, hogy egy kliens, felhasználó, IP-cím vagy hozzáférési token adott idő alatt hány kérést küldhet. Nem csak támadások miatt kell: egy hibás program percenként ezerszer is meghívhat egy API-t; egy népszerű nyitási pillanatban pedig ugyanaz a személy folyamatos frissítéssel ronthatja mások esélyét.
A korlátozás tervezésekor két kérdést kell elválasztani: kit azonosítunk (felhasználó, token, IP-cím), és mit védünk (a bejelentkezési végpont a jelszópróbálgatás miatt szigorúbb, egy nyilvános kép engedékenyebb lehet). A válasznak világosnak kell lennie: az RFC 6585 szerint a 429 Too Many Requests a kliens által túl sok kérést jelzi adott időn belül, és a válasz tartalmazhat Retry-After fejlécet is, amely megmondja, mikor próbálkozhat újra. Kipróbálva egy kliensenként 10 másodpercenként 5 kérést engedő szerveren:
1–5. kérés : 200
6. kérés : 429
7. kérés : 429
HTTP/1.1 429 Too Many Requests
Content-Type: application/problem+json
Retry-After: 10
{"type":"about:blank","title":"Túl sok kérés","status":429,
"detail":"10 másodpercenként legfeljebb 5 kérés engedélyezett."}
Másik kliens (bela) ugyanekkor: 200
A korlát kliensenként működik: Béla kérései nem számítanak Anna korlátjába. A válasz a 10.2-ben látott hibaformát használja, így a kliens géppel is érti, mennyit kell várnia.
A rate limit nem büntetés, hanem a közös erőforrás szervezése. Rossz kialakítás esetén azonban igazságtalan: egy egyetemi hálózat sok hallgatója ugyanazon külső IP-cím mögött jelenhet meg, ezért az IP-cím alapú korlát őket együtt sújtja. A tervezőnek értenie kell a következményt, nem csak bekapcsolni a kapcsolót.
Várakozási sorok (queue)
Egyes műveletekhez a felhasználó azonnali választ vár: belépés, kosárba helyezés, fizetés visszaigazolása. Mások késhetnek: számla vagy visszaigazoló e-mail küldése, nagy kép feldolgozása, értesítések kiküldése, keresőindex frissítése. A várakozási sor (queue) ez utóbbi munkákat leválasztja a közvetlen kérésről. A webalkalmazás gyorsan elfogadja a feladatot, majd egy háttérfolyamat később, a saját tempójában dolgozza fel.
Egy feltöltött videónál rossz élmény volna, ha a böngésző addig várna, amíg minden változat elkészül. A rendszer inkább visszajelezhet: „A feltöltés sikerült, a feldolgozás folyamatban van.” Ez javítja a válaszkészséget és kisimítja a terhelést. Cserébe meg kell tervezni a késést, az esetleges sikertelen feldolgozást és azt, hogy egy feladat kétszer futva se okozzon kétszeres hatást (idempotencia, 2.3 és 10.2).
A fokozatos szolgáltatáscsökkentés (graceful degradation) azt jelenti, hogy hiba vagy túlterhelés esetén a rendszer nem egyetlen pillanatban válik használhatatlanná. Először a kevésbé fontos funkciókat korlátozza, egyszerűbb nézetet ad, vagy későbbi feldolgozást ajánl. A legfontosabb feladatokat próbálja megőrizni. Egy jegyértékesítő rendszernél például átmenetileg kikapcsolható a személyre szabott ajánlórendszer, kevesebb képet tölthet be az oldal, és a keresés helyett előre definiált kategóriák jelenhetnek meg. Az alapvető cél (a jegyek korrekt kiválasztása és megvásárlása) előnyt kap. Ha a készletinformáció nem garantálható, a rendszernek őszintén kell kommunikálnia, nem szabad hamis ígérettel elkérnie a fizetést.
Ez nem a minőség feladása, hanem a prioritások tudatosítása. A tervezéskor meg kell kérdezni: mi a szolgáltatás minimálisan elfogadható működése? Mely adatnak kell pontosnak lennie? Mi várhat? Mit lehet ideiglenesen elrejteni? A válasz üzleti, felhasználói és etikai kérdés is.
Megfigyelhetőség: honnan tudjuk, mi történik?
Egy összetett webes rendszer állapota nem látható közvetlenül. A felhasználó annyit mond: „lassú” vagy „nem sikerült a fizetés”. A megfigyelhetőség (observability) az OpenTelemetry meghatározása szerint azt jelenti, hogy a rendszert kívülről, a belsejének ismerete nélkül, kérdések feltevésével meg tudjuk érteni, és új, váratlan problémákat is ki tudunk vizsgálni. Ehhez az alkalmazásnak telemetriai jeleket kell kibocsátania. A három alapvető jel:
Jel
Mi ez?
Mire jó?
Példa
Napló (log)
Időbélyeges, konkrét események feljegyzése
A részletes ok kiderítése egy adott eseményre
„14:02:11 – a jelentkezés mentése időtúllépéssel hibázott, kérés: 8841”
Metrika (metric)
Időben összesített, számszerű érték
Trendek, rendellenességek észlelése, riasztás
kérés/s, hibaarány, p95 válaszidő, a sor hossza
Trace
Egy kérés útja a feldolgozó szolgáltatásokon át
Hol megy el az idő?
a jelentkezés: alkalmazás 20 ms, adatbázis 400 ms, fizetési szolgáltató 1,2 s
Az OpenTelemetry szerint a trace spanekből áll (egy-egy munkaegység, névvel, időmérésekkel és attribútumokkal); a gyökér span a teljes kérést fedi, a gyermek spanek a lépéseket. A naplók akkor a leghasznosabbak, ha egy trace-hez vagy spanhez kapcsolhatók.
A naplóba nem szabad felelőtlenül személyes adatot vagy jelszót írni (9.6, 8.6): a hasznosság és az adatvédelem egyensúlyt kíván. A metrikák kiválóak a trendekre: ha a hibaarány 0,1%-ról 8%-ra ugrik, az feltűnik akkor is, ha még nem tudjuk, melyik felhasználó melyik kérésénél volt a hiba. Az a naplóból és a trace-ből derül ki. A megfigyelhetőség a 8. fejezet felé is kapcsolódik: az OWASP Top 10:2025 külön kategóriája a naplózási és riasztási hiba (8.7).
Riasztás: nem minden grafikon kér figyelmet
A riasztásnak cselekvést kell kiváltania. Ha egy csapat percenként tucatnyi jelentéktelen üzenetet kap, megszokja és figyelmen kívül hagyja őket (riasztási fáradtság). Jó riasztás ezért nem pusztán azt mondja, hogy egy gép processzora magas, hanem felhasználói hatáshoz kötődik: tartósan nő a sikertelen fizetések aránya, vagy a bejelentkezések p95 válaszideje meghalad egy küszöböt (10.1: SLI/SLO). Riasztást gyakran több jel együtt indokol: egy rövid forgalmi csúcs lehet normális, a növekvő késleltetés, hibaarány és sorhossz együtt már erős figyelmeztetés. A küszöbök nem örök értékek: a rendszer és az elvárás változásával felül kell vizsgálni őket.
Végigvezetett példa: a Kurzuspont tárgyfelvételi nyitása
Kilenc órakor megnyílik a tárgyfelvétel.
Eszköz
Mit csinál nyitáskor?
CDN (4.4, 10.4)
A főoldal statikus elemei nem terhelik az alkalmazást.
Sebességkorlátozás
A belépés korlátozott, így a jelszópróbálgatás és az agresszív újrapróbálás nem blokkol mindenkit; a korlát 429 + Retry-After választ ad.
Pontos kezelés
A tárgylista és a férőhely kritikus: a szerver dönt, hamis „van hely” ígéret nélkül.
Várakozási sor
A visszaigazoló e-mailek sorba kerülnek: a hallgató előbb a képernyőn látja a sikert, az e-mail később érkezik.
Fokozatos csökkentés
Túlterhelés esetén kikapcsolható a nem létfontosságú ajánlás és statisztika.
Megfigyelés
A metrikák: hibaarány, p95, adatbázis-kapcsolatok száma, sor hossza; a problémás kérés trace-ben vizsgálható; a részletek a naplóban kereshetők.
Riasztás
A sikeres jelentkezések aránya az SLO (10.1) alá esik → az ügyeletes értesül.
Így a rendszer nem csak reagál, hanem diagnosztizálható is.
Gyakori tévhitek
Állítás
Pontosítás
„Ha van monitoring, biztosan észrevesszük a hibát.”
Csak azt lehet észrevenni, amit mérünk, ha a jel értelmezhető és valaki reagál rá.
„A több szerver minden túlterhelést megold.”
Nem, ha az adatbázis, egy külső API vagy egy közös zárolás a szűk keresztmetszet.
„A rate limit csak a rosszindulatú támadókat érinti.”
Jóindulatú, de hibás klienst is érinthet; az üzenet és a szabály méltányossága számít.
„A fokozatos csökkentés azt jelenti, hogy hibásan működik a rendszer.”
Előre meghatározott, biztonságos korlátozás a kontrollálatlan hiba helyett.
„Minél több riasztás, annál biztonságosabb.”
A sok jelentéktelen riasztás fáradtságot okoz, és elnyomja a fontosat.
Röviden
A túlterhelés önmagát erősíti (újratöltés, újrapróbálkozás); előbb a szűk keresztmetszetet kell megtalálni.
Eszközök: sebességkorlátozás (429, Retry-After), várakozási sor, fokozatos szolgáltatáscsökkentés.
Terhelési csúcs és megfigyelhetőség
Célok
A lecke végére meg tudod magyarázni, miért súlyosbodik magától a túlterhelés, ismered a védekezés eszközeit (sebességkorlátozás, várakozási sor, fokozatos szolgáltatáscsökkentés), és el tudod különíteni a megfigyelhetőség három jelét: a naplót, a metrikát és a trace-t.
Miért nem elég „több szervert indítani”?
Egy webáruház normál hétköznapon másodpercenként néhány tucat kérést fogad. Akció kezdetekor vagy egy népszerű koncert jegyértékesítésekor azonban néhány perc alatt ezrek próbálhatják ugyanazt a műveletet elvégezni. Nemcsak az oldalletöltések száma nő: sokan frissítenek, bejelentkeznek, kosárba tesznek, fizetést indítanak. A rendszer különböző részei másként reagálnak. A 10.3 leckében láttuk, hogy a kapacitás közelében a válaszidő térdszerűen romlik. Most azt vizsgáljuk, mit tehetünk akkor, ha a terhelés mégis eléri vagy túllépi a határt.
Csúcsforgalom: miért súlyosbodik magától a hiba?
Egy lassú oldalra a felhasználó gyakran újra rákattint vagy frissít. Egy kliens automatikusan újrapróbálhat egy sikertelen kérést. Ez érthető viselkedés, de egy már túlterhelt rendszert tovább terhel. Ha a háttérszolgáltatás lassú, az alkalmazásszerver több megnyitott kérést tart életben, több memóriát fogyaszt, és végül más, még működő funkciók is lelassulnak.
flowchart LR U[Sok egyidejű kérés] --> G[Belépési korlát] G --> Q[Várakozási sor] Q --> S[Elsődleges művelet] S --> M[Mérőszámok és naplók] M --> D[Döntés a kapacitásról]Sebességkorlátozás (rate limit)
A sebességkorlátozás (rate limit) azt szabályozza, hogy egy kliens, felhasználó, IP-cím vagy hozzáférési token adott idő alatt hány kérést küldhet. Nem csak támadások miatt kell: egy hibás program percenként ezerszer is meghívhat egy API-t; egy népszerű nyitási pillanatban pedig ugyanaz a személy folyamatos frissítéssel ronthatja mások esélyét.
A korlátozás tervezésekor két kérdést kell elválasztani: kit azonosítunk (felhasználó, token, IP-cím), és mit védünk (a bejelentkezési végpont a jelszópróbálgatás miatt szigorúbb, egy nyilvános kép engedékenyebb lehet). A válasznak világosnak kell lennie: az RFC 6585 szerint a
429 Too Many Requestsa kliens által túl sok kérést jelzi adott időn belül, és a válasz tartalmazhatRetry-Afterfejlécet is, amely megmondja, mikor próbálkozhat újra. Kipróbálva egy kliensenként 10 másodpercenként 5 kérést engedő szerveren:A korlát kliensenként működik: Béla kérései nem számítanak Anna korlátjába. A válasz a 10.2-ben látott hibaformát használja, így a kliens géppel is érti, mennyit kell várnia.
A rate limit nem büntetés, hanem a közös erőforrás szervezése. Rossz kialakítás esetén azonban igazságtalan: egy egyetemi hálózat sok hallgatója ugyanazon külső IP-cím mögött jelenhet meg, ezért az IP-cím alapú korlát őket együtt sújtja. A tervezőnek értenie kell a következményt, nem csak bekapcsolni a kapcsolót.
Várakozási sorok (queue)
Egyes műveletekhez a felhasználó azonnali választ vár: belépés, kosárba helyezés, fizetés visszaigazolása. Mások késhetnek: számla vagy visszaigazoló e-mail küldése, nagy kép feldolgozása, értesítések kiküldése, keresőindex frissítése. A várakozási sor (queue) ez utóbbi munkákat leválasztja a közvetlen kérésről. A webalkalmazás gyorsan elfogadja a feladatot, majd egy háttérfolyamat később, a saját tempójában dolgozza fel.
Egy feltöltött videónál rossz élmény volna, ha a böngésző addig várna, amíg minden változat elkészül. A rendszer inkább visszajelezhet: „A feltöltés sikerült, a feldolgozás folyamatban van.” Ez javítja a válaszkészséget és kisimítja a terhelést. Cserébe meg kell tervezni a késést, az esetleges sikertelen feldolgozást és azt, hogy egy feladat kétszer futva se okozzon kétszeres hatást (idempotencia, 2.3 és 10.2).
Fokozatos szolgáltatáscsökkentés (graceful degradation)
A fokozatos szolgáltatáscsökkentés (graceful degradation) azt jelenti, hogy hiba vagy túlterhelés esetén a rendszer nem egyetlen pillanatban válik használhatatlanná. Először a kevésbé fontos funkciókat korlátozza, egyszerűbb nézetet ad, vagy későbbi feldolgozást ajánl. A legfontosabb feladatokat próbálja megőrizni. Egy jegyértékesítő rendszernél például átmenetileg kikapcsolható a személyre szabott ajánlórendszer, kevesebb képet tölthet be az oldal, és a keresés helyett előre definiált kategóriák jelenhetnek meg. Az alapvető cél (a jegyek korrekt kiválasztása és megvásárlása) előnyt kap. Ha a készletinformáció nem garantálható, a rendszernek őszintén kell kommunikálnia, nem szabad hamis ígérettel elkérnie a fizetést.
Ez nem a minőség feladása, hanem a prioritások tudatosítása. A tervezéskor meg kell kérdezni: mi a szolgáltatás minimálisan elfogadható működése? Mely adatnak kell pontosnak lennie? Mi várhat? Mit lehet ideiglenesen elrejteni? A válasz üzleti, felhasználói és etikai kérdés is.
Megfigyelhetőség: honnan tudjuk, mi történik?
Egy összetett webes rendszer állapota nem látható közvetlenül. A felhasználó annyit mond: „lassú” vagy „nem sikerült a fizetés”. A megfigyelhetőség (observability) az OpenTelemetry meghatározása szerint azt jelenti, hogy a rendszert kívülről, a belsejének ismerete nélkül, kérdések feltevésével meg tudjuk érteni, és új, váratlan problémákat is ki tudunk vizsgálni. Ehhez az alkalmazásnak telemetriai jeleket kell kibocsátania. A három alapvető jel:
Az OpenTelemetry szerint a trace spanekből áll (egy-egy munkaegység, névvel, időmérésekkel és attribútumokkal); a gyökér span a teljes kérést fedi, a gyermek spanek a lépéseket. A naplók akkor a leghasznosabbak, ha egy trace-hez vagy spanhez kapcsolhatók.
A naplóba nem szabad felelőtlenül személyes adatot vagy jelszót írni (9.6, 8.6): a hasznosság és az adatvédelem egyensúlyt kíván. A metrikák kiválóak a trendekre: ha a hibaarány 0,1%-ról 8%-ra ugrik, az feltűnik akkor is, ha még nem tudjuk, melyik felhasználó melyik kérésénél volt a hiba. Az a naplóból és a trace-ből derül ki. A megfigyelhetőség a 8. fejezet felé is kapcsolódik: az OWASP Top 10:2025 külön kategóriája a naplózási és riasztási hiba (8.7).
Riasztás: nem minden grafikon kér figyelmet
A riasztásnak cselekvést kell kiváltania. Ha egy csapat percenként tucatnyi jelentéktelen üzenetet kap, megszokja és figyelmen kívül hagyja őket (riasztási fáradtság). Jó riasztás ezért nem pusztán azt mondja, hogy egy gép processzora magas, hanem felhasználói hatáshoz kötődik: tartósan nő a sikertelen fizetések aránya, vagy a bejelentkezések p95 válaszideje meghalad egy küszöböt (10.1: SLI/SLO). Riasztást gyakran több jel együtt indokol: egy rövid forgalmi csúcs lehet normális, a növekvő késleltetés, hibaarány és sorhossz együtt már erős figyelmeztetés. A küszöbök nem örök értékek: a rendszer és az elvárás változásával felül kell vizsgálni őket.
Végigvezetett példa: a Kurzuspont tárgyfelvételi nyitása
Kilenc órakor megnyílik a tárgyfelvétel.
429+Retry-Afterválaszt ad.Így a rendszer nem csak reagál, hanem diagnosztizálható is.
Gyakori tévhitek
Röviden
429,Retry-After), várakozási sor, fokozatos szolgáltatáscsökkentés.Ellenőrző kérdések
429és aRetry-After?Tanulási források
429meghatározása.