Jak se staví CDN: úvod a použité komponenty

Motivace k použití CDN

Hlavní motivace pro použití CDN je jasná – zajistit rychlé a spolehlivé načítání stránek a jejích obsahu i v zahraničí. Pokud se ale staráte o provoz projektů, jejichž měsíční návštěvnost je v milionech uživatelů a provoz jenom na JS/CSS dělá desítky TB, tak se dříve nebo později dostanete do stavu, kdy vaše gigabitová přípojka na internet prostě přestane stíhat.

Webové stránky jsou obvyklé složené z dynamického a statického obsahu. Dynamický obsah obvykle zahrnuje generovaný HTML kód a data z různých API (typicky REST/SOAP/GraphQL). Statický obsah je tvořen ze souborů jako jsou javascripty, styly, obrázky, fonty či audio nebo video. Typický poměr u našich projektů je, že dynamický obsah tvoří 10 % a statický 90 % z celkového datového přenosu.

Pokud máte opravdu vysokou návštěvnost, nepomůže vám moc ani zavedení pravidla, že jsou statické soubory plošně kešovány v prohlížeči s platností jeden rok. Změna obsahu souboru pak vyžaduje soubor s novým názvem nebo nějakou „verzí“ v parametru query, abyste vynutili v prohlížeči stažení nového souboru. Pokud děláte release každých pár dní, i když používáte JS/CSS chunky, tak minimálně nějaká část JS/CSS se vykompiluje znovu a každý návštěvník si ji musí stáhnout.

Když pak ve špičce návštěvnosti dosahujete na gigabit, tak začnete řešit co dál a tím pádem se i rozhlížet po nějaké CDN.

Hlavní benefity CDN z našeho pohledu

• Rychlost pro zahraniční návštěvníky – pokud máte projekt hostovaný na serverech pouze v jedné konkrétní zemi, tím se úměrně vzdálenosti prodlužuje i doba načtení stránek. Tedy čím dále na světě, tím pomaleji na obrazovce. Důvodem je vysoká latence a nízká přenosová rychlost. Zde ale pozor – pokud máte drtivou většinu návštěvníků z ČR, ověřte si, že má váš CDN poskytovatel servery (PoPy) i v ČR. Jinak si mohou vaši primární koncoví návštěvníci po nasazení CDN naopak pohoršit.
• Rychlost pro tuzemské návštěvníky – všechny prohlížeče mají limit na max. počet souběžných požadavků na jednu IP adresu. Pokud prohlížeč může načítat obsah z více různých domén a IP adres (domain sharding), dovolí si více paralelizace a obsah se načte do prohlížeče rychleji. To je zásadní hlavně pro JS/CSS/obrázky a fonty, které jsou součástí prvotního renderování stránky. HTTP/2 s multiplexingem tento problém pomáhá řešit velmi dobře, ale pouze do jisté míry. Z reálných testů požadavků/renderování nám vychází, že i s HTTP/2 streamy, kde v jednom streamu jsou desítky souborů, je výsledné zobrazení stránky pomalejší než se zapojením CDN na jiné doméně, než samotný web.
• Snížení zátěže primárních serverů – když nemáte CDN, tak musí vaše primární servery a jejich konektivita odbavovat jak požadavky na dynamický obsah, tak i poměrně triviální requesty na statická data. To je neefektivní, protože optimální konfigurace serverů pro dynamický obsah je jiná než pro odbavování statických souborů.
• Optimalizace obsahu – dobrá CDN poskytuje i nástroje pro datovou/binární optimalizaci statického obsahu. Díky tomu se přenáší méně dat a stránky se načítají rychleji (brotli komprese, WebP a AVIF obrázky).
• Ušetření nákladů – i když je již dávno možné pořídit si skoro neomezeně „tlustou“ linku k vašim primárním serverům, skoky jsou poměrně razantní – proč si platit 10 Gbit, když nám 90 % času stačí 1 Gbit?
• Zjednodušení života DevOpsákům – pokud se detailně vypiplávají konfigurace webových a aplikačních serverů na maximální výkon i bezpečnost, tak je nutné mít k dispozici všechny možné metriky z reálného provozu. Pokud je provoz pro dynamický a statický obsah striktně oddělený, tak jsou statistiky čistější. Je tedy možné dělat lepší rozhodnutí a optimalizovat výkonnostní i bezpečnostní parametry přesně na míru konkrétnímu provozu.

Proč jsme se rozhodli pro stavbu vlastní CDN

Na trhu existuje spousta komerčních CDN, najdete je například na CDNPerf. Mezi nejznámější patří CloudFlare, Amazon CloudFront, Google, Fastly, Akamai, CDN77 či KeyCDN.

