AWS Network Load Balancer (NLB): az eszköz definíciója és működése

Az AWS Network Load Balancer (NLB) Alapjai: Definíció és Célja

Az AWS felhőinfrastruktúra gerincét képező szolgáltatások között a terheléselosztók kiemelkedő szerepet játszanak a modern, skálázható és magas rendelkezésre állású alkalmazások biztosításában. Az Amazon Web Services (AWS) Elastic Load Balancing (ELB) szolgáltatáscsaládjának tagjai közül a Network Load Balancer (NLB) egy speciális, nagy teljesítményű megoldás, amelyet elsősorban a hálózati réteg (OSI modell 4. rétege) forgalmának hatékony kezelésére terveztek. Ez a terheléselosztó ideális választás olyan alkalmazásokhoz, amelyek rendkívül alacsony késleltetést, magas átviteli sebességet és statikus IP-címeket igényelnek.

Az NLB alapvetően egy olyan szolgáltatás, amely automatikusan elosztja a bejövő hálózati forgalmat a regisztrált célpéldányok – például Amazon EC2 példányok, konténerek vagy IP-címek – között. A célja, hogy biztosítsa az alkalmazások folyamatos rendelkezésre állását és skálázhatóságát, még akkor is, ha a forgalom hirtelen megnő, vagy ha az egyik mögöttes szerver meghibásodik. Míg az Application Load Balancer (ALB) a webes alkalmazások (HTTP/HTTPS) összetett, alkalmazásrétegbeli (7. réteg) forgalmának kezelésére specializálódott, az NLB a protokollfüggetlen TCP és UDP forgalomra összpontosít, ami sokkal szélesebb körű felhasználási lehetőségeket nyit meg.

A definíció lényegi eleme, hogy az NLB a kapcsolat szintjén működik. Ez azt jelenti, hogy miután egy ügyfél és a terheléselosztó között létrejött a TCP kapcsolat, az NLB biztosítja, hogy az adott kapcsolat teljes életciklusa során ugyanahhoz a célpéldányhoz irányuljon a forgalom, amennyiben az állapotellenőrzéseken átmegy. Ez a viselkedés kritikus fontosságú számos protokoll és alkalmazás számára, amelyek a kapcsolat folytonosságára épülnek. A célpéldányok egészségi állapotának folyamatos ellenőrzésével az NLB automatikusan eltávolítja a forgalomból a meghibásodott példányokat, és csak az egészségesekhez irányítja a kéréseket, ezzel növelve a rendszer ellenállóképességét a hibákkal szemben.

Miért az NLB? A Főbb Előnyök és Használati Esetek

Az NLB kiválasztása nem véletlen, hanem specifikus igényekre adott válasz. Számos olyan előnnyel rendelkezik, amelyek megkülönböztetik az ELB család többi tagjától, és ideálissá teszik bizonyos architektúrákhoz és munkaterhelésekhez.

Rendkívül Magas Teljesítmény és Skálázhatóság

Az NLB-t az AWS úgy tervezte, hogy kivételesen nagy teljesítményt és rendkívül alacsony késleltetést biztosítson. Képes másodpercenként több millió kérést kezelni, miközben a késleltetés mindössze néhány ezredmásodpercben mérhető. Ez a képesség teszi az NLB-t ideális választássá olyan alkalmazásokhoz, amelyek nagy forgalommal és szigorú teljesítménykövetelményekkel rendelkeznek, mint például a valós idejű játékok, a pénzügyi tranzakciók, vagy a nagy mennyiségű adatot feldolgozó rendszerek. Az NLB automatikusan skálázódik a bejövő forgalom alapján, anélkül, hogy előzetes kapacitástervezésre lenne szükség. Ez azt jelenti, hogy a terheléselosztó képes kezelni a hirtelen forgalomnövekedést anélkül, hogy a teljesítmény romlana, vagy az alkalmazás elérhetetlenné válna.

Statikus IP-címek és Kliens IP-cím Megőrzése

Az NLB egyik legkiemelkedőbb jellemzője, hogy statikus IP-címeket biztosít minden engedélyezett rendelkezésre állási zónában. Ezek az IP-címek lehetnek Elastic IP-címek (EIP-k), amelyeket Ön allokál és társít az NLB-hez, vagy az AWS által automatikusan hozzárendelt statikus IP-címek. Ez a funkció rendkívül fontos olyan forgatókönyvekben, ahol a DNS-gyorsítótárazás vagy a tűzfal-konfigurációk miatt stabil IP-címre van szükség. Az EIP-k használata lehetővé teszi, hogy az NLB IP-címe ne változzon, még akkor sem, ha a mögöttes infrastruktúra változik, ami leegyszerűsíti a hálózati konfigurációt és a kapcsolódást külső rendszerekből.

