Jak si v Livesportu automatizací ulehčujeme život

V Livesportu jsme si během let vybudovali pokročilý systém automatizace, který nám hodně ulehčuje práci. Ať už se jedná o rutinní úkony, nebo o kontroly, s tím vším nám tento systém, který neustále vyvíjíme, pomáhá. I díky němu máme víc času zkoumat a implementovat nové a pokročilejší technologie.

Na začátku byl člověk. Respektive víc lidí, kteří chtěli zobrazovat aktuální sportovní výsledky a zpravodajský servis v co nejlepší formě. Když jsme začali Livesport budovat, začínali jsme v roce 2006 více méně na zelené louce. Tehdy bylo velmi málo nástrojů pro Configuration Management (CM) a růst našeho „startupu“ byl postupný. V počátku jsme proto ani moc nemuseli řešit škálování infrastruktury a s tím spojenou hromadnou správu, která je dnes přirozenou součástí plánů většiny startupů.

Spousty věcí jsme museli řešit ručně, což znamená dělat také opakovaně stejné věci. A jestli něco většina administrátorů rozhodně nemá ráda, je to opakování čehokoliv pořád dokola.

Škálování z jednoho serveru

Nějakou dobu nám na provoz služeb stačilo pár serverů, klasický LAMP stack. Jak jsme ale rostli, museli jsme řešit víc uživatelů na stránce a tím pádem větší traffic.

Nejdřív nám tak sice stačil jeden webový server, na kterém všechno pracovalo, ale kvůli limitům hardwaru, především síťových karet, jsme velmi rychle museli přidávat další a další servery a vytvářet tak serverovou farmu, hlavně pro náš populární produkt FlashScore. 
Štábní kultura při postupném osazování racku.

Tady je asi na místě zmínit pár důležitých věcí. Naše produkty jsou mj. specifické tím, že jsou extrémně vytížené o víkendech, zatímco v týdnu jsou nároky výrazně menší. Také jsme velmi netypičtí v tom, jaké požadavky máme na rychlost a počet transakcí. Naše řešení nelze provozovat efektivně v cloudu a rovněž je problém používat různá cloudová řešení. Počet transakcí, které zpracováváme za sekundu, je příliš vysoké i pro ty největší poskytovatele. Buď to nezvládnou z technologického pohledu, nebo se jim to vůbec nevyplatí ekonomicky.

Na začátku jsme dokonce ani neměli proxy, jen webové nody za dvěma load balancery a oddělenou MySQL replikaci. Postupně ale i to přestávalo stačit a museli jsme přidávat další mezivrstvy pro cachování, oddělit backend od frontendu a rozdělit databázi na větší počet replikací. V začátcích jsme také používali hlavně open source technologie jako LVS (Linux Virtual Server) pro load balancing, kterou později nahradilo enterprise řešení. Open source je ale u nás pořád majoritně zastoupený v různých částech infrastruktury. 

Dnes už se počet serverů pouze v rámci frontend “farmy” pro FlashScore dostal na 80 a se 100% redundancí s ní dokážeme obsloužit až 800 000 rps.

Komplikace bez automatizace

Jak počet serverů rostl, začaly se projevovat problémy s tím, že jsme hodně věcí neměli dostatečně automatizované. Každý server se totiž řešil ručně, a i když jsme se snažili o jednotné prostředí, stávalo se, že se našel takový, který měl trochu jiné skripty a mírné odlišnosti. To přinášelo problémy i z toho důvodu, že už se o farmu staralo více lidí zároveň. Jeden administrátor změnil něco tady, druhý jinde a zpětné dohledávání případných změn a řešení chyb tak bylo dost zdlouhavé a komplikované. Dnes už je to něco nemyslitelného, jenže tehdy nebyl běžně dostupný nějaký CM a naše vlastní skripty nebyly dokonalé. Bylo jasné, že je nutná změna a musíme začít servery obsluhovat jinak. Obzvláště když jsme začali přidávat desítky serverů najednou a nechtěli jsme to dělat dny, nebo se z toho zbláznit.

Ruční přidávání by běžně trvalo několik dní a výsledkem by stejně byla zase trochu jiná konfigurace, třeba jen kvůli tomu, že na jednom z nich uděláte v nějakém souboru navíc mezeru. A všichni víme, jak málo někdy stačí, aby se něco rozbilo.

Boj s přirozeným strachem

Protože se Livesport zvětšoval, potřebovali jsme stále víc a víc serverů. Vzhledem k tomu, že jsme neměli připravené pořádné nástroje na hromadnou instalaci ani CM, nám ale bylo jasné, že škálování se neobejde bez obtíží.