Naše projekty nejčastěji navštěvují klienti z České a Slovenské republiky. Bezkonkurenčně v takovém případě, jak funkčně, cenově i okamžitou profi podporou, vychází CDN77 od spolehlivého poskytovatele z naší kotliny. Protože v SiteOne nechceme vymýšlet kolo, koukali jsme se nejdřív, jestli by nám nevyhovoval některý z výše zmíněných poskytovatelů. Naše požadavky byly:

• 100 TB přenos měsíčně (majorita Evropa).
• Nízká latence a rychlé přenosy v ČR/SK.
• Velmi dobré pokrytí celé Evropy, dobré pokrytí Severní Ameriky a dostatečné pokrytí ostatních kontinentů.
• HTTP/2 (a rychlé nasazení HTTP/3, poté co se více standardizuje).
• Brotli komprese, která je na textové soubory ještě o 15 % – 30 % efektivnější než gzip (LZ77 + slovník).
• Automatická konverze JPG/PNG → WebP/AVIF, pokud to prohlížeč podporuje (sníží datový přenos bez znatelné ztráty kvality o 30 % až 1 000 % dle toho, jak hodně už byl optimalizovaný zdrojový JPG/PNG).
• TLSv1.3 s 0-RTT (zero round-trip) výrazně zkracuje čas komunikace prohlížečů se servery.
• API pro celkovou, ale i selektivní invalidaci cache pomocí regulárních výrazů.
• Přístup k logům a statistiky.
• 100 GB úložiště s možností pushnutí obsahu (typicky pro videa).
• Vlastní HTTPs certifikáty.

Sehnat takového poskytovatele, který většinu požadavků splňuje, nebyl problém. Potíž byla cena. U progresivních hráčů (jako je CDN77) pořídíte službu za zhruba 20 – 30 000 Kč/měsíc, u dalších lídrů na trhu s CDN začínají náklady i na 100 000 Kč/měsíc a stoupají i do násobků. Pokud s takovými částkami začnete pracovat jako s rozpočtem na stavbu vlastní CDN, začne být návratnost více než zajímavá. Na globálním trhu jsou samozřejmě i další cenově přívětiví poskytovatelé, ale obvykle je jejich pokrytí ČR/SK velmi slabé, takže je nelze doporučit pro primárně tuzemské projekty.

Spojením výše zmíněných požadavků s naším nadšením pro IT výzvy jsme došli k závěru, že si postavíme vlastní CDN. Výsledná (ale naše vlastní) CDN není zdaleka tak robustní jako u komerčních poskytovatelů, přesto ale splňuje všechny naše požadavky. Velkou výhodou je i fakt, že můžeme podle naší reálné potřeby velmi rychle škálovat, a to s nízkými náklady.

Další naší motivací pro vlastní CDN je i to, že u všech webových projektů posledních let používáme GraphQL. To na rozdíl od REST-u nejde na reverzní proxy jednoduše kešovat, protože všechno jsou POST požadavky na jeden endpoint. Samozřejmě už jsou ve světě pokusy, nicméně žádná komerční CDN sofistikovanou cache POST požadavků nenabízí. Máme typy projektů, kde by chytré selektivní kešování POST požadavků na úrovni CDN (napsané pravděpodobně v Lua) mohlo zásadně odlehčit aplikačním serverům. Pro nás je to tedy další budoucí užitečný benefit, který komerční CDN ještě dlouho nenabídnou.

Na závěr této kapitoly je nutné podotknout, že naše CDN je navržená primárně pro odbavování statických souborů a její nasazení na web nevyžaduje žádné změny v DNS origin domény. Naše CDN tedy neslouží jako proxy před naprosto všemi požadavky na web (co je obvyklý způsob nasazení komerčních CDN), pouze na statické soubory. Pro nasazení naší CDN je nutné prefixovat cesty k souborům naší hlavní CDN doménou, co se dá velmi jednoduše vyřešit i bez nutnosti zásahu do samotné aplikace, např. použitím output filtru v Nginxu (sub_filter).

Komponenty CDN

Aby naše CDN splňovala všechny požadované parametry, museli jsme nejdříve zajistit všechny komponenty i procesy, které jsou k provozu kvalitní CDN potřeba. A samozřejmě si i nějaké oblasti dostudovat. Protože pro naše projekty spravujeme více než 120 serverů, měli jsme všechno potřebné k tomu, abychom to technicky i procesně zvládli.

Následující kapitoly ve větším detailu popisují jednotlivé součásti CDN, které budete potřebovat:

