🟡 Intermediate

Load Balancing — Rozloženie záťaže

Load balancer (LB) rozdeľuje prichádzajúcu sieťovú prevádzku medzi viacero backendových serverov. Cieľom je zvýšiť dostupnosť, výkon a škálovateľnosť aplikácií.

1. L4 vs L7 Load Balancing

Vlastnosť	L4 (Transport)	L7 (Application)
Vrstva OSI	TCP / UDP	HTTP / HTTPS / gRPC
Rozhodovanie	IP + port	URL, hlavičky, cookies, obsah
Výkon	Rýchlejší (menej inšpekcie)	Pomalší, ale inteligentnejší
Príklady	AWS NLB, HAProxy (TCP mód)	AWS ALB, Nginx, HAProxy (HTTP mód)
SSL termination	Zvyčajne nie (passthrough)	Áno — dešifruje a znova šifruje
Use case	Databázy, TCP služby, gaming	Web aplikácie, API gateway, microservices

Kedy L4? Keď nepotrebuješ rozhodovať na základe obsahu a chceš minimálnu latenciu. Kedy L7? Keď potrebuješ routing podľa URL path, host header alebo cookie-based sessions.

2. Algoritmy rozloženia záťaže

Round Robin

Požiadavky sa striedavo posielajú na každý server v poradí.

Request 1 → Server A
Request 2 → Server B
Request 3 → Server C
Request 4 → Server A  (opäť od začiatku)

✅ Jednoduchý, funguje dobre keď sú servery rovnako výkonné. ❌ Neráta s aktuálnym zaťažením servera.

Weighted Round Robin

Servery s vyšším výkonom dostanú väčšiu váhu:

server backend1 weight 3   # dostane 3x viac requestov
server backend2 weight 1

Least Connections

Požiadavka ide na server s najmenším počtom aktívnych spojení.

upstream backend {
    least_conn;
    server 10.0.0.1;
    server 10.0.0.2;
    server 10.0.0.3;
}

✅ Lepší pre dlhé spojenia (WebSocket, databázy). ❌ Overhead na sledovanie spojení.

IP Hash

Hash klientovej IP adresy určí, na ktorý server pôjde. Rovnaká IP → vždy rovnaký server.

upstream backend {
    ip_hash;
    server 10.0.0.1;
    server 10.0.0.2;
}

✅ Prirodzené sticky sessions bez cookies. ❌ Nerovnomerné rozloženie ak veľa klientov ide cez jeden NAT.

Ďalšie algoritmy

Random — náhodný výber (prekvapivo efektívny pri veľkom počte serverov)
Least Response Time — kombinácia najmenej spojení + najrýchlejšia odozva
Resource-based — na základe health check reportov (CPU, RAM)

3. HAProxy

HAProxy je open-source, vysoko výkonný L4/L7 load balancer a reverse proxy.

Inštalácia

# Debian/Ubuntu
sudo apt install haproxy

# Overenie
haproxy -v

Základná konfigurácia

# /etc/haproxy/haproxy.cfg

global
    log /dev/log local0
    maxconn 4096
    user haproxy
    group haproxy
    daemon

defaults
    log     global
    mode    http
    option  httplog
    option  dontlognull
    timeout connect 5s
    timeout client  30s
    timeout server  30s
    retries 3

frontend http_front
    bind *:80
    default_backend web_servers

backend web_servers
    balance roundrobin
    option httpchk GET /health
    server web1 10.0.0.1:8080 check inter 5s fall 3 rise 2
    server web2 10.0.0.2:8080 check inter 5s fall 3 rise 2
    server web3 10.0.0.3:8080 check inter 5s fall 3 rise 2

listen stats
    bind *:8404
    stats enable
    stats uri /stats
    stats auth admin:password123

HAProxy — kľúčové parametre

Parameter	Popis
`balance`	Algoritmus (roundrobin, leastconn, source)
`check`	Zapne health check
`inter`	Interval medzi health checkmi
`fall`	Počet zlyhaní pred označením "down"
`rise`	Počet úspechov pred označením "up"
`weight`	Váha servera
`backup`	Server sa použije len ak sú primárne down