Místo toho, abyste se těšili z růstu, vás mrazí z pomyšlení na to, co všechno za problémy přinese instalace nových serverů, na co nesmíte zapomenout, kolik postupů (checklistů) musíte dodržet a další věci. Abychom se toho strachu zbavili, byla jednotná správa a automatizace nutností, bez níž se nelze obejít.

Jenže zavádět zpětně CM, na tehdy přibližně 100 serverů, to není procházka růžovou zahradou. Stačí něco opomenout a rázem se z běžící služby stane služba nedostupná. Nebo se rozbije jenom malá část, na kterou přijdete až za pár týdnů a musíte těžce hledat příčinu. My se ale nebojíme mít strach! Naopak, pohání nás k zlepšování nejenom nástrojů a postupů, ale i sebe sama. Nutí nás k preciznosti a pedantství, a to se vyplatí. 

Jednotný CM a automatizace vás a vaše kolegy také nutí dodržet určitá pravidla. Pokud je nedodržíte s tím, že si ulehčíte práci, tak si ji paradoxně zásadně zkomplikujete.

Standardizace hardwaru

Abychom začali skutečně od podlahy, zaměřili jsme se už na samotný hardware, na kterém všechny naše servery běží. Poučeni z minulosti jsme se snažili použitý hardware co nejvíc sjednotit a standardizovat. Důvodů je několik. Každý server má stejný hardware a tím pádem i stejnou hardwarovou konfiguraci. To zjednodušuje počáteční nastavení, správu i řešení problémů a urychluje nákup.

Stejný hardware navíc znamená, že přesně víme, jaký má výkon, respektive jaké jsou jeho limity v různých úkolech. 

Nemusíme tak řešit nevyužité nebo naopak přetížené servery, protože víme, kolik toho přesně zvládnou, můžeme je monitorovat a jakmile dosáhnou známého a ověřeného limitu, přidává se jednoduše další.

Velkou část naší infrastruktury tvoří Dell servery.

Postupně jsme se dopracovali k serverům od výrobců Dell a Huawei, se kterými jsme spokojeni i z pohledu servisu dodavatele. Základem je pro nás co nejvyšší hustota výkonu na 1U. Máme proto vybraných několik specifických konfigurací serverů v kombinaci s platformou — procesor (Intel Xeon E5), operační paměť (minimálně 64 GB) a disky (SSD). Umíme tak typicky do 1U narvat 80 jader s HT a 256 GB operační paměti pro výpočetní nody, nebo 3,2 TB SSD kapacity pro databázové stroje. To samozřejmě není naše technologické maximum, ale běžná konfigurace. 

V extrémních případech jsme pak v 1U schopni mít až 144 procesorových jader, 1 TB operační paměti nebo 48 TB SSD kapacity. 

Vybrali jsme si i síťové karty, které umíme nastavit přesně pro naše potřeby a využít tak naplno výkon strojů pro naše aplikace.

Standardizovaný máme i plán pro osazování racku. Nejen že víme, do kterého z 42U můžeme osadit nový hardware, kam ho zapojit do switche a PDU, ale máme i jistotu, že rack „nepřetížíme“ a zachováme redundanci napájení, byť 7,5 kW ve 100% redundanci není málo.

Nemonitorujeme jen servery, ale i řadu veličin samotného datacentra.
Hardwarová redundance se týká všeho — serverů, bladů, switchů a dalších prvků. 

Stejně jsme postupovali i při výběru našeho datacentra, které se pyšní několika nezávislými trasami napájení (dieselové agregáty pro každou trasu jsou samozřejmostí), má několik optických tras od různých operátorů, je nad ním bezletová zóna a poskytuje další výhody, které řada jiných datacenter nemá. Je totiž zařazeno do kritické infrastruktury státu.

Zajímavostí je, že náš datový sál je jeden z prvních, které vznikly pod Žižkovským vysílačem v Českých Radiokomunikacích, a také to, že jsme si zabrali rovnou celý jeden sál. Díky tomu jsme se částečně podíleli i na samotném návrhu tohoto datového sálu z pohledu chlazení, napájení a dalších parametrů, které CRa rádi přizpůsobili našim požadavkům. Mimochodem, původní sál s 12 racky jsme v roce 2017 rozšířili na dvojnásobnou plochu a 25 racků. Také jsme vyměnili UTP mezi racky za optiku a nyní tam máme téměř 1 200 optických vláken. To všechno jsme zvládli v plném provozu datacentra a bez výpadku našich služeb. Náš uživatel tedy vůbec nic nepoznal.

Průběh rozšiřování produkčního datacentra “za běhu”.

Je důležité být paranoidní