• Doména – slouží hlavně pro konfiguraci GeoDNS pravidel a případné odkazování dalších domén přes CNAME.
• GeoDNS – síťová služba, která bude návštěvníky podle vašich nastavení směrovat na nejbližší servery.
• Servery – strategicky rozmístěné po světě, s cílem minimalizovat návštěvníkům latenci a maximalizovat přenosovou rychlost.
• Technologie a jejich konfigurace – odladěný operační systém a reverzní proxy s kešováním a optimalizací obsahu (brotli komprese, WebP, AVIF).
• Provozní nástroje – budete mít mnoho serverů a potřebujete vyřešit orchestraci, monitoring, metriky, logy a mnohé další.
• Pomocné aplikace – procesy na pozadí, které zajišťují např. statickou brotli kompresi nebo konverzi obrázků do WebP/AVIF.

Doména

Nejdříve si vyberte a kupte doménu druhého řádu, na které budete CDN provozovat. Ideální je vybrat si takovou doménu, kterou docílíte „cookie-less“ požadavků. Při velkém provozu se totiž počítá každý ušetřený bajt. V příkladech článku budeme využívat „cdn.cz“ a její subdoménu „moje.cdn.cz“.

Zónový soubor DNS této domény budete spravovat u poskytovatele GeoDNS, kterého/které si vyberete.

K doméně si zařiďte i SSL/TLS certifikát, ať už od Let’s Encrypt či nějaké komerční CA. Zvažte rovnou i wildcard certifikát, který vám zjednoduší život v případě, že budete využívat více subdomén. Důvěryhodné wildcard certifikáty seženete už od 40 USD/rok. Doporučuji např. ssl2buy.com a dát pár vteřin i googlení slevového kódu. Často identický certifikát od stejné CA pořídíte za 30 – 40 % ceny, než jinde.

Abyste zabránili útočníkům podvrhnout u vaší domény jiné IP adresy, zajistěte u své domény DNSSEC. Správnost konfigurace DNS si sami zkontrolujte nástrojem Zonemaster od CZ.NIC. My jsme museli u naší CDN DNSSEC dočasně deaktivovat, protože používáme dva poyktovatele DNS v režimu primary-primary (u každého z nich se GeoDNS pravidla a failovery definují jinak). V tomto režimu je nastavení DNSSEC u obou poskytovatelů obtížné, protože oba by museli sdílet i stejný privátní klíč. Zatím je pro poskytovatelé tento ruční zásah komplikovaný, ale do budoucna přislíbili, že to umožní.

Jestli budete přímo tuto doménu používat i v URL adresách nebo pouze jako hostname, abyste mohli přes CNAME směrovat na CDN jiné domény, je už jenom na vás.

GeoDNS s podporou failover

K čemu GeoDNS potřebujete

Kritickou komponentou skutečné CDN je zajímavá oblast, říkejme jí: GeoDNS. Můžete se s ní setkat i pod názvy IP intelligence, GeoIP, Geo-based routing, Latency-based routing apod.

GeoDNS je síťová služba, která zajišťuje překlad doménového jména na IP adresu/adresy, přičemž bere v potaz i místo/zemi, ze které návštěvník přichází. Pokud někoho zajímají detaily, může si je nastudovat RFC 7871 (Client Subnet in DNS Queries).

My, jako správce GeoDNS nastavení naší CDN domény, můžeme definovat různá pravidla, ze kterých kontinentů/států má provoz směrovat na jaké IP adresy (PoPy v konkrétních státech). Pro upřesnění – PoP (Point of Presence) může technicky znamenat pouze jeden server nebo více serverů, před kterými je load balancer (typicky např. HAProxy).

Protože jsme potřebovali pronajmout servery v zahraničí a u různých poskytovatelů, navíc s některými nemáme dlouholetou zkušenost, tak jsme potřebovali vyřešit garanci vysoké dostupnosti. Proto je pro nás kritickou funkčností GeoDNS i automatický failover – schopnost monitoringu dostupnosti jednotlivých PoPů a okamžité vyřazení nebo nahrazení nedostupného či nefunkčního PoPu v CDN topologii.

V praxi to vypadá tak, že se každou minutu monitoruje naše status URL na každém PoPu. Když začne selhávat z více míst najednou, automaticky se aktivuje nastavený failover scénář, který má podle našeho per-PoP uvážení 2 hlavní podoby:

• Deaktivace DNS záznamu – v takovém případě bude směrovat provoz pouze na druhý sekundární PoP v dané lokalitě (pokud existuje), nebo se začnou návštěvníci směřovat na výchozí PoPy (v našem případě všechny v ČR).
• Nahrazení IP adresy za jinou/jiné – tímto nastavením můžete říct “Když ve Francii vypadne PoP v Paříži, tak ať se místo něj směruje provoz na nedaleký PoP v Nizozemsku a kdyby nefungoval náhodou ani ten, tak na PoP v Německu”.