HAProxy v TCP (L4) móde

frontend tcp_front
    bind *:3306
    mode tcp
    default_backend mysql_servers

backend mysql_servers
    mode tcp
    balance leastconn
    server db1 10.0.0.10:3306 check
    server db2 10.0.0.11:3306 check backup

4. Nginx ako Load Balancer

Nginx je primárne web server, ale výborne funguje aj ako L7 load balancer.

Základná konfigurácia

# /etc/nginx/conf.d/load-balancer.conf

upstream backend_app {
    least_conn;
    server 10.0.0.1:8080 weight=3;
    server 10.0.0.2:8080;
    server 10.0.0.3:8080 backup;
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://backend_app;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Timeouty
        proxy_connect_timeout 5s;
        proxy_read_timeout 30s;
        proxy_send_timeout 30s;
    }
}

Nginx vs HAProxy

	Nginx	HAProxy
Primárne	Web server + LB	Čistý LB/proxy
L4	Áno (stream modul)	Áno (natívne)
L7	Áno	Áno
Health checks	Pasívne (free) / Aktívne (Plus)	Aktívne (free)
Dashboard	Nginx Plus ($$$)	Zadarmo (stats page)
Výkon	Výborný	Mierne lepší pri čistom LB

5. Cloud Load Balancers

AWS

Typ	Vrstva	Use Case
ALB (Application)	L7	HTTP/HTTPS, path-based routing, gRPC
NLB (Network)	L4	TCP/UDP, ultra-nízka latencia, statická IP
CLB (Classic)	L4/L7	Legacy — nepoužívať pre nové projekty
GWLB (Gateway)	L3	Firewall, IDS/IPS appliances

# Terraform — ALB príklad
resource "aws_lb" "app" {
  name               = "app-alb"
  internal           = false
  load_balancer_type = "application"
  subnets            = var.public_subnets
  security_groups    = [aws_security_group.alb.id]
}

resource "aws_lb_target_group" "app" {
  name     = "app-tg"
  port     = 8080
  protocol = "HTTP"
  vpc_id   = var.vpc_id

  health_check {
    path                = "/health"
    healthy_threshold   = 2
    unhealthy_threshold = 3
    interval            = 30
    timeout             = 5
  }
}

GCP

HTTP(S) Load Balancer — globálny L7, anycast IP, Cloud CDN integrácia
TCP/UDP Load Balancer — regionálny L4
Internal Load Balancer — pre interný traffic vo VPC

Azure

Azure Application Gateway — L7, WAF integrácia
Azure Load Balancer — L4, interný aj verejný

6. Health Checks

Health checks overujú, či sú backend servery živé a schopné obsluhovať požiadavky.

Typy health checkov

Typ	Popis	Príklad
TCP	Overí, či je port otvorený	`check` v HAProxy
HTTP	Pošle GET request, očakáva 2xx	`option httpchk GET /health`
Custom script	Spustí externý skript	`external-check` v HAProxy
gRPC	gRPC health check protocol	ALB s gRPC target group

Best practices pre health check endpoint

// GET /health
app.get('/health', async (req, res) => {
  try {
    // Over pripojenie na DB
    await db.query('SELECT 1');
    // Over pripojenie na cache
    await redis.ping();

    res.status(200).json({
      status: 'healthy',
      timestamp: new Date().toISOString()
    });
  } catch (error) {
    res.status(503).json({
      status: 'unhealthy',
      error: error.message
    });
  }
});

⚠️ Liveness vs Readiness: Liveness = "som živý?" (reštart ak nie). Readiness = "som pripravený na traffic?" (vyraď z LB ak nie).

7. Sticky Sessions (Session Affinity)

Sticky sessions zabezpečia, že klient je vždy smerovaný na rovnaký backend server.

Kedy ich potrebuješ?

