Vysoká dostupnost (High Availability)

Příklady z praxe

1. 01

   E-shop přežije pád jednoho serveru v Black Friday

   E-shop běží ve třech instancích ve dvou zónách dostupnosti za load balancerem. Během kampaně jedné instanci dojde paměť a přestane odpovídat na health check, takže ji balancer do několika sekund vyřadí z rotace. Zákazníci si výpadku nevšimnou, jen se provoz rozloží mezi zbylé dvě instance, a monitoring mezitím spustí náhradní instanci.

2. 02

   Health check, který nekontroluje jen že proces běží

   Užitečný health check ověřuje i závislosti, například dostupnost databáze. Endpoint, který vrací 200 vždy, když aplikace naběhla, udrží v rotaci instanci, jež ve skutečnosti neumí obsloužit jediný požadavek.

   app.get('/healthz', async (req, res) => {
     try {
       await db.query('SELECT 1');
       res.status(200).json({ status: 'ok' });
     } catch (err) {
       res.status(503).json({ status: 'degraded', dep: 'db' });
     }
   });

Časté omyly

MýtusMáme zálohy, takže máme vysokou dostupnost.

Ve skutečnostiZálohy patří k disaster recovery, ne k vysoké dostupnosti. Obnova ze zálohy trvá minuty až hodiny, během kterých služba nefunguje, zatímco HA znamená, že provoz převezme jiný běžící uzel bez znatelného přerušení.

MýtusCloud má dostupnost vyřešenou, stačí tam aplikaci nasadit.

Ve skutečnostiPoskytovatel garantuje dostupnost své infrastruktury, typicky až při rozložení do více zón dostupnosti. Aplikace běžící v jediné instanci v jedné zóně spadne s ní, protože SLA poskytovatele se na takové nasazení obvykle vůbec nevztahuje.

Mýtus99,9 % je skoro to samé jako 99,99 %.

Ve skutečnostiRozdíl je desetinásobný: 99,9 % povoluje asi 43 minut výpadku měsíčně, 99,99 % jen zhruba 4 minuty. Ta druhá hodnota vylučuje jakýkoli ruční zásah a vyžaduje plně automatický failover.

Časté dotazy

Jakou dostupnost má smysl si stanovit pro běžný e-shop?

Pro běžný e-shop bývá rozumným cílem 99,9 %, tedy zhruba 43 minut výpadku měsíčně. Této úrovně se dosáhne dvěma aplikačními instancemi ve dvou zónách, replikovanou databází a slušným monitoringem, což je nákladově zvládnutelné. Posun na 99,99 % obvykle znamená násobně dražší architekturu, tým se službou v pohotovosti a automatický failover databáze. Vyplatí se to teprve tehdy, když spočítaná ztráta z hodiny nedostupnosti převýší roční náklad na tu složitější variantu.

Jak se počítá dostupnost složené aplikace z více služeb?

Dostupnost série závislých komponent se násobí. Pokud požadavek musí projít přes CDN, aplikační server a databázi a každá část má 99,9 %, výsledek je přibližně 99,7 %, tedy asi dvakrát tolik výpadku, než čekáte. Redundance funguje opačně: dvě nezávislé instance téže služby s dostupností 99 % dají v paralelním zapojení zhruba 99,99 %, ovšem jen pokud jsou skutečně nezávislé a nesdílejí napájení, síť ani stejnou chybu v kódu.

Co je split brain a jak mu předejít?

Split brain je stav, kdy se po výpadku sítě rozdělí clusteru na části a v každé se nějaký uzel prohlásí za primární. Obě části pak přijímají zápisy a data se nenávratně rozejdou. Prevencí je kvórum: zápisy povolí jen ta část clusteru, která má nadpoloviční počet hlasů, k čemuž se používá lichý počet uzlů nebo pomocný arbitr. Doplňkově se nasazuje fencing, tedy tvrdé odstavení podezřelého uzlu, aby nemohl zapisovat.

