Load balancing uitgelegd: verkeer slim verdelen

Zodra je meer dan één server gebruikt, heb je iets nodig dat bepaalt welke server welk verzoek afhandelt. Dat is wat een load balancer doet. Simpel concept, maar de details maken het verschil.

Een load balancer staat tussen de bezoeker en je applicatieservers in. Hij ontvangt elk inkomend verzoek en stuurt het door naar een van de beschikbare servers in je cluster. Dat klinkt rechttoe rechtaan, maar achter die doorstuurlogica zit behoorlijk wat slimheid.

Waarom load balancing?

De meest voor de hand liggende reden is capaciteit: één server kan maar zo veel aan. Door verkeer te spreiden over meerdere servers vergroot je het totale verwerkingsvermogen. Maar er is meer:

• Beschikbaarheid: als één server uitvalt, neemt de load balancer hem uit de rotatie. Bezoekers merken niets.
• Onderhoud zonder downtime: je kunt servers één voor één bijwerken terwijl de rest het verkeer opvangt.
• Beveiliging: je applicatieservers zijn niet direct bereikbaar van buitenaf. Alleen de load balancer staat bloot aan het internet.
• Health checks: de load balancer controleert continu of servers beschikbaar zijn en stuurt geen verkeer naar servers die niet reageren.

De belangrijkste algoritmen

Hoe een load balancer besluit welke server een verzoek krijgt, hangt af van het gekozen algoritme. De gangbare opties:

Round Robin is de standaard. Elk verzoek gaat naar de volgende server in de lijst, om beurten. Eenvoudig en eerlijk bij gelijkwaardige servers. Het nadeel is dat het geen rekening houdt met hoe zwaar de servers al belast zijn.

Least Connections stuurt elk verzoek naar de server met de minste actieve verbindingen op dat moment. Dit werkt beter als verzoeken sterk variëren in duur – lange zoekopdrachten, uploads of API-calls worden dan niet allemaal op één server gestapeld.

IP Hash (of Sticky Sessions) stuurt dezelfde bezoeker altijd naar dezelfde server, op basis van IP-adres of een cookie. Dat is handig als je applicatie sessiedata lokaal opslaat. Het nadeel: bij uitval van die ene server is de sessie weg. Liever los je sessie-opslag op met Redis.

Weighted Round Robin verdeelt verkeer op basis van gewichten. Een server met 16 cores krijgt dan twee keer zoveel verzoeken als een server met 8 cores. Handig bij heterogene clusters.

Least Response Time combineert serverbelasting en responsetijd om de meest optimale server op dat moment te kiezen. Geavanceerder, maar effectiever bij grote clusters met variabele belasting.

Layer 4 vs Layer 7: op welk niveau werkt de load balancer?

Load balancers werken op twee niveaus van het OSI-model, en dit onderscheid is praktisch relevant.

Layer 4 (transport): de load balancer kijkt alleen naar IP-adres en TCP/UDP-poort. Hij heeft geen idee wat er in de payload zit. Dit is razendsnel en gebruikt weinig resources, maar biedt weinig flexibiliteit. Je kunt geen beslissingen nemen op basis van URL-pad, HTTP-headers of cookies.

Layer 7 (applicatie): de load balancer begrijpt HTTP. Hij kan verkeer routeren op basis van URL-patronen, host-headers, cookies en query-parameters. Zo kun je API-verkeer naar andere servers sturen dan reguliere paginaverzoeken, of A/B-tests uitvoeren op infrastructuurniveau. Dit kost iets meer overhead, maar biedt veel meer mogelijkheden.

Voor de meeste webapplicaties is Layer 7 de juiste keuze. Layer 4 is interessant voor protocollen die niet HTTP zijn, of als je absolute maximale throughput nodig hebt.

HAProxy en NGINX: de twee standaarden

In de praktijk worden twee tools het meest gebruikt voor load balancing:

HAProxy is gebouwd voor één doel: load balancing. Het is extreem stabiel, heeft uitgebreide statistieken ingebouwd en ondersteunt zowel Layer 4 als Layer 7. De configuratiesyntax is specifiek en vereist even wennen, maar de controle die je krijgt is groot. HAProxy is de keuze als load balancing het enige is wat de server hoeft te doen.

NGINX is primair een webserver die ook load balancing kan. Voor veel setups is dat voldoende: je combineert reverse proxy-functionaliteit met load balancing in één configuratiebestand. De syntax is toegankelijker. NGINX is de juiste keuze als je load balancer ook SSL-terminatie, statische bestanden of andere webserverfuncties moet verzorgen.

Voor grootschalige, dedicated load balancing presteert HAProxy beter. Voor geïntegreerde setups is NGINX praktischer.

SSL-terminatie bij de load balancer

Een gangbare aanpak is om SSL-verbindingen af te handelen bij de load balancer (SSL termination). De load balancer ontcijfert het HTTPS-verkeer en stuurt het onversleuteld door naar de applicatieservers op het interne netwerk. Voordelen:

• Certificaatbeheer op één plek, niet op elke server apart
• Applicatieservers hoeven geen SSL-overhead te verwerken
• Centralisatie van TLS-configuratie en cipher-beleid

Op het interne netwerk (tussen load balancer en applicatieservers) is verkeer dan niet versleuteld. In een goed geïsoleerde privénetwerkomgeving is dat acceptabel. Vereist je compliance-beleid end-to-end encryptie, dan gebruik je SSL passthrough of re-encryptie.

Health checks: de continue keuring

Een load balancer doet continu health checks op de servers achter hem. Dat kan simpel zijn (TCP-verbinding lukt) of geavanceerder (een specifiek HTTP-endpoint retourneert 200). Zodra een server niet meer reageert, wordt hij uit de rotatie gehaald totdat hij weer beschikbaar is.

Het configureren van goede health checks is een onderschatte stap. Een check die te oppervlakkig is, laat een falende server te lang in de rotatie. Een check die te zwaar is, veroorzaakt onnodige belasting. Een goede praktijk: laat de applicatie een dedicated /health-endpoint aanbieden dat ook de databaseverbinding en kritieke afhankelijkheden controleert.

Wanneer heb je load balancing nodig?

Niet elke website heeft een load balancer nodig. Een enkelvoudige server met goede caching kan heel wat verkeer aan. Load balancing wordt relevant zodra:

• Je applicatie niet meer op één server past (qua capaciteit of risico)
• Je zero-downtime deployments nodig hebt
• Piekmomenten onvoorspelbaar zijn en je auto-scaling wil inzetten
• Je hoge beschikbaarheidseisen hebt (99,9% of hoger)

Voor webshops met meer dan een paar honderd gelijktijdige bezoekers is een load balancer geen luxe meer. Het is de basis van een betrouwbare infrastructuur.

Conclusie

Load balancing is geen ingewikkeld concept, maar de implementatiedetails tellen. Algoritme, laag, health checks, sessie-afhandeling – elke keuze heeft gevolgen voor performance en beschikbaarheid. Een goed geconfigureerde load balancer is de ruggengraat van elke serieuze webomgeving.

Hulp nodig bij load balancing? Bekijk onze high-traffic oplossingen of e-commerce hosting.