Nginx HTTP proxyzás, terheléselosztás, pufferelés és gyorsítótárazás: áttekintés

Bevezetés

Nginx egy nagy teljesítményű webszerver, amelyet fordított proxyként, levelezési proxyként, terheléselosztóként és HTTP-gyorsítótárként is használnak. Az Nginx ingyenes és nyílt forráskódú, így bárki letöltheti és használhatja a szerverkörnyezetében.

Lehet, hogy már használta az Nginx-et webhelyek kiszolgálására. Ebben az útmutatóban az Nginx egyéb képességeit fogjuk megvitatni. A HTTP proxyzás képessége lehetővé teszi az Nginx számára, hogy a kéréseket feldolgozásra továbbítsa a háttér-HTTP-szervereknek. Ezzel a funkcióval több háttérszervert is beállíthat. Lehetővé teszi az infrastruktúra igény szerinti skálázását az ügyfélkérések megugrásának kezelésére.

Ahogy haladunk az útmutatóval, megismerheti az infrastruktúra skálázását az Nginx terheléselosztási tulajdonságai, a pufferelés és a válaszok gyorsítótárazása segítségével, hogy javítsa a szerver teljesítményét, valamint jobb élményt biztosítson az ügyfelek számára. Kezdjük el!

Mindenekelőtt, az Nginx használatának megkezdéséhez tekintse meg az Nginx Ubuntu szerverre történő telepítéséről szóló útmutatónkat.

Általános információk a proxyzásról

Ha a webszerverekkel kapcsolatos ismeretei csak a webhelykérések feldolgozására és a weboldalak kiszolgálására korlátozódnak, felmerülhet Önben a kérdés, hogy miért van szükség a kérések proxyzására. Az alábbiakban elmagyarázzuk ennek okait.

Az egyik ok, amiért érdemes a kéréseket más szerverekre proxyzni az Nginx-ből, az infrastruktúra skálázhatóságának támogatása. Az Nginx alapértelmezés szerint sok kapcsolatot kezel egyidejűleg. Ez tökéletessé teszi arra, hogy az ügyfelek első kapcsolattartási pontja legyen. Ezután továbbíthatja a kéréseket a különböző háttérszervereknek, hogy azok végezzék el az ügyfélkérések tényleges feldolgozását. Ez az, ami elosztja a terhelést. Ezáltal biztosítja, hogy az infrastruktúrát a lehető legnagyobb mértékben skálázhassa. Lehetővé teszi azt is, hogy egyes szervereket leállítson karbantartás céljából, miközben a többi továbbra is kiszolgálja a kéréseket.

A második ok, amiért érdemes lehet a kéréseket más szerverekre proxyzni, az az, amikor olyan alkalmazásszervereket használ, amelyek éles környezetben nem alkalmasak az ügyfelektől érkező kérések közvetlen kezelésére. Számos keretrendszer, beleértve a webszervereket is, nem alkalmas olyan nagy teljesítményre, mint az Nginx. Ha hagyja, hogy az Nginx legyen a belépési pont, és proxyzza a kéréseket ezekre az alacsony teljesítményű szerverekre, azzal jobb élményt biztosíthat a felhasználóknak. Emellett fokozott biztonságot is garantálhat az alkalmazása számára.

A kérések proxyzásának folyamata az Nginx-ben magában foglalja az Nginx szervertől érkező kérés módosítását és továbbítását más háttérszervereknek a tényleges feldolgozás érdekében. Miután a többi háttérszerver feldolgozta a kérést, visszaküldik az eredményt az Nginx-nek. Ezután az Nginx elküldi az eredményt válaszként az ügyfélnek. Az ügyfél ebben az esetben egy webböngésző vagy akár egy mobil webalkalmazás. A többi háttérszerver lehet olyan helyi szerver, amely az interneten nyilvánosan nem érhető el, távoli szerver, vagy akár más virtuális szerver az Nginx szerverblokk-konfigurációkon belül. Ezeket a szervereket, amelyekre az Nginx a kéréseket proxyzza, upstream szervereknek nevezzük..

Az Nginx képes kéréseket proxyzni olyan szerverekre, amelyek több különböző protokoll használatával kommunikálnak, beleértve a HTTP(S)-t, a Memcached, SCGI, FastCGI, valamint az uWSGI protokollokat. Minden protokolltípushoz tartoznak direktívakészletek. Ebben az útmutatóban a HTTP-protokollra összpontosítunk. Az Nginx elemzi a kéréseket és az üzenetösszetevőket, majd olyan formátumba alakítja őket, amelyet az upstream szerver értelmezni és feldolgozni képes.