Vzhledem k minutovému TTL se tak reálně nefunkční PoP deaktivuje či nahradí jiným, to nejpozději do 2 – 3 minut všem koncovým návštěvníkům. Pokud ale máte pro každou lokalitu definované alespoň dva PoPy, tak si prohlížeče i s takovým výpadkem poradí a návštěvníci nemusí poznat ani ten kritický 2 – 3 minutový moment, což popisujeme v další kapitole. V případě, že máte pro nějakou lokalitu definovaný pouze jeden PoP a nemáte k němu definovaný záložní PoP, tak jsou návštěvníci z této lokality při výpadku směrování na výchozí PoPy, které jsou nastavené jako implicitní pro „ostatní svět“.

I vzhledem k minutovému TTL je nutné myslet na rychlost překladu DNS, to má taky značný vliv na rychlost načtení stránky. Doporučujeme si proto vybrat takového DNS poskytovatele, který má anycastové NS (Name Servery) po celém světě. V žebříčku rychlosti vede Cloudflare, viz. benchmarky na DNSPerf.com. S globálním DNS poskytovatelem máte jistotu, že se vaše doména přeloží za jednotky až desítky milisekund po celém světě.

S vysokou dostupností pomáhají i prohlížeče

Protože je pro nás vysoká dostupnost zásadní, využíváme nativní funkčnosti prohlížečů, které umí pracovat s faktem, že se naše CDN doména přeloží ve všech hlavních lokalitách na více IP adres u různých poskytovatelů. Reálné chování prohlížečů je pak takové, že si prohlížeč vybere náhodně jednu z IP adres a zkouší požadavky provést na ní. V případě, že je IP adresa nedostupná, tak po pár vteřinách prohlížeč zkusí jinou IP adresu.

Výpadek jedné z IP adres/serverů/poskytovatelů tak nezpůsobí nefunkčnost požadovaného obsahu. Pouze bude trvat načtení stránky o trochu déle. Dnešní prohlížeče již jsou v oblasti detekce výpadků, obnovy spojení a auto-retry logiky opravdu chytré a velmi nápomocné. Hnacím motorem této oblasti jsou zejména mobilní/přenosná zařízení, kde dochází k častým mini výpadkům kvůli přepínání konektivity mezi BTS v mobilních sítích, jejich střídání s WiFi sítěmi, atp.

Bohužel jsme zatím nedohledali žádné veřejně dostupné informace/specifikace, které by upřesnili, jak přesně jsou tyto pomocné funkcionality implementované v jednotlivých prohlížečích. Spoléháme proto pouze na vlastní testy a analýzy chování z aktuálních verzí jednotlivých prohlížečů.

Pokud máte někdo tuto jedinečnou problematiku nastudovanou, podělte se proto nejen s námi o informace v diskuzi.

Jaké poskytovatele GeoDNS vybrat?

Na výběr máte mnoho poskytovatelů GeoDNS – za zmínku stojí Amazon Route53, NS1, ClouDNS, Constellix GeoDNS, FastDNS od Akamai, EasyDNS, UltraDNS od Neustar nebo DNS Made Easy.

Kvůli vysoké dostupnosti nedoporučujeme spoléhat se pouze na jednoho DNS poskytovatele a to i když má NS servery po celém světě, s anycast IP adresami. Stejně obvykle distribuci změn řeší jeden „centrální mozek“ a jednou za pár let se vyskytnou závady, které ve finále postihnou více, či všechny NS servery najednou (reálná zkušenost z roku 2019). Proto jsme se rozhodli jít cestou redundantního primary-primary nastavení, kde veškerá GeoDNS nastavení provozujeme u dvou zcela nezávislých poskytovatelů.

Je to trošku otravné, protože protokol AXFR pro synchronizaci DNS zón GeoDNS problematiku nepodporuje, takže musíme vše spravovat ručně u dvou nezávislých poskytovatelů. Vyzkoušeli jsme šest GeoDNS poskytovatelů a i vzhledem k jejich uchopení „modelování pravidel GeoDNS“ a monitoringu si neumíme představit, že by pro GeoDNS problematiku někdo navrhl jednotnou specifikaci, aby bylo možné synchronizovat DNS zóny.

My v SiteOne jsme pro GeoDNS vybrali jako prvního poskytovatele ClouDNS, který nabízí výborné možnosti nastavení samotných „geo pravidel“ a automatického failoveru s více možnostmi chování. Poskytovatel disponuje DDoS ochranou, má anycastové IP adresy a nízkou latenci i z ČR/SK. Poskytuje i statistiky provozu a má velmi slušné limity a pricing vzhledem k počtu DNS požadavků (v základním balíčku GeoDNS je 100M dotazů měsíčně).

Velkou výhodou je nonstop chat podpora 24/7, která v řádu minut umí zodpovědět technické otázky, případně uzpůsobit cenový program na míru, a to i v případě že nezapadáte do žádného z předpřipravených balíčků.

