Na letošní konferenci Peering Days měl přednášku také Lee Hetherington z Facebooku. Hovořil o automatizaci provozu a o tom, jak se Facebook připravuje na velké výpadky způsobené například přírodní katastrofou. Protože je to zajímavý příběh, rozhodli jsme se vám jej převyprávět.
Facebook je dnes už celá škála produktů od sociální sítě přes Messenger, Instagram až po WhatsApp. Máme dvě miliardy uživatelů, kteří se snaží dostat svůj obsah přes Facebook,
řekl na konferenci Peering Days Lee Hetherington. Měsíčně se k Facebooku připojí 2,2 miliardy uživatelů, pokud se k tomu připočítají další zmíněné služby, jde až o 5 miliard lidí. Nejsou to samozřejmě unikátní uživatelé, ale i tak se musíte starat o obrovskou masu jednotlivých lidí, kterým vše musí fungovat.
Každou minutu projde sítí Facebooku přes milion komentářů. Připočítejte k tomu fotky, videa a další příspěvky, které se nesmí ztratit a musí být vždy dostupné.
Co se stane, když něco v takto velkém systému selže? Selhání se stávají, tohle je internet, nezbývá nám než je řešit.
Automatizace provozu
Pokud odešlete obsah směrem k Facebooku, dorazí do jednoho z datacenter. Uvnitř je komplikované softwarové prostředí skládající se z mikroslužeb. Spousta malých součástí spolu komunikuje intenzivně po síti pomocí různých rozhraní, síť je pro nás naprosto zásadní.
Všechny součásti musí fungovat, aby uživatel kdekoliv na světě zobrazil třeba obrázek.
Schéma součástí Facebooku
V takovém objemu dat a prostředků je nevyhnutelné používat automatizaci. Inženýři staví roboty, roboti spravují síť.
Facebook se snaží automatizovat všechny své postupy. Když dnes do infrastruktury připojíte novou síťovou kartu, nikdo nemusí nic udělat ručně. Karta se detekuje, zapojí do sítě a můžeme jít dál.
Automatizace samotná ale nestačí, to je jen prostředek k dosažení většího cíle.
Tím je plnohodnotný spolehlivý běh bez dalších zásahů administrátorů. Naše heslo zní: nejdřív provoz, pak nové vlastnosti.
V případě provozních problémů jde o čas a čím více lidí je do procesu řešení zapojeno, tím déle to trvá. Jak jsme rostli, kladli jsme si čím dál častěji otázku: je tu vůbec někdo, kdo zná celou naši infrastrukturu?
Jak se celý systém rozrůstá, už nemůže stát na jednotlivcích. Jak se v takovém prostředí vyrovnáte s výpadky?
Vývoj za běhu
Facebook tedy začal stavět své systémy jinak. Původně jsme se snažili chybám předcházet, pamatuji si na software, který jsme testovali 18 měsíců před nasazením do produkce.
Dnes se firma zaměřuje spíš na detekci a automatické řešení chyb. Dnes se zaměřujeme na automatizaci řešení problémů, které prostě v provozu vždy nastávají.
Postavit neselhávající řešení je v praxi nemožné. Je třeba problémy rychle detekovat a vyřešit za méně než jednu sekundu.
Jak toho dosáhnout?
Lee Hetherington na konferenci Peering Days 2019
Hlavní je změnit pohled na celou věc. Nemusíte postavit dokonalé řešení. Když v něm umíte detekovat a opravit chyby, můžete ho nasadit. Pak se z provozu poučíte a řešení vylepšíte.
Původní tvůrce je stále součástí provozu a své řešení vylepšuje, nespokojí se s prvním výsledkem, který by mohl považovat za dokonalý. Musíme se průběžně zlepšovat.
Datacentrum v cestě hurikánu
V roce 2012 prošel Spojenými státy hurikán Sandy, který způsobil rozsáhlé výpadky energie, záplavy a velkou katastrofu. Prošel jen pár kilometrů od dvou datacentrer Facebooků. Položili jsme si otázku: co by se stalo, kdyby šel trochu jižněji a zničil naše datacentrum?
V každém z datacenter běží tisíce služeb, tečou stovky terabitů dat za sekundu a spalují se desítky megawattů. Dokázali bychom běžet bez jednoho z našich datacenter? Nedokázali, naše služby by selhaly. Naštěstí šel hurikán mírně severněji.
Sandy jen těsně minula datacentrum Faceboku
Na základě této zkušenosti začalo velké plánování rozsáhlého výpadku a vznikl projekt Sandstorm. Myšlenka byla jednoduchá: vypneme jedno z našich datacenter. Prostě to celé vypneme a uvidíme, co se stane.
Od myšlenky k výsledku ale vedla velmi dlouhá cesta. Trvalo nám dva roky, než jsme se na tohle cvičení připravili.
Cílem řešení výpadku je minimalizovat jeho dopad na uživatele. Děláme to především pomocí software, jsme softwarová firma.
V rozsáhlé infrastruktuře Facebooku je potřeba všechny záchranné operace automatizovat. Nemáme čas při výpadku ve dvě ráno ručně hledat problém a měnit nastavení. Nemáme lidi, kteří se dívají v řídicím centru na velké obrazovky.
Srdcem je globální kontroler, který rozhoduje o tom, kam potečou která data. Když dojde k výpadku, může automatizovaně pomocí lokálních prvků přesměrovat tok jinou cestou nebo dokonce do jiné sítě.
Změna v zatížení linek během výpadku
Když přišlo datum vypnutí, zavolal do místnosti plné správců jejich nadřízený. Řekl mi: odvedli jste při plánování výpadku skvělou práci, ale nechcete to doopravdy vypnout, že ne? Řekl jsem mu, že opravdu chceme. Jediným způsobem, jak se můžete přesvědčit, že všechno funguje, je to opravdu vypnout.
Téměř dva roky příprav a vytváření automatizačních nástrojů byly doopravdy zakončeny vypnutím. Stalo se, co jsme předpokládali. Ostatní datacentra zvýšila své zatížení a z hlediska uživatelů všechno fungovalo dál.
Dvakrát do roka
Ze cvičení Sandstorm vyplynula spousta výstupů a zapojena do něj byla celá řada oddělení. Důležité je zapojit do toho všechny, jinak to nedokážete.
Důležité jsou také správné nástroje, bez nich se s tak rozsáhlým výpadkem nevyrovnáte. Zásadní je například sběr dat, ve kterém jsou lidé obecně velmi špatní. Musíte naučit stroje, aby vám o výpadku dodaly data k analýze.
Protože Sandstorm pomohl spoustu věcí urovnat a vyřešit, rozhodli se ho ve Facebooku opakovat.
Podobný výpadek v jednom z datacenter proběhne každých šest měsíců. Cílem je se v tom zlepšovat, zkracujeme dobu potřebnou k přípravě.
Ve Facebooku k tomu vyvinuli nový nástroj: kostku. Šéf adminů prostě dvakrát ročně hodí kostkou s názvy datacenter a dá lidem 48 hodin na to, aby ho vypnuli. Problém je, že to neškáluje. Brzy budeme mít víc než šest datacenter. Budeme muset použít generátor náhodných čísel místo kostky.
Skutečná kostka, která rozhoduje o vypnutí
Podstatné je, že pravidelné nucené odstávky pozitivně ovlivnily běh celého systému, pomohly opravdu zautomatizovat všechny procesy a zlepšily běh i v plném provozu. Naučili jsme se při tom hromadu nových věcí.
Jednou z nich je rozpoznání všech závislostí mezi systémy. Když tohle nevíte, nemůžete dobře monitorovat, jste slepí. Možná při výpadku běžíte, ale nevíte nic.
Máte například v ostatních datacenter kapacitu, aby převzala provoz? Nezjistíte to, dokud to doopravdy nevypnete.
To celé vede k vylepšování nástrojů a automatizace. Lépe rozumíme skutečnému světu a daří se nám stále se v tom zlepšovat.
Facebook chce úžeji spolupracovat s místními poskytovateli připojení, testovat různé scénáře lokálních výpadků a sledovat například přetížení záložních linek při výpadku hlavních spojů.
S přetížením se lze vyrovnat pomocí různých technik: místní keše schopné pohltit velkou část provozu, lokální peering pro zahuštění sítě a propojení s dalšími poskytovateli, regionální peering pro další rozšíření sítě a propojení s tranzitními operátory pro případ výpadku lokálních propojů. Tohle všechno dohromady nám umožňuje snížit náklady a zajistit naše služby proti výpadkům.
Co bude dál?
Postupným vylepšováním procesů se podařilo snížit dopad velkých výpadků. Z desítek minut jsme se dostali na jednotky, většina uživatelů ani nemá možnost si všimnout, že k nějakému rozsáhlému výpadku došlo.
Podařilo se to díky spolupráci s mnoha poskytovateli připojení, analýzou skutečných dat a vývojem vlastních automatizačních nástrojů. Provádíme spoustu testů, skutečně zkoušíme záložní linky, testujeme opravdové výpadky a analyzujeme data z nich.
Tady všude najdete kousek Facebooku
Tohle všechno se pravidelně děje ve velkých datacentrech, ale Facebook má na mnoha místech na světě své PoPy. To je úplně jiný příběh. Když vypnete PoP, způsobíte přelití velkého množství dat do cizích sítí.
Správci mají v plánu testovat i tyto scénáře, ale potřebují k tomu úzkou spolupráci s místními poskytovateli připojení. Musíme od nich mít podrobná data, potřebujeme vědět, jak se jejich síť chová a jak se při výpadku provoz chová.
ČLÁNKY DO MAILU