Egy alapvető HTTP Proxy Pass elemzése

A legegyszerűbb proxy típus egy kérés továbbítását jelenti egyetlen olyan szerverre, amely HTTP-n keresztül kommunikál. Ezt a proxy típust általában „proxy pass”-ként emlegetik, és az Nginx konfigurációs fájljaiban a találóan elnevezett proxy_pass direktíva kezeli.

A proxy_pass direktíva a location blokkokon belül jelenik meg. Emellett a location kontextus blokkjaiban és a limit_except kontextusokban is megtalálható. Ha egy kérés megegyezik egy olyan location blokkal, amelyben proxy_pass direktíva található, a kérés a direktíva által meghatározott URL-re irányul. Alább látható egy példa egy konfigurációs részletre:

A fenti példában a 80-as portra érkező kérések a localhost:3000-re mennének:

A fenti képernyőkép az alapértelmezett Nginx oldalt mutatja, amikor megpróbálja elérni a localhost-ot. Miután újraindította az Nginx szervert az érvényben lévő proxy pass direktívával, az összes kérés a 3000-es portra fog menni. Egy demó alkalmazás fut a 3000-es porton, amelyet az alábbi képen láthat, és közvetlenül elérheti a localhost-ról a port megadása nélkül:

A következő példában nincs URI megadva a szerver végén a proxy_pass definícióban. Az ebbe a mintába illeszkedő definíciók esetében az ügyfél által kért URI változatlan formában kerül továbbításra az upstream szervernek.

Például, amikor ez a blokk egy /match/url/here kérést kezel, a kérés URI-ja a http://example.com/match/url/here címen fog eljutni az example.com szerverre.

Alább látható egy példa egy alternatív konfigurációs részletre:

Ahogy a fenti részletben látható, a proxy szerver végén egy URI szegmenst határoztunk meg new/url/prefix formájában. Ha URI-t határoz meg a proxy_pass definícióban, a kérésnek a location definíciónak megfelelő része kicserélődik erre az URI-ra, amikor a kérés feldolgozásra az upstream szerverre kerül.

Például az Nginx szerveren a /match/url/here kérés http://example.com/new/url/here formájában továbbítódik az upstream szerverre. A /match/url helyére a /new/url lép. Ezt a pontot tartsa szem előtt.

Bizonyos esetekben a fenti módon történő URI-továbbítás nem lehetséges. Ilyen esetekben az Nginx figyelmen kívül hagyja a proxy_pass definíció végén lévő URI-t. Végül vagy az ügyféltől érkező eredeti URI, vagy a más direktívák által módosított URI kerül továbbításra az upstream szervernek.

Példa erre, amikor reguláris kifejezések illeszkednek a location-re. Előfordulhat, hogy az Nginx nem tudja meghatározni, hogy az URI melyik része felelt meg a kifejezésnek. Ezért az eredeti ügyfélkérés URI-ját küldi el. Ez az ügyfél URI-jának átírását és kezelését okozza ugyanabban a blokkban. Ilyen esetben az átírt URI kerül továbbításra.

Hogyan dolgozza fel az Nginx a fejléceket?

A fejlécek kulcsfontosságúak a kérések szerver általi feldolgozásában. Egyes fejlécek hitelesítési információkat is tartalmazhatnak. Ezért meg kell értenünk, hogyan dolgozza fel az Nginx proxyzás a fejléceket. Az Nginx-től az upstream szerver felé irányuló proxy kérés másképp fog kinézni, mint az, amelyik közvetlenül az ügyféltől érkezett. A különbségek egy része a proxy kéréssel együtt járó fejlécekből adódik.

A kérés proxyzása során az Nginx módosítja az ügyféltől kapott kérésfejléceket. Ezen módosítások közé tartoznak a következők:

• Minden üres fejléc eltávolítása. Az üres fejlécek csak feleslegesen növelik a kérés méretét, így nincs értelme továbbítani őket az upstream szervernek.

• Az aláhúzásjelet tartalmazó fejlécek alapértelmezés szerint érvénytelennek minősülnek, ezért eltávolításra kerülnek a kérésből. Ha meg szeretné változtatni ezt a viselkedést, és engedélyezni szeretné az Nginx számára, hogy az aláhúzásjelet tartalmazó fejléceket érvényesként értelmezze, akkor az underscores_in_headers direktívát „on” értékre állíthatja. Ha ezt nem teszi meg, az ügyféltől érkező ilyen fejlécek soha nem érik el az upstream szervert.

