Load balancer (vyvažovač zátěže)

Proč se provoz neposílá na jeden server

Load balancer řeší situaci, kdy jedna instance aplikace nestačí výkonem, spolehlivostí nebo geografickou blízkostí k uživateli. Klient pošle požadavek na jednu známou adresu a load balancer vybere konkrétní backend: webový server, kontejner, virtuální stroj nebo službu. Aplikace se díky tomu může rozšiřovat přidáním dalších instancí, aniž by klient musel znát jejich adresy.

Rozdělování provozu není jen otázka rychlosti. Load balancer odděluje veřejný vstup do systému od vnitřních uzlů, pomáhá při nasazování nových verzí a umožňuje vyřadit porouchanou instanci bez ruční změny DNS. V cloudu bývá load balancer spravovaná služba, v Kubernetes často vzniká nad službou typu LoadBalancer.

Rozhodování o další cílové instanci

Load balancer může pracovat na různých vrstvách. Na síťové vrstvě obvykle sleduje IP adresy a porty, takže je rychlý a hodí se i pro protokoly mimo HTTP. Na aplikační vrstvě rozumí například HTTP hlavičkám, cestám URL nebo TLS terminaci, takže může posílat /api jinam než statické soubory.

Výběr backendu se řídí algoritmem. Round robin střídá cíle postupně, least connections preferuje méně vytíženou instanci a vážené směrování dovolí poslat větší část provozu na silnější server. U reálných systémů se přidávají limity, timeouty a ochrana proti tomu, aby pomalý backend dostával další požadavky jen proto, že je stále technicky dostupný.

Kontroly zdraví a vyřazení uzlu

Kontrola zdraví je pravidelný test, kterým load balancer zjišťuje, zda má backend dostávat provoz. Jednoduchý test ověří otevřený port, lepší test zavolá endpoint typu /health a zkontroluje, že aplikace zvládá odpovědět včas. Zdravý proces ale ještě nemusí znamenat zdravou službu, protože aplikace může běžet a zároveň nemít přístup k databázi.

Po selhání kontroly load balancer obvykle backend dočasně vyřadí. Návrat do provozu má být opatrný: instance po restartu může potřebovat zahřát cache, otevřít spojení nebo dokončit migrace. Příliš agresivní kontroly mohou naopak způsobit kolísání, kdy se uzel rychle vyřazuje a vrací.

Dva praktické scénáře

E-shop během kampaně

E-shop spustí slevovou akci a návštěvnost se během minut několikanásobně zvýší. Load balancer rozdělí HTTP požadavky mezi deset aplikačních serverů a nemocnou instanci přestane používat po neúspěšných health checkech. Zákazník si většinou nevšimne, že jeden server spadl, protože další požadavek obslouží jiný backend.

Kubernetes služba pro webové API

Tým provozuje API v několika podech a nechce ručně vystavovat každý pod do internetu. Kubernetes Service typu LoadBalancer požádá cloudovou platformu o externí load balancer a směruje provoz na dostupné pody. Ukázka vynechává detaily zabezpečení, ale ukazuje základní záměr:

apiVersion: v1
kind: Service
metadata:
  name: orders-api
spec:
  type: LoadBalancer
  selector:
    app: orders-api
  ports:
    - port: 80
      targetPort: 8080

Kde load balancer nestačí

Load balancer nezachrání aplikaci, která neumí běžet ve více instancích. Stav uložený jen v paměti jednoho serveru může rozbít přihlášení, košík nebo rozpracovaný formulář. Řešením bývá sdílené úložiště relací, tokeny, externí cache nebo návrh služby tak, aby byla bezstavová.

Samotný load balancer také nesmí být jediným kritickým bodem. Produkční architektura proto řeší redundanci load balanceru, více zón dostupnosti, monitoring, logování a kapacitní rezervu. Bez těchto vrstev se problém jen přesune z aplikačního serveru na vstupní komponentu.