V průběhu let jsme se pochopitelně potýkali s obrovským množstvím problémů. Samotné řešení ale nestačí, protože je jen otázkou času, kdy se stejný problém objeví v budoucnu znovu a vy ho budete muset opět řešit.

V tomto směru jsme „paranoidní“ a začali jsme problémy řešit chytře a analyticky. 

Jakmile se tedy objevil problém, našla se příčina a problém se vyřešil, následovaly také akce k tomu, aby se stejný nebo podobný incident v budoucnu neopakoval. Výpadky a problémy jsme tak začali mít svým způsobem rádi, protože se z nich učíme a díky nim vylepšujeme náš systém blíž k dokonalosti — i když je jasné, že té nelze nikdy dosáhnout.

Typickou ukázkou jsou zálohy, které máme několikavrstvé, přičemž jakmile se provede záloha, automaticky se také zkontroluje její funkčnost pomocí automatické obnovy do testovacího prostředí a navíc si ji zkopírujeme do offsite úložiště v jiné serverovně. Máme i MySQL slave databázi se zpožděním půl hodiny, ze které můžeme rychle obnovit data, pokud dojde k nějaké nečekané poruše hlavní databáze, nebo když někdo databázi omylem dropne.

Pro baterie našich UPS máme připravené místo na zdvojnásobení kapacity. Hasicí systém je dedikovaný čistě pro náš sál.

Vše musí jít přes git (původně jsme používali svn) — víme kdo, kdy, kde a jakou udělal změnu, můžeme to jednoduše a rychle vrátit do předchozího stavu a to samé dělat i automatizovaně, pokud nastane nečekaná nebo neznámá chyba.

Nové servery v provozu během pár minut

Zatímco dřív trvala instalace a zprovoznění jednoho serveru do farmy přibližně 2 hodiny, v rámci současné automatizace, kterou máme implementovanou napříč systémy, trvá instalace 50 nových čistých serverů pouhou hodinu. A to jsou servery, které už poté hned běží a vyřizují reálný traffic.

Supervisor — systém pro automatizaci instalací systémů.

Pomocí našich nástrojů jednoduše servery zapneme, nainstalujeme na ně základní systém a pak už puppet u každého nabootovaného serveru detekuje, jaký má server název a o jaký jde druh. Aplikuje předpisy, nainstaluje balíky, konfiguraci a spustí vše potřebné. Pokud jde o operační systém, používáme Debian, který máme hodně upravený „k obrazu svému“ — ano, toto je pokus o ajťácký vtip!

Dohromady máme aktuálně více než 430 fyzických serverů, z čehož je přes 130 serverů jako zálohy připravené k nasazení nebo testování, a skoro 450 nainstalovaných systémů (kontejnery nepočítáme). 

Z těchto čísel je zajímavé, že 30 % našich fyzických serverů je v záloze připraveno k okamžitému nasazení nebo pro testovací účely.

Obecně preferujeme větší počet systémů s dedikovaným výkonem podle potřeby před větším počtem aplikací na jednom systému. Dochází totiž k lepšímu rozložení, snadněji se hledají problémy a případný výpadek nezasáhne tak velkou část aplikací.

Používáme křišťálovou kouli

Abychom nemuseli všechno dokolečka kontrolovat, což je nuda a otrava, vyvinuli jsme si (a stále rozvíjíme) náš systém, vhodně pojmenovaný jako Log Check. Ten sbírá a analyzuje logy, maily nebo výstupy z kontrol ze všech možných míst, která si lze představit.

Zatímco samotný sběr je relativně jednoduchý, ta skutečná „chytrá“ část je v automatické analýze a kontrole, která nahrazuje nudnou opakovanou činnost, kterou by administrátor jinak musel dělat ručně. Kontrolní systém sám vyhodnotí a zveřejní případné problémy přehledně a jasně se seznamem nebo grafy. Člověk, který má službu, se pak zaměří na řešení případného problému.

Víc času na hraní

Díky automatizaci máme víc času na ty nejzajímavější věci a další vylepšování, prozkoumávání technologií do hloubky a zkoušení nových věcí. I když by se ale mohlo zdát, že automatizace znamená snížení odpovědnosti, je to právě naopak — jeden špatný příkaz totiž může potenciálně napáchat víc škody, takže je nutné být pečlivý.

Pokud tedy rád řešíš zajímavé problémy, zkoumáš nové technologie a řešení, které by se daly implementovat, a obecně chceš dělat hodně různorodou práci, určitě se ti u nás bude líbit. A budeme rádi, když se k nám přidáš do týmu!


Zaujalo tě, co v Livesportu děláme? Přidej se k nám!