• A „Host” fejléc átíródik a $proxy_host változó által meghatározott értékre. Ez az upstream szerver IP-címe vagy neve és portszáma, a proxy_pass direktívában meghatározottak szerint.

• A „Connection” fejléc értéke „close”-ra változik. A connection fejléc a két fél között létrejött konkrét kapcsolatról tartalmaz információkat. Amikor az Nginx az értékét close-ra állítja, azt jelzi az upstream szervernek, hogy a kapcsolat lezárul, miután az eredeti kérésre megérkezett a válasz, így nem kell tartós kapcsolatra számítania.

Íme néhány pont, amelyet megjegyezhetünk a fent vázolt proxy kérés fejléc-módosításaiból:

• Ha nem szeretné, hogy egy fejléc továbbításra kerüljön az upstream szerver felé, akkor egy üres karakterláncra való beállítása teljesen eltávolítja azt a kérésből.

• Ha az upstream szerveren futó alkalmazás nem szabványos fejléceket fog feldolgozni, győződjön meg arról, hogy a fejlécek nem tartalmaznak aláhúzásjelet. Opcionálisan beállíthatja az underscores_in_headers direktívát „on” értékre a konfigurációban (ez érvényes az IP-cím/port kombináció alapértelmezett szerverdeklarációjának kontextusában vagy a HTTP kontextusban is). Ez biztosítja, hogy a fejlécek ne legyenek érvénytelennek jelölve, és így ténylegesen továbbításra kerüljenek az upstream szerver felé.

• A „Host” fejléc rendkívül fontos a legtöbb proxyzási helyzetben. Alapértelmezés szerint a $proxy_host értékére van beállítva, amely egy olyan változó, ami a proxy_pass specifikációból kinyert tartománynevet vagy IP-címet és portot tartalmazza. Ez a cím alapértelmezés szerint van kiválasztva, és közvetlenül a kapcsolat információiból kerül lekérésre. Ez az egyetlen olyan cím, amelyre az Nginx garantálni tudja, hogy az upstream szerver válaszolni fog.

Az alábbiakban a „Host” fejléc leggyakoribb értékei láthatók:

• $host – egy változó, amely prioritási sorrendben a kérés sorából származó állomásnévre, az ügyfélkérésből származó „Host” fejlécre vagy a kérésnek megfelelő szervernévre van beállítva.

• $http_host – egy változó, amely a „Host” fejlécet az ügyfélkérésből származó „Host” fejlécre állítja be. Az ügyfél kérésében szereplő fejlécek az Nginx számára mindig elérhetők változókként. Ezek a változók egy $http_ előtaggal kezdődnek, amelyet a fejléc neve követ kisbetűvel. Bár a $http_host változó többnyire jól működik, ha az ügyfélkérésből hiányzik az érvényes „Host” fejléc, az a továbbítás sikertelenségét eredményezheti.

• $proxy_host – egy változó, amely a „Host” fejlécet a proxy_pass specifikációjából kinyert tartománynév vagy IP-cím és port kombinációra állítja be. Ez az Nginx szempontjából az alapértelmezett viselkedés, és ezért biztonságosnak tekinthető. Azonban előfordulhat, hogy a szervernek nem erre van szüksége a kérés megfelelő kezeléséhez.

A legtöbb konfigurációban a „Host” fejlécet a $host változóra állítják be. Ez rendkívül rugalmas, és pontosan kitöltött fejléceket biztosít az upstream szerver számára.

Fejlécek beállítása és módosítása

A proxy_set_header direktíva lehetővé teszi a fejlécek beállítását vagy módosítását a proxy kapcsolatokhoz. A korábban tárgyalt „Host” fejléc esetében a következőket tehetjük a proxyzott kéréseknél megszokott további fejlécek módosítására és hozzáadására:

A fenti konfigurációs részletben a „Host” fejlécet a $host változóra állítjuk be, amely a kért eredeti állomásról tartalmaz információkat. Az X-Forwarded-Proto fejlécet az ügyféltől érkező eredeti kérés sémájára (ez lehet HTTP vagy HTTPS kérés) vonatkozó információkkal állítjuk be.