Jako druhého DNS poskytovatele jsme si vybrali společnost Constellix (sestra DNS Made Easy), která nabízí podobné možnosti nastavení GeoDNS problematiky, monitoringu a failoveru, jako ClouDNS. Silnou stránkou Constellix je definování vah (rozkládání provozu) v některých situacích.

Zpočátku nám dost seděl i Microsoft Azure a jeho Traffic Manager, ale nakonec jsme od něj upustili, protože nám nedal možnost řídit provoz v některých zemích tak, jak jsme chtěli. Azure nás ale v oblasti DNS velmi mile překvapil cenovou politikou oproti jiným globálním cloud poskytovatelům, např. Amazonu či Google.

Za zvážení stojí i Route53 od Amazonu, která je cenově výhodnější, pokud DNS resolvují na IP adresy v AWS. Jestliže ale budete z AWS měsíčně odesílat vyšší desítky TB, potom počítejte s měsíčními náklady i ve stovkách tisících Kč. To už ale máte stejné nebo dražší jako když si pohodlně pronajmete komerční CDN.

U všech GeoDNS poskytovatelů ale platí, že se cena odvíjí zejména od počtu DNS požadavků a počtu i frekvence health-checků. Jinými slovy, od počtu PoPů, které v CDN máte, nebo z kolika míst po světě je necháte hlídat kvůli eliminování false positives a samozřejmě frekvence hlídání, která se dá nastavovat obvykle od 30 vteřin do desítek minut – naše výchozí hodnota je jedna minuta. Cenu za DNS požadavky můžete i násobně snižovat zvýšením TTL u jednotlivých DNS záznamů. Ovšem a pochopitelně na úkor rychlosti případného auto-failoveru, protože rekurzivní cache NS si budou překlady držet déle v jejich cache.

Pro největší pionýry se nabízí i varianta postavit si vlastní GeoDNS službu s vlastními name servery. Aby to ale mělo smysl a skutečnou hodnotu, bylo by potřeba anycastových IP adres. Také množství dalších spolehlivých serverů po světě s DDoS ochranou a pak pochopit, vybrat a adaptovat např. EdgeDNS či český Knot DNS (který mj. používá i Cloudflare). Komerční GeoDNS služby jsou ale relativně levné a spolehlivé, takže si neumíme představit ROI-ku, která by u vlastního nevelkého, nekomerčního řešení DNS, dávala smysl.

Servery

GEO rozložení serverů a výběr poskytovatelů

V případě, že se do stavby vlastní CDN pustíte, tak počítejte s tím, že pokud to má být skutečná CDN, budete i v tom nejmenším setupu potřebovat 8–10 serverů různě po světě. My jich máme aktuálně dvacet produkčních a tři testovací. Taky máme dva vývojové, dostupné pouze na interní síti, které mohou vývojáři používat pro nasazení CDN i na interní vývojové domény.

Hlavním cílem CDN je návštěvníkům po celém světě zajistit co nejnižší latenci a nejvyšší přenosovou rychlost k datům, které CDN lokálně kešuje.

Ideální stav je, pokud máte možnost analyzovat návštěvníky projektů, pro které CDN využijete. Jestli víte, z jakých kontinentů/států jakou návštěvnost a jaké datové přenosy odbavujete, tak se podle toho můžete strategicky rozhodnout na kterých kontinentech a do kterých států svoje PoPy umístíte.

Ze začátku nebudete mít servery v každém státě a nejspíš ani na každém kontinentu, proto zvažte „spádové oblasti“. Podle reálných měření latence a traceroute ale budete často překvapení, že latence mezi ISP v jednotlivých státech zdaleka neodpovídá geografické blízkosti. Peering mezi státy a jednotlivými ISP je různý, velmi často „soused není soused“. Např. z Finska můžete mít u některých poskytovatelů výrazně nižší latenci do Čech než do Polska. Pokud zatím v zahraničí nemáte žádné servery skrz které byste měření mohli provést, tak vám může pomoct i nástroj WonderNetwork.com. Tento nástroj ukazuje latence mezi různými městy světa, vice-versa. Je to samozřejmě poplatné využívaným ISP v tomto nástroji, nicméně pro orientaci je to dostatečné.

Při výběru poskytovatele serverů a konektivity si udělejte dobrý průzkum trhu. Cena pochopitelně není jediný ani poslední faktor, ale nesmí být ani první. My jsme se zaměřili na:

• Kvalitu a renomé poskytovatele – v každém ze států obvykle vyčnívají 2 – 3 robustní poskytovatelé, kteří by měli být nejspolehlivější. Jejich robustní infrastruktura by měla být schopná lépe odolávat případným DDoS útokům. Malé a neprověřené poskytovatele nedoporučujeme.
• Lokální a globální konektivitu poskytovatele – je třeba počítat s tím, že servery budou odbavovat objemné přenosy. Částečně ve své zemi, některé jsou spádové i pro další státy. Zaměřte se proto na nastudování a porovnání jejich konektivity do ciziny. Kvalitní poskytovatel svojí konektivitu na webu popisuje, protože je na ní obvykle hrdý. Skvěle to u nás dělá SuperHosting, u kterého máme i my 15 let část naší infrastruktury.
• Kvalitní podporu – dřív nebo později se nějaké potíže určitě objeví a je nutné reagovat rychle. Jako první test můžete zvolit komunikaci s podporou ohledně toho, jakou linku bude mít server reálně k dispozici (obvykle 100 či 1 000 Mbps), jakou má agregaci a co v jejich pojetí znamená „Unlimited traffic“. Jestli to zahrnuje i vašich odhadovaných XY terabajtů měsíčně, které daný server bude muset obsloužit. Druhý dotaz můžete směřovat k možnostem a fungování jejich DDoS ochrany.
• Očekávaný datový provoz na daném serveru by měl být ideálně v ceně, případně by měla být dopředu jasná cenová politika.

Naše CDN prozatím čítá 20 PoPů a každý je u jiného poskytovatele. Naše primární ČR/SK návštěvníky zatím pokrývá šest PoPů (4× Praha, Brno a Bratislava). Dále Německo (dva PoPy) a Polsko (dva PoPy) pro část východní a severní Evropy. Po jednom PoPu máme i ve Francii, Itálii, Anglii a Maďarsku. Dva PoPy pokrývají i Severní Ameriku. Jižní Ameriku pokrývá pouze jeden PoP v Sao Paulo. Afriku pokrývá jeden PoP v Káhiře, Austrálii jeden PoP v Sydney, Ruskou federaci jeden PoP v Moskvě a Asii pokrývá jeden PoP v Bombaji. K těmto PoPům spadají i vybrané okolní státy, kde nám to podle naměřených latencí dávalo smysl.

V další kapitole najdete i informace o tom, jak můžete různé sekundární lokality pokrýt velmi efektivně za pomocí komerční CDN, pokud vám to dá funkčně a ekonomicky smysl. U naší CDN nám to smysl dává, proto jsme většinu výše popsaných neredundantních lokalit pokryli komerční CDN a některé PoPy již máme pouze jako zálohu.

Doporučení: v každé důležité lokalitě vyberte alespoň dva nezávislé poskytovatele – v ideálním případě i s jinou zahraniční konektivitou. Snažte se docílit toho, aby se v každé lokalitě DNS překládaly alespoň na dva nezávislé PoPy (IP adresy). V případě, že by došlo k selhání jednoho z PoPů, návštěvníci nebudou muset čekat 2 – 3 minuty na DNS failover, protože to prohlížeče detekují a hned přehodí provoz na druhou IP adresu. V aktuálních verzích prohlížečů uvidíte jenom 2 – 3 vteřiny „Connecting…“ a obsah se pak okamžitě načte z druhé IP adresy.

Tip: kvalitu své CDN topologie (hlavně s ohledem na latence z různých míst ve světě) můžete testovat pomocí online nástroje MapLatency.com. Ten je skvělý v tom, že latenci měří z koncových zařízení u různých ISP, což znamená že měří reálnější latenci návštěvníků k vaší CDN, ne jen a pouze ze serverů/datacenter. Pro nás je klíčové pokrytí Evropy a to máme pro naše potřeby velmi dobré (viz. screenshot). Stejný účel splní i CDN Latency Test od CDNPerf – ten ale měří latence z datacenter, nikoliv z koncových zařízení.

Latence naší CDN v Evropě

Latence naší CDN ve světě

Využití komerční CDN pro lepší pokrytí

Určitě vás (stejně jako nás) v nějaký moment zamrzí, že návštěvníkům v odlehlých koutech světa (pro nás je to zejména Afrika, Asie, Austrálie a Jižní Amerika) nedopřejete takový komfort (latenci a přenosovou rychlost) jako v Evropě. Ale i to má svoje efektivní a jednoduché řešení.

Odlehlé kouty světa můžete pokrýt nějakým komerčním CDN poskytovatelem, který má robustní infrastrukturu a silné pokrytí i v těchto lokalitách. Protože jde o sekundární lokality se slabým provozem (stovky GB až jednotky TB měsíčně), můžete využít CDN poskytovatele s programem pay-as-you-go a měsíčně vás to vyjde na pár desítek či stovek dolarů. Na jednu stranu to může vypadat jako parazitování, ale na druhou stranu, když jsme sami zkoumali na jaké IP adresy se v různých státech resolvují komerční CDN, zjistili jsme, že někteří poskytovatelé mezi sebou v různých lokalitách sdílí vlastní infrastrukturu. Není to tedy nic neobvyklého. Všichni chceme klientům dodat maximální hodnotu, ale zároveň musíme myslet i na ekonomiku a provozní náklady.

