Abstrakt: V éře cloud computingu a globálních digitálních služeb se vysoká dostupnost (High Availability - HA) a škálovatelnost staly základními nefunkčními požadavky každého významného systému. Uživatelé očekávají služby dostupné 24/7 a nulovou toleranci k výpadkům. Tento článek poskytuje hloubkovou analýzu principů návrhu distribuovaných systémů. Zkoumá teoretická omezení definovaná CAP teorémem a jeho rozšířením PACELC. Detailně rozebírá architektonické vzory pro eliminaci SPOF (Single Point of Failure), strategie škálování (vertikální vs. horizontální, Sharding) a techniky pro zajištění odolnosti (Resilience), jako jsou Circuit Breaker a Bulkhead. Závěrem se věnuje moderní praxi Chaos Engineeringu, která testuje odolnost systému řízeným zaváděním poruch.
---
1. Úvod: Mýtus o 100% dostupnosti
Prvním krokem k návrhu vysoce dostupného systému je přijetí faktu, že 100% dostupnost je nedosažitelná. Vždy existuje nenulová pravděpodobnost, že selže hardware, software, lidský faktor nebo fyzikální infrastruktura (překopnutý kabel, požár datacentra).
Cílem architekta není absolutní dokonalost, ale dosažení definované úrovně služeb (SLA - Service Level Agreement), která odpovídá byznysovým potřebám a nákladům.
- 99.9 % (Tři devítky): Výpadek 8.76 hodin ročně. (Standard pro běžné webové aplikace).
- 99.99 % (Čtyři devítky): Výpadek 52.56 minut ročně. (Kritické podnikové systémy).
- 99.999 % (Pět devítek): Výpadek 5.26 minut ročně. (Telekomunikace, bankovní jádra).
Každá další "devítka" zvyšuje náklady na infrastrukturu a složitost systému exponenciálně. Architektura pro 99.999 % vyžaduje geografickou redundanci, automatický failover a nulové odstávky při nasazování (Zero Downtime Deployment).
---
2. Teoretická východiska distribuovaných systémů
Distribuované systémy (systémy běžící na více počítačích propojených sítí) se chovají jinak než monolity na jednom serveru.
2.1 CAP Teorém (Eric Brewer)
CAP teorém říká, že distribuovaný systém může garantovat maximálně dvě ze tří vlastností:
- Consistency (Konzistence): Každé čtení vrátí nejnovější zapsanou hodnotu nebo chybu. (Všichni vidí to samé).
- Availability (Dostupnost): Každý požadavek dostane (bezchybnou) odpověď, bez záruky, že obsahuje nejnovější data.
- Partition Tolerance (Odolnost vůči rozdělení): Systém funguje, i když se ztratí nebo zpozdí zprávy mezi uzly (síť se rozdělí na dva ostrovy).
Realita: V distribuovaném systému (jako je cloud) se síťové výpadky dějí. P (Partition Tolerance) je tedy nutnost. Musíme si vybrat mezi CP a AP.
- CP (Consistency + Partition Tolerance): Pokud se síť rozdělí, systém odmítne odpovídat, aby nevrátil stará data. (Např. bankovní transakce - raději zamítnout platbu, než dovolit přečerpání).
- AP (Availability + Partition Tolerance): Pokud se síť rozdělí, systém odpoví, i když data mohou být zastaralá. (Např. Facebook feed - nevadí, že nevidím lajk, který jsi dal před sekundou, hlavně že se stránka načte).
2.2 PACELC Teorém
Rozšíření CAP teorému. Říká: Pokud je síť rozdělená (P), volíme mezi dostupností (A) a konzistencí (C). Else (pokud síť běží normálně), volíme mezi Latencí (rychlostí) a Conzistencí.
- Příklad: DynamoDB nebo Cassandra umožňují nastavit úroveň konzistence. Pokud chci silnou konzistenci, musím se dotázat více uzlů (Quorum), což zvyšuje latenci.
---
3. Strategie škálování (Scalability)
Škálovatelnost je schopnost systému zvládnout rostoucí zátěž přidáním zdrojů.
3.1 Vertikální škálování (Scale Up)
"Koupíme větší server." Přidáme CPU, RAM, rychlejší disky.
- Výhody: Jednoduchost. Nemusíme měnit kód aplikace.
- Nevýhody: Fyzikální limity (neexistuje server s nekonečnou RAM). Exponenciální cena high-end hardwaru. Single Point of Failure (když tento super-server spadne, stojíme).
3.2 Horizontální škálování (Scale Out)
"Přidáme více serverů." Místo jednoho silného stroje máme klastr deseti slabších.
- Výhody: Teoreticky nekonečné škálování. Lineární cena. Odolnost (když jeden server spadne, ostatní převezmou zátěž).
- Nevýhody: Složitost. Aplikace musí být navržena jako distribuovaná.
3.3 Stateless Architektura
Aby horizontální škálování fungovalo, aplikační servery musí být Stateless (bezstavové). Nesmí si pamatovat stav uživatele (Session) v lokální paměti RAM.
- Řešení: Stav se ukládá do externího sdíleného úložiště (Redis, Memcached, Databáze). Díky tomu může kterýkoliv server obsloužit kterýkoliv požadavek.
---
4. Architektonické vzory pro HA
4.1 Load Balancing (Rozložení zátěže)
Load Balancer (LB) je "dopravní policista", který stojí před farmou serverů a rozděluje příchozí požadavky.
- Algoritmy: Round Robin (kolečko), Least Connections (tomu, kdo má nejméně práce), IP Hash (stejný uživatel vždy na stejný server).
- Health Checks: Klíčová funkce. LB se pravidelně ptá serverů "Jsi naživu?". Pokud server neodpoví (nebo vrátí chybu 500), LB ho vyřadí z rotace a přestane na něj posílat provoz.
4.2 Redundance a Failover
Základní pravidlo HA: N+1 redundance. Pokud potřebuji N komponent pro provoz, musím mít alespoň N+1, aby jedna mohla selhat.
- Active-Passive: Primární server pracuje, záložní (Standby) čeká a replikuje data. Při výpadku se Standby povýší na Primary. (Nevýhoda: Platíme za hardware, který nic nedělá).
- Active-Active: Všechny servery pracují. Při výpadku jednoho se zátěž rozdělí mezi zbylé. (Efektivnější, ale složitější na synchronizaci dat).
4.3 Databázové škálování
Databáze je často úzkým hrdlem (Bottleneck).
- Read Replicas: Jeden Master pro zápis (INSERT, UPDATE), více Slaves pro čtení (SELECT). Vhodné pro aplikace, kde se více čte než zapisuje (což je 90 % webů).
- Sharding (Partitioning): Rozdělení databáze na menší kusy (Shards) podle klíče (např. UserID). Uživatelé A-M jsou na serveru 1, N-Z na serveru 2.
- Výhoda: Obrovská kapacita zápisu.
- Nevýhoda: Ztráta ACID transakcí napříč shardy. Nelze snadno udělat JOIN mezi tabulkami na různých serverech.
---
5. Vzory odolnosti (Resilience Patterns)
Jak zabránit tomu, aby selhání jedné mikroservisy shodilo celý systém (Cascading Failure)?
5.1 Circuit Breaker (Jistič)
Inspirováno elektrickým jističem. Pokud volání externí služby (např. Platební brána) opakovaně selhává (Timeout), jistič "vypadne" (Open state). Další volání jsou okamžitě zamítnuta bez čekání na Timeout. Tím se ulehčí přetížené službě a dá se jí čas na zotavení. Po čase jistič zkusí "zkušební volání" (Half-Open), a pokud projde, znovu se sepne (Closed).
5.2 Bulkhead (Vodotěsná přepážka)
Inspirováno stavbou lodí. Pokud se prorazí trup, voda zaplaví jen jednu komoru, ne celou loď. V softwaru: Vyčleníme zdroje (vlákna, connection pooly) pro konkrétní služby. Pokud se zahltí služba pro generování PDF, nevyčerpá vlákna pro přihlašování uživatelů.
5.3 Retry s Exponential Backoff
Pokud volání selže, zkusíme to znovu. Ale ne hned! (To by mohlo službu dorazit - Retry Storm). Čekáme exponenciálně déle (1s, 2s, 4s, 8s) a přidáme náhodný šum (Jitter), aby se požadavky nesynchronizovaly.
---
6. Chaos Engineering: Testování hypotéz
Tradiční testování ověřuje: "Funguje systém, když je vše v pořádku?". Chaos Engineering se ptá: "Co se stane, když vypnu databázi? Co když zvýším latenci sítě na 5 sekund?".
Tuto disciplínu zpopularizoval Netflix nástrojem Chaos Monkey, který náhodně vypínal servery v produkci.
- Princip: Zavádíme kontrolované poruchy do systému, abychom ověřili, že automatické mechanismy (Failover, Circuit Breaker) fungují správně.
- Cíl: Budovat důvěru v systém. Je lepší, když server vypne Chaos Monkey v úterý dopoledne (kdy jsou inženýři v práci), než když selže sám v neděli ve 3 ráno.
---
7. Závěr
Návrh pro vysokou dostupnost a škálovatelnost není o nákupu nejdražšího hardwaru, ale o softwarové architektuře, která počítá se selháním (Design for Failure). V cloudu je hardware komodita, která přichází a odchází. Aplikace musí být jako voda – obtékat překážky a přizpůsobovat se nádobě (infrastruktuře).
Klíčem je jednoduchost. Každá nová komponenta (cache, fronta, load balancer) zvyšuje dostupnost teoreticky, ale snižuje ji prakticky, protože přidává další bod, který se může pokazit. Umění architekta je najít rovnováhu mezi robustností a komplexitou.
---
Reference a doporučená literatura
- Kleppmann, M. (2017): Designing Data-Intensive Applications. O'Reilly Media. (Absolutní bible pro distribuované systémy).
- Beyer, B., et al. (2016): Site Reliability Engineering: How Google Runs Production Systems.
- Nygard, M. T. (2018): Release It!: Design and Deploy Production-Ready Software. (Kniha o Circuit Breakers a Bulkheads).
- Brewer, E. (2000): Towards Robust Distributed Systems (CAP Theorem).
- Abadi, D. (2012): Consistency Tradeoffs in Modern Distributed Database System Design (PACELC).
- Netflix Tech Blog: The Netflix Simian Army.