Az ügyfél tényleges IP-címét adjuk át az X-Real-IP-nek. Ez lehetővé teszi az upstream szerver számára, hogy az ügyfél IP-eredete alapján hozzon megfelelő döntéseket vagy tárolja a naplókat. Az X-Forwarded-For fejléc tartalmazza az összes olyan szerver IP-címének listáját, amelyeken az ügyfél keresztülhaladt (proxyzva lett), mielőtt elérte ezt a pontot. A fenti kódrészletben ezt a $proxy_add_x_forwarded_for változóra állítjuk be. Ez a változó átveszi az ügyféltől kapott eredeti X-Forwarded-For fejléc értékét, és a végéhez fűzi az Nginx proxy szerver IP-címét.

Ha azt szeretné, hogy a proxy_set_header direktívákra egynél több helyen (location) is hivatkozzanak, áthelyezheti azokat a server vagy http kontextusba. Tekintse meg az alábbi konfigurációs részletet:

Upstream kontextus definiálása a proxizott kapcsolatok terheléselosztásához

Eddig megértette, hogyan kell egy egyszerű http proxyt beállítani egyetlen backend upstream szerverhez. Szerencsére az Nginx segítségével skálázhatja ezt a konfigurációt úgy, hogy backend szerverek csoportjait (pool) határozza meg, amelyeknek átadhatja a kéréseket feldolgozásra.

Az Nginx biztosít egy upstream nevű direktívát, amely szerverek csoportjának meghatározására szolgál. A direktíva konfigurációján belül csak olyan szervereket szabad megadnia, amelyek képesek kiszolgálni az ügyfél kérését. Az Nginx mint proxyszerver minimális erőfeszítéssel teszi lehetővé az infrastruktúra skálázását. Az upstream direktívát az Nginx konfiguráció http kontextusán belül kell megadni.

Íme egy példa, amely bemutatja az upstream direktívát:

A fenti konfigurációs kódrészletben meghatároztunk egy several_backend_hosts nevű upstream kontextust. A definiált kontextusnév mostantól elérhető a proxy pass-okon belül. Úgy használható, mintha egy normál domain lenne, ahogy a példában is látható. A server blokkon belül az example.com/proxy-me/… címre érkező összes kérést átirányítjuk az upstream direktívával meghatározott csoportba, jelen esetben a several_backend_hosts-ba. A csoporton belül egy konfigurálható algoritmus alapján kerül kiválasztásra egy gazdagép a bejövő kérések kezelésére. Alapértelmezés szerint a kiválasztás egy round-robin (körforgásos) folyamatot követ – minden kérés sorban egy másik gazdagéphez kerül átirányításra.

Hogyan változtassuk meg az upstream terheléselosztási algoritmust

Ahogy fentebb kiemeltük, a kiválasztási folyamat egy round-robin folyamatot követ. Ebben a részben megvizsgáljuk, hogyan módosíthatjuk az upstream csoport által használt terheléselosztási algoritmust. Az algoritmus módosításához más direktívákat vagy jelzőket (flags) kell megadnia az upstream kontextuson belül, az alábbiak szerint:

• (round-robin) – ha nincs más upstream terheléselosztási direktíva megadva, akkor alapértelmezés szerint az upstream kontextusban meghatározott összes szerver egymás után, sorban kapja meg a kéréseket.

• least_conn – ez a direktíva arra utasítja az upstream-et, hogy azt a backend szervert válassza ki, amelyik a legkevesebb aktív kapcsolattal rendelkezik. Ez olyan helyzetekben hasznos, amikor az egyik backend szerverhez való kapcsolódás hosszabb ideig is eltarthat.

• hash – ez a direktíva gyakori a memcached proxizásnál. A kapcsolatok egy véletlenszerűen megadott hash kulcs értéke alapján kerülnek átadásra a backend szervereknek. A hash kulcs értéke lehet változó, szöveg vagy a kettő kombinációja. A hash az egyetlen olyan terheléselosztási módszer, amelyhez a felhasználóknak meg kell adniuk a hash-hez használandó kulcsot.

• ip_hash – ez a direktíva arra utasítja az upstream-et, hogy a kéréseket az ügyfél IP-címe alapján ossza el a különböző szerverek között. Az IP-cím első három oktettje a kulcs annak meghatározásához, hogy melyik szervernek kell feldolgoznia a kérést. Ennek a direktívának az az előnye, hogy az ügyfelek általában ugyanazt a szervert érik el minden alkalommal, így biztosítva a munkamenet (session) konzisztenciáját.

Íme egy példa arra, hogyan adhatjuk hozzá a terheléselosztási algoritmus direktívát az upstream kontextushoz:

