Na monitoru přibývají objednávky rychleji, než je stačí někdo kontrolovat. Graf návštěvnosti stoupá téměř kolmo vzhůru, telefon na stole vibruje a administrace se načítá s protivným zpožděním. Přitom nejde o žádný hackerský útok ani chybu v kódu. Jeden článek, televizní zmínka nebo časově omezená nabídka jednoduše přivedly na web víc lidí, než na kolik byl připravený.
Právě v takové chvíli se ukáže, zda web obsluhuje každý požadavek ze svého jediného serveru, nebo má část práce rozdělenou mezi síť distribuovaných serverů. CDN, tedy síť pro doručování obsahu, ukládá kopie často žádaných souborů na místa rozmístěná po světě. Návštěvník z Brna tak nemusí stahovat obrázek z datového centra na druhém konci Evropy. Dostane ho z bližšího uzlu, kterému se říká edge server.
Rozdíl člověk většinou nevnímá jako technickou revoluci. Spíš jako web, který se otevře hned, bez prázdné obrazovky a bez čekání, jestli se konečně objeví fotografie produktu. U pomalejšího připojení nebo na mobilu je ale každá zbytečná cesta dat znát. Web působí svižněji a hlavní server mezitím nemusí znovu a znovu posílat stejný obrázek, stylopis nebo soubor JavaScriptu.
Rozsah takové infrastruktury ukazuje například Amazon CloudFront. Jeho síť má více než 225 okrajových lokalit, které jsou propojené redundantními linkami s kapacitou 100 Gb/s. Pro běžného provozovatele webu to neznamená, že potřebuje vlastní globální datovou síť. Znamená to, že může využít připravenou infrastrukturu, která je navržená pro situace, kdy provoz náhle vyskočí.
CDN ale není kouzelná krabička, která zrychlí všechno. Nejlépe funguje u obsahu, který se opakuje: obrázků, videí, fontů, instalačních balíčků, skriptů nebo statických stránek. Když si stejný soubor vyžádají tisíce lidí, edge server ho nemusí pokaždé stahovat z původního webu. Po prvním doručení ho může po určitou dobu nabídnout dalším návštěvníkům ze své cache.
Naopak nákupní košík, osobní účet nebo výsledky vyhledávání se musí často generovat podle konkrétního člověka. Tady CDN pomůže spíš s přenosem, zabezpečením a rozložením provozu než s prostým uložením odpovědi. Špatně nastavené cachování může být dokonce nebezpečné: návštěvník by mohl dostat starou cenu, neaktuální stav skladu nebo v horším případě část obsahu určenou jinému uživateli. Pravidla pro to, co se ukládá a na jak dlouho, proto nejsou drobný detail v administraci, ale součást návrhu celého webu.
Dobře je to vidět u služeb, které pracují s obrovským množstvím opakovaných požadavků. Skyscanner zvládá až 1,5 miliardy API požadavků denně a u obrázků dosahuje průměrné cache-hit rate 99,99 procenta. Prakticky to znamená, že téměř každý požadavek na obrázek obslouží cache, nikoli původní server. U takového provozu by posílání každého souboru přes jediný zdroj nebylo jen drahé. Zbytečně by také spotřebovávalo jeho výkon pro úkoly, které se dají vyřešit mnohem blíž uživateli.
Podobnou zkušenost popisuje Slack, který snížil průměrnou globální latenci API z 90 na 15 milisekund. V jejich srovnání to znamenalo přibližně o 300 milisekund rychlejší odezvu. U jediné akce může jít o rozdíl, který člověk sotva pojmenuje. Při opakovaném načítání konverzací, souborů a dalších prvků se ale krátká prodleva nasčítá. Aplikace pak nepůsobí, jako by se každou chvíli rozmýšlela.
Provozovatelé webů obvykle začnou o CDN uvažovat ve třech situacích. První nastane při nárazové návštěvnosti: e-shop spustí výprodej, vydavatel zveřejní dlouho očekávaný text nebo pořadatel otevře registraci. Druhá přichází s růstem mimo domácí trh, kdy uživatelé z různých zemí čekají na obsah z jednoho vzdáleného datového centra. Třetí souvisí s náklady. Pokud původní server neustále obsluhuje velké soubory a opakované požadavky, může být levnější přesunout jejich doručování do distribuované sítě.
Příkladem je LadiPage, který přes CloudFront obsluhuje 10 miliard požadavků měsíčně. Dostupnost se po nasazení zvýšila z 96 na 99,6 procenta a náklady klesly o 10 až 15 procent. Tady CDN neřešilo jen rychlost. Pomohlo také držet službu dostupnou a omezit tlak na původní infrastrukturu.
Podobná změna nemusí znamenat dlouhou rekonstrukci celého webu. Mwave po migraci na CloudFront zlepšil výkon webu o 15 procent, snížil náklady na distribuci o 60 procent a přešel bez výpadku za méně než dva týdny. Právě obava z odstávky bývá přitom jedním z důvodů, proč se firmy do změny nepouštějí. Přechod se dá připravit postupně: nejprve se přes CDN pošlou obrázky a statické soubory, potom další části provozu.
Při plánování se vyplatí sledovat především poměr požadavků, které vyřeší cache, velikost přenášených souborů, geografické rozložení návštěvníků a cenu odchozích dat. Stejně důležitá je doba platnosti cache. Příliš krátká doba zvyšuje počet dotazů na původní server, příliš dlouhá zase může držet starý obsah. V praxi se proto často používá verzování souborů: nový obrázek nebo skript dostane nové jméno a starou kopii není třeba složitě hledat a mazat.
CDN se vyplatí tam, kde web doručuje hodně stejného obsahu, obsluhuje návštěvníky z více míst nebo musí přežít nárazové špičky bez paniky v serverovně. U malého interního webu s několika stránkami a několika desítkami návštěvníků denně může být přínos sotva patrný. Jakmile se ale provoz začne chovat jako dav u pokladny po otevření obchodu, distribuované doručování přestává být luxusem a stává se způsobem, jak udržet celý systém v chodu.