Ezen felül az NLB alapértelmezés szerint megőrzi a kliens forrás IP-címét. Ez azt jelenti, hogy a célpéldányok közvetlenül látják az eredeti kliens IP-címét, nem pedig a terheléselosztó IP-címét. Ez a képesség kritikus fontosságú a naplózáshoz, a biztonsági ellenőrzésekhez, a geolokációs szolgáltatásokhoz és minden olyan esetben, ahol az alkalmazásnak tudnia kell, honnan érkezett a kérés. Sok régi terheléselosztó vagy proxy átírja a forrás IP-címet, ami megnehezíti a hibakeresést és a forgalom elemzését. Az NLB ezen a téren is jelentős előnyt kínál.

Réteg 4 (TCP/UDP) Terheléselosztás

Az NLB az OSI modell 4. rétegén, azaz a szállítási rétegen működik. Ez azt jelenti, hogy a terheléselosztást a TCP és UDP protokollok szintjén végzi. Ez a megközelítés protokollfüggetlenné teszi az NLB-t a felsőbb rétegek szempontjából, és rendkívül hatékony. Mivel nem kell elemeznie a HTTP fejléceket vagy más alkalmazásrétegbeli adatokat, az NLB gyorsabban és alacsonyabb késleltetéssel tudja továbbítani a forgalmat. Emiatt ideális olyan alkalmazásokhoz, amelyek nem HTTP/HTTPS alapúak, például:

• Játék szerverek: Gyakran használnak UDP-t a gyors, valós idejű kommunikációhoz.
• DNS szerverek: A DNS lekérdezések is gyakran UDP alapon működnek.
• IoT (Internet of Things) eszközök: Sok IoT protokoll TCP vagy UDP alapon működik.
• Adatbázis kapcsolatok: Közvetlen TCP kapcsolatok terheléselosztása.
• Streaming média szolgáltatások: UDP alapú adatátvitel optimalizálása.
• VPN végpontok: Statikus IP-címekkel és alacsony késleltetéssel.
• Microservices architektúrák: Belső TCP/UDP kommunikáció skálázása.

Magas Rendelkezésre Állás és Zónák Közötti Forgalomelosztás

Az NLB automatikusan elosztja a forgalmat több rendelkezésre állási zónában (Availability Zones – AZs), növelve ezzel az alkalmazás rendelkezésre állását és hibatűrését. Ha egy AZ meghibásodik, az NLB automatikusan átirányítja a forgalmat az egészséges AZ-kben található célpéldányokhoz. A zónák közötti terheléselosztás (cross-zone load balancing) alapértelmezetten engedélyezett az NLB-nél (ellentétben az ALB-vel, ahol konfigurálni kell), ami tovább növeli a forgalom egyenletes elosztását a regisztrált célpéldányok között, függetlenül attól, hogy melyik AZ-ban helyezkednek el.

Egyszerűsített Hálózati Architektúra

Az NLB használatával a hálózati architektúra leegyszerűsödik, mivel a terheléselosztó kezeli a bejövő forgalom elosztását, és elrejti a mögöttes szerverek komplexitását. Ez csökkenti a felügyeleti terheket és a konfigurációs hibák kockázatát.

Az NLB Működése: Részletes Áttekintés

Az NLB működési elve a hálózati forgalom hatékony és intelligens irányításán alapul. Ahhoz, hogy megértsük, hogyan éri el a magas teljesítményt és megbízhatóságot, vessünk egy pillantást a kulcsfontosságú komponensekre és folyamatokra.

Figyelők (Listeners)

A figyelők az NLB bejövő forgalmának „ajtói”. Minden figyelő egy adott protokollt és portot figyel, és amikor bejövő kérést észlel ezen a kombináción, átirányítja azt a hozzárendelt célcsoport(ok)hoz. Az NLB támogatja a következő protokollokat a figyelőkön:

• TCP: A leggyakoribb protokoll, amely megbízható, kapcsolatorientált kommunikációt biztosít.
• UDP: Kapcsolat nélküli protokoll, amelyet gyors, valós idejű adatátvitelre használnak, ahol a csomagvesztés elfogadható (pl. streaming, játék).
• TLS: Lehetővé teszi a TLS/SSL végződtetést az NLB-n. Ez azt jelenti, hogy az NLB dekódolja a titkosított forgalmat, mielőtt továbbítaná azt a célpéldányoknak. Ez tehermentesíti a célpéldányokat a titkosítás/dekódolás feladatától, és lehetővé teszi a központosított tanúsítványkezelést.
• TCP_UDP: Egyetlen figyelővel kezelheti a TCP és UDP forgalmat is ugyanazon a porton, ami kényelmes lehet bizonyos protokollok (pl. DNS) esetén, amelyek mindkettőt használhatják.