A fenti kódrészletben az Nginx a legkevesebb kapcsolattal rendelkező szerverek közül választ egyet a beérkező kérés feldolgozásához. Az ip_hash direktíva ugyanezt a szintaxist követi. A hash direktíva esetében meg kell adnia egy tetszőleges kulcsot, amely alapján a hash elkészül, íme egy példa:

Az itt használt hash az ügyfél IP-címének és portjának eredménye lesz. Az opcionális consistent paraméter a ketama konzisztens hashing algoritmust valósítja meg. Ez minimális hatást biztosít a gyorsítótárra, ha megváltoztatja az upstream szervereket.

Hogyan határozzuk meg a szerverek súlyát a terheléselosztáshoz

Alapértelmezés szerint a háttérszerverek deklarálásakor minden szerver egyenlő súlyozást kap. Feltételezzük, hogy minden szerver rendelkezik az azonos mennyiségű terhelés kezeléséhez szükséges erőforrásokkal és képességekkel, természetesen ezt az upstream kontextusban megadott terheléselosztási algoritmus figyelembevételével. Ezen alapértelmezett viselkedés megváltoztatásához a deklaráció során alternatív súlyt állíthat be az egyes szerverekhez. Lássunk egy példát:

Ebben a példában a host1.example.com kétszer akkora forgalmat fog kapni, mint a másik két szerver. Az egyes szerverek súlya alapértelmezés szerint egy.

Háttérszerverek felszabadítása pufferekkel

Miközben a proxyzást konfigurálja a szerverkonfigurációban, aggódhat amiatt, hogy a további szerverek hozzáadása milyen hatással lesz a teljesítményre. Szerencsére az Nginx olyan pufferelési és gyorsítótárazási funkciókkal rendelkezik, amelyek segíthetnek enyhíteni ezeket a teljesítményproblémákat.

Két különböző kapcsolat sebessége biztosan befolyásolja az ügyfél élményét, amikor egy másik szerverre irányítja át a forgalmat:

• Az első kapcsolat az ügyféltől az Nginx proxyig tart.

• A második kapcsolat az Nginx proxytól a háttér upstream szerverig tart.

Az Nginx szükség szerint módosíthatja a viselkedését, hogy segítsen optimalizálni bármelyik kapcsolatot.

Ha eltávolítjuk a puffereket, az upstream háttérből származó adatok továbbítása azonnal megkezdődik az ügyfél felé az Nginx proxynál. Ha tudja, hogy az ügyfelei gyorsak, teljesen kikapcsolhatja a pufferelést, hogy az adatok elég gyorsan eljussanak az ügyfélhez. Ha a pufferek be vannak kapcsolva, az Nginx proxy ideiglenesen tárolja a háttér upstream szervertől kapott válaszadatokat. Ezután a sebességüktől függően küldi el az adatokat az ügyfélnek. Amint az Nginx pufferében van a válasz, lezárhatja a kapcsolatot a háttérszerverrel. Ezután az ügyfél által támogatott sebességgel továbbítja az adatokat az ügyfélnek. Ezzel egyidejűleg lehetővé teszi a háttérszerver számára, hogy folytassa a többi beérkező kérés feldolgozását.

Alapértelmezés szerint az Nginx pufferelése be van kapcsolva. Ennek az az oka, hogy nem tudhatjuk az ügyfelek kapcsolati sebességét. Az ügyfelek általában különböző, esetleg lassabb kapcsolatokkal rendelkeznek. Az alábbiakban meghatározzuk azokat a különféle direktívákat, amelyeket megadhatunk az Nginx pufferelési viselkedésének beállításához. A direktívák megadhatók a http, server vagy location kontextusokban, azonban vegye figyelembe, hogy a méretezési direktívák kérésenként vannak konfigurálva. Ezért ezeknek a feltétlenül szükségesnél nagyobb mértékű növelése befolyásolhatja a szerver teljesítményét, ha túl sok beérkező ügyfélkérés érkezik. Íme a direktívák:

• proxy_buffering – az az irányelv, amely szabályozza, hogy a pufferelés aktív-e egy adott kontextus és gyermekkontextusai esetében. A proxy_buffering alapértelmezett konfigurációja „on”.