Počítá se plánovaná údržba do výpadku podle SLA?

Plánovaná údržba se do měřené nedostupnosti podle většiny SLA nezapočítává, pokud ji poskytovatel oznámí předem v dohodnutém předstihu a v definovaném okně. Právě proto může být reálná zkušenost uživatele horší než číslo ve smlouvě. Při čtení SLA je dobré sledovat i to, jak se dostupnost měří (odkud, jak často, co se považuje za chybu) a jaká je sankce. Kredit ve výši několika procent měsíční platby zpravidla nepokryje skutečnou obchodní ztrátu.

Zdroje

1. High availability(otevře se v novém okně)Wikipedia
2. AWS Well-Architected Framework(otevře se v novém okně)Amazon Web Services
3. Google Cloud Architecture Framework(otevře se v novém okně)Google Cloud
4. PostgreSQL: High Availability, Load Balancing, and Replication(otevře se v novém okně)PostgreSQL Global Development Group
5. Kubernetes Documentation: Concepts(otevře se v novém okně)Kubernetes

Související pojmy

• Disaster recoveryDisaster recovery je soubor plánů, technických opatření a provozních postupů, které umožní obnovit IT služby po havárii, kyberútoku nebo jiné vážné poruše. Řeší zálohy, náhradní infrastrukturu, odpovědnosti lidí, pořadí obnovy a cíle RTO a RPO, aby organizace věděla, co zprovoznit jako první a kolik dat smí ztratit.
• Load balancerLoad balancer je síťová nebo aplikační komponenta, která rozděluje příchozí provoz mezi více serverů nebo služeb. Zvyšuje dostupnost, umožňuje škálování a chrání uživatele před výpadkem jedné instance tím, že směruje požadavky jen na cíle, které podle kontrol zdraví a zvolené strategie dokážou odpovědět.
• ACIDACID je sada čtyř vlastností databázové transakce: atomicity, consistency, isolation a durability. Zaručuje, že skupina zápisů proběhne jako jeden celek, neporuší definovaná pravidla databáze, nebude se nebezpečně míchat s jinými transakcemi a po potvrzení přežije pád systému, například při převodu peněz.
• Adaptive IconAdaptivní ikona je formát ikony aplikace na Androidu, který se místo jedné hotové bitmapy skládá z oddělených vrstev: pozadí a popředí. Systém výsledný tvar sám ořízne podle masky výrobce zařízení a může vrstvy animovat nebo přebarvit. Vývojář tak dodá jeden zdroj a launcher z něj vytvoří kruh, čtverec i squircle.
• Adresa v pamětiAdresa v paměti je číslo, kterým procesor jednoznačně označuje konkrétní buňku operační paměti, obvykle jeden bajt. Program pomocí adresy říká, odkud má data načíst nebo kam je zapsat. Adresy tvoří souvislý číselný rozsah, jehož velikost určuje šířka adresní sběrnice a architektura, typicky 32 nebo 64 bitů.
• AI agentAI agent je softwarový systém, který pomocí modelu umělé inteligence vnímá zadaný kontext, plánuje další kroky a samostatně volá nástroje nebo služby k dosažení cíle. Na rozdíl od jednorázového promptu udržuje stav úlohy, vyhodnocuje výsledky akcí a může opakovat postup, dokud nesplní zadání nebo nenarazí na limit.
• AndroidAndroid je operační systém postavený nad linuxovým jádrem, který vyvíjí Google a otevřeně uvolňuje jako projekt AOSP. Android pohání převážnou většinu chytrých telefonů, dále tablety, televize, hodinky i palubní systémy aut. Aplikace se pro něj píší hlavně v Kotlinu nebo Javě a distribuují přes Google Play i alternativní obchody.
• APIAPI je smluvené rozhraní, přes které spolu dva programy komunikují, aniž by jeden musel znát vnitřní fungování druhého. Definuje, jaké operace lze volat, jaká data se posílají a co se vrátí zpět.