Minden figyelőhöz legalább egy alapértelmezett célcsoportot kell rendelni. Az NLB az alapértelmezett célcsoportba irányítja a forgalmat, ha nincsenek speciális szabályok, vagy ha egy szabály nem egyezik. Az NLB nem támogatja a szabály alapú útválasztást (mint az ALB), hanem a figyelő és a célcsoport közötti közvetlen kapcsolatot használja.

Célcsoportok (Target Groups)

A célcsoportok logikai csoportosítások, amelyek azokat a célpéldányokat tartalmazzák, amelyekhez az NLB a forgalmat irányítja. Egy célcsoporton belül definiálhatja a következőket:

• Protokoll és port: Az NLB melyik protokollon és porton keresztül kommunikáljon a célpéldányokkal (pl. TCP 80, TCP 443). Fontos, hogy ez eltérhet a figyelő protokolljától és portjától. Például, ha a figyelő TLS 443-at figyel, a célcsoport lehet TCP 80, ha az NLB-n végződik a TLS.
• Célpéldányok: Az EC2 példányok, IP-címek vagy Lambda függvények, amelyek a forgalmat fogadják. Az NLB támogatja a célok regisztrálását IP-címmel is, ami lehetővé teszi az on-premise szerverek vagy más AWS szolgáltatások (pl. ECS, EKS) regisztrálását is.
• Állapotellenőrzések (Health Checks): A célpéldányok egészségi állapotának ellenőrzésére szolgáló mechanizmusok.

Egy NLB több célcsoportot is használhat, de egy figyelő csak egy alapértelmezett célcsoporthoz van rendelve. A forgalom elosztása a célcsoporton belül történik az ott regisztrált, egészséges célpéldányok között.

Állapotellenőrzések (Health Checks)

Az állapotellenőrzések kritikusak az NLB működésében, mivel biztosítják, hogy a forgalom csak az egészséges és működőképes célpéldányokhoz jusson el. Az NLB folyamatosan ellenőrzi a célpéldányok állapotát a célcsoportban definiált paraméterek alapján. Ha egy célpéldány nem felel meg az állapotellenőrzésnek, az NLB automatikusan eltávolítja a forgalomból, és csak akkor irányítja vissza hozzá a forgalmat, ha ismét egészségesnek minősül. Az állapotellenőrzés paraméterei a következők:

• Protokoll: TCP, HTTP, HTTPS. Bár az NLB 4. rétegen működik, HTTP/HTTPS állapotellenőrzéseket is végezhet a 7. rétegen, hogy részletesebb képet kapjon az alkalmazás állapotáról.
• Port: A port, amelyen az állapotellenőrzés történik. Ez lehet a célpéldány forgalmi portja, vagy egy dedikált port az állapotellenőrzéshez.
• Egészséges küszöb (Healthy threshold): Az egymást követő sikeres állapotellenőrzések száma, mielőtt egy célpéldány egészségesnek minősül.
• Egészségtelen küszöb (Unhealthy threshold): Az egymást követő sikertelen állapotellenőrzések száma, mielőtt egy célpéldány egészségtelennek minősül.
• Időköz (Interval): Az állapotellenőrzések közötti idő (másodpercben).
• Időtúllépés (Timeout): Az az időtartam, ameddig az állapotellenőrzés válaszra vár, mielőtt sikertelennek minősül.

Az állapotellenőrzések konfigurációja kulcsfontosságú a rendszer stabilitása szempontjából. Túl agresszív beállítások (rövid időköz, alacsony küszöbök) esetén a célpéldányok túl gyorsan kerülhetnek forgalmon kívülre, vagy túl lassan kerülhetnek vissza. Túl laza beállítások esetén pedig a hibás példányok túl sokáig kaphatnak forgalmat, ami felhasználói problémákhoz vezethet.

Forrás IP-cím Alapú Ragaszkodás (Client IP Preservation)

Ahogy korábban említettük, az NLB megőrzi a kliens forrás IP-címét. Ez a képesség lehetővé teszi, hogy a célpéldányok közvetlenül lássák, honnan érkezik a kérés. Ez a funkció alapértelmezett viselkedés az NLB-nél. TCP forgalom esetén az NLB egy flow hash algoritmust használ a forgalom elosztására, amely a forrás IP-címét, a forrásportot, a cél IP-címet, a célportot és a protokollt veszi figyelembe. Ez biztosítja, hogy ugyanaz a kapcsolat mindig ugyanahhoz a célpéldányhoz irányuljon, ami kapcsolat alapú ragaszkodást eredményez. UDP forgalom esetén is hasonló hashing mechanizmust alkalmaz.