Jak to nastavit?

• Komerční CDN vám poskytne hostname, zpravidla pod jejich doménou 3. řádu spravovanou v jejich GeoDNS (např. „mojecdn.cdn-provider.com“), na kterou můžete svojí CDN doménu skrz CNAME nasměrovat.
• U komerční CDN nastavte, aby kromě výše zmíněného hostname „poslouchala“ i na vaší doméně „moje.cdn.cz“. Budete muset zároveň nastavit SSL certifikát. Nejspíš vám poskytovatel nabídne možnost využít Let’s Encrypt, ale doporučujeme využít vlastní SSL certifikát zakoupený u veřejné CA, jednotný pro všechny PoPy. Pokud totiž budete mít v různých lokalitách různé certifikáty a navíc s krátkou platností, nebude možné využívat SSL pinning, který v některých situacích můžete potřebovat.
• U svého GeoDNS poskytovatele nasměrujte CNAME své domény ve všech sekundárních lokalitách, na hostname komerční CDN. Technicky znázorněno: nastavte to ve smyslu „(Africa) moje.cdn.cz → CNAME mojecdn.cdn-provider.com“.
• Musíte zabránit zacyklení. Nesmíte totiž komerční CDN říct, aby poslouchala na „moje.cdn.cz“ a zároveň ji nastavíte jako origin tu samou doménu. Ten Africký PoP by totiž origin z DNS resolvnul sám na sebe. Abyste zabránili takovému zacyklení, musíte si zajistit, že pár hlavních PoPů bude poslouchat i na doméně např. „moje-src.cdn.cz“ (směruje A záznamy např. na tři hlavní PoPy v EU). Jako origin pak nastavíte „moje-src.cdn.cz“, takže když PoP komerční CDN nebude mít daný soubor ve své cache, stáhne si ho z některého z hlavních PoPů v EU skrz „moje-src.cdn.cz“.
• Pokud časem ze statistik a vyúčtování zjistíte, že pro vás bude kvůli zvýšené návštěvnosti výhodnější nějakou lokalitu pokrýt svými PoPy, tak tu možnost máte vždy a nasadit to lze bez jediného výpadku.

Nevýhodou sekundárních lokalit je, že jsou velmi daleko od origin serverů a než sa cache zahřeje, je pravděpodobné, že většina prvních návštěvníků bude čekat poměrně dlouho. Proto je vhodné si připravit proces na pozadí, který bude pravidelně ze statistiky TOP požadavků pushovat tyto nejvíce dotazované soubory do storage komerční CDN. Bude tak velká šance, že vzdálení návštěvníci dokáží načíst obsah z lokálního PoPu okamžitě i přesto, že se na daném PoPu provolal poprvé.

Hardware

Pokud už máte vybrané poskytovatele, musíte si ještě vybrat z jejich nabídky konkrétní fyzický či virtuální server. To je pochopitelně závislé na vašem rozpočtu. Rozhodujte se ale i podle toho, jak je pro vás a vaše návštěvníky daná lokalita důležitá.

Pár našich ověřených doporučení