• proxy_buffer_size – az az irányelv, amely meghatározza a backend kiszolgálótól érkező válaszban található fejlécek tárolására szolgáló puffer méretét. A fejlécek a backend kiszolgáló válaszának első részét alkotják. Ezen fejlécek pufferelése a válasz többi részétől elkülönítve történik. Alapértelmezés szerint ennek a puffernek a beállított mérete megegyezik a proxy_buffers méretével. Ha azonban a fejléc-információ kicsi, a méretet alacsonyabb értékre is beállíthatja.

• proxy_buffers – a proxyzott válaszok puffereinek számát (első argumentum) és méretét (második argumentum) szabályozó irányelv. Az alapértelmezett konfiguráció 8 puffert határoz meg, amelyek mérete megegyezik egy memórialappal (vagy 4k, vagy 8k). A pufferek számának növelésével több információ pufferelését teheti lehetővé.

• proxy_max_temp_file_size – az az irányelv, amely meghatározza a lemezen lévő ideiglenes fájlok maximális méretét kérésenként. Ideiglenes fájlok akkor jönnek létre, ha az upstream válasz túl nagy ahhoz, hogy elférjen egy pufferben.

• proxy_busy_buffers_size – az az irányelv, amely meghatározza a „kliens-kész” (client-ready) és így foglaltként kezelhető pufferek maximális méretét. A kliens egyszerre csak egy pufferből tudja olvasni az adatokat. A pufferek azonban egy sorban állnak, hogy kötegekben küldjék el őket a kliensnek. Ennek az irányelvnek a módosításával meghatározhatja az ebben az állapotban engedélyezett pufferterület méretét.

• proxy_temp_file_write_size – az az irányelv, amely meghatározza, hogy az Nginx egyszerre mennyi adatot írjon az ideiglenes fájlba, ha a backend upstream kiszolgálótól érkező válasz túl nagy ahhoz, hogy elférjen a konfigurált pufferekben.

• proxy_temp_path – az az irányelv, amely meghatározza a lemezen lévő azon hely elérési útját, ahol az Nginx-nek tárolnia kell az ideiglenes fájlokat, ha az upstream backend kiszolgálótól érkező válasz túl nagy ahhoz, hogy elférjen a konfigurált pufferekben.

Az Nginx nagymértékben testreszabható, és számos irányelvet biztosít a pufferelési viselkedés finomhangolásához. A legtöbb esetben az alapértelmezett értékek tökéletesen megfelelnek. Ugyanakkor jó tudni, hogy ezek közül az értékek közül néhányat módosíthat az egyedi implementációjához. Leggyakrabban a proxy_buffers és a proxy_buffer_size irányelveket fogja módosítani.

Az alábbiakban egy olyan példa látható, amely növeli az elérhető proxy pufferek számát minden egyes upstream kéréshez. Ezt úgy éri el, hogy közben csökkenti a fejléceket tároló puffer méretét:

Lássuk, hogyan szolgálhat ki gyorsabban adatokat a gyors klienseknek a pufferelés teljes kikapcsolásával. Ha a kliens nem elég gyors, az Nginx automatikusan puffereket fog használni. Azonban először kiüríti (flush) az adatokat a kliensnek, ahelyett, hogy a pufferkészletekre várna. Ennek a konfigurációnak van egy hátránya. Ez a konfiguráció azt eredményezi, hogy a lassú kliensek esetében az upstream kiszolgáló kapcsolata nyitva marad mindaddig, amíg a kliens meg nem kapja az összes válaszadatot. Ha a pufferelés „off” értékre van állítva, csak a proxy_buffer_size irányelv által meghatározott puffer lesz használva. Íme egy részlet, amely bemutatja, hogyan adhatja meg a pufferelés kikapcsolását:

• Magas rendelkezésre állású (HA) infrastruktúra konfigurálása (opcionális beállítás)

Hozzáadhat egy redundáns terheléselosztó-készletet az Nginx proxy konfigurációjához, biztosítva, hogy az robusztusabb és ezáltal magas rendelkezésre állású legyen. A magas rendelkezésre állású (HA) beállítás egy olyan infrastruktúra, amely nem tartalmaz egyetlen hibapontot sem. A terheléselosztók részét képezik ennek a konfigurációnak. Több terheléselosztóval megelőzheti a potenciális leállásokat, ha az egyik terheléselosztó meghibásodik vagy karbantartás miatt leáll.

Hogyan implementáljuk az Nginx proxy gyorsítótárazást a válaszidők csökkentése érdekében

