S expanzí našeho rychlého sportovního zpravodajství do vzdálenějších lokalit začaly přicházet potíže s rychlostí. Našli jsme řešení — cluster v Kubernetes nám funguje opravdu dobře.

Livesport
Livesport
Sep 17 · 7 min read

Pokud jde o lokální trh a blízké okolí, neměli jsme nikdy problém s rychlostí, respektive dokázali jsme se stabilně zlepšovat se vzrůstajícím počtem uživatelů. Jak se ale naše platformy rozšiřovaly dál do světa, začali jsme už před mnoha lety cítit potřebu optimalizace například ve Spojených státech a dalších vzdálených zemích, kde naše servery nebyly k dispozici.

Nejdříve podrobný výzkum

Před nějakými pěti lety jsme ještě neměli tak velký globální provoz a hlavní pro nás byl evropský trh. Věděli jsme ale, že naše rychlost v zámoří není ideální a že je potřeba to změnit. Začali jsme tak jednoduše pomocí několika serverů v USA sloužících jako cache pro tamní uživatele. Ze začátku se to jevilo jako dostatečné řešení, které jsme používali až do minulého roku.

Uživatelé a partneři z jiných vzdálenějších míst na světě se však začali zmiňovat o tom, že u nich není rychlost zrovna nejlepší. Bylo jasné, že nestačí jen někde přidat pár serverů, ale potřebujeme koncepční řešení. Abychom vůbec dokázali zjistit, jak velký je problém s rychlostí načítání dat v dané lokalitě, museli jsme si vyvinout a připravit nástroje na podrobné snímání rychlosti u konkrétních uživatelů.

Do naší webové aplikace jsme si zadali měření, jak se stahuje hlavní datový feed, v němž jsou zápasy. Začali jsme měřit ze všech projektů a z celého světa — a zpomalení ve vzdálených lokalitách se nám potvrdilo.

Při spolupráci s Martinem Michálkem se nám osvědčila i dodatečná měření pomocí služby Speed Curve, která na stejných kalibrovaných zařízeních měří různé metriky v Lighthouse.

Pět minut není dost

Když už jsme věděli, že máme problém s rychlostí, přišla těžší otázka — jak tento problém vyřešit. Jako nejjednodušší se nabízelo použití nějaké CDN. CDN jsou však vhodné hlavně pro statické nebo nepříliš dynamické věci. Dynamická invalidace cache pamětí je u komerčních CDN nemožná, alespoň v současné době, kdy se nabízí garance pouze kolem 5 minut. A to jsme zkoušeli různé CDN, včetně například CDN77 nebo Cloudflare a dalších.

I když jsme CDN mohli použít pro různý statický obsah v podobě obrázků a dalších částí, čímž se zlepšila řada měřených metrik, stále jsme měli problém, jak k uživatelům rychle dostat dynamický obsah v podobě samotných dat ze zápasů. Ta se totiž mění v reálném čase a naši uživatelé oceňují právě rychlost jejich aktualizace.

Nejvíce trpěli mobilní uživatelé, a to jak na webu, tak i v samotných mobilních aplikacích, kde rovněž dochází ke stahování dat v reálném čase. Konečná volba tedy byla jasná — musíme si postavit vlastní řešení, které bude vycházet z toho, co jsme už nějakou dobu úspěšně používali v USA.

Vlastní infrastruktura a speciální úpravy

Naše infrastruktura se skládá z pasivních a aktivních proxy serverů. Pasivní proxy servery slouží hlavně k odbavení většiny uživatelů, udržují cachovaná data, která se dají použít ve spojení s CDN a není nutné je promazávat. Pasivní proxy tak drží dané spojení s uživatelem.

Tyto proxy pak komunikují s aktivní vrstvou tvořenou aktivními proxy, které drží veškerá dynamická data, jež jsme schopni dynamicky invalidovat. Vrstva pak komunikuje s backendem, popřípadě naší vlastní CDN cache.

Architektura POPu

Pro reverzní proxy používáme open source řešení Varnish 3.0.8, které ale historicky máme ošetřené vlastními patchy. Patche jsou přizpůsobené přesně pro naše potřeby a díky tomu dosahujeme několikanásobně vyššího výkonu, než umí Varnish v základu.

Výkon je po těch osmi letech z naší strany natolik optimalizovaný, že je stále nesrovnatelně lepší než u nejnovější verze Varnishe (5, 6), která změnila určité věci k horšímu (alespoň pro naše použití). V některých úlohách například nedokáže efektivně využít všechna jádra procesoru. Tím dojde velmi rychle k omezení výkonu — jedno jádro vyšplhá na 100 % využití a je konec, což se u naší optimalizované verze neděje.

Snížení počtu requestů za sekundu na backend — stejný princip používáme v naší CDN.

Optimalizace po světě

S řešením v USA jsme měli dobré zkušenosti, takže jsme se rozhodli, že bychom udělali několik takových „popů“ na různých místech světa, kde je v blízkosti větší penetrace našich uživatelů. Technické inženýry ale tenhle nápad zrovna nenadchnul.