Zónák Közötti Terheléselosztás (Cross-Zone Load Balancing)

Alapértelmezés szerint engedélyezett az NLB-nél. Ez azt jelenti, hogy az NLB a regisztrált célpéldányok között egyenletesen osztja el a forgalmat az összes engedélyezett rendelkezésre állási zónában, nem csak az adott zónán belül. Például, ha van 10 példány az AZ-A-ban és 20 példány az AZ-B-ben, és az AZ-A NLB csomópontja kap egy kérést, azt elküldheti az AZ-B-ben lévő példánynak is. Ez segíti az erőforrások optimális kihasználását és növeli a rendszer ellenállóképességét zónaszintű meghibásodások esetén. Fontos megjegyezni, hogy bár a cross-zone load balancing alapértelmezett, ez extra adatkimeneti díjakkal járhat az AZ-k között továbbított forgalomért.

Az AWS Network Load Balancer (NLB) egy réteg 4-es terheléselosztó, amely kivételes teljesítményt, ultra-alacsony késleltetést és statikus IP-címeket biztosít, miközben megőrzi a kliens forrás IP-címét, ezzel ideális választássá téve a legigényesebb TCP és UDP alapú munkaterhelésekhez.

NLB Konfigurálása: Lépésről Lépésre

Az NLB beállítása az AWS konzolon, CLI-n vagy CloudFormation segítségével viszonylag egyszerű folyamat. Íme a főbb lépések:

1. Network Load Balancer Létrehozása

Először is válassza ki az Elastic Load Balancing szolgáltatást az EC2 konzolon belül, majd kattintson a „Create Load Balancer” gombra. Itt kiválaszthatja a „Network Load Balancer” opciót. Meg kell adnia egy nevet az NLB-nek, és kiválasztania, hogy Internet-facing (nyilvános) vagy Internal (belső) legyen-e. Az Internet-facing NLB nyilvánosan elérhető IP-címmel rendelkezik, míg az Internal NLB csak a VPC-n belülről érhető el.

Ezután ki kell választania a Virtual Private Cloud (VPC) hálózatot, amelyben az NLB működni fog, és legalább két rendelkezésre állási zónát, ahol engedélyezni szeretné az NLB-t. Minden kiválasztott AZ-hoz rendelnie kell egy alhálózatot. Itt van lehetősége Elastic IP-címek hozzárendelésére is az NLB-hez, ami biztosítja a stabil, statikus nyilvános IP-címeket.

2. Figyelők (Listeners) Konfigurálása

A következő lépés a figyelők konfigurálása. Adja meg a figyelő protokollját (TCP, UDP, TLS, TCP_UDP) és a portot, amelyen az NLB fogadja a bejövő forgalmat (pl. TCP 80 vagy TLS 443). Minden figyelőhöz hozzá kell rendelnie egy alapértelmezett célcsoportot, ahová a forgalmat irányítja. Ha TLS figyelőt konfigurál, fel kell töltenie egy SSL/TLS tanúsítványt az AWS Certificate Manager (ACM) szolgáltatásba, és azt itt kiválasztania.

3. Célcsoportok (Target Groups) Létrehozása és Konfigurálása

Ezen a lépésen belül hozza létre a célcsoportokat. Adja meg a célcsoport nevét, a protokollját és a portot, amelyen a célpéldányok fogadják a forgalmat. Válassza ki a célpéldány típusát: Instance (EC2 példányok), IP (IP-címek) vagy Lambda (Lambda függvények). Az IP típus különösen hasznos, ha konténereket (ECS, EKS) vagy on-premise szervereket szeretne regisztrálni.

Nagyon fontos az állapotellenőrzések (Health Checks) beállítása. Válassza ki az állapotellenőrzés protokollját (TCP, HTTP, HTTPS), a portot, az időközöket, a küszöböket és az időtúllépést. Ezek a paraméterek határozzák meg, hogyan ellenőrzi az NLB a célpéldányok egészségi állapotát.

4. Célpéldányok Regisztrálása

Miután létrehozta a célcsoportot, regisztrálnia kell a célpéldányokat. Ez lehet EC2 példány, amelyeket futtat, vagy specifikus IP-címek. Válassza ki a regisztrálni kívánt példányokat/IP-címeket, és adja hozzá őket a célcsoporthoz. Az NLB ezután elkezdi ellenőrizni a regisztrált célok állapotát az állapotellenőrzési beállítások alapján.

5. DNS Beállítások (Opcionális, de Ajánlott)

Bár az NLB-hez statikus IP-címek tartoznak, javasolt egy DNS alias rekordot (CNAME vagy A rekord, ha Route 53-at használ) létrehozni az NLB DNS nevével. Ez lehetővé teszi, hogy egy könnyen megjegyezhető tartománynévvel érje el az alkalmazását (pl. `app.example.com`), és rugalmasabbá teszi a konfigurációt, ha az NLB DNS neve a jövőben változna (bár az EIP-k ezt minimalizálják).

NLB és Más AWS Szolgáltatások Integrációja

Az NLB erejét nemcsak önálló képességei adják, hanem az is, hogy zökkenőmentesen integrálható más AWS szolgáltatásokkal, tovább növelve az alkalmazások skálázhatóságát, megbízhatóságát és biztonságát.

Auto Scaling

Az NLB szorosan integrálódik az AWS Auto Scaling szolgáltatással. Amikor egy Auto Scaling csoportot konfigurál, hozzárendelheti azt egy vagy több célcsoporthoz. Az Auto Scaling csoport ezután automatikusan elindítja vagy leállítja az EC2 példányokat a konfigurált skálázási politikák alapján (pl. CPU kihasználtság, hálózati forgalom). Amikor az Auto Scaling új példányokat indít, automatikusan regisztrálja azokat az NLB célcsoportjában, és amikor leállít példányokat, deregisztrálja azokat. Ez biztosítja, hogy az alkalmazás mindig rendelkezzen a megfelelő számú erőforrással a forgalom kezeléséhez, miközben az NLB egyenletesen osztja el a bejövő kéréseket az új és meglévő példányok között.

AWS PrivateLink

Az AWS PrivateLink egy hálózati szolgáltatás, amely lehetővé teszi a biztonságos, privát kapcsolódást az AWS szolgáltatásokhoz, harmadik féltől származó szolgáltatásokhoz és on-premise alkalmazásokhoz anélkül, hogy a forgalom az interneten keresztül haladna. Az NLB kulcsszerepet játszik a PrivateLink architektúrában, mivel az NLB a PrivateLink endpoint szolgáltatásának alapja. Egy szolgáltató létrehozhat egy endpoint szolgáltatást az NLB mögött, és a fogyasztók ezután privát VPC endpointokon keresztül csatlakozhatnak ehhez a szolgáltatáshoz. Ez a képesség rendkívül fontos a SaaS (Software as a Service) szolgáltatók és a nagyméretű vállalatok számára, akik szeretnék biztosítani a biztonságos és privát kapcsolódást a szolgáltatásaikhoz.

Amazon Route 53

Az Amazon Route 53, az AWS DNS szolgáltatása, kiválóan integrálható az NLB-vel. Ahogy korábban említettük, egy alias rekord konfigurálása a Route 53-ban az NLB DNS nevére a legjobb gyakorlat. Ez lehetővé teszi a felhasználók számára, hogy egy könnyen megjegyezhető tartománynéven keresztül érjék el az alkalmazását. A Route 53 támogatja a különböző útválasztási politikákat (pl. súlyozott, késleltetés alapú, földrajzi), amelyek tovább optimalizálhatják a forgalom irányítását az NLB-k között, például katasztrófa-helyreállítási (DR) forgatókönyvek esetén.

Amazon CloudWatch és AWS CloudTrail

Az NLB integrálódik az Amazon CloudWatch szolgáltatással a metrikák és riasztások biztosításához. Az NLB számos metrikát küld a CloudWatch-nak, például az aktív kapcsolatok számát, a bájtok átvitelét, a sikeres/sikertelen állapotellenőrzések számát, és a célpéldány hibáit. Ezek a metrikák létfontosságúak az NLB teljesítményének és az alkalmazás egészségi állapotának monitorozásához. Riasztásokat konfigurálhat a kritikus metrikákra, hogy értesítést kapjon, ha problémák merülnek fel.

Az AWS CloudTrail rögzíti az NLB-hez kapcsolódó API hívásokat, ami lehetővé teszi a biztonsági elemzést, a változások nyomon követését és a megfelelőség ellenőrzését. Láthatja, ki, mikor és milyen módosításokat végzett az NLB konfigurációján.

VPC Flow Logs

Bár az NLB maga nem generál közvetlenül hozzáférési naplókat (mint az ALB), a mögötte lévő EC2 példányok hálózati forgalmát rögzítheti a VPC Flow Logs segítségével. Ez lehetővé teszi a hálózati forgalom részletes elemzését, beleértve a forrás és cél IP-címeket, portokat, protokollokat és a forgalom mennyiségét. Ez a hibakereséshez, a biztonsági elemzéshez és a hálózati teljesítmény optimalizálásához elengedhetetlen.

NLB vs. ALB vs. CLB: Melyiket Mikor?

Az AWS Elastic Load Balancing szolgáltatáscsaládja három fő típust kínál: Classic Load Balancer (CLB), Application Load Balancer (ALB) és Network Load Balancer (NLB). Mindegyik más-más igényekre optimalizált, és a megfelelő választás az alkalmazás típusától és a teljesítménykövetelményektől függ.

Classic Load Balancer (CLB)

A CLB a legkorábbi ELB típus, és ma már kevésbé ajánlott új architektúrákhoz. Mind a réteg 4 (TCP), mind a réteg 7 (HTTP/HTTPS) szinten képes terheléselosztást végezni, de kevésbé rugalmas és teljesítményes, mint az ALB vagy az NLB. Hiányoznak belőle az újabb funkciók, mint a Path-based routing vagy a konténeres alkalmazások támogatása. Alapvetően örökölt alkalmazásokhoz érdemes használni, ahol már működik, de új fejlesztéseknél kerülendő.

Application Load Balancer (ALB)

Az ALB az OSI modell 7. rétegén (alkalmazási réteg) működik. Ez azt jelenti, hogy képes elemezni a HTTP/HTTPS kérések tartalmát, például az URL útvonalát, a gazdagép fejlécét és a HTTP metódusokat. Az ALB ideális választás webes alkalmazásokhoz, mikro-szolgáltatásokhoz és konténeres alkalmazásokhoz (pl. ECS, EKS). Főbb jellemzői:

• HTTP/HTTPS alapú terheléselosztás: Részletes útválasztási szabályok (path-based, host-based, query string-based).
• Konténerbarát: Lehetővé teszi több alkalmazás futtatását ugyanazon az EC2 példányon, különböző portokon.
• Websocket és HTTP/2 támogatás.
• Integráció az AWS WAF-fal a webes biztonsági védelem érdekében.
• Lassú indítási mód: Lehetővé teszi az új példányok fokozatos felmelegítését.
• Nem őrzi meg alapértelmezetten a kliens IP-címét (X-Forwarded-For fejlécet használ).
• Dinamikus port mapping konténeres alkalmazásokhoz.

Mikor válassza az ALB-t? Amikor webes alkalmazásokat (HTTP/HTTPS) futtat, mikro-szolgáltatásokat használ, vagy részletes útválasztási szabályokra van szüksége a kérések tartalmának elemzése alapján.

Network Load Balancer (NLB)

Ahogy már részletesen tárgyaltuk, az NLB az OSI modell 4. rétegén (szállítási réteg) működik (TCP/UDP). Főbb jellemzői:

• Rendkívül magas teljesítmény és alacsony késleltetés.
• Statikus IP-címek.
• Kliens forrás IP-cím megőrzése.
• TCP és UDP forgalom terheléselosztása.
• TLS végződtetés lehetősége.
• Közvetlen IP-címre való regisztrálás.
• Nincs fejlett útválasztási logika (csak port és protokoll alapján).

Mikor válassza az NLB-t? Amikor extrém teljesítményre, alacsony késleltetésre, statikus IP-címekre van szüksége, vagy nem-HTTP/HTTPS alapú protokollokat (pl. játék szerverek, DNS, IoT, adatbázisok) használ.

Összefoglaló Táblázat: NLB vs. ALB

Jellemző	Network Load Balancer (NLB)	Application Load Balancer (ALB)
OSI Réteg	4. réteg (TCP, UDP, TLS)	7. réteg (HTTP, HTTPS)
Teljesítmény	Extrém magas, alacsony késleltetés	Magas, de az alkalmazásréteg elemzése miatt magasabb késleltetés
IP-címek	Statikus (Elastic IP-címek)	Dinamikus (DNS névvel érhető el)
Kliens IP megőrzés	Igen, alapértelmezett	Nem (X-Forwarded-For fejléccel továbbítja)
Forrás IP ragaszkodás	Kapcsolat alapú flow hash	Cookie alapú
Útválasztási logika	Egyszerű, port/protokoll alapú	Fejlett, URL útvonal, host, HTTP metódus alapján
Célpéldányok	EC2, IP-címek, Lambda	EC2, IP-címek, Lambda
Használati esetek	Játék szerverek, DNS, IoT, adatbázisok, mikro-szolgáltatások TCP/UDP, PrivateLink	Webes alkalmazások, mikro-szolgáltatások, konténeres alkalmazások, API Gateway
TLS végződtetés	Igen, az NLB-n	Igen, az ALB-n
Biztonsági csoportok	Nincs közvetlenül (a célpéldányokon)	Igen, az ALB-n