• Virtuální vs. fyzický server – toto je dost kontroverzní téma a není vhodné ho zobecňovat. Pokud vám to ekonomika dovolí, u kritických serverů zvolte raději fyzické servery, i kdyby jenom ty ze základní nabídky. Nutností jsou redundantní disky, v ideálním případě i redundantní zdroj. S fyzickým serverem obvykle dostanete 1 Gbps linku a přímé fyzické připojení přímo do ToR switche. Je mnohem nižší šance, že budete bojovat s dělením se o CPU a IO či konektivitu na fyzickém hypervisoru, kde běží stovky, v lepším případě desítky virtuálních serverů. Pokud máte štěstí, tak mají sdílenou „trubku“ o sile *×10 Gbitu, v horším případě mají 1 Gbit. U ověřených poskytovatelů se nemusíte bát ani virtuálních serverů, pouze si hlídejte agregaci a výkon (např. benchmarkem nench). Hodně vám s odstupem času napoví i sbírané metriky a to obzvláště u redundantních PoPů, které budou odbavovat ± stejný provoz (DNS round-robin). My jsme díky tomu velmi rychle odhalily velmi agresivní CPU throttling nebo volatilní IO výkon u některých poskytovatelů.
• CPU – pokud to uděláte chytře a dotáhnete správně statickou kompresi gzip a brotli, zvládnete obsloužit stovky Mbps i s 1–2 jádry CPU. Pokud ale statickou kompresi nezajistíte a budete ad-hoc komprimovat každý požadavek, potřebujete alespoň 4 – 8 jader. Je dobré volit novodobé CPU s vysokým taktem (turbo na 3 GHz+). Mimochodem, absence statické komprese je něco, co podle našich benchmarků komerčním CDN často chybí a výsledkem je, že textový obsah posílají výrazně pomaleji, než s ním.
• RAM – minimum je 1 GB, ale čím více, tím lépe. Do RAM se totiž ukládá cache filesystému (PageCache). Obvykle bude v této cache většina malých, ale nejvíce stahovaných souborů (typicky JS/CSS). Čím víc se jich vejde do RAM, tím nižší nároky máte na IOPS, takže si pak můžete bezpečněji dovolit i větší rotační HDD místo SSD. Když máte dostatek RAM, tak i se stovkami Mbps můžete mít téměř nulové IOPS na storage.
• SSD vs. HDD – pochopitelně doporučujeme SSD kvůli zvládání vysokých IOPS. Opravdová potřeba ale závisí na reálném provozu. My jsme všude preferovali SSD před vysokou kapacitou. 100 – 200 GB per-server nám postačuje. Nutné je ale zohlednit i fakt, že potřebujete logovat. Optimální je logy průběžně rotovat, posílat je na nějaké sběrné místo k dalšímu zpracování a uklízet je.
• Konektivita – je vhodné mít reálnou představu, jak velký provoz a zejména jeho špičky budete odbavovat. Pokud jde o méně důležitý PoP, tak postačí i 100 Mbps. Pokud jde ale o PoP v důležité lokalitě, tak preferujte 1 Gbps a rozkládejte zátěž mezi více PoPů (round-robin DNS, kdy se vrací více A záznamů). Dosáhnete tak celkové vyšší propustnosti a nižší zátěž konkrétních ISP, navíc s vyšší dostupností CDN jako celku. Kdo na to má rozpočet a reálnou potřebu, samozřejmě může volit 10 Gbps port, ale je potřeba počítat s vysokou cenou.

Orchestrace

Protože budete spravovat několik serverů po světě a na nich bude z 99 % identická konfigurace, potřebujete si zajistit automatizovanou instalaci, konfiguraci a hromadnou orchestraci.

My používáme a doporučujeme Ansible. Historicky jsme chvíli používali i Puppet, Chef a SaltStack, ale jedině Ansible splňuje dlouhé roky to, co potřebujeme. Za ta léta používání v něm máme přes 80 vlastních rolí, proto při přípravě každého dalšího serveru je časově nejnáročnější objednávka a čekání na aktivační e-mail. Jestli máme serverů 10 či 50, je z pohledu orchestrace jedno.

Ať už budete servery spravovat jakýmkoliv orchestračním nástrojem, doporučujeme pár věcí, které vám pomůžou eliminovat „globální výpadek“:

• Když budete deploy změn na všechny servery nasazovat hromadně, tak pozor – deploy na jednotlivé servery ať běží raději sériově, nikoliv paralelně. Případně i paralelně, ale např. po třech serverech najednou (v Ansible playbooku to řídí direktiva „serial“). V případě selhání deploye na jednom ze serverů vynuťte, aby se deploy raději přerušil (v Ansible direktiva „max_fail_percentage“).
• Před restartem/reloadem komponent nejdřív zkontrolujte validitu konfigurace (configtest). Eliminujete výpadek související s nevalidní konfigurací. Některé distribuce a jejich init skripty to nedělají automaticky. Ideální je, pokud se configtest provádí i před restartem služby, aby se zabránilo stopnutí a nenaběhnutí služby.
• V závěru deploymentu na jednotlivý server proveďte sadu testů funkčnosti CDN na tomto konkrétním serveru. Např. provoláním status URL a ideálně i provoláním nějaké funkční URL z jednoho z originů, která se vrátí z cache a taky i jednu URL, která naopak v cache nebude a bude se muset stáhnout z originu. My máme pro tyto účely i jednu „servisní“ origin doménu. Ve spojení se sériovým deploymentem tak budete mít jistotu, že nezpůsobíte výpadek na více než 1 PoPu najednou.

Konfigurace serverů a reverzní proxy (cache)

Pokud už máte zajištěné servery, čeká vás ta opravdu zajímavá a kreativní část – příprava konfigurací jednotlivých SW komponent, ze kterých je CDN složená.

V dalším článku se zaměříme na nastavení operačního systému, reverzní proxy (cache) a dalších aspektů, které s provozem CDN souvisí – optimalizaci obsahu, bezpečnost, ochranu proti útokům či nastavení, které ovlivňují chování vyhledávačů.