Az előző szakaszban arról volt szó, hogyan használhatjuk a pufferelést a háttérkiszolgálók felszabadítására, hogy több kérést tudjanak kezelni. Az Nginx egy másik funkcióval is rendelkezik, amely lehetővé teszi a háttérből érkező válaszadatok gyorsítótárazását. Ez teljesen szükségtelenné teszi az upstreamhez való kapcsolódást minden bejövő kérés esetén.

Proxy gyorsítótár implementálása

A proxy_cache_path direktíva lehetővé teszi egy gyorsítótár beállítását a proxizott tartalom tárolására szolgáló lemezterület megadásával. A proxy_cache_path direktíva a http kontextusban kap definíciót.

Az alábbi konfigurációs kód részlet egy példa arra, hogyan implementálhat gyorsítótárazási rendszert:

Ebben a kódrészletben a proxy_cache_path direktívát használtuk a gyorsítótárunkat tartalmazó könyvtár meghatározására a fájlrendszerben. Ebben az esetben a /var/lib/nginx/cache könyvtárat állítottuk be. Szabadon meghatározhat egy tetszőleges könyvtárútvonalat. Használja a következő parancsokat a kiválasztott könyvtárak létrehozásához, a megfelelő jogosultságokkal és tulajdonossal:

A kódrészletben a levels= paraméter határozza meg a gyorsítótár felépítését. Az Nginx egy gyorsítótár-kulcsot hoz létre egy kulcs értékének hashelésével (amelyet a proxy_cache_key direktívával adunk meg). Az általunk megadott szintek (1:2) azt jelzik, hogy egy egykarakteres könyvtár (azaz a hash érték utolsó karaktere) jön létre egy kétkarakteres alkönyvtárral (amely a hash érték végétől számított következő két karakterből áll). A legtöbb esetben ez nem fogja érinteni Önt. Azonban jó tudni, hogyan segíti az Nginxet a releváns értékek gyors megtalálásában.

A keys_zone= paraméter határozza meg a gyorsítótár-zóna nevét, esetünkben ezt backendcache-nek neveztük el. Itt azt is meghatározzuk, hogy mennyi metaadatot szeretnénk tárolni. Ebben a példában 8 MB-nyi kulcsot tárolunk. Az Nginx megközelítőleg 8000 bejegyzést tud tárolni megabájtonként. A max_size paraméter a tényleges gyorsítótárazott adatok maximális méretét határozza meg, ami a mi példánkban 50 MB.

Figyelje meg a használt proxy_cache_key direktívát is. Ez a direktíva határozza meg azt a kulcsot, amelyet a gyorsítótárazott értékek tárolására fogunk használni. Ugyanezt a kulcsot fogjuk használni annak ellenőrzésére is, hogy a kérés létezik-e a gyorsítótárban. Ezt a kulcsot a séma (http vagy https), a HTTP kérés metódusa, valamint a kért gazdagép és URI kombinációjaként határoztuk meg.

Ezenkívül a proxy_cache_valid direktívát is használtuk. Ez a direktíva többször is megadható a különböző állapotkódokhoz. Lehetővé teszi számunkra, hogy meghatározzuk, mennyi ideig tároljuk az értékeket az állapotkódtól függően. A kódrészletben 10 percet adtunk meg a sikeres kódokhoz, és 1 percet a 404-es válaszokhoz.

Mivel konfiguráltuk a gyorsítótár-zónát, a következő lépés a konfiguráció életbe léptetése azáltal, hogy megmondjuk az Nginxnek, mikor használja a gyorsítótárat. Az alábbiakban egy konfigurációs részlet látható, amely bemutatja, hogyan implementálhatjuk a gyorsítótár használatát:

A proxy_cache direktívában megadtuk, hogy ehhez a kontextushoz a backendcache gyorsítótár-zónát kell használni. Ha a gyorsítótár konfigurációjában más nevet választott, itt kell azt kicserélnie. Minden érvényes bejegyzés esetén az Nginx ellenőrzi a gyorsítótárat, mielőtt továbbítaná a kérést a háttérben lévő upstream szervernek.

A proxy_cache_bypass direktívát úgy határozzuk meg, hogy a $http_cache_control változót használja. Ez a változó megmondja a szervernek, hogy gyorsítótárazott válasszal vagy az erőforrás friss, nem gyorsítótárazott verziójával válaszoljon-e. Ezen direktíva megfelelő beállítása lehetővé teszi az Nginx számára, hogy helyesen kezelje az ügyfelektől érkező különféle típusú kéréseket.