Aplikácia ukladá session do pamäte (nie do Redis/DB)
WebSocket spojenia
Uploadovanie veľkých súborov v čiastkových requestoch

Implementácia v HAProxy

backend web_servers
    balance roundrobin
    cookie SERVERID insert indirect nocache
    server web1 10.0.0.1:8080 check cookie s1
    server web2 10.0.0.2:8080 check cookie s2

Implementácia v Nginx

upstream backend {
    ip_hash;  # sticky na základe IP

    # Alebo s nginx-sticky-module:
    # sticky cookie srv_id expires=1h;

    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
}

⚠️ Anti-pattern: Sticky sessions sťažujú škálovanie. Preferuj stateless aplikácie s externým session store (Redis, DB).

8. SSL/TLS Termination

SSL termination = load balancer dešifruje HTTPS traffic a posiela plain HTTP na backend.

Client --[HTTPS]--> LB --[HTTP]--> Backend

Výhody

Backend servery nemusia spracovávať TLS → menšia záťaž
Jednoduchšia správa certifikátov (len na LB)
LB vidí obsah requestu → môže robiť L7 routing

HAProxy SSL termination

frontend https_front
    bind *:443 ssl crt /etc/ssl/certs/app.pem
    http-request set-header X-Forwarded-Proto https
    default_backend web_servers

backend web_servers
    balance roundrobin
    server web1 10.0.0.1:8080 check

SSL Passthrough

Ak potrebuješ end-to-end šifrovanie (napr. compliance požiadavky):

frontend tcp_front
    bind *:443
    mode tcp
    default_backend web_servers

backend web_servers
    mode tcp
    server web1 10.0.0.1:443 check

SSL Re-encryption

LB dešifruje, inšpektuje a znovu šifruje smerom na backend:

Client --[HTTPS]--> LB --[HTTPS]--> Backend

9. Best Practices

Architektúra

✅ Používaj minimálne 2 LB (active-passive alebo active-active) pre HA
✅ Umiestni LB do viacerých AZ (availability zones)
✅ Nastav connection draining — dokonči existujúce requesty pred vyradením servera
✅ Používaj DNS failover medzi regiónmi pre disaster recovery

Health Checks

✅ Nastav rozumné intervaly — príliš časté zaťažujú backend
✅ Používaj dedikovaný health endpoint — nie hlavnú stránku
✅ Over všetky závislosti v health checku (DB, cache, externé služby)
❌ Nepoužívaj príliš agresívne fall hodnoty — krátkodobý spike ≠ výpadok

Bezpečnosť

✅ SSL termination na LB, plain HTTP len v internej sieti
✅ Nastav rate limiting a DDoS ochranu na LB
✅ Filtruj X-Forwarded-For hlavičky — nedôveruj klientom
✅ Použi WAF (Web Application Firewall) na L7 LB

Monitoring

✅ Sleduj response time, error rate, active connections
✅ Nastav alerty na vysokú latenciu alebo error rate > threshold
✅ Loguj access logy na LB pre debugging a audit

Session Management

✅ Preferuj stateless aplikácie s externým session store
✅ Ak musíš sticky sessions → používaj cookie-based, nie IP-based
❌ Nepoužívaj sticky sessions ako náhradu za správny session management

10. Zhrnutie

                    ┌─────────────┐
    Klienti ──────► │ Load        │
                    │ Balancer    │
                    └──────┬──────┘
                           │
              ┌────────────┼────────────┐
              │            │            │
         ┌────▼───┐  ┌────▼───┐  ┌────▼───┐
         │ App 1  │  │ App 2  │  │ App 3  │
         └────────┘  └────────┘  └────────┘

Čo	Odporúčanie
Webové aplikácie	L7 LB (ALB, Nginx, HAProxy HTTP)
TCP služby	L4 LB (NLB, HAProxy TCP)
Algoritmus	`least_conn` pre väčšinu prípadov
Sessions	Stateless + Redis/DB
SSL	Termination na LB
HA	Min. 2 LB + multi-AZ
Health checks	HTTP GET /health s dependency checkmi