Biztonsági Megfontolások az NLB Használatakor

Bár az NLB a 4. rétegen működik, és nem rendelkezik közvetlenül biztonsági csoportokkal (Security Groups), a biztonság továbbra is kiemelten fontos. A biztonságot a mögötte lévő célpéldányokon és a hálózati hozzáférés-vezérlési listákon (Network ACLs) keresztül kell kezelni.

Hálózati Hozzáférés-vezérlési Listák (Network ACLs)

A Network ACL-ek alhálózati szinten működő, állapot nélküli tűzfalak. Konfigurálhatja őket, hogy engedélyezzék vagy megtagadják a bejövő és kimenő forgalmat az NLB alhálózataiban. Mivel az NLB megőrzi a kliens IP-címét, a NACL-ekkel szabályozhatja, hogy mely forrás IP-címekről érkezhet forgalom az NLB-hez, vagy mely cél IP-címekre mehet ki forgalom a célpéldányok felől. Fontos, hogy a NACL-ek állapot nélküliek, tehát mind a bejövő, mind a kimenő szabályokat explicit módon meg kell adni.

Biztonsági Csoportok (Security Groups) a Célpéldányokon

Az NLB nem asszociálható biztonsági csoportokkal. Ehelyett a biztonsági csoportokat a célpéldányokon kell konfigurálni. A célpéldányok biztonsági csoportjainak engedélyezniük kell a bejövő forgalmat az NLB alhálózatainak IP-cím tartományából, valamint az NLB szolgáltatás IP-cím tartományából (ha PrivateLink-et használ), a figyelő portján. Mivel az NLB megőrzi a kliens IP-címét, a célpéldányok biztonsági csoportjait úgy is konfigurálhatja, hogy csak bizonyos kliens IP-címekről érkező forgalmat engedélyezzenek, ami további biztonsági réteget biztosít.

TLS Végződtetés

Ha az NLB-n TLS figyelőt használ, az NLB kezeli a TLS/SSL titkosítást és dekódolást. Ez azt jelenti, hogy a célpéldányokhoz már titkosítatlanul érkezik a forgalom. Fontos, hogy a célpéldányok és az NLB közötti forgalom az AWS belső hálózatán belül marad, de ha szigorú megfelelőségi követelmények vannak, érdemes lehet az end-to-end titkosítást fenntartani, azaz a célpéldányokon is újra titkosítani a forgalmat (re-encryption). Az NLB-n való TLS végződtetés előnye, hogy központosítja a tanúsítványkezelést az AWS Certificate Manager (ACM) segítségével, és tehermentesíti a célpéldányokat a titkosítási terhektől.

DDoS Védelem

Az NLB alapértelmezetten integrálódik az AWS Shield Standard szolgáltatással, amely védelmet nyújt a leggyakoribb hálózati rétegbeli DDoS támadások ellen. Magasabb szintű védelemre van szükség esetén az AWS Shield Advanced használható, amely további védelmi mechanizmusokat és 24/7-es DDoS válaszadó csapatot biztosít.

Monitorozás és Hibakeresés

Az NLB hatékony működésének biztosításához elengedhetetlen a folyamatos monitorozás és a gyors hibakeresés képessége.

Amazon CloudWatch Metrikák

Az NLB számos részletes metrikát tesz közzé a CloudWatch-ban, amelyek segítenek nyomon követni a terheléselosztó és a mögöttes célpéldányok állapotát és teljesítményét. Néhány kulcsfontosságú metrika:

• HealthyHostCount / UnHealthyHostCount: Az egészséges és egészségtelen célpéldányok száma. Ez a legfontosabb metrika az alkalmazás rendelkezésre állásának ellenőrzésére.
• ActiveFlowCount: Az aktív TCP/UDP folyamatok száma.
• NewFlowCount: Az újonnan létrehozott TCP/UDP folyamatok száma.
• ConsumedLCUs: A Load Balancer Capacity Units (LCU) fogyasztása, amely az NLB költségeinek alapja.
• TargetConnectionErrorCount: Hiba a célpéldányhoz való csatlakozáskor.
• ClientTLSNegotiationErrorCount: Hiba a kliens és az NLB közötti TLS kézfogás során (ha TLS figyelőt használ).