Egy további, X-Proxy-Cache nevű fejléc is megadásra került. Ennek a fejlécnek az értéke a $upstream_cache_status változó. Információt nyújt arról, hogy a kérés gyorsítótár-találatot (cache hit), gyorsítótár-tékát (cache miss) eredményezett-e, vagy a gyorsítótárat kifejezetten megkerülték. Az ilyen információk hasznosak lehetnek a kliens számára, és kulcsfontosságúak az alkalmazások hibakeresése során.

Fontos szempontok a gyorsítótárazási eredményekkel kapcsolatban

Bár a gyorsítótárazás nagymértékben javítja a proxyszerver teljesítményét, a gyorsítótárazás megvalósításakor vegye figyelembe a következőket:

A felhasználó személyes adataival kapcsolatos semmilyen adatot nem szabad gyorsítótárazni, elkerülve azokat a forgatókönyveket, amikor az egyik felhasználó adatai láthatóvá válnak egy másik felhasználó számára.

A háttérszervereknek figyelembe kell venniük a webhely összes dinamikus elemét. Számos Cache-Control fejlécet adhatunk meg a válaszunkban a különböző célok kiszolgálására. Beszéljük meg őket:

• no-cache – meghatározza, hogy a proxynak ellenőriznie kell, hogy az adatok megváltoztak-e a háttérben, mielőtt választ adna. Ez dinamikus és fontos adatokra vonatkozik. Minden kérésnél ellenőrzésre kerül egy ETag hash-elt metaadat-fejléc, és ha a háttér ugyanazt a hash-értéket adja vissza, akkor a korábbi érték kerül kiszolgálásra.

• no-store – nem engedélyezi a gyorsítótárazást semmilyen fogadott adat esetében, így minden kérés a szerverhez fordul friss adatokért. Ez a legbiztonságosabb az érzékeny adatok esetében.

• private – meghatározza, hogy semmilyen megosztott gyorsítótár-terület nem gyorsítótárazhatja az adatokat. Ezzel a fejléccel megadhatja a gyorsítótárazást a felhasználó böngészőjében, de tájékoztathatja a proxyszervert is, hogy a későbbi kérések szempontjából tekintse érvénytelennek az adatokat.

• public – nyilvános választ határoz meg, és lehetővé teszi a gyorsítótárazást a kapcsolat bármely pontján.

A max-age fejléc segítségével másodpercekben adhatja meg, hogy mennyi ideig tartson a gyorsítótár. A fent meghatározott különféle fejlécek segíthetnek a gyorsítótárazás megvalósításában, miközben biztonságban tartják az érzékeny adatokat, frissen a dinamikus adatokat, és ami a legfontosabb, javítják a szerver teljesítményét.

Ha a háttérszerverei Nginx szervereket futtatnak, a szerverblokkokon belül megadhatja, hogy a gyorsítótár meddig legyen érvényes. Ezt úgy teheti meg, hogy hozzáadja az expires direktívát a konfigurációhoz az alábbiak szerint:

Az első blokk 59 percig teszi lehetővé a tartalom gyorsítótárazását, míg a második blokk azt jelzi, hogy nincs gyorsítótárazás. Ezek a beállítások a Cache-Control fejlécek opcióira vonatkoznak, például a „no-cache” értékre a második blokk esetében.

Az add-header direktívát használhatja további értékek beállítására:

Összegzés

Ebben az útmutatóban megismertük az Nginx hatékony funkcióit. Az Nginx egyszerre webszerver és ami a legfontosabb, egy fordított proxy. Az Nginx kialakítása lehetővé teszi több ezer egyidejű kapcsolat kezelését. Ez tökéletessé teszi a terheléselosztásra. A kialakításnak köszönhetően a kérések továbbítása más háttérszerverek felé feldolgozásra meglehetősen egyszerű.

Az ebben az útmutatóban szerzett ismeretekkel képesnek kell lenned összetett proxyk és terheléselosztók megvalósítására, az Nginx rugalmasságának köszönhetően.

Íme néhány forrás, amelyet a blogunkon találsz, amelyek segítségével jobban megismerkedhetsz az Nginx-szel:

• Hogyan biztosítsuk az Nginx-et Let’s Encrypt segítségével Ubuntu 20.04-en

• Hogyan telepítsük a LEMP szoftvercsomagot (Linux, Nginx, MySQL PHP) Ubuntu 20.04-en

• A webszerverek világa: Apache vs. Nginx

• Laravel, Nginx és MySQL üzembe helyezése Docker Compose segítségével

Kellemes számítógép-használatot!