Česká společnost Livesport do celého světa dodává rychlé sportovní výsledky, což jen v loňském roce přineslo tržby přes 1,5 miliardy korun. Firma je finančně zdravá a i díky tomu si v Praze zcela za vlastní peníze nedávno postavila nové sídlo. Vyšlo na stovky milionů korun.
Dodávání velkého množství výsledků sportovním fanouškům s sebou nese i nároky na technologickou infrastrukturu a vývoj. Technický ředitel Livesportu Petr Burian v rozhovoru přibližuje, jak firma nad servery, sítěmi či vývojem přemýšlí, jaké technologie používá, proč běží na vlastním hardwaru, a ne v cloudu, či jak se jí daří kombinovat staré a nejnovější nástroje.
Je Livesport spíše firma točící se kolem sportu, nebo firma technologická?
Považujeme se určitě za technologickou firmu, ale i za „sporťáky“. Oba světy propojujeme.
Livesport velice rychle vyrostl. Jak zásadní bylo mít připravenou technologickou část pro škálování?
Já jsem v Livesportu jedenáct let, tedy od jeho začátku. Z dnešního pohledu jsme poněkud unikátní firma a museli jsme si vše vyšlapat. V době, kdy jsme začínali, byly běžné všechny ty free hostingy a podobně a žádné cloudy typu AWS. Nebylo možné si vzít hotové technologie a poskládat si je. S kluky kolem Livesportu jsem začal spolupracovat ještě jako dodavatel. Objednali si tehdy ode mě asi jeden, dva servery. Asi po třech týdnech provozu jsme začali řešit výkon a v tom jsme se v podstatě nezastavili několik let. Museli jsme hodně rychle reagovat na situace, které přicházely. První pětiletka byla o tom, že jsme měli řadu momentů, kdy jsme ve špičkách nezvládali odbavit provoz. Po zhruba pěti, šesti letech se situace změnila tak, že už takové problémy nebyly běžné a my mohli růst připravovat dopředu a stavět na historické zkušenosti. Firma od začátku měla vizi, že chce být globální a velká, ale moc jsme netušili, co nás všechno čeká.
Jaké takové výpadky způsobily škody?
Vzpomínám si, že jsem kamarádům u piva říkal, že točíme tisíc dotazů za sekundu. Pak to bylo deset tisíc, pořád to rostlo a dnes se pohybuje někde kolem půl milionu dotazů za sekundu. A umíme je odbavit. Hlavní špičky nastávají během hlavních soutěží fotbalu. Je to zejména konec Ligy mistrů a také špičky o víkendu, kdy se hrají anglická Premier League nebo španělské a německé ligy. To bývaly momenty, kdy uživatelé poznali, že máme problémy, služba reagovala pomalu. Bylo to vždy na pár minut. Pokud jde o finanční ztráty, to pro nás asi nikdy nebylo hlavní téma. Tím hlavním, čeho jsme chtěli dosáhnout, bylo, aby služba fungovala i ve špičkách. Na tom jsme museli zapracovat.
U modelu, že si nakupujete vlastní hardware, jste vydrželi do dnešní doby?
Jak už jsme naťukli, v době, kdy jsme začínali, jiné možnosti nebyly a vše jsme si museli udělat svépomocí. Jak jsme postupně rostli, začali jsme si uvědomovat, že jsou nové možnosti. Začali jsme je zkoumat a většinou jsme se dobrali k tomu, že tam je nějaké velké „ale“. Například se objevovaly cenové nevýhody, případně masově dostupné služby řeší potřeby většího množství zákazníků, kdežto my máme specifické potřeby. Naučili jsme se to důležité vyřešit sami. Když nám něco nefunguje, jsme sami schopní rychle kvalitu vyřešit. Na druhou stranu vidíme, že při postupném růstu a rozvoji už existují technologie, které bychom si sami dělat nemuseli a možná ani neměli. Zatím model, kdy máme co nejvíce věcí „in-house“, převládá, ale hodně se rozhlížíme, co by šlo dát ven a propojit.
Jak tedy vaše infrastruktura vypadá?
Máme vlastní serverovnu, kde používáme servery od Dellu a Huawei. Máme dva dodavatele, abychom zabránili „vendor lock-inu“. Spíše jdeme po kvalitě zařízení, než že bychom kupovali co nejlevnější servery a škálovali je, aby jich byla velká hromada. Zajímá nás vysoká hustota, takže jsme schopní do racku dát výrazně více serverů, než je běžně uváděných 42 pozic. Teoreticky dnes umíme kolem 90 serverů na rack. Prakticky se ale musíme dívat, jak jsme na tom s energiemi. Když si vezmete blade šasi, které na 10U zvládne 32 serverů, tak běžně bere 2 až 2,5 kW, ale umí také 8 kW. Takové šasi, když si tam dáš třeba tři, tak už to nevychází. Nikdo v Česku ti tolik elektřiny na jeden rack neposkytne. Hardware musíme rozumně kombinovat tak, aby různé služby byly rozložené v různých racích a dosáhlo se optimálního využití. Dobré je, že dnes máme k dispozici 25 racků, které by nám měly při vyšší hustotě osazování serverů chvíli vydržet.
Servery od Huawei se v těchto končinách běžně nevidí. Jak jste k jejich nasazování dospěli?
Historicky jsme brali servery hlavně od Dellu. Jak jsme rostli, začalo dávat stále větší smysl, abychom se poohlédli po druhém dodavateli. Zjistili jsme, že celosvětově jsou na trhu asi tři firmy, které dělají to, co potřebujeme. Huawei v té době v Čechách začínal. Je to firma, která je z Číny, což tady v Česku úplně nehraje do karet, ale zároveň nám přišlo, že se snaží a chtějí, aby to celé dávalo smysl a aby to fungovalo obchodně a z pohledu partnerského vztahu. Dlouho jsme fungovali na jednom dodavateli a při růstu jsme to příliš neřešili. Během příprav nám Huawei zapůjčil zařízení, na kterých jsme si mohli vše vyzkoušet a vyladit naše automatizační nástroje. Vše klaplo a začali jsme spolupracovat. Na Huawei nyní běžíme asi dva roky a máme od nich servery, switche a teď jsme brali i disková pole. Nevybavuji si nic zásadně negativního, co by nám nefungovalo.
Jak vypadá vaše síťová infrastruktura?
Naše řešení dnes ještě stále vypadá centralizovaně. Produkční serverovnu máme v datacentru Českých Radiokomunikací na Žižkově. Cokoliv se v datovém sálu řeší, jsme v roli částečného architekta. Zajímavé je, že 95 procent našeho provozu jde do zahraničí, ale přitom ho řešíme z Prahy. Byť provozujeme globální službu, Česko je ideální místo, odkud ji dělat. Jsme z pohledu infrastruktury vyspělí a zároveň je to zde levné. Víme, kolik stojí rack nebo konektivita třeba v Japonsku a dalších zemích a Česká republika nám vychází velice dobře.
Náš výsledkový produkt (v Česku livesport.cz) se skládá z mnoha malých souborů. Když ti jako uživateli naší služby chceme poslat aktualizaci (třeba aktuální gól), dostaneš malý feed, který je velikosti pár desítek bajtů. Takové množství informací lze dostat rozumně kamkoliv po světě, i když zde samozřejmě funguje fyzika a zmíněný gól letí do Sydney trochu déle než do Londýna. Kdybychom třeba dělali streamované video, už by to takto řešit nešlo. Jak jsme postupně rostli, zjistili jsme, že nám globální služba dobře funguje i z Prahy. Zkoušeli jsme také komerční CDN a v produkčním experimentálním módu si provozujeme vlastní CDN. Tu máme v Miami a další připravujeme v Jižní Americe a Japonsku. Je to pro nás technologický koncept a investice do budoucna, když bychom chtěli přenášet větší datové objemy, které by už z Prahy nešly řešit. Software který používáme, zkoušíme ohnout tak, aby šel používat i vzdáleně.
Jinak máme slušnou zahraniční konektivitu s garantovanou kapacitu 60 Gb/s. Řešíme to přes dva operátory, konkrétně přes České Radiokomunikace a Dial Telecom. Zatím to funguje dobře, ale uvidíme, jak to půjde dál. Vždy, když přijdeme a řekneme, že chceme přidat třeba dalších 20 Gb/s, už se zamýšlí. Peering nevyužíváme.
Je to takto udržitelné do budoucna?
Nad tím hodně přemýšlíme. Klíčové je správné rozhodnutí ve správný čas – nebýt zbrklý ani nezaspat. Hraje nám do karet i to, že jak se zlepšují servery, software a tak dále, problém se částečně řeší přirozeně. Ale určitě nastane moment, kdy budeme řešit tranzit jinak, ať už kvůli ceně, nebo že nám takovou kapacitu v ČR nikdo neprodá.
Jaké máte datové toky?
Velmi často máme opakované špičky, které trvají krátkou dobu, třeba 15 minut. V běžném provozu točíme 10 až 15 Gb/s odchozího trafficu, ve špičkách se dostáváme někam na 30 Gb/s. Těchto hodnot běžně dosahujeme a musíme mít rezervu pro krátké výkyvy, nebo kdyby se něco stalo. Ta je kolem 50 procent běžného provozu.
Z datacentra ven máme 40Gb porty. Tuto oblast řešíme vždy jednou za tři roky, kdy musíme kompletně vyměnit routování, abychom provoz utáhli. Letos v létě toto téma budeme opět otevírat. Když jsme 40Gb technologii pořizovali, 100Gb technologie byla ještě drahá. Dnes už by dávala smysl. Důležité je, že vše potřebujeme mít dvakrát, což navyšuje cenu. U všech těchto „dospěláckých“ technologií se navíc platí podpora. Cenu, kterou dáš na začátku, během tří let zaplatíš znovu.
Jak vypadá vaše storage?
Naše služba je náročná na přenosy a na výkon. Řešíme tedy procesory a podobně. Na storage služba tolik náročná není. SSD disky používáme už řadu let a věřím, že v běžné produkci žádné rotační disky už nemáme. Dříve jsme měli disky s 15 tisíci otáček, které měly velké odběry. SSD oproti nim neberou skoro nic.
K tomu mám jednu příhodu. V době, kdy jsme chtěli jít do SSD, byly tak drahé, že jsme hledali cestu, jak to zkusit jinak. Vybrali jsme si lepší desktopové SSD disky, udělali jsme si na ně destruktivní testy a měřili řadu metrik. Z toho nám vyplynulo, že tyto disky jsou použitelné celkem dobře. Výzkum probíhal asi půl roku. Z toho půlročního projektu jsme pak do serverů dávali desktopové MLC disky a věřili jsme si, že to bude fungovat. A ono to moc nefungovalo. Disky vydržely chvilku a pak jim začala výrazně klesat přenosová rychlost. Myslíme si, že disk chránil sám sebe, aby vydržel záruku. Dnes se to už běžně ví, ale tenkrát to pro nás byla novinka. SSD disky běžně dosahují rychlostí 200, 300 MB/s v sekvenčním zápisu a my jsme se dostali na hodnoty 1 až 2 MB/s. Navíc jsme na to přišli v nevhodnou dobu. Něco se nám rozbilo na databázi, potřebovali jsme rychle obnovit data, ale nešlo to, protože disky byly ukrutně pomalé. Ze serverů jsme tedy disky vyházeli a vše jsme začali řešit znovu a lépe.
Dnes používáme serverové disky a kupujeme si hlavně ty od Intelu. Máme vybraných pár typů, abychom v každém stroji neměli něco jiného. Většina serverů má lokální disky pro systém a data pro odkládání. Také databáze běží na lokálních discích. Storage používáme hlavně pro potřeby virtualizace.
Pro vás je i kvůli rychlosti důležitá RAM. Kolik paměti využíváte?
Standardně dáváme do každého serveru minimálně 64 GB RAM. U serverů, na kterých běží databáze, je paměti výrazně více – i více než 256 GB na stroj.
Dotklo se vás nějak zásadně Meltdown/Spectre?
Dotknulo se nás to tak, že z toho obecně cítíme rozčarování. A to v tom, že takový problém vůbec vzniknul a jak se komunikoval. Opravy, které vydával Intel, se nepovedly. Zranitelnosti jsou každopádně popsané – kdy k nim může dojít a kdy ne. Vzali jsme si servery, u kterých jsme cítili, že by se nás problém měl týkat, nasadili nový kernel a nechali ho běžet. Z pohledu výkonu jsme dramatický propad nezaznamenali.
Zaujal vás AMD EPYC, který se začíná pro použití v serverech jevit jako celkem zajímavá alternativa?
AMD jsme používali úplně v začátcích Livesportu. To bylo v dobách, kdy byly na trhu Opterony. A také AMD tehdy mělo výkonově navrch a zároveň procesory byly levnější než ty od Intelu. Dnes AMD nepoužíváme, ale po očku sledujeme, jak se vyvíjí situace. Pro nás je důležité, co nasazují dodavatelé jako Dell a spol., a když se u nich AMD začne víc objevovat, asi bychom to zvážili. Hardware vždy řešíme generačně.
Zamýšleli jste se někdy nad využitím vlastního open hardwaru?
Je to strašně zajímavá oblast a sledujeme ji. Ještě jsme nedorostli do takové velikosti, kdy by se nám vyplatilo něco takového aktivně řešit. Je to podobné, jako jsme mluvili o Dellu. Ten nám vždy fungoval a byli jsme spokojení, řešili jsme pouze detaily. Otevírali jsme otázky, zda bychom dodavatelů neměli mít více, ale několik let jsme tento krok odkládali. Potřebovali jsme, aby množství serverů bylo nějaké, kdy druhý vendor začne dávat smyl. V tomto ohledu jsme zatím malá firma. Věřím, že by to mohla být otázka času, kdy open hardware i pro nás začne být zajímavý jak z pohledu nákladů, tak z pohledu technologického progresu.
Jak vypadá váš softwarový „stack“?
Snažíme se jít cestou open source. Ze začátku to bylo z ekonomických důvodů, časem se nám začalo líbit spíše to, že si nástroje můžeme různě ohnout. Jsou i případy, kdy musíme jít i do hloubky daného software a věci si měnit tak, aby nám vše fungovalo, jak potřebujeme. Máme pár komerčních řešení, ale jsou to výjimky. Spojujeme tradiční ověřené technologie s těmi mladšími. Najdeš u nás věci jako Apache, PHP a MySQL, ale i novější technologie, které jsou z posledních pár let – třeba Docker, Kubernetes, GraphQL či Node.js. Kombinujeme to tak, aby vše dávalo smysl.
V minulosti jsme měli období, kdy jsme se snažili vše dělat jednou technologií. Dnes hledáme vývojáře, kteří často musí technologií zvládnout více. Jinak z každé technologie bereme to, co má silné, a tyto věci kombinujeme tak, aby nám to vše fungovalo. Například máme poměrně rádi MySQL. Ta má sice řadu problémů, ale vždy je nějak dokážeme vyřešit. Technologie je vyzrálá, není překombinovaná a lidi s ní umí dělat. V MySQL máme sportovní databázi – data, která vidíš u nás na Livesportu. A když už tě zajímají kurzy na dané zápasy, ty ukládáme do MongoDB. MongoDB používáme výrazně kratší dobu jak MySQL, takže když dojde k problému, často hledáme a řešíme, co se děje. MySQL známe hodně dobře a příčin problémů se rychle dopátráme – i proto, že jsou kolem ní lepší nástroje. Celkově dnes používáme něco přes stovku technologií.
Tak velký projekt jako Livesport jde dobře škálovat na MySQL?
Když jsem byl pod tlakem názorů zvenčí, že přeci MySQL je špatná a nemůže na tom běžet velký projekt, začal jsem zjišťovat, jak to dělají velcí hráči. Zjistil jsem, že na takových technologiích běží také. Mají je samozřejmě různě upravené a poskládané podle jejich potřeb. Když bys od MySQL potřeboval hodně zápisů v jeden moment, tak ti řeknu, že to není optimální volba. Když řešíš projekt, je důležité si říci, co vlastně potřebuješ a jaké jsou limity. MySQL si limity za poslední léta velice posunula. Před pěti, šesti lety jsme řešili, že nám MySQL na dual-core serveru běžela výrazně lépe než na quad-core serveru. Dnes už to neplatí. MySQL umí jádra dobře využít.
Sportovní databázi dnes provozujeme asi na 24 serverech. Je to kvůli vysoké redundanci a kvůli rozložení toho, co se s databází dělá. Pokud se ti to zdá hodně, je to i proto, že rozdělujeme servery na skupiny, které zpracovávají rychlé dotazy pro produkci a servery, kde běží náročné dotazy delší dobu. Pak se navzájem neovlivňují. Když máš databázi, která má 400 GB, a ty ji potřebuješ proskenovat, chvíli to trvá. Před sedmi lety jsme mysleli, že to technologicky budeme muset nějak změnit, ale nemuseli jsme. Funguje nám to dobře. Vývoj kolem MySQL rychle pokračuje a věříme, že na tom poběžíme dále.
Takže nutně nepodléháte moderním hypům?
Je to komplexní věc. Hype také nemusí být špatný. Kdybychom si dali inzerát, že sháníme lidi a děláme ve FoxPro, nikdo nám do firmy nepřijde. Na to musíme dát pozor. Kdybychom byli firma, která používá jenom PHP a MySQL, tak zde spousta lidí, které zde dnes máme, nebude. Potřebujeme to řešit tak, abychom se rozumně posouvali dopředu, ale zároveň nemusíme být hned na té první vlně. Stejně tak nemůžeme být úplně pozadu. Hodně tyto věci s kolegy řeším. Jak se firma posouvá, řadu otázek kolem technologií nechávám už na nich. Potřebuji, aby si kolegové řekli, co jim vyhovuje a co ne, a zároveň v tom mít i takovou tu moudrost a zkušenost. Když vezmeš super novou technologii, která tě bude bavit první dva měsíce, co budeme dělat, až se objeví nová super technologie? Kdo se o ni bude starat? Proto kombinujeme moderní technologie s těmi tradičními a osvědčenými, které fungují dobře a někam se posouvají. To je zároveň zásadní, aby i tradiční technologie měla své místo v dnešním světě.
V poslední době si v Livesportu hodně hrajeme s Kubernetes. Do Dockeru jsme naskočili už před lety. Dnes na něm máme především ve vývojovém stacku hromadu věcí. Šetří nám to čas. Kubernetes logicky následoval. Jsou to technologie, které mají potenciál, aby u nás byly masově nasazeny v produkci. Zároveň tyto technologie ještě musí dospět. Dnes už to potenciál má.
Jaké jsou vaše zdroje dat a jak s nimi pracujete?
Když Livesport začínal, tak si data kupoval. Nebyla jiná možnost, jak se k nim dostat. Časem jsme tuto možnost opustili, protože jsme neměli žádný vliv na kvalitu. Pouze jsme si mohli na základě chyb dojednat slevu. Sportovní data jsme si postupně začali řešit sami a dnes jsme v tom plně soběstační. Máme stoprocentní kontrolu nad kvalitou a to pro nás bylo klíčové.
Tím, že nejsme zakázková firma a děláme si vlastní projekty, se různě pereme s technologickým dluhem. Neděláme akce typu „tak to celé přepíšeme“, protože všichni vědí, jak by to celé dopadlo. Musíme se vyrovnat s tím, že kód z podstaty zastarává. Dnes kombinujeme starší programování – v našem výsledkovém servisu bys našel spoustu kódu, který jsem psal ještě já, a rozhodně bych na něj dnes nebyl pyšný – a zároveň je třeba mít nové přístupy. V týmech se dnes běžně píší mikroservisy a testy. Data do kódu dostáváme pomocí SQL procedur a API. Na „apíčka“ se zaměřujeme v posledních letech stále víc.
Narážíte na používání starších technologií u náboru lidí?
U pohovorů chceme lidem říkat, jak to u nás máme, a nenatírat věci narůžovo. Osobně jsem rád, když se uchazeči ptají, co nám nefunguje, kde jsme se spálili a co chceme zlepšit. Říkáme jim, že se u nás budou běžně střetávat i se starým kódem, a že se u nás hodně refaktoruje. Pravdou také je, že se u nás lidi hodně naučí – to beru jednoznačně jako výhodu, ale pro nováčky to znamená i to, že se budou muset hodně učit. Máme obrovskou návštěvnost z celého světa, a když děláme změny, musíme vše pohlídat. Je třeba dávat pozor na performance i kvalitu.
Jak při této komplexitě a legacy IT řešíte deploying, patchování, DevOps a podobně?
Kde začít (smích). Základ je ve vývoji. Je třeba co nejvíce věcí automatizovat. Napíšeš nějaký kód, otestuješ ho, „pushneš“ ho do „repa“, hned musí naskočit automatický „job“, který spustí třeba integrační testy, vyhodnocení a nahodí ti to na testovací server. Dnes v tomto ohledu máloco řešíme ručně. Používáme řadu automatizačních nástrojů, řadu věcí máme napojených na Jenkins, GitLab a podobně.
Co se týče produkce, potřebovali jsme sjednotit více produktů. Například FlashScore (v Čechách livesport.cz) dnes není monolit. Z části je to větší balík, ale z části je tam spousta mikroservis, které je třeba dostat do produkce. Ušli jsme velkou cestu od toho, kdy jsme přes nějaké rozhraní jednotlivé soubory někam nahrávali a příkazy řekli, že se mají rozkopírovat po clusteru. Nasazujeme tak často, jak je potřeba. Když je něco kritického, nasazujeme klidně v sobotu dopoledne. Ale máme i pravidelné větší deploy cykly. Děláme je v úterý ráno, protože už je po víkendu, kdy se hrají sportovní zápasy, a do dalšího víkendu je daleko. Znamená to, že každé úterý zveřejníme větší balík změn. Software, který používáme, se jmenuje Deploy Tool, což je věc z naší dílny hodně přizpůsobená naší architektuře.
Mluvil jsem o FlashScore – to je náš globální brand výsledkového servisu. Na řadě trhů ale používáme lokální značku (v Čechách livesport.cz, v Itálii je to třeba Diretta.it a podobně). Stejné je to také u mobilních aplikací – na různých trzích je jiná aplikace. Je to kvůli lokálním odlišnostem. Nejenom ve sportech, ale i konfiguracích nebo zavedené značce. Z toho důvodu máme značné množství mobilních aplikací – je jich přibližně 150. Nejenom že máme více značek na dvě platformy (Android, iOS), ale také vydáváme vlastní .apk, kde máme některé funkce, s kterými nemůžeme na Google Play. I zde musíme řešit automatizaci. Základ je pro všechny aplikace stejný a je to jedna code base. Poslední rok sdílíme většinu kódu mezi Androidem a iOS.
Jak to funguje, přes Xamarin?
Nešli jsme cestou nějakého frameworku, protože ty přináší velké množství omezení. Aplikace máme dělané nativním kódem. Logika se píše v čisté Javě a vzniklý „sdílitelný“ kód se následně kompiluje do obou platforem. Když potřebujeme přidat nový sport nebo přidat něco nového ve fotbale, napíšeme to tímto způsobem a následně zaintegrujeme do aplikace. Ještě asi před rokem jsme měli velké rozdíly funkčnosti mezi Androidem a iOS. Android byl napřed. Dnes se i díky tomuto přístupu tyto rozdíly téměř ztratily. O způsobu psaní sdíleného kódu nedávno hovořil kolega Pavel Cvetler na mDevTalku.
Jak u Androidu aplikace na různých zařízeních testujete?
U Androidu existuje spousta výrobců telefonů a verzí operačního systému. Aplikace uděláš sice z jedné „code base“, ale na několika přístrojích to může běžet a na dalším ne. Řešíme to tak, že máme desítky fyzických zařízení od různých výrobců a různého stáří. Na nich pouštíme naši aplikaci a automatizovaně tam provádíme testy. Představ si to jako zeď s telefony, které jsou napojené do počítače. V noci se všechny rozsvítí a začnou testovat naše „appky“. Ráno na tebe čeká report s výsledky. Vedle toho máme crash reporting z produkčních aplikací. Když zjistíme, že nám aplikace začala zlobit na nějakém exotičtějším kousku telefonu, který ještě nemáme, zařízení si pořídíme a problém vyřešíme. O tom, že něco nefunguje, se dozvídáme také přímo od lidí, kteří nám případnou chybu nahlásí.
ČLÁNKY DO MAILU