Ezekre a metrikákra riasztásokat állíthat be a CloudWatch-ban, hogy értesítést kapjon, ha a rendszer rendellenesen viselkedik (pl. túl sok egészségtelen célpéldány, túl sok kapcsolódási hiba).

VPC Flow Logs

A VPC Flow Logs használatával rögzítheti az összes IP forgalmat, amely az NLB mögötti hálózati interfészeken keresztül áramlik. Ez rendkívül hasznos a hálózati problémák hibakereséséhez, a biztonsági auditokhoz és a forgalomelemzéshez. Láthatja, ki csatlakozik az alkalmazásához, milyen portokon, és mennyi adatot továbbít.

Célpéldányok Naplói

A célpéldányokon futó alkalmazások és szerverek naplóinak (pl. web szerver naplók, alkalmazás naplók) elemzése szintén kulcsfontosságú. Ezek a naplók részletes információt szolgáltatnak a kérésekről, a hibákról és az alkalmazás belső működéséről, kiegészítve az NLB és VPC Flow Logs által nyújtott adatokat.

Költségek és Optimalizáció

Az NLB költségeit két fő komponens határozza meg:

1. Óradíj: Az NLB minden órában díjat számol fel, ameddig fut.
2. LCU (Load Balancer Capacity Units) fogyasztás: Az LCU-k a terheléselosztó kapacitásának mértékegységei. Az LCU fogyasztás a következő dimenziók alapján kerül kiszámításra:
   • Új kapcsolatok: Az NLB által másodpercenként létrehozott új TCP/UDP kapcsolatok száma.
   • Aktív kapcsolatok: Az egyidejűleg fennálló aktív TCP/UDP kapcsolatok száma.
   • Adatfeldolgozás: A terheléselosztón keresztül továbbított bájtok száma.
   • TLS kézfogások: A TLS figyelők által kezelt TLS kézfogások száma (ha TLS végződtetés van engedélyezve).

   Az AWS minden hónapban a legmagasabb LCU fogyasztás alapján számolja a díjat.

Költségoptimalizációs Tippek:

• Megfelelő méretezés: Bár az NLB automatikusan skálázódik, a feleslegesen sok aktív, de inaktív kapcsolat elkerülése segíthet csökkenteni az LCU költségeket.
• Egészséges célpéldányok: Győződjön meg róla, hogy a célpéldányok egészségesek és képesek kezelni a forgalmat, hogy elkerülje a sikertelen kapcsolatok és az újrapróbálkozások generálta extra LCU fogyasztást.
• Zónák közötti terheléselosztás: Bár alapértelmezetten engedélyezett és ajánlott a magas rendelkezésre állás érdekében, a cross-zone forgalomért extra díjak merülnek fel. Ha az alkalmazás architektúrája megengedi, és szigorú költségoptimalizálási céljai vannak, érdemes lehet megfontolni a kikapcsolását, és helyette AZ-specifikus NLB-ket használni, bár ez bonyolultabb architektúrához vezet.
• TLS offload: Az NLB-n történő TLS végződtetés csökkenti a célpéldányok terhelését, ami kisebb példányméretekhez vagy kevesebb példányhoz vezethet, ezáltal csökkentve az EC2 költségeket.

Összefoglalás és Következtetések

Az AWS Network Load Balancer (NLB) egy rendkívül hatékony és robusztus megoldás a hálózati rétegbeli (Layer 4) terheléselosztáshoz az AWS felhőben. Kiemelkedő teljesítménye, alacsony késleltetése, statikus IP-cím támogatása és a kliens IP-cím megőrzésének képessége révén ideális választás a legigényesebb TCP és UDP alapú alkalmazások, mint például a valós idejű játékok, IoT platformok, DNS szerverek, adatbázisok és PrivateLink szolgáltatások számára.

Az NLB zökkenőmentesen integrálódik más AWS szolgáltatásokkal, mint az Auto Scaling, Route 53, CloudWatch és PrivateLink, lehetővé téve a skálázható, magas rendelkezésre állású és biztonságos architektúrák építését. Bár az ALB a webes alkalmazások összetett igényeit szolgálja ki, az NLB a nyers teljesítményre és a hálózati rétegbeli protokollokra specializálódik, kitöltve egy fontos rést az AWS terheléselosztási kínálatában.

A megfelelő konfigurációval, beleértve az állapotellenőrzéseket és a biztonsági csoportokat a célpéldányokon, az NLB jelentősen hozzájárulhat az alkalmazások megbízhatóságához és felhasználói élményéhez. A folyamatos monitorozás a CloudWatch metrikákkal és a VPC Flow Logs segítségével biztosítja, hogy bármilyen probléma gyorsan azonosítható és orvosolható legyen.