Mít vlastní fyzické servery po celém světě je komplikované a přináší to řadu omezení z oblasti správy. Nemohou si dělat velké aktualizace, nemohou si instalovat vlastní verze systému na dálku a podobně (ne všechno jde zvládnout přes SSH). I když existuje možnost vzdálené objednávky, tak to trvá nějaký čas, což není zrovna ideální. Nešlo zkrátka o správnou cestu.

Po dlouhém přemýšlení nás napadlo, že bychom udělali cluster v Kubernetes v nějaké lokalitě. Celé řešení jsme tedy přepsali do Dockeru, nahráli ho do Kubernetes a zkusili pustit v dané lokalitě. Nakonec jsme zjistili, že tohle řešení funguje neuvěřitelně dobře.

Proč jsme zvolili cloud od Googlu

Řešení jsme stavěli obecně, takže jsme si mohli vybrat, na jakém cloudu ho budeme provozovat. Zvolili jsme cloud od Googlu, což má svůj důvod. Jako první jsme sice zkoušeli Amazon, který patří mezi jedničku v oboru hlavně kvůli počtu nástrojů a možností, ale pro nás nebyl ideální. Problém s Amazonem spočíval v tom, že když si u něho do cloudu dáte vlastní Kubernetes, musíte si sami nainstalovat a spravovat i master node.

U Googlu si v jejich Kubernetes enginu kupujete pouze virtuální hardware pro dané nody, na které si vše instalujete. Google za vás spravuje master node a dokonce si můžete říci, jakou verzi chcete, a oni se o to postarají.

První funkční verzi popu jsme nasadili v Japonsku. Okamžitě po spuštění se snížil čas doručení dat o neuvěřitelných 60 %. Byli jsme z toho překvapení, ale tím to nekončilo.

Zjistili jsme totiž, že se nedržely cache, protože jsme posílali špatné hlavičky. Proxy tak fungovaly jen jako proxy, nikoli jako reverzní proxy s cache. Jednalo se tak pouze o čistý tok dat z našich serverů tady v Česku. Proč tedy došlo ke snížení doby doručení o 60 %?

Tím důvodem byl Google, respektive jeho neuvěřitelně optimalizovaná síťová infrastruktura napříč celým světem. Jakmile si totiž dáte cokoli na Google, můžete využít Premium Tier Network. Zmíněná úspora tak byla pouze v rámci infrastruktury Googlu vs. klasického internetu.

Google má vlastní kabely pod mořem, kontinentální kabely a podobně. A po celém světě také Edge pointy, což jsou vstupní body do jejich infrastruktury. Uživatel, ať už je kdekoli, se tedy anycastuje na nejbližší edge point a v tu chvíli už všechno frčí po neuvěřitelně rychlé síti Googlu.

Když jsme ještě rychle doladili zmíněné hlavičky, snížili jsme čas doručení dat o dalších přibližně 10 %.

Stejná rychlost díky osmi lokalitám

Výsledky optimalizací se samozřejmě liší podle země, ale největšího zlepšení jsme dosáhli hlavně u uživatelů, kteří používají mobilní aplikace, respektive i mobilní web. Například v Austrálii se snížil medián času doručení dat z 1,4 sekundy na pouhých 0,18 sekundy, což je pro uživatelský zážitek ohromný rozdíl. V dané lokalitě tak naše platforma vlastně začala fungovat stejně rychle jako uživatelům v Česku.

A přesně to byl náš cíl — aby naše produkty fungovaly všem uživatelům na světě pokud možno stejně rychle. Získali jsme skvělou odezvu, partneři v daných zemích si zlepšení moc pochvalují.

Srovnání lokální livesport verze s australskou před a po optimalizaci

Naše vlastní řešení jsou aktuálně rozprostřená v rámci 8 lokalit po celém světě — v Belgii, Londýně, Bombaji, Sao Paulu, Singapuru, Jižní Karolíně, Sydney a Tokiu. V každé z nich máme minimálně čtyři servery a dle provozu, který se vzhledem ke sportovním událostem dokáže značně zvýšit, se zvládne naškálovat až na 15 serverů. Díky tomu si poradíme i s nenadálým velkým provozem a všichni naši uživatelé jsou spokojení.

Škálování je přitom velmi rychlé — virtuální stroje naskočí do minuty, přičemž se vždy pracuje s určitou rezervou — nikdy nefungujeme úplně na krev, aby náhodou ani zmíněná minuta při spouštění nového stroje případně nebyla problém.

Aktuální lokality

Pokud v dané lokalitě nemáme při skokovém zvýšení requestů dost prostředků, uživatel se automaticky přesměruje do nejbližší lokality s volnou kapacitou. Jakmile se přetížená lokalita naškáluje, uživatele začne znovu odbavovat nejbližší pop.

Naším dalším úkolem je vyladit hardware a škálování, aby nám to dávalo smysl z hlediska poměru cena/výkon. Až s tím budeme spokojení, chystáme se přesunout většinu našeho provozu do cloud POPů. Pak konečně vyzkoušíme víc providerů, čímž se chceme vyhnout vendor locku. A taky přijde na řadu multi-cloud a hybridní cloud — ale o tom až příště. :)


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

Livesport Dev

Od vývojářů pro vývojáře.

Livesport

Written by

Livesport

Livesport Dev

Od vývojářů pro vývojáře.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade